IPP> NOT - 6 Notification ISSUES: Telecon Wed 7/18, 10-11 PDT (1-2 EDT )

IPP> NOT - 6 Notification ISSUES: Telecon Wed 7/18, 10-11 PDT (1-2 EDT )

Hastings, Tom N hastings at cp10.es.xerox.com
Tue Jul 17 16:31:19 EDT 2001


There have been 6 issues (some changes and some clarifications) of the IPP
Notification Specification and the three Delivery Methods (ippget, indp, and
mailto).  Some of these issues have come up as folks implement IPP FAX which
REQUIRES the ippget Delivery Method.  We are close to consensus on the
mailing list and my calling those who have sent email.  However, I want to
make sure and each time I talk to someone they bring up some more good
points.  So I'd like to have a quick telecon tomorrow to make sure we agree.
I'll send out the specific text changes later today for the following 6
issues.

Time:  Wednesday, 7/18/01, 10-11 PDT (1-2 EDT)
Phone: 1(712)884-1555 (Xerox folks: 8*596-5170
Passcode: 654970

If you can't make the telecon, please send email.  We don't want to impact
any implementations underway, unless you participate.  I want to update
these specifications before the next Internet-Draft deadline which is this
Friday.

The summary of the 6 issues are:

1. Clarify that the Printer MAY send Event Notifications in any order. 

2. IPPGET spec: Get-Notification matching "notify-recipients-uri" with
Subscription objects: octet-by-octet versus URI matching rules. (IPPGET
currently says both).

3. IPPGET spec: In a Get-Notifications response when the client has
requested the wait mode (persistent operation), allow a Printer to return
the unexpired Notification Events, but also indicate to the client to please
disconnect and try again at the indicate interval
("suggested-ask-again-time-interval").  (IPPGET currently only allows the
interval to be returned if the client didn't ask for wait mode or if the
Printer is too busy to return any Notification Events).

4a. IPPGET spec: Clarify that the Get-Notifications operation is for
querying any kind of unexpired Events, not just ippget Events.  Thus the
"notify-recipients-uri" operation attribute can match any Subscription
object including the scheme.  Also all Events have a life time, not just
ippget Events, if the Printer supports Get-Notifications (which requires
ippget scheme at least).

4b. Same as 4a, but make it OPTIONAL for a Printer to support other schemes
with Get-Notifications.

5. Change the sense of the Get-Notifications "notify-no-wait" (boolean)
operation attribute to a positive "persistent-operation" (boolean), so that
omitted and 'false' mean the easier non-persistent operation.

6. IPPGET spec: Rename some attributes but keep the same semantics:  
		"notify-ippget-redirect" (uri) to "notify-redirect-uri"
(uri), 
		"suggested-ask-again-time-interval" (integer(0:MAX)) to
"notify-get-interval", and 
		"begin-to-expire-time-internal" (integer(0:MAX)) to
"event-life-time" (integer(0:MAX)).




More information about the Ipp mailing list