From: Randy Turner <[email-masked]>
Date: Mon, 18 Aug 1997 12:02:00 -0700

At the Monday plenary session of the IPP committee, Scott Isaacson
stated that at a recent meeting (Redmond) the Job URI had
been discussed and that the attendees had decided that a 32-bit
job ID was a better way to go.

I talked with Scott and Steve Zilles about the technical 
justification for this decision. Between Scott and Steve, I 
came away with the following three reasons why the decision
was made.

		1. Make it easier for one particular vendor
		   to code.

		2. Alignment with the job mib.

		3. Make it easier to write LPD gateways.

When I originally proposed the multiple URI "create-job" response,
it was to provide a really scalable solution for deploying IPP in
a wide array of environments and topologies. Awhile back, it was
decided that multiple response URIs could be boiled down to just
the "job" URI, and I grudingly agreed that it was possible to have
a scalable solution with only one URI. This latest move to remove all
URIs (except printer URI) from the model just doesn't make any sense.
It's a fundamental concept within the model that job and printer
objects are referenced by URI. Long ago we rationalized this out,
but I will repeat some of the rationale (I'm not sure why I have to
do this) here for review.

	1. Allowing the server to decide how to reference a job
	   object scales to the widest possible measure of
	   implementations. It not only works for today's systems,
	   but also future systems that are more distributed or
	   systems that use a more flexible means of job object
	   reference than we are thinking about for IPP 1.0. The
	   current proposal for forcing vendors to use 32-bit
	   job IDs seems too restrictive within the environment
	   we are working. And the argument that "Gee, but that
	   means the vendor can support 4 billion jobs!" implies
	   that the vendor's use of Job ID has some cardinality
	   associated with it. There's just no reason we have to
	   limit how a vendor wants to index jobs.

	2. Scalability. Vendor's should have the ability to 
	   distribute print jobs for load balancing, or for
	   whatever site-specific scheduling policy is needed.
	   Using job URIs allows the IPP print system to do this
	   not only at job submission time, but also anytime
	   during job processing (using "create-job" "send-doc").

	   The ability to do this at job submission time means
	   that for future references, the server can vary any
	   of the URL fields (protocol, host, port number, etc.)
	   that is needed depending upon the granularity of
	   scalability or scheduling that is needed. 

	   To achieve this goal during job processing, the job
	   could be requeued either automatically or through
	   operator intervention, and the client would 
	   automatically be notified of this change through the
	   use of HTTP redirects on the URI it had been using to
	   deliver the job.

	   Funneling every IPP printer request through a single
	   URI (and URI host) does not scale at all, and you
	   can't use HTTP redirects with the printer URI because
	   that implies you are redirecting the printer, which
	   is NOT what you are doing. What you are doing is
	   redirecting the job.

	3. Less of an operational rationale but still worth
	   noting is that it is much easier to understand a model
	   in which objects are referenced uniformally 
           (in this case, URI). And it allows us more flexibility
           in the future, if printing systems allow individual
           object access to documents. Its just more consistent.

To address the concerns that the group had in Redmond...

	1. I don't think making it easier for one particular
	   implementation to code is sufficient justification
	   to remove the job URI capability. If we need to
	   "hand hold" existing implementations, then we should
	   think about adding some other type of job attribute
	   that acts as a "helper" value for existing 
	   implementations. We can discuss how this would work.

	2. I'm not sure if alignment with the job MIB is 
	   absolutely required, since there are no existing
	   implementations. I think we should think about 
	   making job identifiers within the job MIB an octet
	   string, as opposed to a binary value, for the same
	   reasons I outlined in rationale #1 above. And SNMP
	   MIBS DO allow you to index tables using octet strings
	   so using an octet-string job identifier as an index
	   into a table works.

	3. We should not strip functionality out of a protocol
	   destined for future print systems just to make it
	   easy to write gateways. The burden of writing an
	   IPP-to-LPD gateway should be on the gateway author,
	   and should not serve as a filter to what types of
	   functionality we provide in IPP.

           On the same topic
	   of the LPD mapping document, it is my opinion, and
	   the opinion of most in the IETF Plenary audience,
	   that the mapping document SHOULD NOT be standards
	   track, or serve as an exact reference for 
           implementing a gateway. The LPD mapping document
	   should only serve as an informational document,
	   providing "guidelines" only for implementers to 
	   consider when implementing a gateway; not specifying
	   exactly how a gateway should be written. The main
	   reason for this (as everyone knows) is that there
	   are just too many different implementations of LPD
	   in the world, and writing one mapping document,
	   specifically describing how implementers should deal
	   with each one is too complex. This document should
           remain information, just guidelines, and the extent
	   to which gateways are interoperable with certain
	   LPD implementations should NOT be our concern.

Randy