Hi all,
My comments regarding today's upcoming discussion are marked below with
MJ>.
Marty
"Hastings, Tom N" <hastings at cp10.es.xerox.com>@pwg.org on 07/17/2001
06:50:14 PM
Sent by: owner-ipp at pwg.org
To: "ipp (E-mail)" <ipp at pwg.org>
cc:
Subject: IPP> NOT - 6 Notification ISSUES Agenda: Telecon Wed 7/18, 10-11
PDT ( 1-2 EDT )
Here is the document for tomorrow's telecon that describes each issue in
detail, lists PRO and CON, and provide the explicit text for each change.
Several issues have two alternatives (A) and (B).
Time: Wednesday, 7/18/01, 10-11 PDT (1-2 EDT)
Phone: 1(712)884-1555 (Xerox folks: 8*596-5170
Passcode: 654970
This mail message is also provided as a .doc file at:
ftp://ftp.pwg.org/ftp/pub/pwg/ipp/new_NOT/notification-clarifications.doc
SUBJECT: 6 ISSUES with IPP Notification specs
Date: 7/17/01
File: notification-clarifications.doc
There have been a number of issues (some changes and some
clarifications) of the IPP Notification Specification and mostly the
ippget Delivery Method spec. This note is an attempt to summarize
them and indicate support so far for each. The summary of the 6
issues are:
1A. Base Notification Spec: Clarify that the Printer MAY send Event
Notifications in any order.
MJ> Are there existing client implementations that will break if we impose
ordering now?
1B. Base Notification Spec: Clarify that the Printer MUST send Event
Notifications for any given Subscription Object in time stamp order,
but MAY interleave Event Notifications from other Subscription
Objects
MJ> I think that 1B means that all events are ordered, regardless of what
subscription they came from, at least that's what "interleave" implies.
That would differ from the original proposal that they be sorted
chronologically within subscription groups. On looking below at the
proposed text for this, it's saying that events can either be sorted
chronologically regardless of what subscription caused them, or that they
can be sorted chronologically in groups by subscription. You might as well
say that they can either be sorted or not, since
sorted-within-subscription-groups requires as much work at the client as
sorting unordered events.
MJ> 1C. The 3rd option is that events be ordered, which I think makes more
sense than 1B, although I'd prefer 1A. 1B puts sorting onto the client,
and if you're going to do that anyway, you might as well go with 1A.
2. IPPGET spec: Get-Notification matching "notify-recipients-uri"
with Subscription objects: octet-by-octet versus URI matching rules.
(IPPGET currently says both).
MJ> I'm clearly the minority on octet-by-octet, and I don't feel strongly
enough to argue it. From an implementation view, I suppose the most
efficient way to handle the URI-type comparison is to convert everything up
to the first '/' to lower case and store it that way in the notification
object, and on receiving Get-Notifications, do the same thing to the given
notify-recipient-uri before starting the (octet-by-octet) comparisons. The
down side of doing that is that then the case could be changed on the
notify-recipient-uri returned by Get-Notification-Attributes. However,
storing both the original and the lower-case-to-slash versions in the
notification object is a waste of space, and having to do the conversion of
the notify-recipient-uri in each subscription object every time
Get-Notifications is received is a waste of time. Comments?
3. IPPGET spec: In a Get-Notifications response when the client has
requested the wait mode (persistent operation), allow a Printer to
return the unexpired Notification Events, but also indicate to the
client to please disconnect and try again at the indicate interval
("suggested-ask-again-time-interval"). (IPPGET currently only allows
the interval to be returned if the client didn't ask for wait mode or
if the Printer is too busy to return any Notification Events).
4A. IPPGET spec: Clarify that the Get-Notifications operation is for
querying any kind of unexpired Events, not just ippget Events. Thus
the "notify-recipients-uri" operation attribute can match any
Subscription object including the scheme. Also all Events have a
life time, not just ippget Events, if the Printer supports Get-
Notifications (which requires ippget scheme at least).
4B. IPPGET spec: Same as 4a, but make it OPTIONAL for a Printer to
support other schemes with Get-Notifications.
MJ> 4C. Rename Get-Notifications to Get-Ippget-Notifications. If some
future delivery method needs something similar, Get-<future deliver method
name>-Notifications can be added.
MJ> 4D. Allow something like 4A but only for delivery methods that
support both PUSH and PULL like ippget. Letting Get-Notifications support
a delivery method that doesn't support both PUSH and PULL like ippget
1) is unnecessary because events generated by subscriptions for other
delivery methods are going to be delivered anyway, according to the rules
of their delivery method
2) puts additional memory and processing burden on the printer for
something that's unnecessary anyway (see above)
3) Breaks existing implementations, which currently aren't storing
event objects.
5. IPPGET spec: Change the sense of the Get-Notifications "notify-no-
wait" (boolean) operation attribute to a positive "persistent-
operation" (boolean), so that omitted and 'false' mean the easier
non-persistent operation.
MJ> I like this idea, but not if it breaks existing implementations.
MJ> I've got some real problems with the whole PUSH issue for ippget.
>From a design perspective it's probably cut and dry, but I'm losing hair
trying to implement this. Specifically:
a) How am I supposed to handle HTTP's Content-Length?
b) Won't this only work with HTTP's Keep-Alive?
c) Can this even work with HTTP 1.0?
d) How is the client supposed to know when it's done receiving some
events? If clients used Content-Length before, now do they have to add a
timeout?
e) It seems that HTTP's multi-part should be used, 1 part for the first
blast and another either for each event or for each group of events. I
really don't want to have to add HTTP multi-part support just for this.
MJ> I'm tempted to always use the mechanism I proposed for issue 3 and
simply not support PUSH, if I cannot solve the HTTP issues.
6. IPPGET spec: Rename some attributes but keep the same semantics:
"notify-ippget-redirect" (uri) to "notify-redirect-uri" (uri),
"suggested-ask-again-time-interval" (integer(0:MAX)) to
"notify-get-interval", and
"begin-to-expire-time-interval" (integer(0:MAX)) to "event-
life-time" (integer(0:MAX)).
MJ> I like these changes, but not if they break existing implementations.
I've talked with the following folks individually about the above and
have the following positions (blank means they weren't asked or didn't
have an opinion):
ISSUE HL IM BH TH MJ TT CM MS
1A.Clarify no Event ordering Y N Y N Y N N
1B.Events MUST be ordered by SO N Y Y N Y Y
2. URI match rules Y Y Y Y N Y Y
3. Printer suggest disconnect Y Y Y Y Y Y
4A.Poll for any scheme N Y N N N N N
4B.Poll for any scheme OPTIONALLY N Y N Y N
5. change wait sense Y Y Y N Y Y
6. rename some attributes Y Y N N N Y N Y
Now comes the detailed discussion and the actual text change for each
proposal:
1. Notification spec [ipp-ntfy]: General comments about ordering:
a. We need to say something about the ordering of Event
Notifications as sent by the Printer, both for separate Event
Notifications and within Compound Event Notifications.
2. We also need to say that depending on the underlying transport,
the order received of separate Event Notifications by a
Notification Recipient MAY be different.
3. ippget and mailto don't even mention Compound Event
Notifications, so we need to update the text and refer back to
[ipp-ntfy] for all three delivery methods for the ordering
requirements. See the proposed text below.
There are two alternatives: 1A: No ordering requirements and 1B:
ordered by time stamp for each Subscription object, whether
interleaved or not.
Discussion: Most Notification standards require time sequencing.
Requiring the Printer to order by time stamp for each Subscription
object, but allowing interleaving, is not a burden on the Printer and
allows simple clients to deal with events without having to sort.
Complicated accounting clients may still have to sort.
MJ> Sorting most definitely puts a burden on the printer.
1A. Base Notification Spec: Clarify that the Printer MAY send Event
Notifications in any order.
For the Base Event Notifications spec [ipp-ntfy] section 9 after
paragraph 2 add the following text:
Printer Event Sending Algorithm:
When a Printer processes multiple pending Events, the Printer MAY
send the Event Notifications in any order. There is no requirement
that they be sent in time stamp order, i.e., there is no requirement
that they be sent in the order of increasing "printer-up-time"
attribute value in the Event Notification (see Table 5).
Notification Recipients MUST accept the Event Notifications in any
order.
There is no need to add any text to any of the Delivery Methods.
1B. Base Notification Spec: Clarify that the Printer MUST send Event
Notifications for any given Subscription Object in time stamp order, but
MAY interleave Event Notifications from other Subscription Objects.
Notification Delivery Method documents refer to the Base Spec for
ordering.
For the Base Event Notifications spec [ipp-ntfy] section 9 after
paragraph 2 add all of the following text:
Printer Event Sending Algorithm:
When a Printer processes multiple pending Events, the Printer MUST
send Event Notifications in one of the following orders, whether as
multiple separate Event Notifications or together in a single
Compound Event Notification:
a) The Event Notifications are grouped by the Subscription Object
from which the Event Notifications are generated. Within each such
grouping, the Event Notifications are in time stamp order, i.e., in
order of increasing "printer-up-time" attribute value in the Event
Notification (see Table 5). Between such groupings, the order of
Event Notifications is IMPLEMENTATION DEPENDENT.
MJ> a) might as well say that events can be in any order, since that's the
effect on the client, which will most likely have to sort the events.
OR
b) The Event Notifications are in time stamp order (order of
increasing "printer-up-time" attribute value), even when generated
from multiple Subscription Objects.
Note that with either variant a) or variant b) of the Printer Event
Sending Algorithm, the Printer always sends the Event Notifications
generated from a given Subscription Object in time stamp order, even
when the Printer sends intervening Event Notifications generated by
other Subscription objects. If a Subscribing Client wants to ensure
that the Printer sends certain Event Notifications in time stamp
order, the Subscribing Client must ensure that the subscription for
the Events are in the same Subscription Object. Even so, depending
on the underlying transport, the actual order that a Notification
Recipient receives separate Event Notifications MAY differ from the
order sent by the Printer.
A variant wording which is shorter and has examples is the following:
Printer Event Sending Ordering:
When a Printer sends Event Notifications, the Event Notifications
from any given Subscription Object MUST be in time stamp order, i.e.,
in order of increasing "printer-up-time" attribute value in the Event
Notification (see Table 5). These Event Notifications MAY be
interleaved with those from other Subscription Objects, as long as
those others are also in time stamp order. The Printer MUST observe
these ordering requirements whether sending multiple pending Events
as multiple separate Event Notifications or together in a single
Compound Event Notification.
If a Subscribing Client wants the Printer to send certain Event
Notifications in time stamp order, the Subscribing Client ensures
that the subscription for the Events are in the same Subscription
Object. Even so, depending on the underlying transport, the actual
order that a Notification Recipient receives separate Event
Notifications MAY differ from the order sent by the Printer.
Example: Consider two Per-Printer Subscription Objects: SO1 and SO2.
SO1 requests 'job-state-changed' events and SO2 requests 'printer-
state-changed' events. The number in parens is the time stamp. Any
of the following Event Notification sequences conform to the ordering
requirements for the Printer to send the Notification Events:
(a) 'job-created' (1000), 'job-stopped' (1005), 'job-completed'
(1009), 'printer-stopped (1005)'
(b) 'job-created' (1000), 'job-stopped' (1005), 'printer-stopped'
(1005), 'job-completed (1009)'
(c) 'job-created' (1000), 'printer-stopped' (1005), 'job-stopped'
(1005), 'job-completed (1009)'
Examples (b) and (c) are interleaved, (a) is not.
IPPGET:
Make the following changes to the first paragraph in the Get-
Notifications Response, section 5.2 (I put [] around new text, but
deleted old text without indication):
Group 3 through N: Event Notification Attributes
The Printer responds with one Event Notification Attributes Group per
matched Event Notification. [The entire response is considered a
single Compound Event Notification (see [ipp-ntfy]).] The initial
matched Event Notifications are all un-expired Event Notifications
associated with the matched Subscription Objects [and MUST follow the
ordering requirements for Event Notifications within a Compound Event
Notification specified for the "Printer Event Sending Algorithm" in
[ipp-ntfy] section 9].
If the Notification Recipient has selected the option to wait for
additional Event Notifications [(the "notify-no-wait" attribute was
set to 'false' or was omitted)], the Printer {sends} subsequent Event
Notifications in the response [each time it processes additional
Events]. [Each time the Printer sends such Event Notifications,
their ordering MUST be the ordering specified for the "Printer Event
Sending Algorithm" in [ipp-ntfy] section 9.]
[ Note: If a Notification Recipient performs two consecutive Get-
Notifications operations, the time stamp of the first Event
Notification in the second Get-Notifications Response may be less
than the time stamp of the last Event Notification in the first Get-
Notification Response. This happens because the Printer sends all
unexpired Event Notification according to the ordering specified in
[ipp-ntfy] and some Event Notifications from the first Get-
Notifications operation may not have expired by the time the second
Get-Notifications operation occurs. ]
INDP:
In INDP section 8.1 Send-Notifications Request, 2nd paragraph (I put
[] around the new text):
The Printer composes the information defined for an IPP Notification
[ipp-ntfy] and sends it using the Send-Notifications operation to the
Notification Recipient supplied in the Subscription object. [The
ordering of separate Send-Notifications operations that a Printer
sends MUST be the ordering specified for the "Printer Event Sending
Algorithm" in [ipp-ntfy] section 9.]
In INDP section 8.1.1 Send-Notifications Request (I put [] around the
new text):
Group 2 to N: Event Notification Attributes
In each group 2 to N, each attribute is encoded using the IPP rules
for encoding attributes [RFC2910] and [the attributes within a group]
MAY be encoded in any order. [The entire request is considered a
single Compound Event Notification and MUST follow the ordering
requirements for Event Notifications within a Compound Event
Notification specified for the "Printer Event Sending Algorithm" in
[ipp-ntfy] section 9.] Note: the Get-Jobs response in [RFC2911] acts
as a model for encoding multiple groups of attributes.
MAILTO:
MAILTO section 6, add the following after the existing 2nd paragraph:
While the "Printer Event Sending Algorithm" in [ipp-ntfy] section 9
specifies ordering requirements for Printers when sending separate
Event Notifications, email messages are not guaranteed to arrive in
the order sent so that the Notification Recipient may not receive
them in the same order.
MAILTO section 6 Event Notification Content, right before section 6.1
(I put [] around the new text):
The Event Notification content has two parts, the headers and the
message body. The headers precede the message body and are separated
by a blank line (see [RFC 822]).
[A Printer implementation MAY combine several Event Notifications
into a single email message body. Such an email message is
considered a single Compound Event Notification and MUST follow the
ordering requirements for Event Notifications within a Compound Event
Notification specified for the "Printer Event Sending Algorithm" in
[ipp-ntfy] section 9.]
2. IPPGET spec: Get-Notification matching "notify-recipients-uri" with
Subscription objects: octet-by-octet versus URI matching rules. (IPPGET
currently says both).
Discussion: PRO: Its needed in order to get our ippget scheme
accepted by the IETF and is more user friendly, in case a different
human is supplying the Notification Recipient URI than the
Subscribing Client. CON: Its harder to implement. REBUTTAL: Most
platforms have a compare URI routine.
Change IPPGET Section 5.1 from:
"notify-recipient-uri" (url):
The client MUST supply this attribute. The Printer object MUST
support this attribute. The Printer matches the value of this
attribute (byte for byte with no case conversion) against the
value of the "notify-recipient-uri" in each Subscription Object
in the Printer. If there are no matches, the IPP Printer MUST
return the 'client-error-not-found' status code.
to:
"notify-recipient-uri" (url):
The client MUST supply this attribute. The Printer object MUST
support this attribute. The Printer matches the value of this
attribute against the value of the "notify-recipient-uri" in
each Subscription Object in the Printer following the normal
URI comparison rules (see section 9.5.2). If there are no
matches, the IPP Printer MUST return the 'client-error-not-
found' status code.
3. IPPGET spec: In a Get-Notifications response when the client has
requested the wait mode (persistent operation), allow a Printer to
return the unexpired Notification Events, but also indicate to the
client to please disconnect and try again at the indicate interval
("suggested-ask-again-time-interval"). (IPPGET currently only allows
the interval to be returned if the client didn't ask for wait mode or if
the Printer is too busy to return any Notification Events).
Discussion: PRO: For simple Printers, especially IPPFAX, this
allows them not to have to support unlimited numbers of connections
with the REQUIRED ippget Delivery Method. CON: Another thing for
the client to check. REBUTTAL: but the client needs to check this
anyway.
Change section 5.2:
"suggested-ask-again-time-interval" (integer(0:MAX)):
The value of this attribute is the number of seconds that the
Notification Recipient SHOULD wait before trying this operation
again when
a) the Printer returns the 'server-error-busy' status
code OR
b) the Printer returns the 'successful-ok' status
code
and the
client supplied the "notify-no-wait" attribute with a value
of 'true'.
This value is intended to help the client be a good network
citizen.
to:
"suggested-ask-again-time-interval" (integer(0:MAX)):
The value of this attribute is the number of seconds that the
Notification Recipient SHOULD wait before trying this operation
again when
a) the Printer returns the 'server-error-busy' status
code OR
b) the Printer returns the 'successful-ok' status
code
and the
client supplied the "notify-no-wait" attribute with a value
of 'true' (the no wait case).
c) the Printer returns the 'successful-ok' status
code
and the
client supplied the "notify-no-wait" attribute with either
'false' value or omitted the attribute all together (the
wait case) and the Printer wants the client to disconnect,
instead of staying connected. The client MUST accept this
response and MUST disconnect. If the client does not
disconnect, the Printer SHOULD do so. The Printer returns
this attribute for this case only if the implementation
does not want to keep the connection open at this time. If
the Printer wants the client to keep the connection open,
then the Printer MUST NOT return this attribute in the
response.
This value is intended to help the client be a good network
citizen.
4A. IPPGET spec: Clarify that the Get-Notifications operation is for
querying any kind of unexpired Events, not just ippget Events. Thus the
"notify-recipients-uri" operation attribute can match any Subscription
object including the scheme. Also all Events have a life time, not just
ippget Events, if the Printer supports Get-Notifications (which requires
ippget scheme at least).
Discussion: PRO: Other notification mechanisms, like SNMP, have both
polling and traps for the same events. Also the client supplies a
fully general "notify-recipient-uri" operation attribute in the Get-
Notifications operation. CON: Its more complications and not that
useful with our INDP and mailto methods.
MJ> My comments are above in the overview for 4. I'm opposed to both the
4A and 4B proposals.
Add to IPPGET section 5.1, Get Notifications Request, "notify-
recipient-uri" (uri) operation attribute:
The Printer MUST accept this request for any URI scheme that it
supports for Notification, not just the 'ippget' scheme, i.e., for
any value of the Printer's "notify-schemes-supported" Printer
Description attribute. If the URI scheme is not among the values of
the Printer's "notify-schemes-supported" Printer Description
attribute, the Printer rejects the request and returns the 'client-
error-uri-scheme-not-supported' status code.
Change Section 7.3 begin-to-expire-time-interval (integer(0:MAX))
from:
This Printer Description attribute specifies the number of seconds
that a Printer keeps an Event Notification that is associated with
the 'ippget' Delivery Method.
The Printer MUST support this attribute if it supports the 'ippget'
Delivery Method.
The value of this attribute is the minimum number of seconds that
MUST elapse between the time the Printer creates an Event
Notification object for the 'ippget' Delivery Method and the time the
Printer discards the same Event Notification.
to:
This Printer Description attribute specifies the number of seconds
that a Printer keeps an Event Notification that is associated with
any Delivery Method.
The Printer MUST support this attribute if it supports the 'ippget'
Delivery Method or the Get-Notifications operation.
The value of this attribute is the minimum number of seconds that
MUST elapse between the time the Printer creates an Event
Notification object for any Delivery Method and the time the Printer
discards the same Event Notification.
4B. IPPGET spec: Same as 4a, but make it OPTIONAL for a Printer to
support other schemes with Get-Notifications.
Discussion: PRO: Other notification mechanisms, like SNMP, have both
polling and traps for the same events. Also the client supplies a
fully general "notify-recipient-uri" operation attribute in the Get-
Notifications operation. CON: Its more complications and not that
useful with our INDP and mailto methods AND its another
interoperability OPTION, thereby reducing the chances that a client
would both supporting it.
Add to IPPGET section 5.1, Get Notifications Request, "notify-
recipient-uri" (uri) operation attribute:
The Printer MUST accept this request for any URI scheme that it
supports for use with the Get-Notifications operation, not just the
'ippget' scheme, i.e., for any value of the Printer's "notify-
schemes-supported" Printer Description attribute for which the
Printer supports the Get-Notifications operation. If the URI
scheme is not one of the values that the Printer supports for the
Get-Notifications operation, the Printer rejects the request and
returns the 'client-error-uri-scheme-not-supported' status code.
Change Section 7.3 begin-to-expire-time-interval (integer(0:MAX))
from:
This Printer Description attribute specifies the number of seconds
that a Printer keeps an Event Notification that is associated with
the 'ippget' Delivery Method.
The Printer MUST support this attribute if it supports the 'ippget'
Delivery Method.
The value of this attribute is the minimum number of seconds that
MUST elapse between the time the Printer creates an Event
Notification object for the 'ippget' Delivery Method and the time the
Printer discards the same Event Notification.
to:
This Printer Description attribute specifies the number of seconds
that a Printer keeps an Event Notification that is associated with
any Delivery Method for which it supports the Get-Notifications
operation.
The Printer MUST support this attribute if it supports the 'ippget'
Delivery Method or the Get-Notifications operation.
The value of this attribute is the minimum number of seconds that
MUST elapse between the time the Printer creates an Event
Notification object for any Delivery Method for which it supports the
Get-Notifications operation and the time the Printer discards the
same Event Notification.
5. IPPGET spec: Change the sense of the Get-Notifications "notify-no-
wait" (boolean) operation attribute to a positive "persistent-operation"
(boolean), so that omitted and 'false' mean the easier non-persistent
operation.
Discussion: PRO: Boolean attributes should be names with positive
names, else they are likely to be mis-implemented. The harder, more
unusual value should be the 'true' and the normal, easier value
should be 'false' or omitted, i.e., the default behavior. CON: This
will affect any implementations not currently participating in the
discussion and our chair may require us to do another WG Last Call,
thereby further delaying our getting the IPPGET spec out (though its
still in the AD's queue).
Change section 5.1, "notify-no-wait" (boolean) from:
"notify-no-wait" (boolean):
The client MAY supply this attribute. The Printer object MUST
support this attribute. If the value of this attribute is
'false', the Printer MUST send all un-expired Event
Notifications (as defined in the previous attribute) and it
MUST continue to send responses for as long as the Subscription
Objects associated with the specified "notify-recipient-uri"
continue to exist. If the value of this attribute is 'true',
the Printer MUST send all un-expired Event Notifications (as
defined in the previous attribute) and the Printer MUST
conclude the operation without waiting for any additional
Events to occur. If the client doesn't supply this attribute,
the Printer MUST behave as if the client had supplied this
attribute with the value of 'false'.
to:
"persistent-operation" (boolean):
The client MAY supply this attribute. The Printer object MUST
support this attribute. If the value of this attribute is
'false' or omitted, the Printer MUST send all un-expired Event
Notifications (as defined in the previous attribute) and the
Printer MUST conclude the operation without waiting for any
additional Events to occur. If the value of this attribute is
'true', the Printer MUST send all un-expired Event
Notifications (as defined in the previous attribute) and it
MUST continue to send responses for as long as the Subscription
Objects associated with the specified "notify-recipient-uri"
continue to exist.
MJ> This wording looks good, and I like that omission of this attribute
means false.
6. IPPGET spec: Rename some attributes but keep the same semantics:
"notify-ippget-redirect" (uri) to "notify-redirect-uri" (uri),
"suggested-ask-again-time-interval" (integer(0:MAX)) to "notify-
get-interval", and
"begin-to-expire-time-interval" (integer(0:MAX)) to "event-life-
time" (integer(0:MAX)).
Discussion: CON for all 3 changes: This will affect any
implementations not currently participating in the discussion and our
chair may require us to do another WG Last Call, thereby further
delaying our getting the IPPGET spec out (though its still in the
AD's queue).
PRO: The "notify-ippget-redirect" doesn't have "uri" in the name,
like all our other IPP attribute names. Also while the attribute is
restricted to the Get-Notifications operation (and maybe ippget), it
could in principle be used with other operations, so the "ippget"
should be dropped from the name.
PRO: The "suggested-ask-again-time-interval" is too long and doesn't
have anything about notification in the name.
PRO: The "begin-to-expire-time-interval" is too long and doesn't
have anything about events in the name. Also "life-time" is a common
term for this interval.
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Tuesday, July 17, 2001 13:31
To: ipp (E-mail)
Subject: IPP> NOT - 6 Notification ISSUES: Telecon Wed 7/18, 10-11 PDT
(1-2 EDT )
Importance: High
There have been 6 issues (some changes and some clarifications) of the IPP
Notification Specification and the three Delivery Methods (ippget, indp,
and
mailto). Some of these issues have come up as folks implement IPP FAX
which
REQUIRES the ippget Delivery Method. We are close to consensus on the
mailing list and my calling those who have sent email. However, I want to
make sure and each time I talk to someone they bring up some more good
points. So I'd like to have a quick telecon tomorrow to make sure we
agree.
I'll send out the specific text changes later today for the following 6
issues.
Time: Wednesday, 7/18/01, 10-11 PDT (1-2 EDT)
Phone: 1(712)884-1555 (Xerox folks: 8*596-5170
Passcode: 654970
If you can't make the telecon, please send email. We don't want to impact
any implementations underway, unless you participate. I want to update
these specifications before the next Internet-Draft deadline which is this
Friday.
The summary of the 6 issues are:
1. Clarify that the Printer MAY send Event Notifications in any order.
2. IPPGET spec: Get-Notification matching "notify-recipients-uri" with
Subscription objects: octet-by-octet versus URI matching rules. (IPPGET
currently says both).
3. IPPGET spec: In a Get-Notifications response when the client has
requested the wait mode (persistent operation), allow a Printer to return
the unexpired Notification Events, but also indicate to the client to
please
disconnect and try again at the indicate interval
("suggested-ask-again-time-interval"). (IPPGET currently only allows the
interval to be returned if the client didn't ask for wait mode or if the
Printer is too busy to return any Notification Events).
4a. IPPGET spec: Clarify that the Get-Notifications operation is for
querying any kind of unexpired Events, not just ippget Events. Thus the
"notify-recipients-uri" operation attribute can match any Subscription
object including the scheme. Also all Events have a life time, not just
ippget Events, if the Printer supports Get-Notifications (which requires
ippget scheme at least).
4b. Same as 4a, but make it OPTIONAL for a Printer to support other schemes
with Get-Notifications.
5. Change the sense of the Get-Notifications "notify-no-wait" (boolean)
operation attribute to a positive "persistent-operation" (boolean), so that
omitted and 'false' mean the easier non-persistent operation.
6. IPPGET spec: Rename some attributes but keep the same semantics:
"notify-ippget-redirect" (uri) to "notify-redirect-uri"
(uri),
"suggested-ask-again-time-interval" (integer(0:MAX)) to
"notify-get-interval", and
"begin-to-expire-time-internal" (integer(0:MAX)) to
"event-life-time" (integer(0:MAX)).