Shouldn't WADO-RS define Content-Type as "multipart/mixed" instead of "multipart/related" for responses?

[Jouke Numan]

Hi all,

I'd like to start a discussion on the validity/desirability of defining the Content-Type for WADO-RS responses as "multipart/related".

For starters, RFC 2385 (https://tools.ietf.org/html/rfc2387)defines that only one object should be contained in the message, typed by the "type" parameter in the ContentType header and constructed from one of more body-parts that are in turn typed by the ContentType header in the respective bodypart. To me that doesn't match with the usage as described for WADO-RS where the bodyparts don't make up one object, but are (parts of) different instances.

Second, I'm not happy with the consequence it seems to have with regard to the following situation:

- On the server there is a study with instances stored with multiple transfer syntaxes, eg a series in JPEG Lossless and a series in JPEG 2000.
- The client does a RetrieveStudy request for that study and provides Accept headers for both JPEG Lossless and JPEG 2000 Media Types.

Question: What should the server return as the mediatype in the responses ContentType and what should the mediatype be in bodyparts that contain the frames from the instances in the study?

Desirable (from server's perspective) would be that the frames are returned as stored on the server as client is capable understanding both mediatypes, no conversion cpu overhead is needed and no dataloss occurs if conversion between lossy formats would be needed. The ContentType in the bodypart contains the mediatype for the frame in that bodypart.

But in that case, the server doesn't know what to put in the message header for the mediatype in the ContentType. There are two possible values, both which are not valid for all bodyparts.

Undesirable (from server's perspective) and unnecessary from client's perspective is that server chooses one of the mediatypes from the provided accept headers and converts all frames not matching that mediatype. The mediatype in the message header and in all body parts would then be set to the chosen mediatype.

Unfortunately, it seems that this is the only option available at this moment.

The best way out of this that I see is that "multipart/mixed" is chosen as the contenttype for WADO-RS responses. This solves both issues, as it matches the content better and doesn't have the type parameter.

Another way out, if we need to stick with "multipart/related" (eg. because we cannot change it anymore), is to allow the type parameter in the ContentType header of the response to differ from the message content (eg. "application/octet-stream").
Rationale: If we allow one violation of the base standard already, we can allow some more. This is not my preferred choice.

I'm curious what your feedback/thoughts are on this matter.

Regards,

Jouke Numan
Software Architect
GE Healthcare

[Hermann Czedik-Eysenberg]

Hi Jouke,

thanks for bringing up this topic. Your remarks are very valid.
I agree, the DICOM usage does not strictly match the intentions of RFC 2387.

The way we are handling this in our Wado-RS implementation that we contributed to dcm4chee ( https://github.com/dcm4che/dcm4chee-arc-cdi/blob/master/dcm4chee-arc-wado/src/main/java/org/dcm4chee/archive/wado/WadoRS.java ) is as follows:

We allow the content parts to have different types. So in your example we would return some parts with:
Content-Type: image/dicom+jp2; transfer-syntax=1.2.840.10008.1.2.4.90
and some with:
Content-Type: image/dicom+jpeg; transfer-syntax=1.2.840.10008.1.2.4.70

We set the Content-type of the overall response to match the content-type of the first returned body part. (So it would be "Content-Type: image/dicom+jp2, transfer-syntax=1.2.840.10008.1.2.4.90" if the first returned image is JPEG2000.)

I am also unsure, if that is the behavior that was intended by the authors of DICOM PS3.18.

The standard should clarify this. Personally, I'd prefer that we stick with "multipart/related" and allow the mild violation of RFC 2387.

Regards,
Hermann Czedik-Eysenberg
Agfa HealthCare

[Jouke Numan]

Hi Hermann,

This topic is currently under discussion on the WG 27 mailing list after being forwarded to it by David Clunie.

The thinking of the PS 3.18 redoc author is indeed to specify in the new version along the lines you describe, the response header has a ContentType that equals the ContentType of the first body part.

If this is accepted by DICOM, then in my opinion they should also make clear in the standard that behavior deviates from RFC 2387 and the reasons why.
Currently the redoc author is of opinion that the standard is used "creatively", I'm argueing it is been broken. Discussion on this is ongoing at above mailing list.

Anyone interested in following the discussion can join above list as an Observer (free). This can be done by sending a mail to the secretariat of
DICOM (See last page of "How to join DICOM" at http://dicom.nema.org/handbook.html).

With regard to the syntax of contenttype for the response:
This should look like this in your case:

Content-Type: multipart/related type="image/dicom+jp2", transfer-syntax=1.2.840.10008.1.2.4.90; boundary=MyBoundary

Note the double quotes in the type parameter, these are
required as '/' is a delimiter character not allowed in a token,
thus quoted-string must be used. See
http://tools.ietf.org/html/rfc7231#section-3.1.1.1 for definition
of parameters to a media type and http://tools.ietf.org/html/rfc7230#section-3.2.6 for definition of token.

Regards,

Jouke

PS: The fact that no correct media type can be found to use in multipart/related response is for me another indicator that DICOM is breaking RFC 2387...