The SCU shall generate only C-STORE requests with SOP Instances which meet the requirements of the IOD associated with the SOP Class.
During Association Negotiation, an application may propose a specialized SOP Class and its related general SOP Class in separate Presentation Contexts as a Storage SCU. If the Association Acceptor rejects the specialized SOP Class Presentation Context, but accepts the related general SOP Class Presentation Context, the application may send instances of the specialized SOP Class as instances of the related general SOP Class. In this fall-back behavior, the SOP Class UID of the instance shall be the UID of the related general SOP Class, and any special semantics associated with the specialized SOP Class may be lost; the SOP Instance UID shall remain the same.
Note: The SCU may include the SOP Class UID of the original intended specialized SOP Class in the attribute Original Specialized SOP Class UID (0008,001B) of the instance sent under the related general SOP Class. In some cases, e.g., when all intermediate storage applications are Level 2 SCPs, this may allow an ultimate receiver of the instance to recast it as an instance of the specialized SOP Class IOD. However, this transformation is not guaranteed.