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.
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.
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.
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.
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.
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.
a. Option 2 which just sends the Notification attributes in a group seems
easier than using the new 'collection' attribute syntax.
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