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
This archive was generated by hypermail 2b29 : Wed Jul 11 2001 - 21:02:29 EDT