3.3.1.5.6 Presentation Context and Transfer Syntax Negotiation
These extensions extend and augment the message processing rules for presentation context and transfer syntax negotiation, as specified in [C706] section 12.6. The scope of a presentation context in these extensions is a connection.
The basic model for the negotiation process is that the client enumerates all transfer syntaxes it supports, and the server chooses one of them. A detailed description of the processing rules follows.
If a client supports multiple transfer syntaxes, as listed in the List of Supported Transfer Syntaxes in the association, the client SHOULD send multiple elements in the p_cont_elem array of the p_cont_elem_t structure, as specified in [C706] section 12. The abstract_syntax field in each element of the array SHOULD contain the same if_uuid and if_version, and the transfer_syntaxes array of each element SHOULD have one element only. The if_uuid and if_version of the element in the transfer_syntaxes array MUST contain the transfer syntax UUID and version number for the transfer syntax the client is proposing.
The server responds with a bind_ack or alter_context_resp PDU depending on what PDU the client sent to it. The server SHOULD accept, at most, one of the transfer syntaxes. Selection of a transfer syntax is based on the following criteria:
If one of the client proposed transfer syntaxes matches the server's preferred transfer syntax, then that transfer syntax is accepted.
If the client does not propose a transfer syntax that matches the server's preferred transfer syntax, the first transfer syntax in the client's list of proposed syntaxes which is also supported by the server is accepted.
If none of the proposed transfer syntaxes are supported, the server MUST send a bind_ack with all transfer syntaxes rejected.
The response of the server is a p_result_list_t structure that MUST have the same number of elements as the p_cont_elem_t structure the client sent to it. Each array element in the p_result_list_t structure is interpreted to correspond to the array element in the p_cont_elem_t structure in the same position of the array. For example, the first array element in the p_result_list_t structure is interpreted to correspond to the first array element in the p_cont_elem_t structure. If the server does not recognize the abstract_syntax field in an array element in the p_cont_elem_t structure, it MUST set the result field in the p_result_list_t structure corresponding to that array element to abstract_syntax_not_supported. If the server recognizes the abstract_syntax field, the server MUST set the result field corresponding to the transfer syntax it prefers to use to the "acceptance" value and the result field corresponding to all other transfer syntaxes to the "provider_rejection" value. Both of these values are as specified in [C706] section 12.6.
The client SHOULD NOT interpret the rejection of a transfer syntax as an indication that the server will not accept this transfer syntax at a future date but instead SHOULD interpret the rejection as an indication that the server prefers the transfer syntax it accepted over the other transfer syntaxes proposed by the client. A client is allowed to propose a rejected transfer syntax at a later time, but if it has a choice, the client SHOULD use the transfer syntax that the server accepted instead of trying to renegotiate a transfer syntax that was rejected earlier by the server.
If the client receives a bind_ack with no accepted transfer syntax, the client MUST fail the call.<105>
If the client attempts to negotiate a presentation context when the server already has 4000 X NumberOfRegisteredInterfaces or greater presentation contexts, the server MUST fail negotiation of a presentation context with bind_nak packet. The client behavior when receiving the bind_nak packet is as described in [C706] section 11.1.3 (CO_CLIENT Events, RCV_BIND_NAK event).
Once negotiated, a presentation context SHOULD be maintained by both the client and server implementations for the lifetime of the connection it was negotiated on by adding it to the Table of Presentation Contexts in the association and to the List of Negotiated Presentation Contexts in the connection.
Servers SHOULD implement at least transfer syntax NDR, as defined in this document, to allow for a fallback transfer syntax if another transfer syntax cannot be negotiated.<106>