IPP> Why HTTP and thoughts on forms etc -Reply

IPP> Why HTTP and thoughts on forms etc -Reply

IPP> Why HTTP and thoughts on forms etc -Reply

Robert Herriot robert.herriot at Eng.Sun.COM
Fri Dec 20 19:30:51 EST 1996


The point I was trying to make is that all subtypes of Multipart
must have boundaries.  That is, boundaries are a fundamental part of
Multipart.  And in the RFC 1521, there is no concept of Content-length.


But that is the world of general MIME. HTTP seems to have made
some worthwhile improvements and extensions to MIME. 


I have now read through pertinent parts of HTTP/1.1
(draft-ietf-http-v11-spec-07.txt) and have concluded that HTTP extends
MIME by giving Content-length a high priority for determining length.
It is not clear whether this applies to Multipart entities, but I think
we should influence the authors to say that even though boundaries are
required by Multipart, the Content-length has priority.  The byte count
for chunking definitely has priority because an entity-body of a
Multipart/mixed could contain a series of chunks, each preceded by
their length.


Rather than trying to fix rfc 1521, I suggest we follow the MIME
extensions in HTTP/1.1 and influence their changes. The Content-Length
and chunking are exactly what we need in the printing world. 


I have sent these comments to the HTTP email group.


Bob Herriot




Bob Herriot


> From rdebry at us.ibm.com Fri Dec 20 05:43:44 1996
> 
> I agree, and that is why I had suggested a new construct which I called
> Multipart/IPP in the proposal below.
> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/20/96 06:39
> AM ---------------------------
> 
>         ipp-owner @ pwg.org
>         12/19/96 05:23 PM
> 
> 
> To: Roger K Debry/Boulder/IBM, ipp @ pwg.org at internet
> cc:
> Subject: Re: IPP> Why HTTP and thoughts on forms etc -Reply
> 
> 
> Although I share your distaste for the boundary and prefer Content-Length,
> I expect that we would have to do it through some new construct.
> RFC 1521 is very clear in its initial paragraph on multipart:
> 
> 7.2.  The Multipart Content-Type
> 
>    In the case of multiple part entities, in which one or more different
>    sets of data are combined in a single body, a "multipart" Content-
>    Type field must appear in the entity's header. The body must then
>    contain one or more "body parts," each preceded by an encapsulation
>    boundary, and the last one followed by a closing boundary.  Each part
>    starts with an encapsulation boundary, and then contains a body part
>    consisting of header area, a blank line, and a body area.  Thus a
>    body part is similar to an RFC 822 message in syntax, but different
>    in meaning.
> 
> I don't think this leaves any room for a new subtype of multipart which
> does not have a boundary string.
> 
> Bob Herriot
> 
> 
> > From rdebry at us.ibm.com Thu Dec 19 05:50:32 1996
> 
> >
> > We had some discussion of this at the IETF meeting. The multipart/mixed mime
> > type apparently allows content-length, but it is not used for anything in the
> > server. In fact, we were told that if a content-length field exists, the
> > boundary string must still be present and must be used as the boundary.
> > Therefore I would like to suggest a new mime type called multipart/IPP (or
> > something similar) where we can define the rules  for boundaries, I would
> > suggest that if no content-length field is present in a sub-part then boundary
> > strings are used as defined in the current multipart/mixed mime type. However,
> > if a content-length field is present in a sub-part, no boundary string is
> > defined and the content-length field is used.
> >
> > Lengths are extremely valuable for processing on the server side and can make
> a > significant difference in error recovery and in moving data around. I'd
> agree > with Scott's assessment - if the lengths are known, use them!
> 
> 



More information about the Ipp mailing list