Response to Bob's comments ...
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/06/96 06:29
ipp-owner @ pwg.org
12/05/96 04:55 PM
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org at internet
Subject: Re: IPP> Why HTTP and thoughts on forms etc
Great job Roger! Your write-up addresses a lot of important issues.
I have the following comments.
Your description of the difference between the way information is
passed into a CGI script for GET and POST makes me wonder if
we shouldn't use POST for GetAttributes and GetJobs too.
<<RKD>> I came to the same conclusion.
You got my idea pretty much right. The only difference I see is where
you have 'content-type:text/plain' for the job attributes, I suggested
'content-type:application/ippjob' to make it clear that there is
special stuff there. This difference also means that if one entity body
in a multipart/mixed has a content-type of 'application/ippjob', then a
server (cgi script) can assume that the other entity-bodies are
documents. We might even require that the first entity-body be
application/ippjob to simplify processing.
At the bottom of the page you state that the two problems of boundary
and order of entity bodies could be show stoppers. You are also
concerned about adding document attributes.
<<RKD>> I agree that we can define conventions that will
<<RKD>> structure the datastream as you have described.
<<RKD>> However, I still would like to see a length field.
<<RKD>> I believe it will simplify processing.It may even
<<RKD>> be possible to add Content_length as one of the
<<RKD>> header fields for each body part of a multipart
<<RKD>> message and still conform to RFC 1521. Although no
<<RKD>> examples are given and it he use of a length field
<<RKD>> is not explicitly discussed, RFC 1521 does say that
<<RKD>> "The only heder fields that have defined meaning for
<<RKD>> body parts are those the names of which begin with
I will discuss why boundaries aren't a problem below. But first with
regard to ordering, it should be fairly easy to define that servers
(i.e. cgi-scripts) shall assume that the first entity body of the
multipart/mixed is of type application/ippjob and that all subsequent
entities are documents in the order that a user submitted them.
Furthermore a document may be just a document or it may be structured.
If it is a document, its content-type is text/plain,
application/PostScript or whatever. If it is structured, its
content-type is multipart/mixed with a first entity body whose
content-type is application/ippdocument and a second entity body
whose content-type is a document, such as text/plain or
There are certainly other arrangements where the
application/ippdocument is at the same level as application/ippjob and
immediately precedes the document that it modifies. In this case the
entities for a 3 PostScript document job with overrides in the second
document would be: application/ippjob, application/PostScript,
You state that construction of boundaries require prescanning a
document. Prescanning is one solution, but as the quote from rfc 1521
below shows, this is not necessarily the expected solution. And from
samples I have seen, programs generate unique boundary-id via an
algorithm that does not require scanning of the contents.
NOTE: Because encapsulation boundaries must not appear in the body
parts being encapsulated, a user agent must exercise care to
choose a unique boundary. The boundary in the example above could
have been the result of an algorithm designed to produce
boundaries with a very low probability of already existing in the
<<RKD>> I saw this note while reading RFC1521,
<<RKD>> but as it says, the best you can do is
<<RKD>> have a low probability that the string
<<RKD>> will not appear in the body-part.
<<RKD>> If it only happens once in 10,000 print
<<RKD>> jobs it doesn't matter if it is the one
<<RKD>> that I want to print.
Borenstein & Freed [Page 31]
RFC 1521 MIME September 1993
data to be encapsulated without having to prescan the data.
Alternate algorithms might result in more 'readable' boundaries
for a recipient with an old user agent, but would require more
attention to the possibility that the boundary might appear in the
encapsulated part. The simplest boundary possible is something
like "---", with a closing boundary of "-----".
I still think that my proposal is the most viable in the HTTP context.
You show Content-length and Document-length fields. These fields are
nice in some circumstances, but they create a problem of receiving
documents via stdin where the length is unknown.