Should a Storage Commitment SCU be able to handle N-EVENT-REPORT request before N-ACTION response?

[Victor Derks]

When a Storage Commitment SCP uses a different association to send the
N-EVENT-REPORT request the N-EVENT request may be received earlier
then the N-ACTION response. This would be a rare situation but not
unthinkable as messages on different DICOM associations are not
related.

When a SCP uses the same association to send the N-EVENT-REPORT
request it has 2 options:

OPION A:
- Send N-ACTION response
- Send N-EVENT-REPORT request

OPTION B:
- Send N-EVENT-REPORT request
- Send N-ACTION response

Must the SCP follow option A or is option B also legal? Reading PS 3.4
it seems that the logical order is option A but should the SCU reject
option B as a protocol\service violation?

[Marco Eichelberg]

Victor,

> When a Storage Commitment SCP uses a different association to send the
> N-EVENT-REPORT request the N-EVENT request may be received earlier

> then the N-ACTION response. [...]

> When a SCP uses the same association to send the N-EVENT-REPORT
> request it has 2 options:
>
> OPION A:
> - Send N-ACTION response
> - Send N-EVENT-REPORT request
>
> OPTION B:
> - Send N-EVENT-REPORT request
> - Send N-ACTION response
>
> Must the SCP follow option A or is option B also legal? Reading PS 3.4
> it seems that the logical order is option A but should the SCU reject
> option B as a protocol\service violation?

I would say that both options are legal since the sequencing of messages
over multiple associations is not defined in the DICOM standard.
In particular, even if the SCP selects option A, the same kind of
race condition could cause the SCU to receive the N-EVENT-REPORT-RSP
before the N-ACTION-RSP, i.e. effectively "see" option B.
I would, therefore, argue that failure to correctly handle this
situation would be a failure of the SCU. If the SCU supports incoming
associations, then it also needs to be able to handle possible
race conditions.

Best regards,
Marco Eichelberg