Or maybe it would be simpler just to include 'ippget' as if it were a URL
scheme in "notify-schemes-supported", but with the definition that when
using this "scheme", the URL in "notify-recipient-uri" is actually a
zero-length string.
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Monday, October 22, 2001 11:05
To: ipp (E-mail); IPP FAX DL (E-mail)
Subject: RE: IFX> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI
More on the solution to use a zero-length string for "notify-recipient-uri"
to indicate that the 'ippget' delivery method is to be used.
Presumably, the "notify-schemes-supported (1setOf uriScheme) Printer
attribute would not be supported, unless there were other notification
schemes supported as well. (Rather than having a null string scheme value,
right?).
So a client can tell whether or not a Printer has supported the 'ippget'
notification delivery method, if the "operations-supported" included the
Get-Notifications operation.
Of course, an IPPFAX client need not check the "operations-supported" for
the Get-Notifications operation, since an IPPFAX Receiver MUST support
Get-Notifications and 'ippget' Delivery Method.
Comments?
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Friday, October 19, 2001 15:21
To: ipp (E-mail); IPP FAX DL (E-mail)
Subject: IFX> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI
Ira and I were talking about ISSUE 02:
ISSUE 02: How unique do we need the "notify-recipient-uri" (uri)
URL now that the Printer doesn't use anything but the scheme in the URL to
match on?
We realized that we are never going to get the IETF to accept the
registration of the 'ippget' scheme as written, because the URI doesn't
point at a network resource that supports a network protocol. So how about
specifying that if the "notify-recipient-uri" attribute is a null string
(zero length string), then that means the IPPGET Delivery Method? In other
words, the client is going to use the in-band IPP Get-Notifications
operation to get Event Notifications; there is no protocol involved.
This approach is better than adding another attribute to indicate 'ippget',
since the "notify-recipient-uri" attribute is required for Subscription
creation and for Subscription objects.
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Friday, October 19, 2001 03:37
To: ipp (E-mail); IPP FAX DL (E-mail)
Subject: IPP> NOT - IPPGET Delivery Method down-loaded - REQUIRED for
IPPFAX
I've posted the updated IPPGET Event Notification Delivery Method that is
REQUIRED for IPPFAX:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017-rev.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017-rev.doc
The -rev version show the revisions since the July 17, 2001 version.
It has all of the agreements reached at the August 1, IPP FAX meeting in
Toronto and the subsequent 3 telecon, August 11, 14, and 17. See the
telecon and meeting notes for the list of the changes.
I'll send a .txt I-D later Friday. Please send any comments to the mailing
list. We'll also review at the IPPFAX WG meeting, next Wednesday, October
24 in San Antonio.
There are two issues:
ISSUE 01: Although we agreed to extend Job Creation operations to
support Event Wait Mode, it seems to be an unnecessary complication, since
the Printer MUST keep events for at least 15 seconds. So OK NOT to add the
"notify-wait" (boolean) operation attribute to Job Creation operations and
NOT have to have Job Creation responses return Event Notification Groups (in
addition to returning Subscription Attribute Groups).
ISSUE 02: How unique do we need the "notify-recipient-uri" (uri)
URL now that the Printer doesn't use anything but the scheme in the URL to
match on?
Here are the major changes:
1. Removed the "notify-recipients-uri" operation attribute from
Get-Notifications, so no URI matching.
2. Changed "notify-subscription-id" (integer(1:MAX)) to
"notify-subscription-ids" (1setOf integer(1:MAX)); the client MUST supply
with at least one value. Printer MUST support multiple-values.
3. Added "notify-sequence-numbers" (1setOf integer(1:MAX)) to be parallel
and be a floor to the Event Notifications sequence numbers returned. The
client SHOULD supply. Printer MUST support multiple-values.
4. In Event Wait Mode, each response is a full IPP response.
5. Moved "notify-get-interval" back to the operations attributes group in
the response.
6. Added 'successful-ok-events-complete to indicate that there will be no
more events for this Subscription object.
7. The Printer MUST support Event Wait Mode.
8. The client can end Event Wait Mode (without closing the connection) by
sending "notify-wait" = 'false' any time. The Printer can end Event Wait
Mode (without closing the connection) by returning "notify-get-internal"
operation attribute any time (including immediately).
9. Changed the lower limit for "ippget-event-life" from 1 to 15 seconds and
recommend 60 seconds to agree with the PWG Job Monitoring MIB (RFC 2707).
Thanks,
Tom