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

From: [email-masked] (Robert Herriot)
Date: Thu, 5 Dec 1996 15:51:30 -0800

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.

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.

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

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: Andy Newman <[email-masked]>
Date: Fri, 6 Dec 1996 15:11:16 +1100 (EST)

> we shouldn't use POST for GetAttributes and GetJobs too.

Good point however HTTP has specific meanings for its requests that,
although abusable maybe should be respected. A GET is supposed to
(according to the HTTP spec.) "retrieve whatever information (in
the form of an entity) as identified" by the request's URI. The POST
method is used "to request that the destination server accept the
entity enclosed in the request as a new subordinate of the resource
identified buy the Request-URI." The practical side comes into play
too where passing parameters to a CGI program invoked with the GET
request can run into limits on the size of command lines or environment
space where POST doesn't have this limitation.

> documents via stdin where the length is unknown.

Content-length is mandatory when using the POST method, HTTP requires it.
This is one of the issues for tunnelling data inside HTTP. As is mentioned
in the draft IPP spec. HTTP/1.1 offers the ability to send "chunks" which
helps here.

--
Andy Newman <[email-masked]>

---

From: JK Martin <[email-masked]>
Date: Mon, 09 Dec 1996 04:07:00 -0500

Thanks to Roger for posting his thoughts on "Why HTTP?" for the IPP
protocol:

  ftp://ftp.pwg.org/pub/pwg/ipp/contributions-for-discussion/whyhttp.pdf

After reading both this document and Bob Herriot's response, I tend to
agree with Bob regarding the overall utility and compliance to be had
using MIME encodings.  Seems like the MIME approach gives us the kinds
of structuring, attributes and name space possibilities that will be
required for reasonably comprehensive submission capabilities.

Bob also hit the nail on the head with regard to issues surrounding
advance knowledge of the content length of a stream that is part of the
submitted job.  By employing an encoding method (ie, framing format)
that does not require advance knowledge of the stream length, embedded
systems will have a much better chance of supporting advanced
techniques, particularly those that are normally found only on today's
"host" systems (that have far more resources, such as disk capacity). 
After seeing how MIME has been successfully used over the last several
years, I don't believe boundary generation is a problem.  Sure, we'll
end up with some necessarily long boundaries, but as a percentage of the
total transaction size, those boundaries should be viewed as
insignificant IMHO.

Just to make sure I understand the ideas Bob proposed in his reply to
Roger's posting with regard to the use of MIME encodings, I'd like to
walk through a job submission scenario to identify the various content
components.  This scenario may be a bit more complex than the "average"
print job found in a LAN environment, but should serve to note the kinds
of complexities that might be required for a submission mechanism:

  A client wants to submit a job containing four documents to a printer.
  These documents contain (in sequence) Postscript, PCL, G3 fax, and
  plain text.  The client also wants to include a number of separator
  sheets, including a banner sheet, a trailer sheet, and a special
  "cover" sheet for just the G3 fax document.  Furthermore, the
separator
  sheets are specified by reference to the server; the client expects
the
  server to insert the proper type of sheet where specified within the
  job (ie, the client does not actually generate the separator sheets).

If I understand Bob's approach, the resulting content of the POST
message to the printer *could* be structured as shown below (in an
abstract manner).  Note that I don't have the MIME spec handy, so some
of the content-type values are probably bogus.  Also, the indentations
are meant to illustrate the encapsulated components (rather than calling
out the actual "boundary" begin/end lines), and comments are preceded
with "--" ala ASN.1 specs:

  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

Granted, banner and trailer sheets (provided in this manner, by the
server) could be implemented as job attribute options similar to that
done for the fax cover sheet.

Bob, is this the kind of structuring you're thinking about?  Is the
structuring shown above consistent with MIME rules, etc?

If so, then this approach looks *very* powerful and flexible to me.  By
using MIME a client can either hand-craft separator sheets--and pass
them to the server is just addition documents, as is often done
today--or can invoke special features and/or resources provided by the
server using standard tag mechanisms (ie, attributes).

Comments?

        ...jay

        Underscore, Inc.