I agree with Tom's opinions below, with the clarification that I think the
client support should be a SHOULD.
On a related note, it seems to me that not everyone who might be interested
in this is necessarily "listening" to the mailing list. Imagine someone
from deep inside Kinkos trying to architect a new solution for their
far-flung empire. He looks at IPP, notices the polling aspects, then sees
our notification specs, including IPPGET, but realizes that there will be a
problem in his company with each printer handling a number of IPPGET
connections, then notices this redirect mechanism and is happy. Aren't we
possibly leaving this guy out in the cold if we pull functionality? At the
very least, trying to pull functionality out of a spec some number of
months after that spec has been available to the public, *on the basis that
no one on the mailing list seems to be using it*, seems to be ill-advised.
And as far as the IETF approval goes, aren't we only talking about the
following: we get the reponse from the reviewer, and among his *many*
comments is one single comment saying essentially "Why don't you use HTTP
redirect?". Then our response would be "Because our mechanism allows
redirect of one specific command," and he would say "Oh, ok". Are we
really expecting that they won't accept our explanation?
Dennis Carney
IBM Printing Systems
"Hastings, Tom N"
<hastings@cp10.es To: Robert Herriot <bob@herriot.com>, Harry Lewis/Boulder/IBM@IBMUS
.xerox.com> cc: ipp@pwg.org
Sent by: Subject: IPP> RE: IFX> Attempt to close on the two Notification specs at the fa ce to face
owner-ipp@pwg.org meetings
08/27/02 06:19 PM
So Bob proposes:
1. Change the proposed name from "alternate-target-uri" to
"optimal-target-uri".
I agree. This seems to be a better name and doesn't preclude us from using
this attribute for any operation in the future where there is an more
optimal uri. The URI might be more optimal because it is faster or because
the server doesn't keep closing down the Get-Notifications wait mode
connection because the server can keep a huge number of connections open
simultaneously (for a number of printers).
2. Clarify that the URI can be to the same Printer implementation; it
doesn't have to be to a different host that has the Notification Server.
I agree.
3. Clarify that the URI can even be the same as the original URI, so that
it
isn't any more optimal. So the client doesn't have to check for the same
or
different, but can just blindly use it for subsequent Get-Notifications.
I agree. So the description would say that the URI MAY provide more
optimal
performance either faster or less likely to close down the connection.
So the language would be something like the Printer MAY return the
"optimal-target-uri" operation attribute which is a hint to the client to
use for subsequent Get-Notifications requests. The URI returned depends on
implementation. For example, the URI MAY be (1) to a separate Notification
Server, (2) a different URI to the same Printer implementation, or (3) the
same URI as the original target URI to the same Printer implementation.
Depending on implementation, the URI MAY provide better performance or
reduce the chance of the target closing the Get-Notifications Wait Mode
connection in order to reduce the number of simultaneous connections.
4. Change the client conformance requirement to support the
"optimal-target-uri" from SHOULD to MAY.
I'm not sure I agree. Carl Bugler's added reason for using a server to be
able to support a large number of connections (500 or more) seems a
compelling reason for Printers to use a Notification Server with IPPGET and
so at least RECOMMEND that clients use the returned URL, if not REQUIRE
clients to use it, for subsequent Get-Notifications.
Question:
Has this become so simple for Printers, that we could REQUIRE the printer
to
always return "optimal-target-uri" to simplify clients, now that the URI
can
be the same as the original Printer target URI.
Tom
-----Original Message-----
From: Robert Herriot [mailto:bob@herriot.com]
Sent: Tuesday, August 27, 2002 02:15
To: Hastings, Tom N; ipp@pwg.org; ifx@pwg.org; Lewis, Harry
Cc: pwg@pwg.org
Subject: Re: IFX> Attempt to close on the two Notification specs at the
face to face meetings
Tom,
If we agree that we must keep the redirection notion, then I agree (mostly)
with your proposed changes, but not with your reasoning. However, I still
think that most clients will not implement redirection, so redirection ends
up being effectively proprietary and thus not a concept that should be in a
standard. Assuming that we will keep redirection, here are my thoughts on
your proposal.
You propose a possible implementation of a printer with a remote
notification server and imply that the existence of this solution somehow
changes the rules. This implementation may have led you to this solution,
but it is not the essence of your proposal or important to it.
The effect of what your proposed change is that a printer must directly
support ipp-get if it supports event notification. That is, the cannot
return nothing and redirect the client to the real notification server.
Your
proposal could have stopped there and said that the redirection uri is
eliminated.
Instead, you added an optional "alternate-target-uri" attribute, which I
think should be called "optimal-target-uri" (as that is what it really is).
The "redirect-uri" has the flaw that the client gets nothing if it doesn't
implement "redirect-uri". With "optimal-target-uri", the client gets event
notifications even if it doesn't implement "optimal-target-uri". Its
implementation is an optimization only -- but perhaps not sufficiently
optimal to be worth the support of anyone. Once you realize, that
"optimal-target-uri" is just an optimal uri, it need not be just some
remote
notification server. It could also be a different uri in the same printer.
It doesn't really matter, but the presence of this attribute tells the
client that there is a better uri to use. If you keep this attribute, I
would leave the language open for the uri to be anywhere a printer wants it
to be.
I also think that in item 3, client support is a "MAY" rather than a
"SHOULD". It doesn't really matter whether a client supports this
attribute, especially almost no one will implement it.
I also would ask if the "optimal-target-uri" must be different from the
printer-uri. That is, could it always be returned by a printer, even when
it
would be the same as the printer uri. I think that the intention is that a
printer would only return it when there is an optimal uri that is different
from the printer, but that it need not be different (i.e. the client need
not check for this).
Bob Herriot
----- Original Message -----
From: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
To: <ipp@pwg.org>; <ifx@pwg.org>; "Lewis, Harry" <harryl@us.ibm.com>
Cc: <pwg@pwg.org>
Sent: Monday, August 26, 2002 5:25 PM
Subject: RE: IFX> Attempt to close on the two Notification specs at the
face
to face meetings
> Harry et al,
>
> In answering Ira's note, a win-win approach occurred to me. This
approach
> will allow a Printer to use a notification server, but won't put any
burden
> on clients. I called Ira up and he is enthusiastic as well. He helped
me
> flesh out the proposal. Here is the idea:
>
> When a Printer implements Get-Notifications using a Notification Server,
why
> not have the Printer just pass each Get-Notifications request along to
the
> Notification Server, which returns the response to the Printer which
returns
> that response to the client. In protocol terminology, the Printer is
> "relaying" the Get-Notifications request to the notification server.
Yes,
> this are 4 hops, instead of 2, but its transparent to the client. The
> Notification Server can return to the Printer the "redirect-uri"
operation
> attribute as an advisory hint to the client (which the Printer passes
back
> to the client) to improve the performance, but clients not knowing about
> that "redirect-uri" operation attribute would simply keep doing
subsequent
> Get-Notifications to the Printer. The down side is that there are 4
network
> hops, instead of 2, for the client that didn't take the hint and go
directly
> to the Notification Server for subsequent Get-Notifications. In fact,
with
> this approach we even eliminate the 'redirection-other-site' status code,
> since the Printer is REQUIRED to return an accurate and up to date
> Get-Notifications response on the first (and all subsequent)
> Get-Notifications returns (by relaying the request to the Notification
> Server).
>
> Is this a way forward for the IPPGET proposed standard?
>
>
> So the changes to the IPPGET document would be as follows:
>
> 1. Delete the 'redirect-other-site' status code.
>
> 2. Clarify that the "redirect-uri" operation attribute in the
> Get-Notifications response is just a hint that the Printer returns to
> improve performance when the Printer is implemented using a notification
> server.
>
> 3. The client conformance section will say that the client SHOULD observe
> "redirect-uri" and try there (in order to improve performance by
eliminating
> extra hops), but the client doesn't have to. When going to draft
standard,
> if no one has implemented "redirect-uri", we delete it from the standard.
>
> 4. In order not to get our feature confused with HTTP redirect, lets
change
> the operation attribute returned from "redirect-uri" to
> "alternate-target-uri", since the client can perform the
Get-Notifications
> to either the original Printer or the notification server for those
Printers
> that use a notification server. Our feature is really a "relay", not a
> "redirect".
>
> Could this win-win proposal be discussed briefly during the PWG Plenary
> tomorrow (Tuesday, August 27) to see if we have consensus there (and we
will
> discuss it on the mailing list to see if we have consensus there too)?
>
> Comments?
>
> Tom and Ira
>
> P.S. In the future, if we want to generalize the relay mechanism for
other
> operations, the same operation attribute can be returned in any response.
> For job operations, we probably would also need to return
> "alternate-job-uri" and "alternate-job-id" operation attributes in
addition
> to the "alternate-target-uri" operation attribute.
>
>
>
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
> Sent: Monday, August 26, 2002 14:26
> To: 'Hastings, Tom N'; ipp@pwg.org; ifx@pwg.org
> Cc: pwg@pwg.org
> Subject: RE: IFX> Attempt to close on the two Notification specs at the
> fa ce to fac e meetings
>
>
> Hi Tom,
>
> First - I agree that it would still be good to drop redirect from IPPGET
> and design it IN GENERAL for IPP (any operation response could return
> the redirect), including the fact that while it's nice for
interoperability
> IPP Clients do NOT need to honor and follow redirects (any more than
> HTTP Clients need to do so - it's a matter of client policy).
>
> Second - if we publish IPPGET as a Proposed Std RFC (as you suggest)
> and LATER add redirect, we MUST recycle at Proposed Std RFC - it's
> illegal to add ANY new features when moving from Proposed Std to
> Draft Std status - only dropping existing features is legal.
>
> Cheers,
> - Ira McDonald
> High North Inc
>
>
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
> Sent: Friday, August 23, 2002 10:54 PM
> To: ipp@pwg.org; ifx@pwg.org
> Cc: pwg@pwg.org
> Subject: IFX> Attempt to close on the two Notification specs at the face
> to fac e meetings
>
>
> The IPP WG Last Call period closed July 31 on the two IPP Notification
specs
> that are required for IPP Notification:
>
> (1) IPP Event Notifications and Subscriptions
> <draft-ietf-ipp-not-spec-09.txt>
> (2) The 'ippget' Delivery Method for Event Notifications
> <draft-ietf-ipp-notify-get-07.txt>
>
> and Carl-Uno declared that (1) was approved, since there were no comments
> and that (2) achieved consensus to drop the redirection mechanism
entirely
> from the IPPGET document.
>
> However, we have continued discussion about the merits and problems of
the
> redirection mechanism because Harry Lewis has been the main objector to
> removing the redirection mechanism from IPPGET. As a result I have not
yet
> produced a new version of the document and Carl-Uno has not forwarded
either
> of the documents to Ned Freed, our Area Director.
>
> <...snip...>
>
> Process considerations:
>
> Could we delete the redirection mechanism for now from IPPGET? Get our
RFC
> published as a Proposed standard. Implement IPPGET and do
interoperability
> testing. See if the burden in the Printer of supporting the IPPGET
method
> justifies offloading it to a Notification Server using the redirect
> mechanism. If the implementation experience shows that its not much of a
> burden in the Printer we made the right decision to delete redirection.
If
> implementation experience shows that having a Notification Server is
> important to off-load the Printer's support of the IPPGET method, then
add
> the redirection back into the IPPGET spec before progressing the document
to
> a Draft standard. Perhaps in the meantime, IBM can also implement the
> Notification Server and see if it is really a win and that the extra
> administrative effort is worth the benefit to simplifying the Printer
> implementation.
>
> Comments?
>
> Tom
>
> <...snip...>
>
>
This archive was generated by hypermail 2b29 : Wed Aug 28 2002 - 17:59:19 EDT