Carl,
Good point that there are really two reasons why a Printer might want to use
a notification server:
1. off-load notification from the Printer to the Notification Server (e.g.,
the Server maintains the Subscription objects and searches them when the
Printer sends an event to the Notification Server)
2. (new) reduce the number of IPPGET connections that the Printer has to
maintain simultaneously.
So a printer with limited connections would want the clients to go directly
to the Server. However, the Printer can drop an IPPGET connection anytime,
right? So perhaps we should add to the explanation about why a client
SHOULD go directly to the alternate-target-uri notification server, in order
to avoid having the IPPGET connection terminated.
Or are you saying that we need to REQUIRE the client to use the
"alternate-target-uri"? I'm hoping not, so that we can get the IPPGET
document agreed to.
Thanks,
Tom
-----Original Message-----
From: Carl Kugler [mailto:kugler at us.ibm.com]
Sent: Tuesday, August 27, 2002 11:35
To: Hastings, Tom N
Cc: Harry Lewis
Subject: Re: PWG> RE: IFX> Attempt to close on the two Notification specs at
the fa ce to face meetings
One reason to have the redirect is to reduce the number of connections that
the printer has to maintain. Some printers are very limited in the number
of simultaneous connections they can support (like, 4). The relay approach
would only make that situation worse.
-Carl
"Hastings, Tom N" <hastings at cp10.es.xerox.com>
Sent by: owner-pwg at pwg.org
08/26/2002 06:25 PM
To: ipp at pwg.org, ifx at pwg.org, Harry Lewis/Boulder/IBM at IBMUS
cc: pwg at pwg.org
Subject: PWG> RE: IFX> Attempt to close on the two
Notification specs at the fa ce 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 at sharplabs.com]
Sent: Monday, August 26, 2002 14:26
To: 'Hastings, Tom N'; ipp at pwg.org; ifx at pwg.org
Cc: pwg at 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 at cp10.es.xerox.com]
Sent: Friday, August 23, 2002 10:54 PM
To: ipp at pwg.org; ifx at pwg.org
Cc: pwg at 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...>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/20020827/25d319b6/attachment-0001.html