MINT and Transfer Syntax Negotiation
Jason Nye
Hi All,
The current version of the MINT specification does not allow for transfer syntax negotiation and I think this may be a problem with maximizing interoperability going forward. For example, if a dataset is pushed using a JPEG 2000 transfer syntax, a viewer that can only handle little endian implicit uncompressed data will not be able to read that dataset.
I talked to Tim Dawson about a proposed solution to this:
1. The client requests the metadata with a list of transfer syntaxes it can support, in order of preference.
2. The MINT server selects the transfer syntax to use, prepares the metadata (possibly massaging it to account for the specifics of the transfer syntax) and returns it. The transfer syntaxes in the metadata will be the transfer syntax the MINT selected.
3. When the client wants binary data that is stored as bids, it will send this transfer syntax along with the request and the MINT will format the binary data according to the specified transfer syntax if necessary. NOTE: It is assumed that the client has already negotiated a transfer syntax in the request for the metadata and it is also generally assumed that the binary data would be requested after the metadata was requested. For these reasons, I don’t think we need to have the client specify a list of accepted transfer syntaxes here. Although, I don’t see any harm in doing so either; however, the selected transfer syntax would have to be sent along with the binary data in the response.
4. If any request for data does NOT include accepted transfer syntaxes, the MINT should fall back to the current default behavior.
5. If the MINT cannot produce the data in one of the client-specified transfer syntaxes, it should return an error to the client.
I think this functionality will be required to encourage widespread adoption of MINT. Any thoughts?
Thanks,
Jason.
Daniel Chaffee
/studies/{studyuid}/series/{seriesUID}/instances/{SOPInstanceUID}/formats/{xfersyntax}
To tie the xfer syntax request right into the URL as a resource. In this way it is fully cacheable. In terms of the metadata that is an interesting point. Another option might just be to let the MINT server list in the metadata which xfer syntaxes its supports and then let the client request what it wants from the resultant resources like above. In this way we can decouple requests of metadata from requests of binary data.
What about removing xfer syntax from the metadata entirely and let the server list what it supports as a separate resource. Maybe someone can educate me here on this point. Are xfer syntaxes that a sever supports on a study by study basis, or generally on a server basis. If the entire server supports a set of xfer syntaxes for all studies then it might make sense to just have a resource that lists those and let the client pass that back into a request for metadata and binary items...vs a negotiation on every study request.