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><FONT face=Arial color=#0000ff size=2><SPAN class=623362521-27082002>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).&nbsp; 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.&nbsp; 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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=623362521-27082002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=623362521-27082002>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=623362521-27082002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=623362521-27082002>Following on with the strategies of a Printer with 
limited connections, such as might be used for an IPPFAX implementation, we 
have:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=623362521-27082002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=623362521-27082002>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.&nbsp; And the client MUST disconnect and retry.&nbsp; 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.&nbsp; 
</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=623362521-27082002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=623362521-27082002>Its 
only the case where the Printer&nbsp;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).</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=623362521-27082002>From 
the IPPGET spec:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=623362521-27082002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=623362521-27082002>
<P class=MsoNormal style="MARGIN: 0in 0in 12pt 0.8in"><FONT size=3><FONT 
color=#000000><FONT face="Times New Roman"><SPAN 
style="LAYOUT-GRID-MODE: line">However, the Printer MAY decide to terminate <B 
style="mso-bidi-font-weight: normal">Event Wait Mode</B> at any time, including 
in the first response.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>In this case 
the Printer MUST return the &#8220;notify-get-interval&#8221; operation attribute.<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>This attribute indicates that the 
Printer wishes to leave <B style="mso-bidi-font-weight: normal">Event Wait 
Mode</B> and the number of seconds in the future that the Notification Recipient 
client SHOULD try the Get-Notifications operation again.<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN></SPAN>The Notification Recipient client 
MUST accept this response and MUST disconnect.<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>If the Notification Recipient client 
does not disconnect, the Printer SHOULD do so<SPAN 
style="LAYOUT-GRID-MODE: line">.<?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" 
/><o:p></o:p></SPAN></FONT></FONT></FONT></P></SPAN></FONT></DIV>
<DIV class=OutlookMessageHeader align=left><FONT face=Tahoma><FONT size=2><SPAN 
class=623362521-27082002><FONT face=Arial color=#0000ff>So this response would 
also contain the "optimal-target-uri".&nbsp; In this case, the Printer would NOT 
have had to relay the Get-Notifications to the Notification Server.&nbsp; 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).</FONT></SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader align=left><FONT face=Tahoma><FONT face=Arial 
color=#0000ff size=2><SPAN 
class=623362521-27082002></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader align=left><FONT face=Tahoma><FONT face=Arial 
color=#0000ff size=2><SPAN class=623362521-27082002>Tom and 
Carl</SPAN></FONT></FONT></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=623362521-27082002></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=623362521-27082002>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Carl Kugler 
  [mailto:kugler@us.ibm.com]<BR><B>Sent:</B> Tuesday, August 27, 2002 
  14:12<BR><B>To:</B> Hastings, Tom N<BR><B>Cc:</B> 
  ipp@pwg.org<BR><B>Subject:</B> RE: PWG&gt; RE: IFX&gt; Attempt to close on the 
  two Notification specs at the face to face 
  meetings<BR><BR></DIV></FONT></FONT><BR><FONT face=sans-serif size=2>A Printer 
  dropping the connection doesn't help much. &nbsp;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. &nbsp;In most implementations, a connection 
  in TIME_WAIT consumes the same resources as an ESTABLISHED connection.</FONT> 
  <BR><BR><FONT face=sans-serif size=2>&nbsp; &nbsp; &nbsp; &nbsp; -Carl</FONT> 
  <BR><BR><BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>"Hastings, Tom N" 
        &lt;hastings@cp10.es.xerox.com&gt;</B></FONT> 
        <P><FONT face=sans-serif size=1>08/27/2002 01:48 PM</FONT> <BR></P>
      <TD><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp; </FONT><BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; 
        &nbsp; &nbsp;Carl Kugler/Boulder/IBM@IBMUS</FONT> <BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; 
        &nbsp; &nbsp;ipp@pwg.org</FONT> <BR><FONT face=sans-serif size=1>&nbsp; 
        &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: PWG&gt; RE: 
        IFX&gt; Attempt to close on the two Notification specs &nbsp; &nbsp; 
        &nbsp; &nbsp; at the face to face 
  meetings</FONT></TR></TBODY></TABLE><BR><BR><BR><FONT face=Arial color=blue 
  size=2>Carl,</FONT> <BR><FONT size=3>&nbsp;</FONT> <BR><FONT face=Arial 
  color=blue size=2>Good point that there are really two reasons why a Printer 
  might want to use a notification server:</FONT> <BR><FONT size=3>&nbsp;</FONT> 
  <BR><FONT face=Arial color=blue size=2>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)</FONT> <BR><FONT size=3>&nbsp;</FONT> <BR><FONT 
  face=Arial color=blue size=2>2. (new) reduce the number of IPPGET connections 
  that the Printer has to maintain simultaneously.</FONT> <BR><FONT 
  size=3>&nbsp;</FONT> <BR><FONT face=Arial color=blue size=2>So a printer with 
  limited connections would want the clients to go directly to the Server. 
  &nbsp;However, the Printer can drop an IPPGET connection anytime, right? 
  &nbsp;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.</FONT> <BR><FONT size=3>&nbsp;</FONT> 
  <BR><FONT face=Arial color=blue size=2>Or are you saying that we need to 
  REQUIRE the client to use the "alternate-target-uri"? &nbsp;I'm hoping not, so 
  that we can get the IPPGET document agreed to.</FONT> <BR><FONT 
  size=3>&nbsp;</FONT> <BR><FONT face=Arial color=blue size=2>Thanks,</FONT> 
  <BR><FONT face=Arial color=blue size=2>Tom</FONT> <BR><FONT face=Tahoma 
  size=2>-----Original Message-----<B><BR>From:</B> Carl Kugler 
  [mailto:kugler@us.ibm.com]<B><BR>Sent:</B> Tuesday, August 27, 2002 
  11:35<B><BR>To:</B> Hastings, Tom N<B><BR>Cc:</B> Harry 
  Lewis<B><BR>Subject:</B> Re: PWG&gt; RE: IFX&gt; Attempt to close on the two 
  Notification specs at the fa ce to face meetings<BR></FONT><BR><FONT 
  face=sans-serif size=2><BR>One reason to have the redirect is to reduce the 
  number of connections that the printer has to maintain. &nbsp;Some printers 
  are very limited in the number of simultaneous connections they can support 
  (like, 4). &nbsp;The relay approach would only make that situation 
  worse.</FONT><FONT size=3> <BR></FONT><FONT face=sans-serif size=2><BR>&nbsp; 
  &nbsp; &nbsp; &nbsp;-Carl</FONT><FONT size=3> <BR><BR><BR></FONT>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD width="1%">
      <TD width="31%"><FONT face=sans-serif size=1><B>"Hastings, Tom N" 
        &lt;hastings@cp10.es.xerox.com&gt;</B></FONT><FONT size=3> </FONT><FONT 
        face=sans-serif size=1><BR>Sent by: owner-pwg@pwg.org</FONT><FONT 
        size=3> </FONT>
        <P><FONT face=sans-serif size=1>08/26/2002 06:25 PM</FONT><FONT size=3> 
        </FONT></P>
      <TD width="66%"><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp; 
        </FONT><FONT face=sans-serif size=1><BR>&nbsp; &nbsp; &nbsp; &nbsp;To: 
        &nbsp; &nbsp; &nbsp; &nbsp;ipp@pwg.org, ifx@pwg.org, Harry 
        Lewis/Boulder/IBM@IBMUS</FONT><FONT size=3> </FONT><FONT face=sans-serif 
        size=1><BR>&nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; 
        &nbsp;pwg@pwg.org</FONT><FONT size=3> </FONT><FONT face=sans-serif 
        size=1><BR>&nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; 
        &nbsp;PWG&gt; RE: IFX&gt; Attempt to close on the two Notification specs 
        at the fa &nbsp; &nbsp; &nbsp; &nbsp;ce to face 
  meetings</FONT></TR></TBODY></TABLE><BR><FONT size=3><BR><BR></FONT><FONT 
  face="Courier New" size=2><BR>Harry et al,<BR><BR>In answering Ira's note, a 
  win-win approach occurred to me. &nbsp;This approach<BR>will allow a Printer 
  to use a notification server, but won't put any burden<BR>on clients. &nbsp;I 
  called Ira up and he is enthusiastic as well. &nbsp;He helped me<BR>flesh out 
  the proposal. &nbsp;Here is the idea:<BR><BR>When a Printer implements 
  Get-Notifications using a Notification Server, why<BR>not have the Printer 
  just pass each Get-Notifications request along to the<BR>Notification Server, 
  which returns the response to the Printer which returns<BR>that response to 
  the client. &nbsp;In protocol terminology, the Printer is<BR>"relaying" the 
  Get-Notifications request to the notification server. &nbsp;Yes,<BR>this are 4 
  hops, instead of 2, but its transparent to the client. 
  &nbsp;The<BR>Notification Server can return to the Printer the "redirect-uri" 
  operation<BR>attribute as an advisory hint to the client (which the Printer 
  passes back<BR>to the client) to improve the performance, but clients not 
  knowing about<BR>that "redirect-uri" operation attribute would simply keep 
  doing subsequent<BR>Get-Notifications to the Printer. &nbsp;The down side is 
  that there are 4 network<BR>hops, instead of 2, for the client that didn't 
  take the hint and go directly<BR>to the Notification Server for subsequent 
  Get-Notifications. &nbsp;In fact, with<BR>this approach we even eliminate the 
  'redirection-other-site' status code,<BR>since the Printer is REQUIRED to 
  return an accurate and up to date<BR>Get-Notifications response on the first 
  (and all subsequent)<BR>Get-Notifications returns (by relaying the request to 
  the Notification<BR>Server).<BR><BR>Is this a way forward for the IPPGET 
  proposed standard?<BR><BR><BR>So the changes to the IPPGET document would be 
  as follows:<BR><BR>1. Delete the 'redirect-other-site' status code.<BR><BR>2. 
  Clarify that the "redirect-uri" operation attribute in 
  the<BR>Get-Notifications response is just a hint that the Printer returns 
  to<BR>improve performance when the Printer is implemented using a 
  notification<BR>server. &nbsp;<BR><BR>3. The client conformance section will 
  say that the client SHOULD observe<BR>"redirect-uri" and try there (in order 
  to improve performance by eliminating<BR>extra hops), but the client doesn't 
  have to. &nbsp;When going to draft standard,</FONT> <BR><FONT 
  face="Courier New" size=2>if no one has implemented "redirect-uri", we delete 
  it from the standard.<BR><BR>4. In order not to get our feature confused with 
  HTTP redirect, lets change<BR>the operation attribute returned from 
  "redirect-uri" to<BR>"alternate-target-uri", since the client can perform the 
  Get-Notifications<BR>to either the original Printer or the notification server 
  for those Printers<BR>that use a notification server. &nbsp;Our feature is 
  really a "relay", not a<BR>"redirect".<BR><BR>Could this win-win proposal be 
  discussed briefly during the PWG Plenary<BR>tomorrow (Tuesday, August 27) to 
  see if we have consensus there (and we will<BR>discuss it on the mailing list 
  to see if we have consensus there too)?<BR><BR>Comments?<BR><BR>Tom and 
  Ira<BR><BR>P.S. In the future, if we want to generalize the relay mechanism 
  for other<BR>operations, the same operation attribute can be returned in any 
  response.<BR>For job operations, we probably would also need to 
  return<BR>"alternate-job-uri" and "alternate-job-id" operation attributes in 
  addition<BR>to the "alternate-target-uri" operation 
  attribute.<BR><BR><BR><BR>-----Original Message-----<BR>From: McDonald, Ira 
  [mailto:imcdonald@sharplabs.com]<BR>Sent: Monday, August 26, 2002 14:26<BR>To: 
  'Hastings, Tom N'; ipp@pwg.org; ifx@pwg.org<BR>Cc: pwg@pwg.org<BR>Subject: RE: 
  IFX&gt; Attempt to close on the two Notification specs at the<BR>fa ce to fac 
  e meetings<BR><BR><BR>Hi Tom,<BR><BR>First - I agree that it would still be 
  good to drop redirect from IPPGET<BR>and design it IN GENERAL for IPP (any 
  operation response could return<BR>the redirect), including the fact that 
  while it's nice for interoperability<BR>IPP Clients do NOT need to honor and 
  follow redirects (any more than<BR>HTTP Clients need to do so - it's a matter 
  of client policy).<BR><BR>Second - if we publish IPPGET as a Proposed Std RFC 
  (as you suggest)<BR>and LATER add redirect, we MUST recycle at Proposed Std 
  RFC - it's<BR>illegal to add ANY new features when moving from Proposed Std 
  to<BR>Draft Std status - only dropping existing features is 
  legal.<BR><BR>Cheers,<BR>- Ira McDonald<BR>High North 
  Inc<BR><BR><BR>-----Original Message-----<BR>From: Hastings, Tom N 
  [mailto:hastings@cp10.es.xerox.com]<BR>Sent: Friday, August 23, 2002 10:54 
  PM<BR>To: ipp@pwg.org; ifx@pwg.org<BR>Cc: pwg@pwg.org<BR>Subject: IFX&gt; 
  Attempt to close on the two Notification specs at the face<BR>to fac e 
  meetings<BR><BR><BR>The IPP WG Last Call period closed July 31 on the two IPP 
  Notification specs<BR>that are required for IPP Notification:<BR><BR>(1) IPP 
  Event Notifications and 
  Subscriptions<BR>&lt;draft-ietf-ipp-not-spec-09.txt&gt;<BR>(2) The 'ippget' 
  Delivery Method for Event 
  Notifications<BR>&lt;draft-ietf-ipp-notify-get-07.txt&gt;<BR><BR>and Carl-Uno 
  declared that (1) was approved, since there were no comments<BR>and that (2) 
  achieved consensus to drop the redirection mechanism entirely<BR>from the 
  IPPGET document.<BR><BR>However, we have continued discussion about the merits 
  and problems of the<BR>redirection mechanism because Harry Lewis has been the 
  main objector to<BR>removing the redirection mechanism from IPPGET. &nbsp;As a 
  result I have not yet<BR>produced a new version of the document and Carl-Uno 
  has not forwarded either<BR>of the documents to Ned Freed, our Area Director. 
  &nbsp; &nbsp;<BR><BR>&lt;...snip...&gt;<BR><BR>Process 
  considerations:<BR><BR>Could we delete the redirection mechanism for now from 
  IPPGET? &nbsp;Get our RFC<BR>published as a Proposed standard. &nbsp;Implement 
  IPPGET and do interoperability<BR>testing. &nbsp;See if the burden in the 
  Printer of supporting the IPPGET method<BR>justifies offloading it to a 
  Notification Server using the redirect<BR>mechanism. &nbsp;If the 
  implementation experience shows that its not much of a<BR>burden in the 
  Printer we made the right decision to delete redirection. 
  &nbsp;If<BR>implementation experience shows that having a Notification Server 
  is<BR>important to off-load the Printer's support of the IPPGET method, then 
  add<BR>the redirection back into the IPPGET spec before progressing the 
  document to<BR>a Draft standard. &nbsp;Perhaps in the meantime, IBM can also 
  implement the<BR>Notification Server and see if it is really a win and that 
  the extra<BR>administrative effort is worth the benefit to simplifying the 
  Printer</FONT><FONT size=3> </FONT><FONT face="Courier New" 
  size=2><BR>implementation.<BR><BR>Comments?<BR><BR>Tom<BR><BR>&lt;...snip...&gt;</FONT><FONT 
  size=3><BR><BR></FONT><BR><BR></BLOCKQUOTE></BODY></HTML>