> 1. From my understanding the SCP will/should only ever return attributes within its MWL responses that where originally part of the SCU identifier within its C-FIND request and not more. Is this correct?
Correct should not, but expect in practice that some SCPs may return more. So I would implement it to ignore attributes you don't need.
> 2. When it comes to Matching Key Types I am currently interpreting the type R and O from Table K.6-1 in K.184.108.40.206 the following ways: R == each SCP is required to support matching against provided values;
Yes. Kind of difficult to read the table ;) but you got it really well.
> O == SCPs can support matching against provided values but is not required to support it,
Optional attribute supported will be listed in the scp conformance statement.
> but if the Attribute has a Return Key Type of 1, the SCP is required to return it even if it does not support matching against a provided value. (e.g. Requested Procedure ID (0040,1001) is part of my C-FIND query identifier (not as matching key): am I correct to assume that every MWL SCP will return a (valid) value for this attribute since its Return Key Type is 1?)
> 3. Is it valid for an MWL SCU to send an C-FIND request with an identifier without any provided matching key value (so just a list of attributes with Zero Length values) and expect that the MWL SCP returns its items?
Good question my opinion , someone with better DICOM knowledge may have a different interpretation.
According to Part 3.4 "An Identifier in a C-FIND request shall contain values to be matched against the Attributes of the Entities in a Worklist Information Model." I interpret "contain values" as shall have at minimum one value provided.
Anyway I would not try to do this in practice it may generate failure status or even an abort association. I am curious what is the use-case to query for all worklist items? Especially for an undefined timeframe.
> 4. Is it safe for the SCU to assume that all returned MWL items by the SCP are in fact completely valid and that no requested attribute of Return Key Type 1 will be included in the MWL responses without an proper value? Should there be an additional check on the SCU side in place to validated that and in case dump such a broken MWL response?
From my experience you should not expect or restrict too much. Check for the validity of attributes you really need and then accept it. Depends of your specific use-case of course. Generally speaking when creating a DICOM Request implement it strictly to the standard. When receiving a response check it for compliance just as much as you need and ignore the rest. Of course check for valid status.