Hugo,
My comments on your comments starting with TH>.
Tom
-----Original Message-----
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
Notification Protocol
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?
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
subscriber
TH> and the Notification Recipient. Therefore, we just need to clarify
that
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
MAY be
TH> either the IPP Printer object or a third party Notification Service,
depending
TH> on implementation.
>> 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".
TH> The current definition of Notification Recipient is the entity that
receives
TH> the Notification transferred according to the indicated delivery
method:
TH>
TH> Notification Recipient - The entity identified as a recipient within
a
TH> subscription that receives IPP Notifications about Job and/or Printer
events.
TH> A Notification Recipient may be a: Job Submitting End User, Job
Submitting
TH> Application (desktop or server), Job Recipient, Job Recipient Proxy,
Operator,
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
you are
TH> talking about that accepts notifications for multiple other entities and
then
TH> turns around and forwards the notification to the Ultimate Notification
Recipient,
TH> how about introducing the term Ultimate Notification Recipient. The
Notification
TH> Recipient receives the IPP Notification and MAY send some kind of
notification to
TH> the Ultimate Notification Recipient. Presumably any such Ultimate
Notification
TH> Recipient has to have previously agreed with the Notification Recipient
on how to
TH> have the notifications forwarded. For example, an Instant Messaging
Service could
TH> by the Notification Recipient (specified in the "notify-recipient" URL)
and the
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
previously
TH> allocated to the Ultimate Recipient.
TH> The current definition of "subscriber-user-data" has already started to
use the
TH> phrase "ultimate notification recipient" informally:
TH> 5.4 subscriber-user-data (octetString(63))
TH>
TH> This REQUIRED READ-ONLY Subscription object attribute holds opaque
information
TH> being sent from the Subscriber to the Notification Recipient, such as
the
TH> identify of the Subscriber or a path or index to some Subscriber
information.
TH> Or it MAY contain a key that the Notification Recipient needs in
order to
TH> process the Notification, such as the ultimate recipient, if the
Notification
TH> Recipient is a general application that in turn forwards
notifications and the
TH> ultimate recipient isn't included in the value of the
"notify-recipient"
TH> attribute. An Instant Messaging Service is an example of such a
general
TH> application where the "subscriber-user-data" might be the user's id
for that
TH> messaging service and the "notification-recipient" is the URL of the
messaging
TH> service.
TH> Lets formally define Ultimate Notification Recipient as a new term:
TH> Ultimate Notification Recipient - the entity that ultimately receives
the
TH> notification, in cases where the Notification Recipient forwards
notifications
TH> received to another entity, be it a person or a program. In such
cases, the
TH> Notification Recipient is still the entity that receives the IPP
notification
TH> according to the Subscription object's "notify-recipient"
specification. The
TH> Ultimate Notification Recipient is made known to the Notification
Recipient by
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
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?
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
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.
TH> Even with leases, we have a security problem if the Notification
Recipient
TH> is different than the Subscriber (Subscription owner) and the
Notification
TH> Recipient wants to cancel the subscription. The Cancel-Subscription
won't work
TH> because the Notification Recipient isn't the owner. However, if the
Notification
TH> Recipient can return a status code in the Send-Notification response to
the
TH> Notification Source, say, 'successful-ok-cancel-subscription', then that
would be
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
because
TH> the Notification Recipient fails to respond. The Notification Recipient
could be
TH> restarted and pick up right where it left off. Or the Notification
Recipient
TH> could be the victim of temporary network failure so it couldn't reply to
the
TH> Send-Notification request.
>> 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.
TH> So far we don't have any IPP requests with an indefinite number of
attribute
TH> groups in the request. Only Get-Jobs has multiple number of attributes
groups
TH> in the response.
TH> Presumably, multiple notification in a single request would only be when
all of
TH> them are the machine-consumable format, correct?
TH> Another possibility would be to allow the Send-Notification request to
send a
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
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.
TH> Sounds good to me.
>> All for now.
>> Tom