My comments on your comments starting with TH>.
From: Hugo Parra [mailto:HPARRA at novell.com]
Sent: Wednesday, September 22, 1999 00:13
To: hastings at cp10.es.xerox.com; ipp
Subject: Re: IPP> NOT - Comments on Hugo Parra's HTTP-Based IPP
Thank you for taking the time to review the paper. I've added a few
comments to your message. See below.
>>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> 09/21/99 06:36PM
>> 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
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
> method", lets use "Notification Source" defined at line 409 of the
> 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
TH> We are trying hard to make whether an IPP Printer sends the event
TH> notifications or uses a third party notification service to send
TH> the events as an implementer option that is transparent to both the
TH> and the Notification Recipient. Therefore, we just need to clarify
TH> the Notification Source can be either the IPP Printer or a third party
TH> Notification Service.
TH> The current definition of Notification Source is:
TH> Notification Source - The entity that sends Event Notifications.
TH> How about the following clarification:
TH> Notification Source - The entity that sends Event Notifications. It
TH> either the IPP Printer object or a third party Notification Service,
TH> on implementation.
>> b. So instead of "HTTP Notification server" or "HTTP Notification
> lets use "Notification Recipient" defined at lines 410-414 of the
> 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".
TH> The current definition of Notification Recipient is the entity that
TH> the Notification transferred according to the indicated delivery
TH> Notification Recipient - The entity identified as a recipient within
TH> subscription that receives IPP Notifications about Job and/or Printer
TH> A Notification Recipient may be a: Job Submitting End User, Job
TH> Application (desktop or server), Job Recipient, Job Recipient Proxy,
TH> or Administrator, etc., and their representative or log file or usage
TH> statistics gathering application or other active or passive entities.
TH> In order to be able to describe the kind of Notification Recipient that
TH> talking about that accepts notifications for multiple other entities and
TH> turns around and forwards the notification to the Ultimate Notification
TH> how about introducing the term Ultimate Notification Recipient. The
TH> Recipient receives the IPP Notification and MAY send some kind of
TH> the Ultimate Notification Recipient. Presumably any such Ultimate
TH> Recipient has to have previously agreed with the Notification Recipient
on how to
TH> have the notifications forwarded. For example, an Instant Messaging
TH> by the Notification Recipient (specified in the "notify-recipient" URL)
TH> Ultimate Recipient would be specified in the "subscriber-user-data",
i.e., an ICQ
TH> number that the Instant Messaging service (Notification Recipient) has
TH> allocated to the Ultimate Recipient.
TH> The current definition of "subscriber-user-data" has already started to
TH> phrase "ultimate notification recipient" informally:
TH> 5.4 subscriber-user-data (octetString(63))
TH> This REQUIRED READ-ONLY Subscription object attribute holds opaque
TH> being sent from the Subscriber to the Notification Recipient, such as
TH> identify of the Subscriber or a path or index to some Subscriber
TH> Or it MAY contain a key that the Notification Recipient needs in
TH> process the Notification, such as the ultimate recipient, if the
TH> Recipient is a general application that in turn forwards
notifications and the
TH> ultimate recipient isn't included in the value of the
TH> attribute. An Instant Messaging Service is an example of such a
TH> application where the "subscriber-user-data" might be the user's id
TH> messaging service and the "notification-recipient" is the URL of the
TH> Lets formally define Ultimate Notification Recipient as a new term:
TH> Ultimate Notification Recipient - the entity that ultimately receives
TH> notification, in cases where the Notification Recipient forwards
TH> received to another entity, be it a person or a program. In such
TH> Notification Recipient is still the entity that receives the IPP
TH> according to the Subscription object's "notify-recipient"
TH> Ultimate Notification Recipient is made known to the Notification
TH> means outside of this specification.
>> I'll use these terms in the following comments.
>>> 2. How about changing the name of the request from
> to Send-Notification? That makes it parallel with Send-Document.
> used to use the term "report" and "notification report" in the older
> but changed it to Notification to agree with many notification
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?
TH> I suggest that it is ok to use the same term for the information that is
TH> delivered, no matter whether its format is text or machine-consumable.
>> 3. Also change the name of the Attribute group from "Notification
> Attributes" to "Notification Attributes". Same reason.
>>>> Significant issues/comments:
>> 4. Your proposal requires that the Notification Source send requests
> that the Notification Recipient send back responses. In other words
> acknowledgement protocol. That has some nice properties, but the
> IPP Notification spec only has one directional Notification content.
> should change the notification spec to allow one directional and
> request/response delivery methods?
>> One of the advantages to your request/response notification delivery
> is that it provides an easy way for the Notification Recipient to
> subscription when the Notification Recipient is different from the
> Notification Subscriber. The Notification Recipient returns a status
> to the Notification Source that indicates that the Subscription is to
> canceled. Had the (different) Notification Recipient attempted to
> Cancel-Subscription operation, the current spec would have rejected
> 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.
TH> Even with leases, we have a security problem if the Notification
TH> is different than the Subscriber (Subscription owner) and the
TH> Recipient wants to cancel the subscription. The Cancel-Subscription
TH> because the Notification Recipient isn't the owner. However, if the
TH> Recipient can return a status code in the Send-Notification response to
TH> Notification Source, say, 'successful-ok-cancel-subscription', then that
TH> a simple way for the Notification Recipient to cancel a subscription
that it was
TH> no longer interested in.
TH> But I think that the Notification Source must not cancel a subscription
TH> the Notification Recipient fails to respond. The Notification Recipient
TH> restarted and pick up right where it left off. Or the Notification
TH> could be the victim of temporary network failure so it couldn't reply to
TH> Send-Notification request.
>> 5. I suggest that each request be for a single Notification. Then
> operation attributes "attributes-charset",
> and the "request-id" request parameter can mean for the Notification
> request (see lines 282-287). In other words, the Notification and
> request become one thing. Also the status code in the response goes
> single request/Notification. Much simpler! Since our events don't
> 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.
TH> So far we don't have any IPP requests with an indefinite number of
TH> groups in the request. Only Get-Jobs has multiple number of attributes
TH> in the response.
TH> Presumably, multiple notification in a single request would only be when
TH> them are the machine-consumable format, correct?
TH> Another possibility would be to allow the Send-Notification request to
TH> 'multi-part' MIME type, with each part being a separate notification.
TH> Would that work? Or is it better to use our IPP application layer?
>> a. Option 2 which just sends the Notification attributes in a group
> 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
> same thing.
>>> 6. Issue 4: Probably a new 'ipp-ntfy' scheme. Probably needs a new
> port as well, since they asked that the 'ipp' scheme have a new
TH> Sounds good to me.
>> All for now.