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

From: [email-masked]
Date: Fri, 6 Dec 1996 08:49:09 -0500

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@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.

---

From: [email-masked]
Date: Fri, 6 Dec 1996 09:12:38 -0500

Classification:
Prologue:
Epilogue:

Sorry ... the file is called whyhttp.ps and is in the ...for-discussion
directory.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/06/96 06:46
AM ---------------------------

        ipp-owner @ pwg.org
        12/05/96 03:58 PM

To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org@internet
Subject: Re: IPP> Why HTTP and thoughts on forms etc

Roger,

What is the URL of the file you uploaded?

 ...jay

---

From: [email-masked] (Robert Herriot)
Date: Mon, 9 Dec 1996 15:00:57 -0800

Yes, Jay, this is exactly what I had in mind. 

I find it interesting that when other people work with this MIME
structure they see new ways of using it.  I had not thought about
including separator page information in the way that you suggested, but
it seems like a natural use the MIME structure.

Bob Herriot

> 
>   Content-type: multipart/mixed;                -- Outer msg "wrapper"
>     Content-type: application/ippjob;           -- Job attribute set
>       Username: Jane Doe
>       ...                                       -- Other job attributes
>     Content-type: application/ippseparator;     -- Banner sheet
>       Type: banner
>       Color: blue
>       ...                                       -- Other banner options
>     Content-type: application/postscript        -- The 1st document
>       %!PS-...
>       ...
>     Content-type: application/pcl               -- The 2nd document
>       ...
>     Content-type: multipart/mixed               -- The 3rd document
>       ...
>       Content-type: application/ippdocument     -- 3rd document options
>         Cover-sheet: fax
>         From: John Doe
>         ...                                     -- Other cover options
>       Content-type: fax/g3                      -- The 3rd document
>         ...
>     Content-type: text/plain                    -- The 4th document
>       ...
>     Content-type: application/ippseparator;     -- Trailersheet
>       Type: trailer
>       Color: default
>       Inserts: processing-time, sheets-used, interpreter-messages
>       ...                                       -- Other trailer options