Many of my comments on the terminology section, and elsewhere, are purely
editorial in nature, from a perspective of not being familiar with the
detailed background of IPP.
There are a couple of slightly deeper questions on the goals section.
#g
--
><draft-ietf-ipp-not-02.txt> > > Internet Printing Protocol/1.1: Requirements for IPP Notifications > Copyright (C) The Internet Society (1999). All Rights Reserved.
>1 Scope > >The scope of this requirements statement is for end users, print >administrators and operators.
I don't understand how this "scope" applies to a protocol goals document.
[...] >2.4 Job Submitting Application > >An application (for example a batch application), acting on behalf of an >end user, which submits a print job to an IPP Printer. The application .[------] Does this constitute a "Job submitting end user"?
>may or may not be within the same security domain as the Printer. This >application may or may not be geographically near the printer.
[...] >2.6 IPP Client > >The software component on the client system which implements the IPP >protocol.
This begs a definition for "client system".
[...] >2.7 Job Recipient > >A human who is the ultimate consumer of the print job. In many cases >this will be the same person as the Job Submitting End User, but this >need not always be the case. For example, if I use IPP to print a >document on a printer in a business partner's office, I am the Job >Submitting End User, while the person I intend the document for in my >business partner's office is the Job Recipient. Since one of the goals >of IPP is to be able to print near the ultimate recipient of the printed >output, we would normally expect the Job Recipient to be in the same >security domain as, and geographically near the Printer. However, this >may not always be the case. For example, I submit a print job across the >Internet to a Kinko's print shop. I am both the Submitting end User and >the Job Recipient, but I am neither near nor in the same security domain >as the Printer.
I found the last two sentences tend to confuse the purpose of this entry. Having accepted some concept of an ultimate consumer who (presumably) actually reads the document, it's not clear to me who should be the ultimate recipient when a document is sent for printing at Kinko's. I think this begs a clarification of "ultimate consumer" (e.g. who takes delivery of the printed material?)
I think the confusion arises in part because "Job Recipient" implies some kind of _messaging_ function, while (IMO) IPP is primarily a distributed document _presentation_ protocol. This distinction is fuzzy, but I do believe can be quite distinct emphases at work here. I do understand that there are moves to use IPP in a messaging (fax) context, but I think any such considerations should not be permitted to confuse the core protocol goals.
[...] >2.8 Job Recipient Proxy > >A person acting on behalf of the Job Recipient. In particular, the Job >Recipient Proxy physically picks up the printed document from the >Printer, if the Job Recipient cannot perform that function. The Proxy is >by definition geographically near and in the same security domain as the >printer. For example, I submit a print job from home to be printed on a >printer at work. I'd like my secretary to pick up the print job and put >it on my desk. In this case, I am acting as both Job Submitting End >User and Job Recipient. My secretary is acting as a Job Recipient Proxy.
I find myself rather uncomfortable with this use of "proxy" in an otherwise technical context. Especially when the underlying protocol uses elements of HTTP which has its own idea of a proxy.
>2.11 Notification Recipient > >Any of: Job Submitting End User, Job Submitting Application, Job >Recipient, or Job Recipient Proxy or admin etc folks and their >representatives or log file or accounting/audit application or other >active or passive entities or President Clinton. Or Monica.
I think this definition allows just about any IPP component, or non-IPP component, to be a "Notification Recipient", regardless of whether or not they actually receive notification of events.
[...] >2.13 Event > >A event is some occurrence (either expected or unexpected) within the >printing system. Any of the following constitute events that a Job >Submitting End User can specify notifications be sent for: > >@ Any standard Printer MIB alert (i.e. device alerts) (critical and > warning?) (state change notifications)? >@ Job Received (transition from Unknown to Pending) >@ Job Started (Transition from Pending to Processing) >@ Page Complete (Page is stacked) >@ Collated Copy Complete (last sheet of collated copy is stacked) >@ Job Complete (transition from Processing or Processing-stopped to > Completed) >@ Job aborted (transition from Pending, Pending-held, Processing, or > Processing-stopped to Aborted) >@ Job canceled (transition from Pending, Pending-held, Processing, or > Processing-held to Canceled) >@ Other job state changes like 'paused', purged? >@ Device problems on which the job is destine for >@ Job (interpreter) issues
I note that many of these are described in terms of job state transitions. Would it not be easier to allow *any* job state transition to be a notifiable event?
>2.15 Notification Subscription > >It should be possible for end users and operators to 'subscribe' for >notifications of certain types of events, independent of Job Submission. >An end user or operator may subscribe for > >@ All Job Traps >@ All Traps (Job and Printer) >@ None (Reserves a slot in some limited stable of 'notification hosts') >ISSUE: Need to discuss granularity and categorization in the context of >anticipated event frequency
Isn't this last sentence confusing terminology with goals?
[...] >2.19 Queued Notification > >Notifications which are not necessarily sent immediately, but are queued >for delivery by some intermediate network application, or for later >retrieval. Email with store and forward is an example of queued >notification.
Is there a possible further distinction between queued delivery and collection?
E.g. my mobile phone rings me when I come available if a message has been left for me, OR I can call a number to retrieve any messages.
[...] >2.20 Notification over Reliable Transport > >Notifications which are delivered by a reliable, sequenced delivery of >packets or character stream, with acknowledgment and retry, such that >delivery of the notification is guaranteed within some reasonable time >limits. [...]
I think the constraint "sequenced" is unnecessary in this context.
I also think that binding "Reliable Transport" to time limits is not necessarily appropriate. Or maybe "determined" rather than "reasonable" time limits.
The next point underscores this...
>[...] For example, if the notification recipient has logged off and >gone home for the day, an immediate notification cannot be guaranteed to >be delivered, even when sent over a reliable transport, because there is >nothing there to catch it. Guaranteed delivery requires both queued >notification and a reliable transport. If delivery of the notification >requires process to process communications, each session is managed in a >reliable manner, assuring fully ordered, end-to-end delivery.
I think this last sentence has strayed too far into implementation detail.
[...] >2.22 Human Consumable Notification > >Notifications which are intended to be consumed by human end users only. >They contain no machine readable encoding of the event. Email would be >an example of a Human consumable notification.
E-mail might also be machine readable. E.g. DSN and multipart/report.
>ISSUE: Do we need both human and machine or is machine sufficient? >There is no intent to attempt to standardize human readable strings. >Human readable is intended for certain protocols, like e-mail, though >email can also convey machine readable MIME types as well using >multipart/report.
This belongs under requirements rather than terminology. If you have human readable notifications then internationalization issues need to be addressed for them.
>ISSUE: Is e-mail the only, or most likely, means of conveying the >notification through the firewall (which would drive a requirement for >mixed text, binary content).
[...] >3 Requirements
[...] >2.It must be possible to support the IPP Notification interface using > third party notification services that exist today or that may be > standardized in the future.
So what is excluded?
[...] >4.When specifying a notification recipient, a Notification Subscriber > must be able to specify one or more notification events for that > notification recipient.
But (e.g. in a mixed-protocol environment) is it vital that the events and/or categories specified are honoured exactly. I am thinking of a possible destination system that does not recognize the same event specifications.
If not, then a recipient must be prepared to receive events for which it has not explicitly subscribed, or possibly not receive events for which it has subscribed.
>5.When specifying a notification recipient, the Notification Subscriber > must be able to specify either immediate or queued notification for > that notification recipient. This may be explicit, or implied by the > method of delivery chosen by the Job Submitting End User.
Again, MUST any such specification be honoured? A "yes" will impose quite severe constraints on the operating environment. [...] >8.There is no requirement for the IPP Printer receiving the print > request to validate the identity of an event recipient, nor the > ability of the system to deliver an event to that recipient as > requested (for example, if the event recipient is not at work today).
Hmmm... is there a danger here that the event notification mechanism might be hijacked as a spamming tool?
[...]
>12. There must be a mechanism for localizing human consumable > notifications by the Notification Source.
This is a goal IFF the notifications contain human consumable elements.
>13. There must be a way to specify whether or not event delivery > requires acknowledgement back to the Event Source.
Is this really needed? Do even fleas have fleas?
Could this open the door to notification loops?
[...] >4 Scenarios
This section seems out of place at the end of the document, as the material it contains seems to be aimed at providing relevance to the more formal content of this document.
#g
------------ Graham Klyne (GK@ACM.ORG)