Thank you for taking the time to review the paper. I've added a few =
comments to your message. See below.
Cheers,
-Hugo
>>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 09/21/99 06:36PM >>>
> Hugo,
>
> Great paper!
>
> I have several significant comments/issues and some editorial ones.
>
>
> Editorial comments:
>=20
> 1. Instead of inventing new terms, lets use the ones in the Notification
> spec. =20
Generally I'm not in favor of defining new terms whenever existing ones =
can be appropriately used. I'll explain the reason for each new term for =
additional discussion. I'm happy to use the terms you suggested if it =
still makes sense.
>
> a. So instead of "HTTP Notification client" or "HTTP Notification =
delivery
> method", lets use "Notification Source" defined at line 409 of the .pdf =
with
> no revisions file.
"Notification Source" denotes the entity generating events which may or =
may not be the same as the Notification delivery method (for example, when =
an IPP printer employs the services of a Notification Delivery Service). =
Even in cases where it is the printer sending out the notifications, will =
there be times when we'll need different terms to refer to the common =
logic in the printer that "generates" notifications and the different =
delivery methods that actually "send/dispatch" the notifications?=20
>
> b. So instead of "HTTP Notification server" or "HTTP Notification =
Listener",
> lets use "Notification Recipient" defined at lines 410-414 of the .pdf =
with
> no revisions file.
Similarly, "Notification Recipient" refers in a generic way to a logical =
entity interested in receiving/consuming notification. It can refer to a =
user browsing his/her e-mail for notification messages, an application =
parsing through a notification log file, or an application that accepts =
asynchronous notifications and reports them to users in some human-friendly=
format, to name a few. The HTTP Notification Listener (and I'm not sure =
this is the best name for it) may be the latter one but it doesn't have to =
be. A notification service I'm quite familiar with uses a single =
"listener" per workstation/host. All applications running on that =
workstation use the same "listener" to receive notifications. In this =
case, it doesn't make sense to call the "listener" a "Notification =
Recipient" any more than you would like to call an e-mail in-box a =
"Notification Recipient".=20
>
> I'll use these terms in the following comments.
>
>
> 2. How about changing the name of the request from Report-Ipp-Notificatio=
ns,
> to Send-Notification? That makes it parallel with Send-Document. Also =
we
> used to use the term "report" and "notification report" in the older =
specs,
> but changed it to Notification to agree with many notification systems.
>
I like Send-Notification. On removing "report" form "notification =
report": will we ever need to differentiate between the notification data =
generated by a printer regardless of the notification delivery method to =
be used and the notification data (and its syntax) transported by a =
specific delivery method? Do we call the contents of an e-mail notificatio=
n message, of an HTTP notification, SNMP notification, etc. all "Notificati=
on" even though they may all look fairly different due to the constraints =
imposed on them by the protocol used to deliver them?
>
> 3. Also change the name of the Attribute group from "Notification Report
> Attributes" to "Notification Attributes". Same reason.
>
>
>
> Significant issues/comments:
>
> 4. Your proposal requires that the Notification Source send requests and
> that the Notification Recipient send back responses. In other words an
> acknowledgement protocol. That has some nice properties, but the =
current
> IPP Notification spec only has one directional Notification content. So =
we
> should change the notification spec to allow one directional and
> request/response delivery methods?
>
> One of the advantages to your request/response notification delivery =
method,
> is that it provides an easy way for the Notification Recipient to cancel =
the
> subscription when the Notification Recipient is different from the
> Notification Subscriber. The Notification Recipient returns a status =
code
> to the Notification Source that indicates that the Subscription is to be
> canceled. Had the (different) Notification Recipient attempted to =
perform a
> Cancel-Subscription operation, the current spec would have rejected it,
> since the Notification Recipient wasn't the Notification Subscriber.
>
Other notification systems without the "lease" concept use this mechanism =
to clean up orphan notification registrations. We may or may not =
implement it if it complicates our life too much.
>
> 5. I suggest that each request be for a single Notification. Then the
> operation attributes "attributes-charset", "attributes-natural-language",=
> and the "request-id" request parameter can mean for the Notification and =
the
> request (see lines 282-287). In other words, the Notification and the
> request become one thing. Also the status code in the response goes for =
the
> single request/Notification. Much simpler! Since our events don't =
overlap,
> there isn't much need for a Notification Source to send multiple
> Notifications to a single Notification Recipient. =20
I proposed support for multiple notifications per operation for the =
following two reasons:
a) As I mentioned above, we've found it beneficial (reliable, efficient, =
application-developer friendly) to implement a single listener per =
workstation that can service the notification needs of all the apps =
running on that workstation. When multiple applications request notificati=
on from multiple printers, the notification traffic directed at that =
workstation can be significant.
b) Allows us to have a story that scales. If we ever need to support a =
printer that generates heavy loads of notification data, the "Notification =
Source"/Delivery Method can use "chunking" in conjunction with multiple =
notifications per operation to keep up without getting bogged down with =
HTTP connection management.
>
> a. Option 2 which just sends the Notification attributes in a group =
seems
> easier than using the new 'collection' attribute syntax.
I'm OK with this. Does anybody else has a preference?
>
> b. ISSUE 3: becomes moot, since the "attributes-charset" and
> "attributes-natural-language" for the request and the notification are =
the
> same thing.
>
>
> 6. Issue 4: Probably a new 'ipp-ntfy' scheme. Probably needs a new =
default
> port as well, since they asked that the 'ipp' scheme have a new default
> port.
>
> All for now.
>
> Tom=20