Tom
>Return-Path: <rdebry@us1.ibm.com>
>From: rdebry@us1.ibm.com
>X400-Originator: rdebry@us1.ibm.com
>X400-Recipients: non-disclosure:;
>X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002185444000002]
>X400-Content-Type: P2-1988 (22)
>To: <Hastings@cp10.es.xerox.com>, <robert.herriot@eng.sun.com>,
> <scott_isaacson@novell.com>
>Subject: 0.92 review comments
>Date: Wed, 20 Nov 1996 06:19:34 PST
>
>Classification:
>Prologue:
>Epilogue:
>
>My comments noted by <<RKD>>
>---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/20/96 06:08
>AM ---------------------------
>
> ipp-owner @ pwg.org
> 11/19/96 04:43 PM
>
>
>To: ipp @ pwg.org@internet
>cc:
>Subject: 0.92 review comments
>
>Here are some comments, questions I have about some of the material in
>IPP Version 0.92:
>
>Section 3.4
>This indicates one or more Job Templates per Printer. Should this be 0 or
>more?
>
><<RKD>> I'd say 0 or more -- I thought we had agreed that output device
><<RKD>> defaults would be used if there were no Job Template.
I agree. 0 or more Job Templates per printer.
Though a printer that doesn't have a Job Template may have a different
URL scheme than one that does, if the URL naming scheme appends the
local job template name to the printer name.
Thus, a user who leaves off the template suffix (by accident), may
be surprisde at what he gets, if the output device defaults are
very user-friendly.
>
>Section 3.5 and Section 6.2.2.1
>3.5 states that a Job object is "identified" by an attribute called
>job-identifier. 6.2.2.1 indicates that the syntax for job-identifier is
>"url". Is the job-identifier really "url" or is the job-identifier just some
>sting that can be used to build a full URL based off of the Printer URL? For
>example a URL for a certain job might be "http://1.2.3.4/p1/j1". In this case
>is the job-identifier "http://1.2.3.4/p1/j1" or just "j1"?
>
>If job-identifier is "http://1.2.3.4/p1/j1" then why have job-identifier as an
>attribute of the job object? It would be fairly useless to do the following:
>
><<RKD>> I expect that the Printer object could return either form, but I
><<RKD>> prefer returning a full URL. Although not a big deal this would make
><<RKD>> the cient logic a little simpler which helps achieve our goal of very
><<RKD>> thin clients.
I agree that the job-identifier in IPP should be the full URL.
Whether the job-identifier is an attribute of the job object (and the
printer-name URL is an attribute of the printer object), is an interesting
question. The only advantage for having the identifier of the object
as an attribute is for use in filter expressions, since we can define the
protocol to always return the identifier of each object requested.
In a filter expression, you can write expressions that include or exclude
printers if the printer-name is an attribute of the printer object, since
filter expressions deal with attributes of candidate objects.
>
>---->
>POST http://1.2.3.4/p1/j1 http/1.0
>Entity header
> job-identifier:
>
><<RKD>> Scott, I don't know what you intended this flow to do, so it is hard to
><<RKD>> comment precisely. However, it is true that sending the message to the
><<RKD>> URL specified as the Job-identifier and then putting the job identifier
><<RKD>> in the body of the message as well doesn't make much sense. If I were
><<RKD>> asking for status of a previously submitted job, for example,
><<RKD>> I would see this flow as:
>
><<RKD>> ----->
><<RKD>> POST http://1.2.3.4.p1/j1
><<RKD>> Entity Header
><<RKD>> current-job-state : null
>
><<RKD>> The Printer would respond by filling in the actual value of the
><<RKD>> current job state attribute. Now, it may need to add the job-identifier
><<RKD>> attribute in the response so that the client knows which job request
>this
><<RKD>> response belongs to.
><------
>http/1.0 200 "accepted"
>Entity Header
> job-identifier: http://1.2.3.4/p1/j1
>
>
>The same is true for section 6.4.1 printer-name. Is this a name or a URL?
>
><<RKD>> I thought that printer-name was used for the purpose of indicating
><<RKD>> to the end user which output device his or her print job was actually
><<RKD>> printed on in cases where a Printer Object represents multiple
><<RKD>> ouput devices. If this is correct, then I'd suggest that printer-name
><<RKD>> is NOT a URL, but an installation defined name recognizable by humans
><<RKD>> to describe the printer. To be consistent with our terminology, perhaps
><<RKD>> we should call this <output-device-name>.
I agree with Roger. The syntax is name, not url.
Or even the name should be: local-output-device-name, since it may want to
be the name that the output device is know by local to the printer.
Then the URL name can be something that isn't obviously related to the
local-output-device-name. This will help initial usage of this standard
with existing printers as system administrators set up URLs for existing
printers. They may not want to be saddled with inventing a URL that is
tied to the local name that the local users are familar with.
>
>Section 4.2.2 and 4.2.3
>If there are more than one different URLs for a single Printer and the
>reason for more than one is to expose different Job Templates, then the
>Description attribute could be used to help explain the differences in the
>defaults in each Job Template. There can also be more than one
>directory entry for the same URL. Tthe reason for this is to expose the
>same Printer in two different contexts in the directory. Tthe location
>attribute for each directory entry could be customized to the context of
>the directory entry. For example, in one context the Location could be
>informal "Next to Sharon's office" (the directory context itself adds
>meaning to the phrase next to Sharon's office) and in another context the
>Location could be more formal, such as "3rd floor, Room 5".
Sound good.
>
>Section 5.2.1
>This states "job and document attributes" Should this just be Job
>attributes?
>
><<RKD>> I think that it is okay as it is. Although document attributes
><<RKD>> have been treated as one type of job attribute, we do introduce
><<RKD>> the ability to have multiple documents per job and structuring
><<RKD>> the flows this way makes it easier to introduce document objects
><<RKD>> in the future if we decide it is necessary.
I agree with Roger. We may never add per-document attributes, but we may,
so lets not have to change the standard if we decide to.
>
>Section 5.2.2
>Job Id should be a URL coming back to the submitter.
I agree.
>
>Section 5
>Many of this operations suggest passing in a list of attributes for which
>values are being requested? What if the list is empty? Does this mean
>all attribute values are to be returned, or none?
>
><<RKD>> That is what I had intended ... see lines 736-739.
I agree.
>
>Section 5.5
>Should there be an option to request Jobs in:
>1) Scheduled order
>2) Any order
>
><<RKD>> I would assume that we would want to return in scheduled order.
I agree. Seems simpler.
>
>Since we have no operators -- sould Get Jobs return:
>All Job Ids?
>Just Job Ids for the requesting end user?
>Position in the schedule order (my jobs are j1, j2, j3, but their relative
>positions are #3, #5, #99)
>Job Ids and a small set of attributes: size, time, position??
>
><<RKD>> This is an interesting question. I know that I'd like to see
><<RKD>> all of the jobs in the queue so that I can better judge what
><<RKD>> is going on at the printer, e.g. is my job about to print.
><<RKD>> However, are there security/privacy issues here??? Perhaps
><<RKD>> it is okay to let users see the entire queue as long
><<RKD>> as we show just a limited amount of information, maybe just
><<RKD>> job size, time submitted, and position in queue.
>
>I like Roger's suggestion of a count of the total number of jobs pending
>and processing.
So do I like adding a printer attribute which is a count of the number
of jobs waiting to be printed or being printed. Then an administrator
can set up a policy to hide all jobs that don't belong to you and you can
still find out how busy the printer is.
Also lets add the other printer attribute from the Job Monitoring MIB that we
agree to in New Orleans: job-scheduling-algorithm with values:
first-in-first-out and shortest-job-first
>
>Section 6.2.4.1
>Since we have a single operation to "submit" a job, will we ever have the
>state "pre-processing"? Do we want to not have the "printing" state?
>
><<RKD>> I suspect that this is a result of the way that DPA operates. I
><<RKD>> woudl agree taht it doesn't apply when there is a single submit
><<RKD>> operation.
I agree. Lets delete the "per-processing" state.
I think we should keep the held and retained states, since we will need
them in version 2.0. Adding states is troublesome to clients.
>
>Section 6.2.4.6
>Will we ever have the "documents-needed" reason?
>
><<RKD>> Wouldn't this be the case when I give a document URL in the print
><<RKD>> request and the Printer has requested the document but it has not
><<RKD>> yet arrived?
Yes.
>
>job-sheets
>Since we have job-sheets as only "none" or "defuault", isn't this just a
>Boolean "TRUE = print the default banner" "FALSE = don't print the
>default banner"
>
><<RKD>> Makes sense to me.
I disagree. By keeping it as a type3Enum, the standard and the administrator
are free to add other values.
>
>Section 6.4.32
>Since maximum-end-user-priority is a Printer object attribute and not a
>Job Templates attribute, it is hard to acheive the desire effect. Suppose
>you want some users to have a MAX priority of low and some user to
>have a MAX of hight. This would require defining TWO Printer object for
>the same Printer object not just TWO Job Templates for the same Printer
>Object. However, this doesn't work as a Job Template attribute either -
>the user just overrides the priority in the Job submission attributes
>
><<RKD>> We haven't talked much abut how Job Templates could be used to
><<RKD>> set up administrative stuff. Another good example would be ACLs
><<RKD>> on a Job Template basis ... e.g. Anyone in dept A can print on
><<RKD>> this printer, but only the manager can print transparencies.
><<RKD>> Therefore only the manager shows up on the ACL of the Job
><<RKD>> template for the "foils" printer. This whole arae probably
><<RKD>> deserves some discussion.
We've had lots of experience with this problem in ISO DPA.
Job templates are just like initial value jobs (except IPP has improved them
by having a URL that implies both a Job Template and a Printer).
However, Job Templates are only defaults, they are not policy. Anything
that can be said in a template can be said by the submitter.
However, we could (and I thought we were) handle the above case by
fan-in, where two Printers don't queue/spool, but just are a pass through
to another Printer object that does queue/spool. Then the access control
and the xxx-supported attributes on each of the two Printers can be different.
As far as the user is concerned, the two Printers look like any other Printer.
In other words, a Printer object that doesn't queue/spool and feed another
Printer object is exactly what ISO DPA calls a logical printer.
So we can solve the problem of maximum-end-user-priority being different for
different users, by having the system administrator set up two Printers,
one with a higher maximum-end-user-priority than the other and setting up
two different acls on each. The SA also sets each Printer not to queue
or spoool and to feed jobs to another Printer that does queue and spool
(and that may or may not be in the directory, depending on whether the SA
want to allow users to submit directly to it or not).
Ok?
>
>All for now,
>Scott
>
>
>
>