6 Data Communication Requirements

6.1 INTERACTION

[pic]

Figure 6- 0>= 1 "D." 1 — Interaction Diagram

The interaction shall be as shown in Figure 6-1.

6.2 HTTP Request

The HTTP Request used shall use the GET method as defined in IETF RFC2616.

6.2.1 Parameters of the HTTP Request

The parameters of the <query> component of the Request-URI to be sent to the web Server through the HTTP GET method request shall be represented as defined in IETF RFC2396.

Notes: 1. Other components of the Request-URI depend on the configuration, e.g. location and script language of the Web Enabled DICOM Server.

2. The means by which the Web Client System obtains the value of the necessary parameters for web accessing of DICOM objects is out of the scope of the standard.

6.2.2 List of Media types supported in the Response

The "Accept" field of the GET method request shall specify the Media type(s) acceptable to the Web Client System. The(se) Media type(s) shall include at least the items of the list of MIME types specified in Section 7 of this standard devoted to the DICOM persistent object types.

Note: Typically the Accept field will be sent by a Web Client as “*/*”. An optional parameter specifies the MIME type(s) preferred by the Web Client, as a subset of those specified in the "Accept" field.

6.2.3 List of character sets supported in the Response

The "Accept-charset" field of the GET method request shall specify the character set of the object to be retrieved. If the "Accept-charset" field of the GET method is not present, or the Web Enabled DICOM Server does not support the specified character set, the character set of the response will be at the discretion of the Web Enabled DICOM Server.

Note Typically the user of a Web Client does not have control over the “Accept-charset” field. An optional parameter specifies the character set to be used in the returned object.

6.3 HTTP Response

The response shall be an HTTP Response Message as specified in IETF RFC2616.

Note: The content of the message-body varies according to the Media type as defined below.

6.3.1 Body of single DICOM MIME sub-type part response

6.3.1.1 MIME Type

The MIME type shall be ‘application/dicom‘, as specified in IETF RFC3240.

6.3.1.2 Content

The body content shall be a "Part 10 File" that includes a meta-header as defined in PS 3.10.

6.3.1.3 Transfer syntax

The returned DICOM object shall be encoded using one of the transfer syntaxes specified in the transfer syntax query parameter as defined in Section 8.2.11 below. By default, the transfer syntax shall be "Explicit VR Little Endian".

Note: This implies that retrieved images are sent un-compressed by default.

6.3.2 Body of Non–DICOM MIME type response

6.3.2.1 MIME Type

The MIME type shall be one on the MIME types defined in the contentType parameter, preferably the most desired by the Web Client, and shall be in any case compatible with the ‘Accept’ field of the GET method.

Note: The HTTP behavior is that an error (406 – Not Acceptable) is returned if the required content type cannot be served.

6.3.2.2 Content

The content shall be a single MIME part containing the object to be retrieved.

Note: Multiple objects in a response are not supported by this standard. The parameters select only a single object to retrieve. Most current Web Clients are able to retrieve single objects, within a "non multipart" MIME body, and are not able to support multipart/related or multipart/mixed responses.