I've updated Carl-Uno Manros's delivery method specification with the
agreements reached at the IPP WG December meeting as indicated in the posted
minutes.
I changed the scheme name to follow the pattern that we discussed on the
telecon that the IETF likes to avoid abbreviations:
'ipp-notify-xxx'
For this delivery method, I've used the working scheme name
'ipp-notify-get', since it uses
the Get-Notifications operation which returns multiple responses as the
events are generated.
We'd like to discuss this method at next week's meeting when we discuss our
various event notification delivery methods. I've posted the files at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-000203.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-000203.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-000203-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-000203-rev.pdf
Here is the Abstract:
Abstract
The IPP notification specification [ipp-ntfy] is an OPTIONAL extension to
IPP/1.0 and IPP/1.1 that requires the definition of one or more delivery
methods for dispatching event notification reports to Notification
Recipients. This document describes the semantics and syntax of the
'ipp-notify-get' event notification delivery method. For this delivery
method, the client uses an explicit IPP Get-Notifications Printer operation
in order to request (pull) event Notifications from the IPP Printer. The
Get-Notifications request indicates whether the client wants to receive all
future events Notifications for (1) any Subscription for which the client is
the owner or (2) a particular Subscription object. In either case, the
event Notifications are returned as MIME multi-part-related responses to the
Get-Notifications request. The HTTP channel is kept open, so that
subsequence event Notifications are returned using additional MIME
multi-part-related responses.
The Change History is:
The following changes were made to the December 7, 19999 version to make the
February 3, 2000 version:
1. Changed the scheme name and title from 'ipp-get' to
'ipp-notify-get'.
2. Changed the tag delimiter from generic-attributes-tag to
notification-attributes-tag as agreed at the December IPP WG meeting.
ISSUE 01 - What should the name of this delivery method and protocol be that
we use in the title of this document?
ISSUE 02 - What should the scheme name be? Consider 'ipp-notify-get' a
working title, until we see several schemes. The 'ipp-notify-poll',
'ipp-notify-sent', and 'ipp-snmp' delivery methods are our other examples.
The IETF likes words or well-recognized acronyms, not abbreviations in
scheme names, so lets include "notify"?
ISSUE 03 - Should the scheme name be used in the title?
ISSUE 04: Is there a limit to the number of outstanding Get-Notifications
requests that an IPP Printer supports? What is this number? How does it
relate to the maximum number of Subscriptions? Can the client determine the
number?
ISSUE 05: Should an implementation be able to queue event Notifications, so
that a client can get event Notifications that had occurred prior to the
Get-Notifications? If so, how long does the IPP Printer keep the event
Notifications before discarding them (for this delivery method only)? The
lease time of the Subscription object? If this is possible, should the
subscriber get to say whether to queue or not, or is it just baked into the
implementation. If the former, does the subscriber indicate via a
parameter in the notification method URL? If the latter, how does a client
discover whether event Notifications are queued or not? Should we have two
different notification methods, one the queues and one that doesn't?
>From the December meeting:
It was suggested that any "notification queuing service" should
be the responsibility of the Notification Recipient, not the
Printer. However, the Issue was not completely resolved.
ISSUE 06 - Is this correct for MIME multi-part-related responses? This need
prototyping.
ISSUE 07 - What happens if 100 continue isn't supported?
ISSUE 08 - What happens if HTTP keep alive isn't supported?
ISSUE 9 - The problem with assigning new tags for every new kind of
attributes and objects, is that an implementation that does private or
experimental operations that have new kinds of attributes and/or objects,
will be forced to either overload some existing tag or use one of the tags
reserved for future standardization. See email from Ned Freed about the
need to clarify [ipp-pro] about:
0x06-0x0e reserved for future delimiters
0x0F reserved for future chunking-end-of-attributes-tag
0x11 reserved for future 'default'
0x14-0x1F reserved for future "out-of-band" values.
Whereas if we had a generic tag, that same tag could be used for the private
and experimental operations. The Printer and the client then uses the
operation-id itself to determine what kind of attributes or object is being
passed in the request or returned in the response, respectively.
Another possible approach would be to assign one tag for private use and
then keep assigning new tags for standard uses, such as Subscription (0x6)
and Notification (0x7).
ISSUE 10: Any notification delivery scheme has to be registered with IANA,
since it is a URL scheme, correct?