attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII"> <META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD> <BODY> <DIV>I called Carl and his use case for using a separate Notification Server was for a number Printers that supported only a limited number of connections, say 4 as in a number of IPP printer network cards, and a large corporation with many clients (10,000).  Off-loading these persistent connections to a big Notification Server seems important if a large number of clients might be using Event Wait Mode to get events for submitted jobs.  If the job queue gets backed up on a Printer the number of such clients could be large, i.e., the number of jobs in the queue.</DIV> <DIV> </DIV> <DIV>So this argument further justifies keeping the "optimal-target-uri" in the spec and perhaps increasing the client conformance from SHOULD to MUST, but certainly not watering it down to MAY.</DIV> <DIV> </DIV> <DIV>Following on with the strategies of a Printer with limited connections, such as might be used for an IPPFAX implementation, we have:</DIV> <DIV> </DIV> <DIV>Such a Printer can decide to terminate Event Wait Mode at any time, including in the first response, by returning the "notify-get-interval" operation attribute.  And the client MUST disconnect and retry.  So if the client conforms and disconnects, then the Printer's connection becomes free immediately, and the Printer doesn't have to remember the connection.  </DIV> <DIV> </DIV> <DIV>Its only the case where the Printer decides to terminate Event Wait Mode, but the client is non-conforming and doesn't disconnect, that the Printer would have to disconnect (but have to remember the connection for 4 minutes according to TCP rules, thereby tying up the connection for that length of time).</DIV> <DIV> </DIV> <DIV>From the IPPGET spec:</DIV> <DIV> </DIV> <DIV> However, the Printer MAY decide to terminate Event Wait Mode at any time, including in the first response.  In this case the Printer MUST return the “notify-get-interval” operation attribute.  This attribute indicates that the Printer wishes to leave Event Wait Mode and the number of seconds in the future that the Notification Recipient client SHOULD try the Get-Notifications operation again.  The Notification Recipient client MUST accept this response and MUST disconnect.  If the Notification Recipient client does not disconnect, the Printer SHOULD do so.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></DIV> <DIV class=OutlookMessageHeader align=left>So this response would also contain the "optimal-target-uri".  In this case, the Printer would NOT have had to relay the Get-Notifications to the Notification Server.  Then the client MUST disconnect and then MUST/SHOULD/MAY (TBD) retry the Get-Notifications on the returned URI (which could be anywhere, including the original target).</DIV> <DIV class=OutlookMessageHeader align=left> </DIV> <DIV class=OutlookMessageHeader align=left>Tom and Carl</DIV> <BLOCKQUOTE> <DIV class=OutlookMessageHeader dir=ltr align=left> </DIV> <DIV class=OutlookMessageHeader dir=ltr align=left> -----Original Message----- From: Carl Kugler [mailto:kugler@us.ibm.com] Sent: Tuesday, August 27, 2002 14:12 To: Hastings, Tom N Cc: ipp@pwg.org Subject: RE: PWG> RE: IFX> Attempt to close on the two Notification specs at the face to face meetings </DIV> A Printer dropping the connection doesn't help much.  If a TCP server closes the connection, then according to TCP protocol it must remember the connection for two times max TTL, or 4 minutes.  In most implementations, a connection in TIME_WAIT consumes the same resources as an ESTABLISHED connection.         -Carl <TABLE width="100%"> <TBODY> <TR vAlign=top> <TD> <TD>"Hastings, Tom N" <hastings@cp10.es.xerox.com> 08/27/2002 01:48 PM <TD>                To:        Carl Kugler/Boulder/IBM@IBMUS         cc:        ipp@pwg.org         Subject:        RE: PWG> RE: IFX> Attempt to close on the two Notification specs         at the face to face meetings</TR></TBODY></TABLE> 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@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 <TABLE width="100%"> <TBODY> <TR vAlign=top> <TD width="1%"> <TD width="31%">"Hastings, Tom N" <hastings@cp10.es.xerox.com> Sent by: owner-pwg@pwg.org 08/26/2002 06:25 PM <TD width="66%">               To:        ipp@pwg.org, ifx@pwg.org, Harry Lewis/Boulder/IBM@IBMUS        cc:        pwg@pwg.org        Subject:        PWG> RE: IFX> Attempt to close on the two Notification specs at the fa        ce to face meetings</TR></TBODY></TABLE> 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...> </BLOCKQUOTE></BODY></HTML>