- From: Alex Milowski <alex@milowski.org>
- Date: Thu, 7 Jan 2010 10:40:38 -0800
- To: Florent Georges <fgeorges@fgeorges.org>
- Cc: XProc Comments <public-xml-processing-model-comments@w3.org>
On Thu, Dec 24, 2009 at 8:55 AM, Florent Georges <fgeorges@fgeorges.org> wrote: > Hi, > > In p:http-request, a multipart request or response content is > represented as: > > <c:multipart > content-type? = string > boundary = string> > c:header*, > c:body+ > </c:multipart> > > While this maps directly the HTTP entity content structure, > this fails to express the semantics: a multipart is a set of > parts, each of them having a set of headers and a content: > > <c:multipart > content-type? = string > boundary = string> > c:part+ > </c:multipart> > > <c:part> > c:header*, > c:body+ > </c:part> > > This is of course equivalent, but in the later case the > physical structure matches the logical structure. Furthermore > (and I would say more importantly), the former case requires > grouping to get the headers corresponding to one part, and I am > afraid that will be blocking for same applications. If you look at section 6.1 of RFC 2387, you'll see that body parts only require Content-* headers. As of the current draft, that is all we support and it is sufficient for transmitting multipart/related content. I'd be interested in any RFC that describes a header that isn't a content header as described in RFC 2387 that is intended to be used in a multipart entity body rather than as a header for the multipart/related message itself. In the future, we can support multipart bodies with arbitrary headers, as you suggest with a separate element, but we haven't found any requirement to do so as of yet. [1] http://tools.ietf.org/html/rfc2387 -- --Alex Milowski "The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered." Bertrand Russell in a footnote of Principles of Mathematics
Received on Thursday, 7 January 2010 18:41:19 UTC