Classification:
Prologue:
Epilogue:
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!
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/19/96 06:39
AM ---------------------------
ipp-owner @ pwg.org
12/18/96 11:11 AM
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org at internet
cc:
Subject: Re: IPP> Why HTTP and thoughts on forms etc -Reply
General comments:
1. Given that we have an embedded protocol as Roger has outlined in
the "whyhttp" doc on the server, Bob suggests that we should use
POST for all IPP operations. I am now also convinced this this is the
case.
2. We should introduce the fields for Content-length and Document-length
fields. Bob notes that "these fields are nice in some circumstances, but
they create a problem of receiving documents via stdin where the length
is unknown." If the value is "bounded" then look the the "boundry="
fields. I think that it is up to the implmenter of entity to decide on the
tradeoff between "use an aglorithm that generates a unique string with a
low probability of conflict" and "use an algorithm that generates a unique
string with ZERO probability of conflict (prescan, filter and modify as the
stream is passed, etc.)" The rules should be: If the length is known use
it. Otherwise use a "low probability" boundy algorithm unless some
environment QOS indicator suggests using a "zero probability" boundry
algorithm.
3. The embedded protocol that Roger suggests is a GREAT idea since it
can then be sent in an HTTP POST, and email, or anything else. The IPP
protocol is separated from the transport. This lack of clean separation
has caused MANY problems in migration to new products and
technologies.
4. I agree with Bob's suggestions on MIME encodings or documents and
jobs with regard to order and scoping.
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************