Tom,
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 at cp10.es.xerox.com> 09/21/99 06:36PM >>>
> Hugo,
>> Great paper!
>> I have several significant comments/issues and some editorial ones.
>>> Editorial comments:
>> 1. Instead of inventing new terms, lets use the ones in the Notification
> spec.
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?
>> 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".
>> I'll use these terms in the following comments.
>>> 2. How about changing the name of the request from Report-Ipp-Notifications,
> 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 notification message, of an HTTP notification, SNMP notification, etc. all "Notification" 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.
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 notification 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