SCP presentation context negotiation ignores requestor's transfer syntax preference order

[julianmarshall911]

Describe the bug
When acting as an Association Acceptor (SCP), negotiate_as_acceptor() in presentation.py selects the accepted Transfer Syntax by iterating the acceptor's supported TS list and picking the first match found in the requestor's proposed list. This ignores the requestor's preference order.

The DICOM convention (and the behavior of DCMTK, the reference DICOM implementation) is to iterate the requestor's proposed TS list and pick the first one the acceptor supports. The requestor lists transfer syntaxes in preference order, and the acceptor should respect that.

This causes real-world interoperability failures. For example, when a sender has JPEG-LS Lossless compressed mammography files and proposes [JPEG-LS Lossless, Explicit VR LE, Implicit VR LE], the SCP accepts Explicit VR LE (because it appears first in the SCP's own supported list). The sender then cannot use the accepted context because it would need to decompress on the fly, which most DICOM implementations cannot do. The sender aborts the association.

Expected behavior
The SCP should accept 1.2.840.10008.1.2.4.80 (JPEG-LS Lossless) because it is the requestor's first-preference transfer syntax and the SCP supports it. This is how DCMTK's storescp behaves. Actual behavior? The SCP accepts 1.2.840.10008.1.2 (Implicit VR LE) because it appears first in the SCP's own supported transfer syntax list, regardless of the requestor's preference.

Steps To Reproduce

from pynetdicom import AE, evt
from pynetdicom.sop_class import Verification

sop = '1.2.840.10008.5.1.4.1.1.1.2'  # Digital Mammography
jpeg_ls = '1.2.840.10008.1.2.4.80'    # JPEG-LS Lossless
implicit = '1.2.840.10008.1.2'         # Implicit VR LE

# SCP: supports both, but lists implicit first
scp_ae = AE()
scp_ae.add_supported_context(sop, [implicit, jpeg_ls])
scp_ae.add_supported_context(Verification)
server = scp_ae.start_server(('', 11199), block=False)

# SCU: proposes JPEG-LS first (sender's preference)
scu_ae = AE()
scu_ae.add_requested_context(sop, [jpeg_ls, implicit])
scu_ae.add_requested_context(Verification)
assoc = scu_ae.associate('127.0.0.1', 11199)

if assoc.is_established:
    for cx in assoc.accepted_contexts:
        if str(cx.abstract_syntax) == sop:
            print('Accepted TS:', cx.transfer_syntax)
            # Prints: ['1.2.840.10008.1.2'] (Implicit VR LE)
            # Expected: ['1.2.840.10008.1.2.4.80'] (JPEG-LS Lossless)
    assoc.release()

server.shutdown()

**Your environment**
- pynetdicom version: 2.0.2
- Python version: 3.13
- OS: Debian Linux (also reproduced on macOS with Python 3.9)

** Fix**
In `pynetdicom/presentation.py`, function `negotiate_as_acceptor`:

**Current code** (iterates acceptor's list):
```python
for tr_syntax in ac_context.transfer_syntax:
    if tr_syntax in rq_context.transfer_syntax:
        context.transfer_syntax = [tr_syntax]
        context.result = 0x00
        result_contexts.append(context)
        break

Proposed fix (iterates requestor's list):

for tr_syntax in rq_context.transfer_syntax:
    if tr_syntax in ac_context.transfer_syntax:
        context.transfer_syntax = [tr_syntax]
        context.result = 0x00
        result_contexts.append(context)
        break

[CedricConday]

I can reproduce this on 3.0.4 — with the SCU proposing [JPEG-LS Lossless, Implicit VR LE] and the SCP supporting [Implicit VR LE, JPEG-LS Lossless], the accepted context comes back as Implicit VR LE.

Before the patch goes in, though, I think both premises behind it are worth a second look, because I couldn't confirm either.

The standard doesn't appear to require the requestor's order. PS3.7 Section D.3.2 says only that "multiple Transfer Syntaxes may be offered per Presentation Context, but only one shall be accepted", and PS3.8 Section 9.3.3.2 describes the Transfer Syntax sub-item without saying how the acceptor should choose between them. If there's normative text that does mandate honouring the requestor's order I'd like to be pointed at it, but on what I can find the current behaviour is conformant rather than a violation.

DCMTK appears to do what pynetdicom already does. ASC_acceptContextsWithPreferredTransferSyntaxes in dcmnet/libsrc/assoc.cc iterates the acceptor's list, with this comment:

/*
** Accept in the order "least wanted" to "most wanted" transfer
** syntax.  Accepting a transfer syntax will override previously
** accepted transfer syntaxes.
*/
for (i=transferSyntaxCount-1; i>=0; i--)

Each pass calls ASC_acceptContextsWithTransferSyntax, whose inner loop only checks whether the requestor proposed that syntax — it never reads the requestor's ordering. Because the acceptor's list is walked in reverse, the acceptor's own first preference is what ends up accepted. So the proposed change would move pynetdicom away from the implementation the issue cites as the reference, rather than towards it.

And the current behaviour looks deliberate rather than accidental — the "Implementation Note" on the presentation context negotiation page already documents it, including an example where the acceptor's second-listed syntax loses to its first. I ran that example and it behaves exactly as documented.

The reported symptom has a fix that works today. Since the acceptor's ordering decides, listing the preferred syntax first gives the desired result:

# accepted: Implicit VR LE
scp_ae.add_supported_context(sop, [implicit, jpeg_ls])

# accepted: JPEG-LS Lossless
scp_ae.add_supported_context(sop, [jpeg_ls, implicit])

Both verified on 3.0.4. That's also how you'd configure storescp.

Where I do think there's something worth changing: the rule is only written down in the narrative negotiation page, not at the API surface where an SCP is actually configured. Neither AE.add_supported_context nor negotiate_as_acceptor mentions that the order of transfer_syntax decides the outcome, which is presumably how this came to look like a bug. I've opened #1089 to document it in both places and to spell out the consequence — and the one-line remedy — in the negotiation page.