IPP> Why HTTP and thoughts on forms etc -Reply

[rdebry at us.ibm.com]

Classification:
Prologue:
Epilogue:


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!