Suppose an SCU sends an an A-ASSOCIATE request containing exactly two presentation Contexts (two different abstract syntaxes) to a storage-SCP.

The Storage-SCP does not support either presentation context (does not support either abstract syntax).

What should the storage-SCP A-ASSOCIATE response be?

1.
Send associate Accept with the status of each presentation context as "abstract-syntax-not-supported (provider rejection)".

2.
Send associate Reject.
Part 3.8, 7.1.1.9 lists valid reasons for association rejection. None seem to describe the case where the association is rejected because no proposed presentation contexts are supported.
Which would be the correct reason for rejection?

Are both (1) and (2) above correct?
(1) seems like it gives more information to the SCU then (2).

I agree that

> 1.
> Send associate Accept with the status of each presentation context as "abstract-syntax-not-supported (provider rejection)".
>

sounds more sensible, but I don't know any statement in the standard text which explicitly forbid

> 2.
> Send associate Reject.
> Part 3.8, 7.1.1.9 lists valid reasons for association rejection. None seem to describe the case where the association is rejected because no proposed presentation contexts are supported.
> Which would be the correct reason for rejection?

E.g.
Result: 1 - rejected-permanent
Source: 1 - DICOM UL service-user
Reason: 1 - no-reason-given
>
>
> Are both (1) and (2) above correct?
> (1) seems like it gives more information to the SCU then (2).

gunter zeilinger schrieb am Donnerstag, 2. September 2021 um 16:16:14 UTC+2:
> I agree that
> > 1.
> > Send associate Accept with the status of each presentation context as "abstract-syntax-not-supported (provider rejection)".
> >
> sounds more sensible, but I don't know any statement in the standard text which explicitly forbid

Agreeed. But I think that PS3.8, 7.1.2.4
If the acceptor accepts the association, the association is available for use. Both AEs may now use any service provided by the DICOM application context that is in effect (with the exception of A-ASSOCIATE).
Note
This implies that once the association has been established, DICOM Messages can be exchanged as defined in PS3.7.

and 7.1.2.6
The UL service-provider may not be capable of supporting the requested association. In this situation, it shall return an A- ASSOCIATE confirmation primitive to the requestor with an appropriate Result parameter (rejected). The Result Source parameter shall be appropriately assigned either the symbolic value of "UL service-provider (ACSE related function) " or "UL service-provider (Presentation related function)." The indication primitive shall not be issued. The association shall not be established.

could be understood in a way that if no acceptable PC is proposed:
- no DICOM messages can be exchanged as defined in PS3.7
- the UL service provider is not capable of supporting the requested association
- the association should be rejected with "UL service-provider (Presentation related function)."

This is my interpretation, admittedly one could probably reason against it, and accepting the association but rejecting all PCs yields a much better way of conveying "why it does not work"

Hi Mack,

I made a short video in the past about DICOM Association negotiation: https://www.workshopfor.me/dicom-associations .
This does not directly answer the question and you probably already know all of this, but describes the context of your question for other people that will read this post.

I had the same question as you 15 years ago, and had the opportunity to ask this to Bas Revet (former chair WG 6) as he was working at Philips Healthcare in the next room. His answer was that in this case always try to supply as much as possible information to the SCU, meaning send back an A-ASOCIATE-AC, with all presentation context items not accepted using abstract syntax not supported.

So I fully agree with Markus.

Regards,
Marco