The current Notification spec that was posted on 5/18/98 before the
Philadelphia IPP meeting does not yet meet the following requirements in the
Notification Requirements I-D:
6. When specifying a notification event, a Notification Subscriber must
be able to specify that zero or more notification attributes (or attribute
categories) be sent along with the notification, when that event occurs.
11. A mechanism must be provided for delivering a notification to the
submitting client when the delivery of an event notification to a specified
Notification Recipient fails. (Optional? Or not necessary?) Fall back means
of subscribers determining if notifications have failed. I.e. polling?
13. There must be a way to specify whether or not event delivery
requires acknowledgement back to the Event Source.
14. There must be a mechanism to indicate the quality of service for
delivery of event reports. The policy must include stopping the Printer and
allowing the Printer to continue, when delivery of the event report is not
acknowledged.
ISSUE: Should that policy be specified by the Notification Subscriber (and
authorized by the Printer) or by the administrator in configuring the
Printer?
We should begin discussion of how to meet these requirements on the DL and
at the telecon, this Wednesday, 6/30.
The current Notification spec is:
The files are located at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990518.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990518.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990518-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990518-rev.pdf
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Monday, June 28, 1999 15:53
To: ipp
Subject: IPP> NOT - Updated IPP Notification Requirements document
posted
I've down loaded the IPP Notification Requirements that correspond to the
recently announced Internet-Draft (02). Harry Lewis had sent me his edits
from the Philadelphia meeting when we reviewed the 00 version from February
1998. I included my notes from the meeting and indicated things that we
agreed are issues:
ftp://ftp.pwg.org/pub/pwg/ipp/Internet-Drafts/draft-ietf-ipp-not-02.txtftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-02.txtftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-requirements-990624.d
oc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-requirements-990624.p
df
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-requirements-990624-r
ev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-requirements-990624-r
ev.pdf
We will cover this requirements document at the telecon IPP telecon, this
Wednesday, usual time 10-12 PDT (1-3 EDT). Please send any comments ahead
of time to the ipp DL with NOT in the subject line.
After sending it in to the Internet-Drafts in time (6/24) for the up coming
IETF meeting, I discovered that Roger had actually published an 01 version
as an Internet-Draft in March 1998. So one of the things that the 01
version had added over the 00 version was Quality Of Service:
2.16 Quality of Service
Some notification delivery methods may allow users to select quality of
service parameters. These will depend upon the specific delivery method
chosen, and may include parameters such as priority, security, number of
retries, and the like.
We agreed in Philadelphia to add Quality Of Service, so we are moving a
direction agreed to over a year ago.
So adding the above is a first set of comments on the requirements document.
Tom