Existing Wording: Note that when client requests a binary resource using a generic mime type (application/xml, text/xml, or application/json), the server SHOULD return the content directly if the content-type format matches the requested mime type (e.g. if the Accept header is appplication/json, and the?contentType?is vnd.xacml+json).

Comment:

The content of section 2.33.3.1 does not flow. Paragraphs 1, 2, 5 talk about retrieve, 4 is create. I suggest:

• Retrieve when specifying application/fhir types

• Retrieve when specifying other types

• Retrieve when asking for types that don't match either the binary contentType or application/fhir. This can cover things like returning a JPEG as PNG or the generic mime types conversions currently included.

• Clarify that the _summary parameter only applies to retrieving application/fhir content (which therefore returns a Binary), and thus never applies to the content of the Binary (you can't get a summary of a Composition stored in a Binary).

• Create when the content is application/fhir and is Binary

• Create when the content is application/fhir but not a Binary, or is not application/fhir

• Header mappings (clarifying that it is two-way) (hmm, do we define behaviour if posted application/fhir Binary content doesn't match headers?)

Note that there is a "should" in the first paragraph and a "SHOULD" in the fifth. We should be consistent throughout the entire spec.

Summary:

Restructure Binary contentType handling descriptions