D.3.2 Presentation Contexts Negotiation
A Presentation Context defines the presentation of the data on an Association. It provides a lower level of negotiation and one or more Presentation Contexts can be offered and accepted per Association.
A Presentation Context consists of three components, a Presentation Context ID, an Abstract Syntax Name, and a list of one or more Transfer Syntax Names.
Only one Abstract Syntax shall be offered per Presentation Context. However, multiple Transfer Syntaxes may be offered per Presentation Context, but only one shall be accepted.
For each SOP Class or Meta SOP Class a Presentation Context must be negotiated such that this Presentation Context supports the associated Abstract Syntax and a suitable Transfer Syntax. Presentation Contexts will be identified within the scope of a specific Association by a Presentation Context ID.
Figure D.3-1 provides an illustration of Presentation Context Negotiation with the key points as follows:
-
the Association-requestor may offer multiple Presentation Contexts per Association.
-
each Presentation Context supports one Abstract Syntax (related to a SOP Class or Meta SOP Class) and one or more Transfer Syntaxes.
-
the Association-acceptor may accept or reject each Presentation Context individually.
-
the Association-acceptor selects a suitable Transfer Syntax for each Presentation Context accepted.
D.3.3 DICOM Application Association Information
Peer DICOM AEs negotiate, at Association establishment, a number of features related to the DIMSE protocol by using the ACSE User Information Item of the A-ASSOCIATE request. This Section discusses these features.
When the Association is established between peer DIMSE Service Users the Kernel Functional Unit shall be assumed; therefore, the Kernel Functional Unit shall not be included in the A-ASSOCIATE User Information item.
D.3.3.1 Maximum Length Application PDU Notification
The Maximum Length notification allows communicating AEs to limit the size of the data for each P-DATA indication. Each DICOM AE defines the maximum PDU size it can receive on this Association. Therefore, different maximum lengths can be specified for each direction of data flow on an Association. This notification is required. Figure D.3-2 illustrates the Maximum Length notification.
Note
For complete specification see PS3.8.
D.3.3.2 Implementation Identification Notification
The implementation identification notification allows implementations of communicating AEs to identify each other at Association establishment time. It is intended to provide respective (each network node knows the other's implementation identity) and non-ambiguous identification in the event of communication problems encountered between two nodes. This negotiation is required.
Implementation identification relies on two pieces of information:
The Implementation Class UID identifies in a unique manner a specific class of implementation. Each node claiming Conformance to this Standard shall be assigned an Implementation Class UID to distinguish its implementation environment from others. Such Implementation Class UIDs shall be registered by the implementing organization per the policies defined in PS3.5. This Standard does not specify the policies associated with assigning such a UID.
Different equipment of the same type or product line (but having different serial numbers) shall use the same Implementation Class UID if they share the same implementation environment (i.e., software).
The notification by Association requestors and acceptors of their respective Implementation Class UID is required for all implementations conforming to this Standard. Figure D.3-3 illustrates the Implementation Class UID notification.
In addition to the Implementation Class UID, an option is provided to convey an Implementation Version Name of up to 16 characters,
which identifies a version of an implementation for an Implementation Class UID.
Figure D.3-4 illustrates the Implementation Version Name notification.
This Standard does not specify the structure and policies associated with such an Implementation Version Name.
The absence of the Implementation Version Name requires that the use of the same Implementation Class UID by two nodes guarantees that these use the same version of implementation.
Note
-
As the UID shall not be parsed (their structure is not intended to convey any semantic significance beyond uniqueness), this optional Implementation Version Name provides an adequate mechanism to distinguish two versions of the same implementation (same Implementation Class UID).
-
It is expected that if the Implementation Version Name is present, it will will include version information in addition to the name of the implementation.
The Implementation Version Name is expected to be more specific than the Implementation Class UID, and not less;
i.e., the Implementation Version Name will not have the same value when there are different values of the Implementation Class UID.
D.3.3.2.1 Implementation Class UID Sub-Item Structure (A-ASSOCIATE-RQ)
The Implementation Class UID Sub-Item shall be made of a sequence of mandatory fixed length fields followed by a variable field. Only one Implementation Class UID Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-RQ. Table D.3-1 shows the sequence of the mandatory fields.
Table D.3-1. Implementation Class UID Sub-Item Fields (A-ASSOCIATE-RQ)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
52H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Implementation-class-uid field. It shall be encoded as an unsigned binary number.
|
5-xxx
|
Implementation-class-uid
|
This variable field shall contain the Implementation-class-uid of the Association-requestor as defined in Section D.3.3.2. The Implementation-class-uid field is structured as a UID as defined in PS3.5.
|
D.3.3.2.2 Implementation Class UID Sub-Item Structure (A-ASSOCIATE-AC)
The Implementation Class UID Sub-Item shall be made of a sequence of mandatory fixed length fields followed by a variable field. Only one Implementation Class UID Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-AC. Table D.3-2 shows the sequence of the mandatory fields.
Table D.3-2. Implementation UID Sub-Item Fields (A-ASSOCIATE-AC)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
52H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Implementation-class-uid field. It shall be encoded as an unsigned binary number.
|
5-xxx
|
Implementation-class-uid
|
This variable field shall contain the Implementation-class-uid of the Association-acceptor as defined in Section D.3.3.2. The Implementation-class-uid field is structured as a UID as defined in PS3.5.
|
D.3.3.2.3 Implementation Version Name Structure (A-ASSOCIATE-RQ)
The Implementation Version Name Sub-Item shall be made of a sequence of mandatory fixed length fields followed by a variable field. Only one Implementation Version Name Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-RQ. Table D.3-3 shows the sequence of the mandatory fields.
Table D.3-3. Implementation Version Name Sub-Item Fields (A-ASSOCIATE-RQ)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
55H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Implementation-version-name field. It shall be encoded as an unsigned binary number.
|
5-xxx
|
Implementation-version-name
|
This variable field shall contain the Implementation-version-name of the Association-requestor as defined in Section D.3.3.2. It shall be encoded as a string of 1 to 16 ISO 646:1990 (basic G0 set) characters.
|
D.3.3.2.4 Implementation Version Name Structure (A-ASSOCIATE-AC)
The Implementation Version Name Sub-Item shall be made of a sequence of mandatory fixed length fields followed by a variable field. Only one Implementation Version Name Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-AC. Table D.3-4 shows the sequence of the mandatory fields.
Table D.3-4. Implementation Version Name Sub-Item Fields (A-ASSOCIATE-AC)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
55H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Implementation-version-name field. It shall be encoded as an unsigned binary number.
|
5-xxx
|
Implementation-version-name
|
This variable field shall contain the Implementation-version-name of the Association-acceptor as defined in Section D.3.3.2. It shall be encoded as a string of 1 to 16 ISO 646:1990 (basic G0 set) characters.
|
D.3.3.3 Asynchronous Operations (And Sub-Operations) Window Negotiation
The Asynchronous Operations Window is used to negotiate the maximum number of outstanding operation or sub-operation requests (i.e., command requests) for each direction. The synchronous operations mode is the default mode and shall be supported by all DICOM AEs. This negotiation is optional.
The Association-requestor conveys in the A-ASSOCIATE request:
-
when negotiating the SCU role for operations, the maximum number of outstanding operations it may invoke asynchronously; when negotiating the SCP role for operations, the maximum number of outstanding sub-operations it may invoke asynchronously; when negotiating the SCP role for notifications, the maximum number of notifications it may invoke asynchronously
-
when negotiating the SCP role for operations, the maximum number of outstanding operations it may invoke asynchronously; when negotiating the SCU role for operations, the maximum number of outstanding sub-operations it may perform asynchronously; when negotiating the SCU role for notifications, the maximum number of notifications it may perform asynchronously when negotiating the SCP role
A value of zero indicates that the above parameters are unlimited.
A value of one indicates that there is no Asynchronous Operations support.
If the Asynchronous Operations Window is absent the default for the above parameters shall be equal to one.
The Association-acceptor conveys in the A-ASSOCIATE response:
-
when negotiating the SCP role for operations, the maximum number of outstanding operations; when negotiating the SCU role for operations, the maximum number of sub-operations it allows the Association-requestor to invoke asynchronously; when negotiating the SCU role for notifications, the maximum number of outstanding notifications it allows the Association-requestor to invoke asynchronously when negotiating the SCU role. This number shall be equal or less than the number of outstanding notifications, operations and/or sub-operations the Association-requestor offers to invoke (by the A-ASSOCIATE indication).
-
when negotiating the SCU role for operations, the maximum number of outstanding operations; when negotiating the SCP role for operations, the maximum number of sub-operations it allows the Association-requestor to perform asynchronously; when negotiating the SCP role for notifications, the maximum number of outstanding notifications it allows the Association-requestor to perform asynchronously. This number shall be equal or less than the number of outstanding notifications, operations and/or sub-operations the Association-requestor offers to perform (by the A-ASSOCIATE indication).
A value of zero indicates that the above parameters are unlimited. If the Asynchronous Operations Window is absent the default for the above parameters shall be equal to one. Figures D.3-5 and D.3-6 illustrate examples of Asynchronous Operations Window negotiation.
If this negotiation is not present in the A-ASSOCIATE indication it shall be omitted in the A-ASSOCIATE response.
Note
The case where the Association-requestor offers the value of zero (which indicates unlimited operations), the Association-acceptor may return zero (agreeing to unlimited operations) or negotiate the parameter down by conveying a value other than zero.
D.3.3.3.1 Asynchronous Operations Window Sub-Item Structure (A-ASSOCIATE-RQ)
The Asynchronous Operations Window Sub-Item shall be made of a sequence of mandatory fixed length fields. This Sub-Item is optional and if supported, only one Asynchronous Operations Window Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-RQ. Table D.3-7 shows the sequence of the mandatory fields.
Table D.3-7. Asynchronous Operations Window Sub-Item Fields (A-ASSOCIATE-RQ)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
53H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Maximum-number-operations-performed field. In the case of this Sub-Item, it shall have the fixed value of 00000004H encoded as an unsigned binary number.
|
5-6
|
Maximum-number-operations-invoked
|
This field shall contain the Maximum-number-operations-invoked as defined for the Association-requestor in Section D.3.3.3. It shall be encoded as an unsigned binary number.
|
7-8
|
Maximum-number-operations-performed
|
This field shall contain the Maximum-number-operations-performed as defined for the Association-requestor in Section D.3.3.3. It shall be encoded as an unsigned binary number.
|
D.3.3.3.2 Asynchronous Operations Window Sub-Item Structure (A-ASSOCIATE-AC)
The Asynchronous Operations Window Sub-Item shall be made of a sequence of mandatory fixed length fields. This Sub-Item is optional and if supported, only one Asynchronous Operations Window Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-AC. Table D.3-8 shows the sequence of the mandatory fields.
Table D.3-8. Asynchronous Operations Window Sub-Item Fields (A-ASSOCIATE-AC)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
53H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Maximum-number-operations-performed field. In the case of this Sub-Item, it shall have the fixed value of 00000004H encoded as an unsigned binary number.
|
5-6
|
Maximum-number-operations-invoked
|
This field shall contain the Maximum-number-operations-invoked as defined for the Association-acceptor in Section D.3.3.3 It shall be encoded as an unsigned binary number.
|
7-8
|
Maximum-number-operations-performed
|
This field shall contain the Maximum-number-operations-performed as defined for the Association-acceptor in Section D.3.3.3. It shall be encoded as an unsigned binary number.
|
D.3.3.4 SCP/SCU Role Selection Negotiation
The SCP/SCU Role Selection Negotiation allows peer AEs to negotiate the roles in which they will serve for each SOP Class or Meta SOP Class supported on the Association. This negotiation is optional.
The Association-requestor, for each SOP Class UID or Meta SOP Class UID, may use one SCP/SCU Role Selection item. The SOP Class or Meta SOP Class shall be identified by its corresponding Abstract Syntax Name followed by one of the three role values:
-
Association-requestor is SCU only
-
Association-requestor is SCP only
-
Association-requestor is both SCU and SCP
If the SCP/SCU Role Selection item is absent the default role of the Association-requestor shall be SCU and the default role of the Association-acceptor shall be SCP.
The Association-acceptor, for each SCP/SCU Role Selection item offered, either accepts the Association-requestor proposal by returning the same value (1) or turns down the proposal by returning the value (0). The Association-acceptor shall not return the value (1) if the Association-requestor has not proposed the role, i.e., it has sent a value (0). The Association-requestor shall ignore the response if it has not proposed the role.
If the SCP/SCU Role Selection item is not returned by the Association-acceptor then the role of the Association-requestor shall be SCU and the role of the Association-acceptor shall be SCP. Figure D.3-7 illustrates the SCP/SCU Role Selection Negotiation.
If the SCP/SCU Role Selection items do not exist in the A-ASSOCIATE indication they shall be omitted in the A-ASSOCIATE response.
Note
-
The choices made for the default roles are based on clarification made to previous versions of the Standard. Association-requestors that wish to offer Abstract Syntax Names using the SCP role must support this item. Association-acceptors that wish to accept Abstract Syntax Names using the SCU role must support this item.
-
If an Association-requestor offers an SCP/SCU Role Selection item for an Abstract Syntax Name but the Association-acceptor does not return an SCP/SCU Role Selection item for the same Abstract Syntax Name then the proposed roles have not been accepted and the default roles apply (i.e., Association-requestor is SCU and Association-acceptor is SCP).
Note
-
DICOM AE "B" accepts DICOM AE "A"'s proposed role as an SCU for the Storage-MR SOP; therefore, DICOM AE "B" will perform in the SCP role. DICOM AE "B" turns down the SCP proposal from DICOM AE "A".
-
Both DICOM AEs may be SCU and SCP for the Storage-CT SOP.
-
DICOM AE "B" accepts DICOM AE "A"'s proposed role as an SCU for the Print-SOP; therefore, DICOM AE "B" will perform in the SCP role.
D.3.3.4.1 SCP/SCU Role Selection Sub-Item Structure (A-ASSOCIATE-RQ)
The SCP/SCU Role Selection Sub-Item shall be made of a sequence of mandatory fields. This Sub-Item is optional and if supported, one or more SCP/SCU Role Selection Sub-Items may be present in the User Data Item of the A-ASSOCIATE-RQ. The Association-requestor may only offer one SOP Class SCP/SCU Role Selection Sub-Item for each SOP Class UID or Meta SOP Class that is present in the A-ASSOCIATE request. Table D.3-9 shows the sequence of the mandatory fields.
Table D.3-9. SCP/SCU Role Selection Sub-Item Fields (A-ASSOCIATE-RQ)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
54H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the SCP Role field. It shall be encoded as an unsigned binary number.
|
5-6
|
UID-length
|
This UID-length shall be the number of bytes from the first byte of the following field to the last byte of the SOP-class-uid field. It shall be encoded as an unsigned binary number.
|
7 -xxx
|
SOP-class-uid
|
This variable field shall contain the SOP Class UID or Meta SOP Class UID that may be used to identify the corresponding Abstract Syntax for which this Sub-Item pertains. It shall be encoded as a UID as defined in Section 9 “Unique Identifiers (UIDs)” in PS3.5.
|
xxx
|
SCU-role
|
This byte field shall contain the SCU-role as defined for the Association-requestor in Section D.3.3.4. It shall be encoded as an unsigned binary and shall use one of the following values:
0 - non support of the SCU role
1 - support of the SCU role
|
xxx
|
SCP-role
|
This byte field shall contain the SCP-role as defined for the Association-requestor in Section D.3.3.4. It shall be encoded as an unsigned binary and shall use one of the following values:
0 - non support of the SCP role
1 - support of the SCP role.
|
D.3.3.4.2 SCP/SCU Role Selection Sub-Item Structure (A-ASSOCIATE-AC)
The SCP/SCU Role Selection Sub-Item shall be made of a sequence of mandatory fields. This Sub-Item is optional and if supported, one or more SCP/SCU Role Selection Sub-Items may be present in the User Data Item of the A-ASSOCIATE-AC. Table D.3-10 shows the sequence of the mandatory fields.
Table D.3-10. SCP/SCU Role Selection Sub-Item Fields (A-ASSOCIATE-AC)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
54H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the SCP Role field. It shall be encoded as an unsigned binary number.
|
5-6
|
UID-length
|
This UID-length shall be the number of bytes from the first byte of the following field to the last byte of the SOP-class-uid field. It shall be encoded as an unsigned binary number.
|
7-xxx
|
SOP-class-uid
|
This variable field shall contain the SOP Class UID or Meta SOP Class UID that may be used to identify the corresponding Abstract Syntax for which this Sub-Item pertains. It shall be encoded as a UID as defined in Section 9 “Unique Identifiers (UIDs)” in PS3.5.
|
xxx
|
SCU-role
|
This byte field shall contain the SCU-role as defined in Section D.3.3.4. It shall be encoded as an unsigned binary and shall use one of the following values:
0 - The Association-acceptor rejects the Association-requestor's proposal of the SCU role selection
1 - The Association-acceptor accepts the Association-requestor's proposal of the SCU role selection
|
xxx
|
SCP-role
|
This byte field shall contain the SCP-role as defined for the Association-acceptor in Section D.3.3.4. It shall be encoded as an unsigned binary and shall use one of the following values:
0 - The Association-acceptor rejects the Association-requestor's proposal of the SCP role selection
1 - The Association-acceptor accepts the Association-requestor's proposal of the SCP role selection
|
D.3.3.5 Service-Object Pair (SOP) Class Extended Negotiation
The SOP Class Extended Negotiation allows, at Association establishment, peer DICOM AEs to exchange application information defined by specific Service Class specifications. This is an optional feature that various Service Classes may or may not choose to support.
Each Service Class specification is required to document, as part of its SOP Class or Meta SOP Class, the application information it supports and how this information is negotiated between SCUs and SCPs. Service Class specifications shall specify, for both the SCU and SCP roles, the following:
-
semantics of the application information (including the negotiation rules)
-
encoding of the application information
-
conditions for which the application information is mandatory and/or optional
-
default conditions of the application information
Note
The use of the SOP Class Extended Negotiation is not limited to Service Classes defined by this Standard. It may also be used for privately defined Service Classes.
The Association-requestor may only offer one SOP Class Extended Negotiation Sub-Item for each SOP Class UID or Meta SOP Class that is present in the A-ASSOCIATE request.
If the SOP Class Extended Negotiation Sub-Items do not exist in the A-ASSOCIATE indication they shall be omitted in the A-ASSOCIATE response.
D.3.3.5.1 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)
The SOP Class Extended Negotiation Sub-Item shall be made of a sequence of mandatory fields followed by the Service-class-application-information field (specific for each Service Class specification). This Sub-Item is required per the specific Service Class specifications. Multiple SOP Class Extended Negotiation Sub-Items may be present in the User Data Item of the A-ASSOCIATE-RQ, however, only one Sub-Item per SOP Class UID shall be present. Table D.3-11 shows the sequence of mandatory fields.
Table D.3-11. SOP Class Extended Negotiation Sub-Item Fields (A-ASSOCIATE-RQ and A-ASSOCIATE-AC)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
56H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-Length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Service-class-application-information field. It shall be encoded as an unsigned binary number.
|
5-6
|
SOP-class-uid-length
|
The SOP-class-uid-length shall be the number of bytes from the first byte of the following field to the last byte of the SOP-class-uid field. It shall be encoded as an unsigned binary number.
|
7-xxx
|
SOP-class-uid
|
The SOP Class or Meta SOP Class identifier encoded as a UID as defined in Section 9 “Unique Identifiers (UIDs)” in PS3.5.
|
xxx-xxx
|
Service-class-application-information
|
This field shall contain the application information specific to the Service Class specification identified by the SOP-class-uid. The semantics and value of this field is defined in the identified Service Class specification.
|
D.3.3.5.2 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)
The SOP Class Extended Negotiation Sub-Item shall be made of a sequence of mandatory fields followed by the Service-class-application-information field (specific for each Service Class specification). This Sub-Item is required per the specific Service Class specifications. Multiple SOP Class Extended Negotiation Sub-Items may be present in the User Data Item of the A-ASSOCIATE-AC, however, only one Sub-Item per SOP Class UID shall be present. Table D.3-11 shows the sequence of mandatory fields.
D.3.3.6 Service-Object Pair (SOP) Class Common Extended Negotiation
The SOP Class Common Extended Negotiation allows, at Association establishment, peer DICOM AEs to exchange application information, the form of which is generic, and not specific to individual Service Classes, as compared to the information defined in D.3.3.5. This is an optional feature that Association-requestors and Association-acceptors may or may not choose to support.
The information included for each SOP Class for which a sub-item is present consists of a Service Class UID and (optionally) a Related General SOP Class UID.
The Service Class UID conveys the Service Class of the SOP Class.
Note
Explicit conveyance of the Service Class may allow the selection of the proper format for the Service-class-application-information of the SOP Class Extended Negotiation Sub-Item.
The Related General SOP Class UID conveys zero or more Related General SOP Class for the SOP Class.
Note
-
Consider the example of negotiation of support for a Procedure Log Storage SOP Class. That SOP Class is of the Storage Service Class. The encoding of the IOD would be compatible with the more general Enhanced SR Storage SOP Class. Therefore, the following common Extended Negotiation sub-item could optionally be included:
-
SOP Class UID: 1.2.840.10008.5.1.4.1.1.88.40 Procedure Log
-
Service Class UID: 1.2.840.10008.4.2 Storage Service Class
-
Related General SOP Class UID: 1.2.840.10008.5.1.4.1.1.88.22 Enhanced SR
-
The Related SOP Class may be absent, though the Service Class may still be included. For example, there may be a new image storage SOP Class without a Related SOP Class defined in PS3.4, yet it is still useful to an Association-acceptor to be informed that the new SOP Class is of the Storage Service Class:
-
SOP Class UID: 1.2.840.10008.5.1.4.1.1.7.1 MF Single Bit SC Image Storage
-
Service Class UID: 1.2.840.10008.4.2 Storage Service Class
-
Related General SOP Class UID: (none)
The Association-requestor may only offer one SOP Class Common Extended Negotiation Sub-Item for each SOP Class UID that is present in the A-ASSOCIATE request.
No response is necessary, hence the SOP Class Common Extended Negotiation Sub-Items shall be omitted in the A-ASSOCIATE response.
D.3.3.6.1 SOP Class Common Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)
The SOP Class Common Extended Negotiation Sub-Item shall be made of a sequence of mandatory fields, the last two of which may be zero-length. Multiple SOP Class Common Extended Negotiation Sub-Items may be present in the User Data Item of the A-ASSOCIATE-RQ, however, only one Sub-Item per SOP Class UID shall be present. Table D.3-12 shows the sequence of mandatory fields.
Table D.3-12. SOP Class Common Extended Negotiation Sub-Item Fields (A-ASSOCIATE-RQ)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
57H
|
2
|
Sub-Item-version
|
This field indicates the version of the Sub-Item. Fields added to the Sub-Item definition in succeeding editions of the Standard will not affect the semantics of previously defined fields. The version of the Sub-Item defined in this edition of the Standard is 0.
|
3-4
|
Item-Length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Reserved field. It shall be encoded as an unsigned binary number.
|
5-6
|
SOP-class-uid-length
|
The SOP-class-uid-length shall be the number of bytes in the SOP-class-uid field. It shall be encoded as an unsigned binary number.
|
7-x
|
SOP-class-uid
|
The SOP Class identifier encoded as a UID as defined in Section 9 “Unique Identifiers (UIDs)” in PS3.5.
|
(x+1) - (x+2)
|
Service-class-uid-length
|
The Service-class-uid-length shall be the number of bytes in the Service-class-uid field. It shall be encoded as an unsigned binary number.
|
(x+3) - y
|
Service-class-uid
|
The Service Class identifier encoded as a UID as defined in Section 9 “Unique Identifiers (UIDs)” in PS3.5.
|
(y+1) - (y+2)
|
Related-general-sop-class-identification-length
|
The Related-general-sop-class-identification-length shall be the number of bytes in the Related-general-sop-class-identification field. Shall be zero if no Related General SOP Classes are identified.
|
(y+3) - z
|
Related-general-sop-class-identification
|
The Related-general-sop-class-identification is a sequence of pairs of length and UID sub-fields. Each pair of sub-fields shall be formatted in accordance with Table D.3-13
|
(z+1) - k
|
Reserved
|
Reserved for additional fields of the sub-item. Shall be zero-length for Version 0 of Sub-Item definition.
|
Table D.3-13. Related-General-SOP-Class-Identification Sub-Fields
Bytes
|
Sub-Field Name
|
Description of Sub-Field
|
1-2
|
Related-general-sop-class-uid-length
|
The Related-general-sop-class-uid-length shall be the number of bytes in the Related-general-sop-class-uid sub-field. It shall be encoded as an unsigned binary number.
|
3-n
|
Related-general-sop-class-uid
|
The Related General SOP Class identifier encoded as a UID as defined in Section 9 “Unique Identifiers (UIDs)” in PS3.5.
|
D.3.3.7 User Identity Negotiation
The User Identity Negotiation is used to notify the association acceptor of the user identity of the association requestor. It may also request that the association acceptor respond with the server identity. This negotiation is optional. If this sub-item is not present in the A-ASSOCIATE request the A-ASSOCIATE response shall not contain a user identity response sub-item.
The Association-requestor conveys in the A-ASSOCIATE request:
-
the form of user identity being provided, either a username, username and passcode, a Kerberos service ticket, a SAML assertion, or a JSON Web Token (JWT).
-
an indication whether a positive server response is requested.
The Association-acceptor does not provide an A-ASSOCIATE response unless a positive response is requested and user authentication succeeded. If a positive response was requested, the A-ASSOCIATE response shall contain a User Identity sub-item. If a Kerberos ticket is used the response shall include a Kerberos server ticket.
Since a system may ignore request sub-items, the positive response must be requested if the association requestor requires confirmation. If the association acceptor does not support user identification it will accept the association without making a positive response. The association requestor can then decide whether to proceed.
The association acceptor may utilize the User Identity information provided during the association negotiation to populate the user information fields in DICOM audit trail messages. The association acceptor may utilize the User Identity information provided during the association negotiation to perform authorization controls during the performance of other DIMSE transactions on the same association. The user identity information may also be used to modify the performance of DIMSE transactions for other purposes, such as workflow optimizations.
Note
-
User identity authorization controls may be simple "allow/disallow" rules, or they can be more complex scoping rules.
For example, a query could be constrained to apply only to return information about patients that are associated with the identified user.
The issues surrounding authorization controls can become very complex.
The User Identity Negotiation conveys user identity to support uses such as authorization controls and audit controls.
It does not specify their behavior.
-
The option to include a passcode along with the user identity enables a variety of non-Kerberos secure interfaces. Sending passwords in the clear is insecure, but there are single use password systems such as [RFC2289] and the various smart tokens that do not require protection. The password might also be protected by TLS or other mechanisms.
-
For JSON Web Tokens (JWTs), [RFC7519] specifies minimal requirements for encryption, MAC and signature algorithms;
others may be supported as described in the DICOM Conformance Statement.
The encoded format in the Primary-field of the A-ASSOCIATE-RQ is the same as what might be included in an HTTP Authorization: Bearer header field
per [RFC6750] when accessing a Protected Resource on a Resource Server.
If the same trust mechanisms are used by both the DIMSE SCP and the Resource Server, the contents of the Primary-field can be the same as the value of the HTTP Authorization: Bearer field, avoiding the need to perform a conversion of the contents.
-
Care should be taken to not include unnecessary protected content from the User Identity Negotiation into audit log messages.
For example, the password, SAML Assertion, and JSON Web Token (JWT) could be disclosed if included in a log message.
A service such as the OAuth Introspection Service ([RFC7662]) might be needed to obtain unprotected user identity information from a SAML Assertion or JWT.
D.3.3.7.1 User Identity Sub-Item Structure (A-ASSOCIATE-RQ)
The User Identity Negotiation Sub-Item shall be made of a sequence of mandatory fixed and variable length fields. This Sub-Item is optional and if supported, only one User Identity Negotiation Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-RQ. Table D.3-14 shows the sequence of the mandatory fields.
Table D.3-14. User Identity Negotiation Sub-Item Fields (A-ASSOCIATE-RQ)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
58H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the last field sent. It shall be encoded as an unsigned binary number.
|
5
|
User-Identity-Type
|
Field value shall be in the range 1 to 5 with the following meanings:
1 - Username as a string in UTF-8
2 - Username as a string in UTF-8 and passcode
3 - Kerberos Service ticket
4 - SAML Assertion
5 - JSON Web Token (JWT)
Other values are reserved for future standardization.
|
6
|
Positive-response-requested
|
Field value:
0 - no response requested
1 - positive response requested
|
7-8
|
Primary-field-length
|
The User-Identity-Length shall contain the length of the User-Identity value.
|
9-n
|
Primary-field
|
This field shall convey the user identity, either the username as a series of characters, or the Kerberos Service ticket encoded in accordance with [RFC1510],
or the JWT encoded in accordance with [RFC7519] using base64url encoded parts.
|
n+1-n+2
|
Secondary-field-length
|
This field shall be non-zero only if User-Identity-Type has the value 2. It shall contain the length of the secondary-field.
|
n+3-m
|
Secondary-field
|
This field shall be present only if User-Identity-Type has the value 2. It shall contain the Passcode value.
|
D.3.3.7.2 User Identity Sub-Item Structure (A-ASSOCIATE-AC)
The User Identity Sub-Item shall be made of a sequence of mandatory fixed and variable length fields. This Sub-Item is optional and if supported, only one User Identity Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-AC. Table D.3-15 shows the sequence of the mandatory fields.
Table D.3-15. User Identity Negotiation Sub-Item Fields (A-ASSOCIATE-AC)
Item Bytes
|
Field Name
|
Description of Field
|
1
|
Item-type
|
59H
|
2
|
Reserved
|
This reserved field shall be sent with a value 00H but not tested to this value when received.
|
3-4
|
Item-length
|
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the final field. It shall be encoded as an unsigned binary number.
|
5-6
|
Server-response-length
|
This field shall contain the number of bytes in the Server-response. May be zero.
|
7-n
|
Server-response
|
This field shall contain the Kerberos Server ticket, encoded in accordance with [RFC1510], if the User-Identity-Type value in the A-ASSOCIATE-RQ was 3. This field shall contain the SAML response if the User-Identity-Type value in the A-ASSOCIATE-RQ was 4. This field shall be zero length if the value of the User-Identity-Type in the A-ASSOCIATE-RQ was 1 or 2.
|
If the Association-Requestor has requested a positive acknowledgment, the Server-response shall be returned with the Kerberos Server ticket when User-Identity-Type is Kerberos Service ticket (3).
D.3.3.7.3 User Identity Rejection
The association acceptor may utilize the username or username and passcode information to determine whether the user is permitted to establish an association. If the Kerberos mechanism is chosen, the association acceptor shall utilize the Kerberos service ticket to determine whether the user is permitted to establish an association.
If the association acceptor rejects the association because of an authorization failure, the rejection shall be indicated to be rejected-permanent (see PS3.8). The source shall be value (2) "DICOM UL service provided (ACSE related function) ". The rejection is indicated to be rejected-permanent because retries with the same user identity fields will continue to be rejected. A different and valid username, username and passcode, or Kerberos ticket must be provided.
This Standard does not define how the association acceptor performs authentication or what rules apply to this authentication.