>>> Bill Wagner <bwagner@digprod.com> 08/17/97 11:28AM >>>
> Jay,
>
> I will offer some observations about this proposed change.
>
> 1. The concept of the job as an object with an URI was part of the IPP
> initial concept and pervades the documents. It will be no mean task
> to find and edit out all of the allusions to this in the documents.
>
I started this editing task after the Seattle meetings and before the Munich
meetings. As Bill points out, the subtleties of this are "part of the
model". They
are spread through the document. Do we have Job operations are just
Printer operations that apply to a certain Job. Steve Z. makes the point
that Jobs are still first class objects, they have operations. Their
"identifier"
is just not a single URI, but a two part identifier (Printer URI and Job
ID).
I think it is do-able, but extensive.
> 2. Paul Moore of Microsoft strong voiced his opposition to have the
> job as an URI'able object citing, if I recall correctly,
> implementation difficulties.
Other participants voiced the same concern about mapping from existing
application interfaces (APIs) to a new on the wire protocol to existing
print
services. From my point of view there is always a trade off between
new and old (anyting) along the dimension labled:
potential vs. migration and legacy
This IPP support for existing practice is a very valid concern given the
somewhat theoretical "potential". The major stumbling issue at the IPP
meeting in Munich, was the lack of scalability across all configurations
in the inter/intra/extra net world. What about sites that want to return
location or name information in a new Job identifier? This works well
for a URI but not so well for an 32 bit ID.
> 3. A potential advantage to identifying the job by a number at the
> Printer URI was synchronization with the Job Monitoring MIB job index.
> However, at the following Job Monitoring MIB meeting, I pointed out
> that the IPP server assigning the IPP job was not necessarily in the
> same place, dealing with the same physical entities or privy to the
> information in the agent assigning the Job Monitoring MIB index and
> that it was unrealistic to require that the same number be used. I
> recall no other inherent advantages voiced to the proposed change.
I recall just stating that the Job ID was a 32 bit integer with the
potential of
being the same as the Job Index, however that was not mandatory was it?
> 4. The argument to retain the JOB URI centered about the need to
> identify a job independently of the Printer which assigned the ID. No
> good arguments could be found for this requirement.
Other than that is what the model has claimed for the past 9 months and
prototyping has shown it ti be valid and scalable.
> 5. Three proposals were presented.
> a. to identify each job by an ID at the printer URI
> b. to identify each job by a URI composed of the printer URI plus
> some job specific term, that would easily correlate to the IP in (a).
> c. to identify each job with a URI without the constraints in (b).
> The almost absolute consensus was (a).
> I agree that the decision of which way to go is probably less
> important than agreeing on the way.
> Bill Wagner, Osicom/DPI
Although I initially opposed the Job ID rather than Job URI proposal, I
became
convinced at the meeting that "consensus" was to go the "proposal a route".
However, I do agree that in the IETF, the only "real" face to face meetings
are the IETF sponsored ones and the discussion list is the place for
real consensus. The last decision on the DL about Job URI was to add
Printer URI as an operation attribute to all Printer operations and Job URI
as
an operation parameter to all Job operations.
I would like to have a final call of all issues related to Job ID be posted
by
8/22 (including all who were at the IETF meetings in Munich that opposed
the prosposed solution) so we can close this immediately.
A final note, only a few of the more than 40 attendees had even claimed to
read the posted I-Ds.
Scott I.