DAP4: DAP4 Multipart Mime Format: Difference between revisions
No edit summary |
No edit summary |
||
Line 6: | Line 6: | ||
== Introduction == | == Introduction == | ||
A DataDDX response is the way DAP4 returns data to a client. Each DataDDX response is returned over the wire as a multipart MIME document where the first part contains the DDX describing the data requested and the second | A DataDDX response is the way DAP4 returns data to a client. Each DataDDX response is returned over the wire as a multipart MIME document where the first part contains the DDX describing the data requested and the second and later parts contains a binary encoding of the requested data or error information. | ||
See the [[DAP4: DDX Grammar | DAP4 DDX Grammar]] document and the | See the [[DAP4: DDX Grammar | DAP4 DDX Grammar]] document and the |
Revision as of 21:29, 8 May 2012
Note: This document is a revision of material from DAP4 Design.
Introduction
A DataDDX response is the way DAP4 returns data to a client. Each DataDDX response is returned over the wire as a multipart MIME document where the first part contains the DDX describing the data requested and the second and later parts contains a binary encoding of the requested data or error information.
See the DAP4 DDX Grammar document and the DAP4 Lexical Elements document for the DDX syntax and lexical structure respectively. See the on-the-wire format document for the format of transmitted data.
For references to the Multipart MIME specification, see The MIME Multipart/Related Content-type (rfc 2387) and MIME part one.
Organization of the multipart MIME document
Here's what the shell of the document looks like:
Content-Type: multipart/related; type="text/xml"; start="<<start id>>"; boundary="<<boundary>>" --<<boundary>> Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: binary Content-Description: ddx Content-Id: <<start-id>> <<DDX here>> --<<boundary>> Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Description: data Content-Id: <<unique id for this piece of binary data>> <<XDR encoded binary data, part 1>> --<<boundary>> Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Description: data Content-Id: <<unique id for this piece of binary data>> <<XDR encoded binary data, part 2>> ... --<<boundary>> Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Description: data Content-Id: <<unique id for this piece of binary data>> <<XDR encoded binary data, part n>> --<<boundary>>
The example shows multiple sets of MIME headers separated by --<<boundary>> lines; The final boundary line terminates the document. The first group of headers (in a real response, there would be other headers here like Date, XDAP, and others) provide information need to recognize the boundary separators. The payload of that first data part contains references to the related parts using the values of their Content-Id headers (See here).
Choosing values for the DataDDX Content-Ids and Boundaries
We would like the software that builds these DataDDX responses to be compatible with as many different transport protocols as possible, so long as the cost to the implementation for which we know we must support is low. One thing that some transport protocols may do is combine several DataDDX responses into a single document and, while the specifics of that will vary between protocols, one choice we can make now that will facilitate that is to ensure that the values of the Content-Ids and <<boundary>>s are unique within and across systems. This will free software that combines DataDDX responses from having to process the DDX and Content-Id header to ensure that no name collisions are present. While using UUIDs, for example, makes the result values 'ugly', it adds virtually nothing to the time needed to build or process the responses. Other schemes, that combine a URI with some system-generated token could also be employed. The important point is to ensure that these symbols are unique not only within a system, but across systems.
ndp 12:42, 30 March 2010 (PDT) Dennis Heimbigner Modified 5/7/2012.