Marty,
So to be clear, if there are more connections than the Printer wants to
commit to IPPGET wait connections, the Printer can return the
"suggested-ask-again-time-interval" along with any events that haven't
elapsed. The client should then disconnect AFTER getting the response. My
understanding is that if the Printer disconnects right way, that the
response may not get back to the client.
However, if the client doesn't disconnect soon, the Printer MAY.
Also, lets continue to REQUIRE that the Printer support the wait mode for an
IMPLEMENTATION DEFINED number of connections, but allow the Printer to use
the above mechanism if the number of connections exceeds this limit. OK?
Here is the current description of the "suggested-ask-again-time-interval"
attribute:
"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.
OK to change it to the following:
"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'.
c) the Printer returns the 'successful-ok' status code and the client
supplied the "notify-no-wait" attribute with a value of 'false' or omitted
it (meaning that the client is requesting the printer to continue to send
responses), but the Printer wishes the client to close the connection
because the number of connections has exceeded an IMPLEMENTATION DEFINED
number. If the client does not close the connection after receiving this
response, the Printer MAY do so.
This value is intended to help the client be a good network citizen.
COMMENTS?
Thanks,
Tom
-----Original Message-----
From: mjoel@netreon.com [mailto:mjoel@netreon.com]
Sent: Monday, July 16, 2001 13:24
To: ipp@pwg.org
Subject: RE: IPP> NOT - substantive clarification about order Printer
send s Event Notifications
Hi Tom,
Regarding allowing the printer to return
"suggested-ask-again-time-interval" with a reply containing events and then
disconnect, even if the client wanted push mode, I like it. This approach
allows server implementors to either not support push mode, or support it
with a limited number of tied-up connections. It also works with existing
client implementations, which will simply respond to what looks to them
like a lost connection (although they won't wait to reconnect, and I see
nothing we can do about that). Good solution.
Regards,
Marty
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/16/2001 12:51:31 PM
To: mjoel@netreon.com
cc: "Bob Herriot (E-mail)" <rherriot@pahv.xerox.com>, "Tom Hastings
(E-mail)" <hastings@cp10.es.xerox.com>, "McDonald Ira at Sharp
(E-mail)" <imcdonald@sharplabs.com>, "Ira at Xerox XR&T McDonald
(E-mail)" <IMcDonald@crt.xerox.com>, "Lewis Harry (E-mail)"
<harryl@us.ibm.com>
Subject: RE: IPP> NOT - substantive clarification about order Printer send
s Event Notifications
Marty,
You make a good technical and process argument here to make the order
implementation dependent. Then no current implementations of Printers
would
be affected.
What about your other suggestion for IPPGET to have a way to return some
events and request the client to disconnect if the Printer finds that there
are currently too many ports tied up?
Do we need to schedule a telecon this Wednesday 10:00 AM PDT on this issue?
The deadline for the I-Ds, is this Friday!!!!!
Instead of the drastic change to make wait mode OPTIONAL to support [and
invert the sense of the "notify-no-wait" (boolean) and change the name),
how
about the following relaxation of the IPPGET spec:
Allow the Printer to return the "suggested-ask-again-time-interval"
attribute along with Event Notifications even when the client had requested
wait mode if the Printer finds that the number of connections is too high.
Currently, the "suggested-ask-again-time-interval" can only be returned if:
a) the Printer returns "server-error-busy' OR
b) the Printer returns 'successful-ok' status code and the client
supplied
the "notify-no-wait" attribute with a value of 'true'.
We could allow the Printer to return "suggested-ask-again-time-interval"
attribute even when the client supplied the "notify-no-wait' = 'false' or
omitted it, in which case the client is kindly requested to disconnect (or
the Printer will).
Thoughts?
Tom
-----Original Message-----
From: mjoel@netreon.com [mailto:mjoel@netreon.com]
Sent: Wednesday, July 11, 2001 18:02
To: ipp@pwg.org; ifx@pwg.org
Subject: RE: IFX> ippget Spec Change Request
Hi Tom,
Thanks for your comments. I'm glad to know the spec can still be changed,
although Ira raised a good point, that we shouldn't break existing ippget
implementations.
Regarding notify-no-wait, I thought about having the printer just
disconnect, but then the client would probably reconnect immediately. The
spec says that suggested-ask-again-time-interval is only for
notify-no-wait=true or server-error-busy, so that seems to mean that for
notify-no-wait=false, if the printer disconnects, the client should just
reconnect without waiting. It would be nice if the printer could return
events with server-error-busy, but that might confuse existing ippget
clients. The spec seems vague regarding if that is possible. What I don't
want to see happen is for a client to hammer on a printer that either
doesn't support pushing or that has a limited number of sockets it will tie
up for pushing. I think it's a bad assumption that if the client keeps
getting server-error-busy every time it asks for notify-no-wait=false, it
will try notify-no-wait=true, although that would be another solution.
Marty
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/11/2001 04:59:34 PM
To: "'mjoel@netreon.com'" <mjoel@netreon.com>
cc: ipp@pwg.org, ifx@pwg.org
Subject: RE: IFX> ippget Spec Change Request
Marty,
You bring up some good points. I've talked with Bob Herriot, Harry Lewis,
Ira McDonald, and left a message for Carl Kugler who is on vacation until
next Wednesday. Harry is talking with his implementers. We can change the
spec even though it is in the IESG queue if there is general agreement on
the IPP DL that it is broken and needs to be fixed. Another alternative
would be to change the conformance ippget requirements for just IPPFAX, but
not IPP.
1. About "notify-no-wait":
We may want to make some changes to make ippget easier for Printers to
support by making the notify-no-wait OPTIONAL (or maybe RECOMMENDED)
instead
of REQUIRED for IPP and IPP FAX. If we do make it OPTIONAL or RECOMMENDED,
we probably need to invert the sense of the attribute from "notify-no-wait"
(boolean) to "persistent-operation" (boolean), so that the omitted case is
the same as the 'false' case which is the simpler no persistent operations.
However, a question to you: If the IPPFAX Printer that is concerned about
using too many connections (as you indicate in your mail), can simply
disconnect after sending the first Get-Notifications response back,
wouldn't
that solve your problem? (The Printer would need to wait at least 5
seconds before disconnecting to make sure that that response did get back
to
the Notification Recipient). Or better still the Printer could keep the
connection open until the number of channels being tied up gets too great
and then disconnect one.
So are you concerned about the complexity of the IPPFAX Printer
implementation of the "notify-no-wait" attribute, or tying up too many
channels in certain cases?
2. About getting Job events after Job completes
Also we need to clarify that the Subscription object which has ippget MUST
stay around at least for the "begin-to-expire-time-interval" time AFTER the
job completes. Also the Job SHOULD stay around for at least that time plus
15 seconds or so, so that a Notification Recipient can go and get any Job
information, such as the "job-name" AFTER getting the event (and the
"job-id").
3. Your question about the 'redirection-other-site' and the
"notify-ippget-redirect" operation attribute. The reason for this for
ippget, is that the actual Notification Server MAY be in a different server
than the Printer. The Printer sends events to this Notification Server
which keeps the Subscription objects and actually delivers the events. See
[ipp-ntfy] Appendix B and Figure 3. However, if we make other changes in
the spec, maybe we should change the name of the "notify-ippget-redirect"
(uri) to something that could be used with any IPP operation:
"redirect-uri"
(uri).
Comments?
Tom
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Wednesday, July 11, 2001 08:59
To: 'mjoel@netreon.com'; ipp@pwg.org; ifx@pwg.org
Subject: RE: IFX> ippget Spec Change Request
Hi Marty,
Thanks very much for your close reading of IPPGET and comments.
I'll let the editors of IPPGET (Tom Hastings and Harry Lewis)
answer your technical questions.
But for context, note that IPPGET has successfully passed an
IPP WG 'last call' and has already been forwarded to the IESG
for publication as a 'standards track' RFC. Which means any
technical content changes would have to be submitted as comments
during the Internet-wide 'last call' (whenever it is announced).
There are existing implementations of IPPGET from several vendors,
so changes that are not backwards compatible will be very hard
to make.
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc
-----Original Message-----
From: mjoel@netreon.com [mailto:mjoel@netreon.com]
Sent: Wednesday, July 11, 2001 2:32 AM
To: ipp@pwg.org; ifx@pwg.org
Subject: IFX> ippget Spec Change Request
Greetings.
Can the spec of the ippget event notification delivery method please be
changed so that an implementation can either support only pull mode, or can
drop to pull mode as needed? An implementation might only be able to
support a limited number of simultaneous connections.
It seems to me that the way the spec is currently proposed, if the printer
receives a Get-Notifications request with notify-no-wait set to false or
omitted, if the printer doesn't want to tie up a socket, it must return
server-error-busy which I assume means it cannot at the same time return
any events, but please correct me if that assumption is wrong. It seems to
me that a new error code is needed that tells the client that it is too
busy for push mode, but that if the request is made again with
notify-no-wait set true, it would be honored. Even better, please add a
status code like successful-ok-too-busy-for-no-wait, so that the events can
at the same time be returned.
Another change I would like to this spec is removal of
client-error-not-found as a possible status code returned by a
Get-Notifications request. When a job ends that had per-job subscriptions,
those subscription objects will be deleted, but there could be event
notification objects that had been created by those subscriptions that will
last for some amount of time. Just because the subscription objects are
gone shouldn't mean the client cannot receive the events.
Finally, please explain why redirection-other-site would be used, and why
it wouldn't apply to all IPP requests. Thanks.
Regards,
Marty Joel
-----Original Message-----
From: mjoel@netreon.com [mailto:mjoel@netreon.com]
Sent: Monday, July 16, 2001 11:25
To: ipp@pwg.org
Subject: Re: IPP> NOT - substantive clarification about order Printer
sends Event N otifications
Hi Tom, et al,
The whole purpose of defining an event order seems to be to make coding
easy for the client implementors, at the expense of the server
implementors. I'm wearing both hats, so it's all the same to me. I
suppose that theoretically there could be more client than server
implementations, which might be the only rational for all this. As I see
it, for implementing a client, it's as difficult to handle the events
grouped by subscription as it would be if the event order was random. For
that reason, I propose that algorithm option (a) below be discarded.
If I was to decide between forcing the events to be in chronological order
(option (b) below) or that they be random (implementation-specific), I
would choose random. I think it is more important that the server be able
to process requests as quickly as possible, than to make it easy for the
client impementors to code. If sorting is to be done, for performance
reasons it makes more sense to me that it be done at the client.
For these reasons, and for the fact that existing implementations may be
ordering events differently than the proposals below, I propose that the
specifications be changed to state that the event order is determined by
the implementation, and that if the client needs them chronological it
should sort them.
Regards,
Marty Joel
"Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 07/16/2001
10:23:36 AM
Sent by: owner-ipp@pwg.org
To: ipp@pwg.org
cc: mjoel@netreon.com
Subject: IPP> NOT - substantive clarification about order Printer sends
Event N otifications
As Marty and others have pointed out, we need to see if specifying the
order
that a Printer sends separate Event Notifications and Event Notifications
within a Compound Event Notification will affect current implementations of
ippget, indp, and mailto.
Bob, Ira, and I have collaborated on defining the order that the Printer
sends Event Notifications. We suggest that implementations have two
choices
for ordering that should cover the likely implementation approaches. See
"Printer Event Sending Algorithm" below.
***********************************************************************
Please review these proposals to see if you agree on including them in the
next version of the Event Notification spec and the three Delivery Method
documents.
The deadline for I-Ds is this Friday, so I'd like to hear by Tuesday PM,
July 17.
***********************************************************************
General comments:
1. 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.
************** Beginning of proposed new text *****************
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.
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:
In 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.
In 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.]
************** End of proposed new text *****************
Tom
This archive was generated by hypermail 2b29 : Mon Jul 16 2001 - 17:25:14 EDT