Classification:
Prologue:
Epilogue:
Response to Bob's comments ...
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/06/96 06:29
AM ---------------------------
ipp-owner @ pwg.org
12/05/96 04:55 PM
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org at internet
cc:
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.
Page 2:
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.
Page 6:
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.
Page 6:
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
<<RKD>> Content-:.
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
application/PostScript.
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,
application/ippdocument, application/PostScript,
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 "-----".
Page 8:
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.