Graham,
Sorry about having taken quite a few days to respond to your message
with suggestions about our IPP Notification Requirements draft.
We are currently working on a revised version of the draft and will
try to take as many as possible of your constructive suggestions into
account.
Please see my responses in more detail below, and read the new draft
which will be out in a week or so.
Carl-Uno
> -----Original Message-----
> From: Graham Klyne [mailto:GK at Dial.pipex.com]
> Sent: Monday, August 02, 1999 6:27 AM
> To: ipp at pwg.org> Cc: ifx at pwg.org> Subject: IPP> draft-ietf-ipp-not-02.txt
>>> I have made some comments on this document below.
>> 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.
We will do some text changes to clarify, but check the new version
of the document to see if you are happier with the new wording.
>>> [...]
> >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"?
No, we have simplified the terminology and got rid of the problem.
>> >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".
We will add one.
>>> [...]
> >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?)
We have taken out some text and simplified the description.
>> 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.
Talking about fuzzy, we don't really understand what you want to say
in this paragraph.
>> [...]
> >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.
We have changed the term "proxy" to "representative".
>>> >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.
Have improved the wording and taken out Bill and Monica (who put in
that in in the first place?).
>> [...]
> >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?
You are right, we should say "any" state transition here.
We have moved some of the details to the Requirements further down.
>> >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?
You are right again. we have re-written the definition, moved
some text to Requirements and got rid of the issue.
>>>> [...]
> >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.
We have renamed "queued" with "store-and-forward".
> 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.
Well, I don't think we should care. Who cares about whether a user has
a mailbox in their workstation or picks it up via POP or IMAP today?
>> [...]
> >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.
Gone.
>> I also think that binding "Reliable Transport" to time limits is not
> necessarily appropriate. Or maybe "determined" rather than
> "reasonable"
> time limits.
Gone.
>> 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.
You are right, will be removed.
>>> [...]
> >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?
We are not excluding anything that can meet the stated Requirements.
>> [...]
> >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.
This sounds like an implementation scenario for gateways.
We are not planning to go there..
>> >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.
We think this is an important requirement, but expect it to be implied
by the chosen delivery protocol (e.g. mailto:// vs. http://), rather
than explicitly specified by the subscriber.
>> [...]
> >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?
Yep, we have added a new part on security threats.
>> [...]
>> >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?
We expect this to be removed, but it is still in the new draft as
an issue.
>> Could this open the door to notification loops?
Possibly, which is one more reason to remove it.
>>> [...]
> >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.
Right again.
We will reshuffle some of text, so this comes earlier in the document.
>> #g
>> ------------
> Graham Klyne
> (GK at ACM.ORG)
>