All of the 6 issues, except the first (ordering of Event Notifications),
affect ONLY the ippget Delivery Method document. Some of the resolutions to
these issues may be more than just clarifications and so should get another
WG Last Call. So the question is, is having another WG Last Call on ippget
a good idea or a bad idea?
IPPGET was the last of the three Delivery Methods produced and had the least
review. It was completed after the Last Bake Off, so no one had any code
running that was doing it. IPPGET and the MAILTO Delivery Method have not
passed our Area Director's review before going to the IESG. Now that IPPGET
is the only REQUIRED Delivery Method for IPP FAX, perhaps doing another WG
Last Call wouldn't be such a bad idea. (As editor, I don't have any problem
with making the changes to IPPGET, if there is agreement to make them).
Assuming that we agree to make some changes to IPPGET and agree that those
changes require another WG Last Call and I'm able to get the document
published as an Internet-Draft by this Friday's 2:00 PM PDT time, then the
Last Call could happen during the next three weeks (ending with the IETF
meeting in London, week of August 6-10. During this period, our Area
Directory and the IESG are unlikely to get to review the IPPGET document
that we had sent last Fall. So we might not really lose any time in getting
IPPGET published as an RFC with a second Last Call.
We should probably discuss the Last Call aspects at the beginning of our
telecon today, since it may affect participants support for the resolutions
to the 6 issues.
Comments?
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Tuesday, July 17, 2001 18:50
To: ipp (E-mail)
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.
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
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. IPPGET spec: Same as 4a, but make it OPTIONAL for a Printer to
support other schemes with Get-Notifications.
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.
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)).
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.
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.
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.
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.
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)).