ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-ntfy-delivery-991209.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-ntfy-delivery-991209.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-ntfy-delivery-991209-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-ntfy-delivery-991209-rev.pdf
It had been called "HTTP-based IPP Notification Delivery Protocol. We got
comments back not to call it HTTP xxx, since its isn't part of HTTP. Hugo
and I think that we need to consider what methods we are going to have,
before we can pick a good name. The current working title and scheme name
is:
The 'ipp-ntfy' Notification Delivery Method and Protocol
Hugo is unable to attend this upcoming meeting but would like to have the
specification reviewed again as one of the notification delivery methods
defined for use with IPP.
Here is the Abstract:
The IPP event notification specification [ipp-ntfy] is an OPTIONAL extension
to IPP/1.0 and IPP/1.1. [ipp-ntfy] 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-ntfy' event notification delivery method that is itself a
request/response protocol. For this delivery method, an IPP Printer sends
(pushes) IPP event Notifications to the Notification Recipients using the
protocol defined herein which includes HTTP as a transport.
There are 5 issues:
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-ntfy' a working
title, until we see several schemes. The 'ipp-get' delivery method is
another example. Should the scheme name somehow include "notification",
i.e., 'ntfy'? How about 'ipp-ntfy-send' or 'ipp-ntfy-push' and
'ipp-ntfy-get' or 'ipp-ntfy-pull' to go with the Send-Notifications and
Get-Notifications operations, respectively?
ISSUE 03 - Should the scheme name be used in the title?
ISSUE 04 - Ok to add a "Generic Attributes" group tag to [ipp-pro], instead
of adding a special tag for each new object and/or operation that needs a
different set of attributes than Job or Printer? The same issue for the
Subscription object in [ipp-ntfy]. Either we define separate tags for both
or use a single generic tag for both and future objects and attribute
groups.
ISSUE 5 - Ok to extend Notification Model to allow a single notification to
have both Human Consumable form and Machine Consumable form when the client
asks for Human Consumable form by supplying the "notify-text-format"
attribute rather than the Human Consumable being sent instead or in addition
to the Machine Consumable using MIME multi-part-related?