DICOM Web Services use the HTTP and HTTPS protocols as its transport medium. Web Services supports versions 1.0, 1.1, 2 or later of the protocol.
It is recommended that user agents that want to use HTTP/2 first initiate an HTTP/1.1 connection to the origin server and then upgrade to HTTP/2. If the upgrade fails then the user agent can still use the HTTP/1.1 connection. [RFC7540] Section 3 explains how to initiate HTTP/2 connections.
Note
HTTPS may mean any SSL or TLS version and options. [RFC7525] covers selection of TLS versions and options. There may also be national or local regulations that apply, and site-specific risk analysis may affect the selection. TLS version 1.2 or later is often required and always recommended. Earlier versions of TLS and all versions of SSL are known to be vulnerable to well publicized attacks.
The interaction shall be as shown in Figure 6-1.
Multiple communications modes are possible:
Media types are identifiers used to define the data format of a representation. HTTP uses media types in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation. The syntax of media types is:
media-type = type "/" subtype *(OWS ";" OWS parameter)
type = token
subtype = token
parameter = token "=" (token / quoted-string) )
The <type>/<subtype> may be followed by parameters in the form of name=value pairs.
The type, subtype, and parameter name tokens are case-insensitive, but the case sensitivity of parameter values depends on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.
A parameter value can be transmitted either as a token or quoted-string. The quoted and unquoted values are equivalent.
Media types are defined in [RFC7231] Section 3.1.1.1.
IANA maintains a registry of media types at http://www.iana.org/assignments/media-types/media-types.xhtml.
Some of the services defined in this Standard support the multipart media types [RFC2387]. The syntax is:
multipart-media-type = "multipart" "/" subtype *( OWS ";" OWS parameter )
The "application/multipart-related" media type is used by the RS services. Its syntax is:
multipart-related = "multipart/related"
OWS ";" OWS "type" "=" DQUOTE media-type DQUOTE
OWS ";" OWS "boundary" "=" boundary
[related-parameters]
boundary = 0*69bchar bchar-nospace
bchar = bchar-nospace / SP
bchar-nospace = DIGIT / ALPHA / "'" / "(" / ") " / "+" / "_" / "," / "-"
/ "." / "/" / ":" / "=" / "?" "/" / ":" / "=" / "?"
related-parameters = [";" "start" "=" cid]
[";" "start-info" "=" cid-list]
cid-list = cid cid-list
cid = token / quoted-string
The "type" parameter is required. It contains the media type of the "root" body part. It always contains the special character "/" and thus requires quote marks.
The <cid> is a content identifier. It should be unique for each part of the multipart message.
Typically, the "start" and "start-info" parameters are not specified, and the "root" is the first body part.
Table 6.1.1-1 defines Resource Categories that correspond to different SOP Classes. The following sections map each Resource Category to appropriate DICOM and Rendered media types.
Table 6.1.1-1. Resource Categories
|
This category includes all resources that are instances of a multi-frame SOP Class, that are not video and that contain more than one frame. |
|
|
This category includes all resources that contain more than one frame and: |
|
|
This category includes all resources that:
|
|
|
This category includes all resources that are not included above. |
DICOM instances may be converted by a rendering process into non-DICOM media types in order to display them using commonly available non-DICOM software, such as browsers.
-
A DICOM SOP Instance containing an image could be rendered into the image/jpeg or image/png Rendered Media Types.
-
A DICOM SOP Instance containing a multi-frame image in a lossless transfer syntax could be rendered into a video/mpeg or video/mp4 Rendered Media Type.
-
A DICOM SOP Instance containing a Structured Report could be rendered into a text/html, text/plain, or application/pdf Rendered Media Type.
Note
Rendered Media Types are usually consumer format media types. Some of the same non-DICOM media types are also used as Bulk Data Media Types, that is, for encoding bulk data extracted from Encapsulated Pixel Data (used with compressed Transfer Syntaxes), without applying a rendering process; see Section 6.1.1.8.
Table 6.1.1-2 specifies the meaning of media type requirement terms used in Table 6.1.1-3 and the tables in Section 6.1.1.8.
Table 6.1.1-2. Definition of Media Type Requirement Terms
|
The origin server shall return this media type when none of the Acceptable Media Types (see Section 6.1.1.4) are supported. The origin server shall support this media type. |
|
Origin servers that support Web Services shall support rendering instances of different Resource Categories into Rendered Media Types as specified in Table 6.1.1-3.
When an image/jpeg media type is returned, the image shall be encoded using the JPEG baseline lossy 8 bit Huffman encoded non-hierarchical non-sequential process defined in ISO/IEC 10918-1.
The origin server may support additional rendered media types.
A transfer syntax media type parameter is not permitted for Rendered Media Types.
The term Acceptable Media Types denotes the media types that are acceptable to the user agent in the response. The Acceptable Media Types are those specified in:
All requests that expect a response with a payload, shall include the Accept header field. The response to a request without an Accept header field shall be 406 (Not Acceptable). Even if specific media types are provided in the <accept> query parameter, an Accept header field with one or more values shall be present, at a minimum */*.
The Acceptable Media Types shall be either DICOM media-types or Rendered media types, but not both. If the Acceptable Media Types contains both DICOM and Rendered Media Types, the origin server shall return 409 (Conflict).
The user agent may specify the relative degree of preference for media types, whether in the <accept> query parameter or the Accept header field, using the <weight> parameter. See [RFC7231] Section 5.3.1.
weight = OWS ";" OWS "q=" qvalue
qvalue = ("0" ["." 0*3DIGIT]) / ("1" ["." 0*3("0") ])
The <accept> query parameter is primarily designed for use in hyperlinks (URLs) embedded in documents, where the Accept header field is not accessible. It is similar to the Accept header field, except that it shall not have wildcards (<type>/* or */*).
The <accept> query parameter has the following syntax:
accept = accept-name "=" 1#(media-type [weight])
accept-name = "%s" quoted-string
Note
The "%s" that prefixes the <accept-name> specifies that it is a case sensitive token. See [RFC7405].
Its value is a comma-separated list of one or more <media-type>s, possibly including parameters. It shall be supported by the origin server. It is optional for the user agent.
The <accept-name> of the <accept> query parameter is defined by the Service. It is case-sensitive. Table 6.1.1-4 contains the <accept-name> of the <accept> query parameter for some services.
The <accept> query parameter should not be used when the user agent can specify the values in the Accept header field.
All media types present in an <accept> query parameter shall be compatible with a media range in the Accept header field, either explicitly or implicitly through wildcards.
Note
For example, the presence of image/jpeg in the <accept> query parameter will require the Accept header field to include one of the following values: image/jpeg, image/*, or */*.
See Section 6.1.4.
The Accept header field is used to specify media ranges acceptable to the user agent. It has the following syntax:
Accept = 1#(media-range [weight])
media-range = media-type
/ type "/" "*" parameters
/ "*/*" parameters
parameters ; See Section 6.1.1
The Accept header field shall be present. Its value shall be a comma-separated list of one or more media ranges acceptable in the response. See [RFC7231] Section 5.3.2.
A media range is either a media-type or a wildcard. Wildcards use the asterisk ("*") to group media types into ranges, with <type>/* indicating all subtypes of that type, and */* indicating all media types from the target's Resource's Category.
For example, the media range "image/*" matches "image/jpeg", which is the default media type for the Single Frame Image Resource Category, and "text/*" matches "text/html", which is the default media type for the Text Resource Category. The "*/*" media range matches the default media type for the target's Resource Category.
If the origin server receives a request without an Accept header field, but that might have a response payload, it shall return a 406 (Not Acceptable).
Any Accept header field values that are not valid or not supported shall be ignored.
The Selected Media Type is the media type selected by the origin server for the response payload. The media types in the <accept> query parameter and the media ranges in the Accept header field shall each be separately prioritized according to the rules defined in [RFC7231] Section 5.3.1.
For multipart payloads the Selected Media Type is determined independently for each message part in the response.
Note
The Selected Media Type of each message part depends on the Resource Category of the Instance and the Acceptable Media Types for that Resource Category.
The Selected Media Type is chosen as follows:
-
Select the representation with the highest priority supported media type for that category in the <accept> query parameter, which is compatible with the Accept header field.
-
If no media type in the <accept> query parameter is supported, select the highest priority supported media type for that category in the Accept header field, if any.
-
Otherwise, select the default media type for the category if the Accept header field contains a wildcard media range matching the category, if any.
For a set of media types in the <accept> query parameter (step 2 above), or for a set of media ranges in the Accept header field (step 3 above), the highest priority supported media type is determined as follows:
-
Assign a <qvalue> of 1 to any member of the set that does not have a one.
-
Assign each representation supported by the origin server the <qvalue> of the most specific media type that it matches.
-
Select the representation with the highest <qvalue>. If there is a tie, the origin server shall determine which is returned.
For example, consider an origin server that receives a request with the following Accept header field:
Accept: text/*; q=0.5, text/html; q=0.4, text/html; level=1, text/html; level=2; q=0.7, image/png, */*; q=0.4
Suppose that for the resource indicated in the request, the origin server supports representations for the following media types:
text/html(regular, level 1 and level 2)
text/rtf
text/plain
text/x-latex
These media types are assigned the following <qvalue>s, based on the media ranges above:
Although "image/png" has been assigned a default <qvalue> of 1.0, it is not among the supported media types for this resource, and thus is not listed.
The selected media type is "text/html; level=1" since it is the supported media type in the Text Category with the highest qvalue.
This section defines the media types used to represent DICOM Instances and bulk data. It describes:
-
The media type and transfer syntax parameter for DICOM PS3.10 Files
-
The media types that can be used for the bulk data of single and multi-frame images and video extracted from Instances.
-
The syntax of DICOM Media Types including their transfer syntax and character set parameters.
-
The meaning of Acceptable Transfer Syntaxes and Selected Transfer Syntax.
The media types defined in this section are distinct from those into which DICOM Instances may be rendered (which are defined in Section 6.1.1.3); some of the same media types are used for both rendered content and bulk data.
Depending on the service, the media types may be single part or multipart, and may have required or optional transfer syntax and/or character set parameters.
Table 6.1.1.8-1a, Table 6.1.1.8-1b, Table 6.1.1.8-1c and Table 6.1.1.8-1d specify the media types used to encode different representations of DICOM Instances for the Web Services. These media types apply to all Resource Categories and have default encodings for images and video data elements contained in the Instances.
The definitions of media type requirements are provided in Table 6.1.1-2.
Table 6.1.1.8-1a. Media Types for DICOM PS3.10 Files
|
Encodes Composite SOP Instances in the DICOM File Format defined in PS3.10 Section 7 “DICOM File Format”. |
See Table 6.1.1.8-2 |
See Table 6.1.1.8-2 |
Table 6.1.1.8-1c. Media Types for DICOM Uncompressed Bulk Data
|
Encodes a Bulkdata object as a stream of uncompressed bytes, in little endian byte order. NoteThis is the same encoding defined in PS3.19 for the returned value of the getData() call for uncompressed Bulk Data. |
See Table 6.1.1.8-3a |
Table 6.1.1.8-1d. Media Types for DICOM Compressed Bulk Data
|
Encodes Bulkdata values, which in the case of compressed Pixel Data for WADO-RS services, will have each frame encoded as a separate part of a multipart response and identified by an appropriate Content-Type header. |
See Table 6.1.1.8-3b |
Table 6.1.1.8-2 specifies, by Resource Category (see Table 6.1.1-1) , the application/dicom media type for PS3.10 Files, along with the default and allowed Transfer Syntax UID combinations for each resource category for the Web Services. The default media type for the Resource Category shall be returned when the origin server supports none of the Acceptable Media Types.
If no transfer-syntax parameter is specified for the media type for PS3.10 Files (application/dicom) then the Explicit VR Little Endian Transfer Syntax "1.2.840.10008.1.2.1" shall be used.
Note
This is different from the Default Transfer Syntax defined in Section 10.1 “DICOM Default Transfer Syntax” in PS3.5 , which is Implicit VR Little Endian.
Table 6.1.1.8-2. Transfer Syntax UIDs for 'application/dicom' Media Type Instances in the Image or Video Resource Categories
Table 6.1.1.8-3a and Table 6.1.1.8-3b specify, by Resource Category (see Table 6.1.1-1) , the various media types for bulk data, along with the default and allowed media types and Transfer Syntax UID combinations for each resource category for the RS service.
Note
No entries are specified for the WADO-URI service, because it does not support separate retrieval of bulk data.
These media types can be used to retrieve image or video bulk data encoded in a specific Transfer Syntax.
Table 6.1.1.8-3a. Media Types and Transfer Syntax UIDs for Uncompressed Pixel Data in Bulk Data Values
Table 6.1.1.8-3b. Media Types and Transfer Syntax UIDs for Compressed Pixel Data in Bulk Data Values
The Implicit VR Little Endian (1.2.840.10008.1.2) ,and Explicit VR Big Endian (1.2.840.10008.1.2.2) transfer syntaxes shall not be used with Web Services.
If a transfer syntax parameter for a DICOM Media Type is not specified in a request or response, the Transfer Syntax in the response shall be the Transfer Syntax specified as the default for the Resource Category and media type combination in Table 6.1.1.8-3a or Table 6.1.1.8-3b.
The origin server may support additional Transfer Syntaxes.
Note
-
The compressed bulk data of each part of a multipart payload contains only the compressed bit stream and not the DICOM PS3.5 Encapsulated Sequence or Delimiter Items.
-
For the media type image/dicom+jpeg Transfer Syntaxes, the image may or may not include the JFIF marker segment. See Section 8.2.1 “JPEG Image Compression” in PS3.5 .
-
For the media type image/dicom+jp2 and image/dicom+jpx Transfer Syntaxes, the image does not include the jp2 marker segment. See Section 8.2.4 “JPEG 2000 Image Compression” in PS3.5 and Section A.4.4 “JPEG 2000 Image Compression” in PS3.5 .
-
The resource on the origin server may have been encoded in the Deflated Explicit VR Little Endian (1.2.840.10008.1.2.1.99) transfer syntax. If so, the origin server may inflate it, and then convert it into an Acceptable Transfer Syntax. Alternatively, if the user-agent allowed a Content-Encoding header field of 'deflate', then the deflated bytes may be transferred unaltered, but the transfer syntax parameter in the response should be the Explicit VR Little Endian transfer syntax.
-
Compressed multi-frame image bulk data is encoded as one frame per part. E.g., each frame of a JPEG 2000 multi-frame image will be encoded as a separate part with an image/jp2 media type, rather than as a single part with a video/mj2 (RFC 3745) or uncompressed application/octet-stream media type.
-
Video bulk data is encoded as a single part containing all frames. E.g., all frames of an MPEG-4 video will be encoded as a single part with a video/mp4 (RFC 4337) media type.
-
Many of the media types used for compressed Pixel Data transferred as bulk data values are also used for consumer format media types. The browser may not be able to display the encoded data directly, even though some of the same media types are also used for encoding rendered Pixel Data; see Section 6.1.1.3.
E.g., the media type for bulk data values of lossless 16-bit JPEG 10918-1 encoded Pixel Data is "image/jpeg", the same as might be used for 8-bit JPEG 10918-1 encoded Pixel Data, whether extracted as bulk data, or rendered. The transfer syntax parameter of the Content-Type header field is useful to signal the difference.
The syntax of DICOM Media Types is:
dicom-media-type = (dcm-singlepart / dcm-multipart) [dcm-parameters]
dcm-singlepart = dcm-mt-name
dcm-multipart ; see Section 6.1.1.8.1.1.
dcm-parameters = transfer-syntax-mtp ; see Section 6.1.1.8.1.2.
/ charset-mtp ; see Section 6.1.1.8.1.3.
dcm-mt-name = dicom / dicom-xml / dicom-json ; DICOM Media Type name
dicom = "application/dicom"
dicom-xml = "application/dicom+xml
dicom-json = "application/dicom+json"
octet-stream = "application/octet-stream"
All DICOM Media Types may have a transfer syntax parameter, but its usage may be constrained by the service for which they are used.
Note
Note. The application/dicom+xml and application/dicom+json Media Types may have a transfer syntax parameter in order to specify the encoding of inline binary data.
All DICOM Media Types may have a character set parameter, but its usage may be constrained by the service for which they are used.
The syntax of multipart media types is:
dcm-multipart = "multipart/related"
OWS ";" OWS "type" "=" dcm-mp-mt-name
OWS ";" OWS "boundary=" boundary
[dcm-parameters]
[related-parameters]
dcm-mp-mt-name = dicom / dicom-xml / dicom-json / octet-stream
See Section 6.1.1.1 for the definition of boundary and related-parameters.
Each multipart media type shall include a "type" parameter that defines the media type of the parts, and shall also include a "boundary" parameter that specifies the boundary string that is used to separate the parts.
All DICOM Media Types may have a single transfer syntax parameter, but its usage may be constrained by the service for which they are used.
RS origin servers shall support the transfer syntax parameter.
Transfer syntax parameters are forbidden in URI requests and responses.
transfer-syntax-mtp = OWS ";" OWS $s"transfer-syntax=" ts-value
ts-value = transfer-syntax-uid / "*"
transfer-syntax-uid ; a UID from PS3.6 Table A-1 with a UID Type of Transfer Syntax
The value of the transfer syntax parameter may be either a Transfer Syntax UID or the token "*".
For example, to specify that 1.2.840.10008.1.2.4.50 is the acceptable Transfer Syntaxes, an Accept header field could be:
Accept: application/dicom; transfer-syntax=1.2.840.10008.1.2.4.50
A DICOM Media Type may only have one transfer syntax parameter and it shall have only one value.
Note
Per RFC 6838 Media Type Specifications and Registration Procedures, it is an error for a specific parameter to be specified more than once. If a choice of Transfer Syntaxes is acceptable. more than one media type may be provided in the Accept header with different q parameter values to indicate preference. E.g., to specify that 1.2.840.10008.1.2.4.50 and to specify that 1.2.840.10008.1.2.4.57 are acceptable but 1.2.840.10008.1.2.4.50 is preferred, an Accept header field could be:
Accept: multipart/related; application/dicom;transfer-syntax=1.2.840.10008.1.2.4.50,
application/dicom;transfer-syntax=1.2.840.10008.1.2.4.57;q=0.5
The wildcard value "*" indicates that the user agent will accept any Transfer Syntax. This allows, for example, the origin server to respond without needing to transcode an existing representation to a new Transfer Syntax, or to respond with the Explicit VR Little Endian Transfer Syntax regardless of the Transfer Syntax stored.
If an Origin server supports the transfer syntax parameter, it shall support the wildcard value.
Origin servers that support the transfer syntax parameter shall specify in their conformance statement those values of transfer syntax parameter that are supported in the response.
User agents that support the transfer syntax parameter shall specify in their conformance statement those transfer syntax parameter values that may be supplied in the request.
The DICOM Media Type character set parameter is used to specify Acceptable Character Sets for the response. A DICOM Media Type may have a single character set parameter, which shall have only a single value.
charset-mtp = OWS ";" OWS %s"charset" "=" charset
All DICOM Media Types shall have a Default Character Set of UTF-8.
See Section 6.1.2 for character set details.
The transfer syntax query parameter specifies a comma-separated list of one or more Transfer Syntax UIDs, as defined in PS3.6. It is optional.
transfer-syntax-qp = ts-parameter-name "=" (1#transfer-syntax-uid / "*")
ts-parameter-name = %s quoted-string
The URI service defines the ts-parameter-name to be "transferSyntax", which is case-sensitive.
The RS service uses the transfer syntax parameter in the "accept" query parameter (see Section 6.1.1.5) and the transfer syntax query parameter is not supported.
Each media type in the Acceptable Media Types has an associated set of Acceptable Transfer Syntaxes.
The Acceptable Transfer Syntaxes for a media type can be specified in any of the following ways, depending on the service:
-
The transfer syntax media type parameter contained in the accept query parameter (see Section 6.1.1.5)
-
The value(s) contained in the transfer syntax query parameter (see Section 6.1.1.8.4)
-
The transfer syntax media type parameter contained in the Accept header field.
The Selected Transfer Syntax is the transfer syntax selected by the origin server to encode a single message part in the response.
The origin server shall first determine the Selected Media Type as defined in Section 6.1.1.7 and then determine the Selected Transfer Syntax.
If the Selected Media Type was contained in the accept query parameter, then the Selected Transfer Syntax is determined as follows:
If the Selected Media Type was contained in the Accept header field, then the Selected Transfer Syntax is determined as follows:
The URI and RS APIs support the following DICOM Media Types:
uri-media-type = dicom
rs-media-types = (dcm-multipart / dicom-json) [dcm-parameters]
Support for the transfer syntax and charset media type parameters is required for RS services.
Support for the "transfer-syntax" and "charset" parameters is forbidden for URI Services (i.e., they may not present in the request or the response).
HTTP uses charset names to indicate or negotiate the character encoding of textual content in representations [RFC6365] Section 3.3.
Character sets may be identified using the value in the IANA Preferred MIME Name column in the IANA Character Set Registry http://www.iana.org/assignments/character-sets/character-sets.xhtml.
Character sets may be identified by using the DICOM Defined Terms for the character set. See Section C.12.1.1.2 “Specific Character Set” in PS3.3 , and Section 6.1.2.3 “Encoding of Character Repertoires” in PS3.5 .
The origin server shall support the "UTF-8" charset name for RS Retrieve Rendered, but is not required to support the DICOM Defined Term "ISO_IR 192".
charset = token / defined-term / DQUOTE defined-term DQUOTE
Some DICOM Defined Terms for character sets contain space characters; and shall be enclosed in double quotes in HTTP header fields and percent encoded in URLs.
The Conformance Statement shall document all supported character sets. The Retrieve Capabilities response for all RS Services shall also document all supported character sets.
A request without any <charset> query parameter or Accept-Charset header field implies that the user agent will accept any charset in the response.
Annex D contains a mapping of some Specific Character Set (0008,0005) Defined Terms to IANA charset tokens.
The term Acceptable Character Sets denotes the character sets that are acceptable to the user agent in the response. The Acceptable Character Sets are those specified in:
When the Acceptable Character Sets contains a list of one or more Defined Terms they should be ordered as specified in Section C.12.1.1.2 “Specific Character Set” in PS3.3 and Section 6.1.2.3 “Encoding of Character Repertoires” in PS3.5 . This is especially important for ISO 2022 character sets.
Any Accept-Charset header field values that are not defined in Annex D or not supported shall be ignored.
The character set query parameter is primarily designed for use in hyperlinks (URLs) embedded in documents, where the Accept-Charset header field is not accessible.
The character set query parameter has the following syntax:
charset-qp = name "=" 1#(charset [weight])
The character set query parameter value is a comma-separated list of one or more charsets. It is similar to the Accept-Charset header field, except that it shall not have wildcards. It shall be supported by the origin server. It is optional for the user agent.
All charsets present in the character set query parameter may have a corresponding character set in the Accept-Charset header field, either explicitly or implicitly through wildcards.
The name of the character set query parameter is defined by the Service. Table 6.1.2-1 contains the names of the character set query parameter for some services.
If this parameter has a value that is not supported it shall be ignored.
See Section 6.1.4.
The Accept-Charset header field has the following syntax:
Accept-Charset = 1#(charset [weight]) / ("*" [weight])
The user agent may provide a list of Acceptable Character Sets in the Accept-Charset header field of the request. Its value is a comma-separated list of one or more <charset>s and/or the wildcard value ("*"). It shall be supported by the origin server. It is optional for the user agent.
The values of the Accept-Charset header field values are prioritized by their <weight> parameter.
If no wildcard ("*") is present, then any character sets not explicitly mentioned in the header field are considered "not acceptable" to the client.
A request without an Accept-Charset header field implies that the user agent will accept any charset in response.
If the media type defines a "charset" parameter, it should be included with the media type in the Accept header field, rather than in the Accept-Charset header field.
Any Accept-Charset header field values that are not supported shall be ignored.
The origin server shall determine the Selected Character Set(s) as follows:
-
Select the first supported character set in the "charset" parameter(s) of the Selected Media Type.
-
Otherwise, select the highest priority supported <charset> in the <character-set> query parameter.
-
Otherwise, select the highest priority supported <charset> in the Accept-Charset header field.
-
Otherwise, if the Selected Media Type has a default character set that is supported, select it.
Rendered representations returned in the response shall have all contained strings returned in the Selected Character Sets.
If the character set in which the target resource is encoded is not the Selected CharacterSet:
Note
This means that some SOP Instances may be convertible and others will not be, even though they have the same Specific Character Set (0008,0005).
All origin servers shall support conversion to the UTF-8 character set for RS Rendered Retrieve.
If the user agent chooses to perform its own conversion rather than have it done by the origin server:
-
The user agent may omit the Accept-Charset header field or send the "*" wildcard
-
The user agent may transcode the character set replacing all unknown characters with a suitable replacement. For example:
-
A question mark ("?"), or other similar character indicating an unknown character.
-
The corresponding Unicode Code Point for the character, represented as "U+xxxx".
-
The four characters "\nnn", where "nnn" is the 3 digit octal representation of each byte (see Section 6.1.2.3 “Encoding of Character Repertoires” in PS3.5 ).
-
The Content-Type header field specifies the media type of the payload. It should only be present when a payload is present, and any media type parameters shall specify the encoding of the corresponding message part.
In particular, a DICOM Media Type used as the value of a Content-Type header field shall have zero or one transfer syntax parameter (see Section 6.1.1.8.1.2), and zero or one charset parameter (see Section 6.1.1.8.1.3), which corresponds to the character encoding of the corresponding message part.
Content-Type: dicom-media-type +transfer-syntax-mtp +charset-mtp
If there is a conflict between the Transfer Syntax specified in the media type and the one specified in the File Meta Information Transfer Syntax UID (0002,0010) attribute, the latter has precedence.
[RFC3986] does not permit an empty query component, i.e., if the "?" appears in the Target URI, then there shall be at least one Query Parameter in the URI.
The origin server may define and support additional Query Parameters, or additional Query Parameter values for an existing Query Parameter. If an origin server defines new or extends existing Query Parameters, they shall be included in the Conformance Statement and, if the service supports it, the Retrieve Capabilities response.
The origin server shall ignore any unsupported Query Parameters. The origin server shall process the request as if the unsupported parameters were not present, and should include a payload containing an appropriate warning or error message.
If a supported Query Parameter has an invalid value, the origin server shall return a 400 (Bad Request) error response, and should include should include a payload containing an appropriate warning or error message.