Allow role selection for association requests

[stefan-hubert-bl]

Context: dicom_ul::ClientAssociation

Why: In order to implement C-Get (client) in a way conforming to DICOM Standard, there needs to be proper configuration of role selection in the A-ASSOCIATE-RQ. This seems to be specifically required/important for C-Get (as opposed to C-Store or C-Find), because, as far as I understand, for C-Get the AE that requests the association (the client) wants to use the association as SCU for the C-Get service class, but at the same time as SCP for the C-Store sub operations that it wishes to come back. Our verification with dcmqrscp (command line tool of https://dicom.offis.de/en/dcmtk) showed, that it does not properly serve C-Get operations without the association request declaring the roles accordingly, but did successfully served them when role selection was configured (we were using a locally patched version of dicom-ul with the requested feature added).

What: I wish I could use ClientAssociation[Options] to configure role selection, so that A-ASSOCIATE-RQ is sent with role selection configured.

Background/References

• CP/SCU Role Selection Negotiation
• C-GET Operation

[stefan-hubert-bl]

In preparation for my upcoming pull request, let's set expectations of what I am about to propose:

• I only aim for allowing ClientAssociationOptions to configure and to transport the role selection information with the association requests.
• I am NOT aiming for implementing the server side association to make use of the role selection (because I am not planning to implement a c-get service provider here, just to enable implementing c-get service users)
• Still (at least for testing) I make server side associations read the requested role selection user items so they are sent back as is (i.e. accept as requested) with the server's association acknowledge.
• As an effect, both client side and server side Association store the role selection information as user_variables: server (association acceptor) as requested by client (association requestor), and the client as acknowledged by the server.

[pgimeno4d]

I already have a patch ready for this feature, both client and server side, which is implemented on top of the Negotiation trait defined in #734.

It's not possible for the library to implement the semantics of role handling, because it does not deal with commands,just raw data in the form of PDVs (arrays of bytes). It's the application's responsibility to read and make use of these.

[stefan-hubert-bl]

@pgimeno4d: Great, sorry I didn't previously understand that you already working on that. In case you're still interested in what I attempted so far, find it there: stefan-hubert-bl#1 . Looking forward to see and use yours.

[pgimeno4d]

Thanks, here's my version. It's the last commit only, but it's based on the previous 3 commits for the Negotiation trait.

https://github.com/pgimeno4d/dicom-rs/commits/implement-role-negotiation

[stefan-hubert-bl]

@pgimeno4d:

https://github.com/pgimeno4d/dicom-rs/commits/implement-role-negotiation

Thanks for sharing. As of what I could understand from looking at your change, this would perfectly serve our needs (client side can configure role selection). So I am looking forward to seeing this upstream.

[pgimeno4d]

@stefan-hubert-bl Indeed. Your patch and mine essentially do the same thing, except that instead of the server blindly accepting whatever the client proposes (by returning the same as the client sent) during the negotiation, said negotiation is performed through a callback that the server can set, giving it a chance to reject some, which is the whole point of the existence of these user variables. The only problem is that it depends on a previous PR (#734) to be accepted, which implements the trait that allows the callbacks to be defined. The purpose of having that negotiation and the default values is not very clear to me, but whatever; it's just one of these rarities of the standard.

My patch is a bit more "anarchic-style" than yours in that it uses bools instead of enums and tuples instead of structs, but that's something I'm willing to change if Enet4 deems that unacceptable.

I'd even suggest you to send the patch with a caveat that there's no negotiation and the server accepts whatever the client sends, as the negotiation can be added in a later PR. Depends on how much of a hurry you are in to see this feature implemented, as maybe Enet4 can review it more easily if it's independent of #734.

[stefan-hubert-bl]

@pgimeno4d: thanks for your thoughts.... not being in a hurry (currently making progress with using a locally patched version in our workspace)... just wanted to make sure there are good chances to see this upstream at at some point.... Will be monitoring what's happening here, still.