Feedback always appreciated.
Mike
| -----Original Message-----
| From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
| Sent: Tuesday, June 29, 1999 2:20 AM
| To: ipp
| Subject: IPP> NOT - Requirements not met by the 5/18 Notification spec
|
|
| 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.
[Proposal]: For operations Print-Job, Print-URI, Create-Job, Validate-Job,
and Subscribe, add operation attribute "notify-attributes" (or
"notify-event-attributes"). To accommodate a different set of attributes
for each event, it would be a 1setOf keyword for each "notify-events"
keyword.
[Issue]: Would this be better represented as a collection tying each
"notify-event" keyword with "requested-event-attributes" 1setOf keyword? Or
could this be solved without collections by using Bob Herriot's suggestion
to add a SubscribeJob operation?
|
| 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?
|
[Issue]: Which "notify-recipient" is the submitter? Do we require the first
"notify-recipient" to be the submitter?
[Proposal]: Add event 'event-delivery-failed' to "device-trigger-events"
printer attribute. The "device-trigger-message" could contain the
recipient's uri of the failed notification. (?)
| 13. There must be a way to specify whether or not event delivery
| requires acknowledgement back to the Event Source.
[Proposal]: Have the event set "request-id" to a non-zero value.
| 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.
[Proposal]: For printer configured (preferred): Add printer description
attribute "event-not-acknowledged" type 2 keywords with initial values
'stop-printer', 'continue-printer' (or make a Boolean). Add
printer-state-reason value 'event-not-acknowledged' when printer is
'stopped'.
[Alternate proposal]: For subscriber configured: Add job template attribute
"event-not-acknowledged" - same values as above.
"event-not-acknowledged-default" as type 2 keyword, and
"event-not-acknowledged-supported" as 1setOf type 2 keyword.
|
| 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.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990518.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990518-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990518-rev.pdf
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@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.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-02.txt
ftp://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