In Roger's recent comments to Don's latest REQ draft:
> Section 2.1 End User:
>> In the last sentence where you enumerate the categories of function, I'd
> suggest changing "viewing printer status" to "viewing printer status and
> capabilities".
True, view printer capabilities is quite essential. However, since this
section of the document attempts to enumerate functions (rather than just
describing them in prose form), viewing status and viewing capabilities
should be two separate lines in the enumeration list.
> I think that the last item should be "Altering the attributes of a job" rather
> than "altering the status of a job".
Absolutely. The statement of "altering the *status* of the job" has come
up frequently in the near past, and these words should be changed to
reflect reality. Thanks for pointing this out, Roger.
> Section 2.1.1 Create an instance of the printer
>> I think we should specify what we think the role of IPP is in providing this
> function. I think we all clearly agree that "decompressing, unpacking, and
> other installation actions" are far outside the scope of IPP.
>> In some environments, support organizations do not allow their end users to
> install drivers and create printers on their desktops. This would be an
> administrative function. Do we need to point this out?
Hmm... This sends up a couple of red flags to me. Is IPP specifically
directed to solve only the needs of the Enterprise, or is IPP supposed to
equally apply to SOHO and home (ie, consumer) environments? SOHO/consumer
environments typically do not have system administrators.
> Section 2.1.3 Viewing the status of a printer
>> Change the title to Viewing the status and capabilities of a printer.
Similar to the comment near the top, these two features should be described
separately. A user might first query the capabilities of the printer before
submitting a print job (in which case the status may not be relevant), and
then query the printer for status after the job has been submitting (in which
case the printer's current capabilities are irrelevant).
> Section 2.3 Adminsitrator
>> [...]
>> I suspect that this list of function is quite incomplete. Either we ought to
> try to reasonably complete the list or say that the list is probably not
> complete and more detail will be added when Adminsitrative functions are
> addressed in the protocol. For example, Adminstrators will build directory
> entries, fill in admin set attribute values (e.g. printer location), assign
> printers to queues, set up policy, etc. etc. etc.
Considering the schedule, we should probably opt to simply state that the
functionality "includes, but is not limited to" that presented in the list.
> Section 4 Objectives of the Protocol
>> In the second paragraph chnage the second paragraph to read "Any platform
> capable of support a WEB Browser shall be supported as a client".
So much for protocol independence for IPP... ;-)
...jay