Subject: Re: IPP> Why HTTP and thoughts on forms etc -Reply

From: "Scott A. Isaacson" <[email-masked]>
Date: Wed, 18 Dec 1996 09:27:24 -0700

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: [email-masked]
W: http://www.novell.com
************************************************************

---

From: [email-masked]
Date: Thu, 19 Dec 1996 08:49:03 -0500

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@internet
cc:
Subject: Re: IPP> Why HTTP and thoughts on forms etc -Reply

General comments:

Scott

---

From: [email-masked] (Robert Herriot)
Date: Thu, 19 Dec 1996 16:22:36 -0800

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 [email-masked] Thu Dec 19 05:50:32 1996

---

From: [email-masked]
Date: Fri, 20 Dec 1996 08:41:57 -0500

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

Bob Herriot

> 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!

---

From: [email-masked] (Robert Herriot)
Date: Fri, 20 Dec 1996 16:30:51 -0800

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 [email-masked] Fri Dec 20 05:43:44 1996
>