attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4522.1800" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>We seem to be going in circles. So, the question is 
where do we go from here?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Carl Kugler gives an excellent scenario that 
requires both printer and client to support redirection.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>It would seem that other printer vendors should 
have the same issue as IBM. Yet no one has mentioned it.&nbsp; Why is that? Has 
no other vendor begun implementing ipp-get? Do other printers not have the 
connection limitations?&nbsp; </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Michael Sweet has said that his software does not 
support redirection (I assume this includes the client and server). If most 
printer vendors were finding redirection a necessity, would he reconsider his 
position for clients?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>The "optimal-target-uri" solution proposed by Tom 
and Ira&nbsp;doesn't solve Carl Kugler's problem. I think that it should be 
dropped.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>So, there is one&nbsp;essential issue that we need 
to resolve in order make progress.&nbsp; Is IBM's ipp-get implementation an 
a<FONT size=2>nomaly </FONT>that is unlike all other vendors, or is IBM ahead of 
the curve and has discovered what every other printer vendor will discover 
during the implementation of&nbsp;ipp-get -- the need for 
redirection?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Bob Herriot</FONT></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=harryl@us.ibm.com href="mailto:harryl@us.ibm.com">Harry Lewis</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=carl@manros.com 
  href="mailto:carl@manros.com">Carl</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=bob@herriot.com 
  href="mailto:bob@herriot.com">Robert Herriot</A> ; <A 
  title=hastings@cp10.es.xerox.com 
  href="mailto:hastings@cp10.es.xerox.com">Hastings, Tom N</A> ; <A 
  title=ipp@pwg.org href="mailto:ipp@pwg.org">ipp@pwg.org</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, August 27, 2002 10:27 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: IPP&gt; Re: IFX&gt; Attempt 
  to close on the two Notification specs at theface to face meetings</DIV>
  <DIV><BR></DIV><BR><FONT face=sans-serif size=2>This was supposed to be a 
  straightforward, optional, redirect. It was, at one time, cleanly specified. 
  Why do the only choices seem to be reinvent or 
  remove?<BR>---------------------------------------------- <BR>Harry Lewis 
  <BR>IBM Printing Systems <BR>---------------------------------------------- 
  </FONT><BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>"Carl" &lt;<A 
        href="mailto:carl@manros.com">carl@manros.com</A>&gt;</B></FONT> 
        <BR><FONT face=sans-serif size=1>Sent by: <A 
        href="mailto:owner-ipp@pwg.org">owner-ipp@pwg.org</A></FONT> 
        <P><FONT face=sans-serif size=1>08/27/2002 04:45 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;"Hastings, Tom N" &lt;<A 
        href="mailto:hastings@cp10.es.xerox.com">hastings@cp10.es.xerox.com</A>&gt;, 
        "Robert Herriot" &lt;<A 
        href="mailto:bob@herriot.com">bob@herriot.com</A>&gt;, Harry <A 
        href="mailto:Lewis/Boulder/IBM@IBMUS">Lewis/Boulder/IBM@IBMUS</A></FONT> 
        <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; 
        &nbsp; &nbsp; &nbsp;&lt;<A 
        href="mailto:ipp@pwg.org">ipp@pwg.org</A>&gt;, 
        &lt;ifx@pwg.org&gt;</FONT> <BR><FONT face=sans-serif size=1>&nbsp; 
        &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: IPP&gt; Re: 
        IFX&gt; Attempt to close on the two Notification specs at the face to 
        face meetings</FONT> <BR><BR><FONT face=Arial size=1>&nbsp; &nbsp; 
        &nbsp; &nbsp;</FONT></TR></TBODY></TABLE><BR><BR><FONT face="Courier New" 
  size=2>Tom,<BR><BR>It looks like we are saying the same thing on my point 1). 
  It doesn't need<BR>to be mentioned at all in the spec. It is a pure 
  implementation matter, but<BR>as Carl Kugler pointed out, it may not be a 
  feasible solution anyway.<BR><BR>On point 2) I don't think you misunderstood 
  the problem I brought up, viz<BR>what protocol you are using between an IPP 
  Client and a Notification Server.<BR>I don't think we should include a new 
  parameter, which assumes the use of<BR>some non-existent new protocol, even if 
  that happens to be a subset of IPP.<BR>I believe that you are still thinking 
  only about the protocol between an IPP<BR>Client and an IPP Printer in your 
  comment?<BR><BR>Carl-Uno<BR><BR>Carl-Uno Manros<BR>10701 S Eastern Ave 
  #1117<BR>Henderson, NV 89052, USA<BR>Tel +1-702-617-9414<BR>Fax 
  +1-702-617-9417<BR>Mob +1-702-525-0727<BR>Email carl@manros.com<BR><BR>&gt; 
  -----Original Message-----<BR>&gt; From: Hastings, Tom N 
  [mailto:hastings@cp10.es.xerox.com]<BR>&gt; Sent: Tuesday, August 27, 2002 
  1:35 PM<BR>&gt; To: Carl; Robert Herriot; Lewis, Harry<BR>&gt; Cc: 
  ipp@pwg.org; ifx@pwg.org<BR>&gt; Subject: RE: IPP&gt; Re: IFX&gt; Attempt to 
  close on the two Notification<BR>&gt; specs at the face to face 
  meetings<BR>&gt;<BR>&gt;<BR>&gt; Carl-Uno,<BR>&gt;<BR>&gt; See my comments 
  below, bracketed with &lt;th&gt; and &lt;/th&gt;<BR>&gt;<BR>&gt; 
  Tom<BR>&gt;<BR>&gt; -----Original Message-----<BR>&gt; From: Carl 
  [mailto:carl@manros.com]<BR>&gt; Sent: Tuesday, August 27, 2002 07:45<BR>&gt; 
  To: Robert Herriot; Hastings, Tom N; ipp@pwg.org; ifx@pwg.org; Lewis,<BR>&gt; 
  Harry<BR>&gt; Subject: RE: IPP&gt; Re: IFX&gt; Attempt to close on the two 
  Notification<BR>&gt; specs at the face to face 
  meetings<BR>&gt;<BR>&gt;<BR>&gt; Hi all,<BR>&gt;<BR>&gt; It seems we are about 
  reinvent a totally new solution again at the stage<BR>&gt; where we are trying 
  to finalize the IPPGET specification.<BR>&gt; &lt;th&gt;<BR>&gt; I disagree 
  that the proposed solutions are a totally new solution. &nbsp;We are<BR>&gt; 
  trying to tweak the specification so that we can get agreement.<BR>&gt; 
  &lt;/th&gt;<BR>&gt;<BR>&gt; Of the proposals so far, I think that Bob's latest 
  version is getting<BR>&gt; closest to a working solution.<BR>&gt;<BR>&gt; 
  However, there are a couple of pitfalls that nobody has brought up 
  yet:<BR>&gt;<BR>&gt; 1) If the notification server returns the notifications 
  via the<BR>&gt; printer, it<BR>&gt; is totally transparent to the IPP protocol 
  and there is no need for<BR>&gt; mentioning that functionalitty in the spec at 
  all.<BR>&gt; &lt;th&gt;<BR>&gt; I don't understand why this is a pitfall. 
  &nbsp;Yes, the client doesn't need to<BR>&gt; be aware of the URI being 
  returned and can ignore it. &nbsp;That is<BR>&gt; the advantage<BR>&gt; of 
  Bob's and my proposals to the client.<BR>&gt; &lt;/th&gt;<BR>&gt;<BR>&gt; 2) 
  If you use the "optimal-target-uri" in Bob's termilogy, what protocol<BR>&gt; 
  will you be using to get the notifications from the notification 
  server?<BR>&gt; Obviously the notification server is unlikely to be a a full 
  IPP<BR>&gt; Printer, so<BR>&gt; what protocol would you use? A new protocol 
  which is subset of the IPP<BR>&gt; protocol, only supporting one or two 
  operations?<BR>&gt; &lt;th&gt;</FONT> <BR><FONT face="Courier New" size=2>&gt; 
  Yes, the URI has the scheme 'ipp:'. &nbsp;However, section 5.2.3 of the 
  current<BR>&gt; IPPGET spec says (and we'll change the MUST to SHOULD or 
  MAY):<BR>&gt;<BR>&gt; "5.2.3 redirect-uri (uri)<BR>&gt; The value of this 
  attribute is the uri that the Notification<BR>&gt; Recipient MUST<BR>&gt; use 
  for a subsequent Get-Notifications operation."<BR>&gt;<BR>&gt; So the URI 
  isn't used for other IPP operations, only for<BR>&gt; 
  Get-Notifications.<BR>&gt; Do you see a problem with using the IPP URL for 
  just the Get-Notifications<BR>&gt; operation?<BR>&gt; 
  &lt;/th&gt;<BR>&gt;<BR>&gt;<BR>&gt; Considering the two issues above, I think 
  that the smart thing to do is to<BR>&gt; drop the redirect aka optimize 
  feature from the spec.<BR>&gt;<BR>&gt; Carl-Uno<BR>&gt;<BR>&gt; Carl-Uno 
  Manros<BR>&gt; 10701 S Eastern Ave #1117<BR>&gt; Henderson, NV 89052, 
  USA<BR>&gt; Tel +1-702-617-9414<BR>&gt; Fax +1-702-617-9417<BR>&gt; Mob 
  +1-702-525-0727<BR>&gt; Email carl@manros.com<BR>&gt;<BR>&gt; &gt; 
  -----Original Message-----<BR>&gt; &gt; From: owner-ipp@pwg.org 
  [mailto:owner-ipp@pwg.org]On Behalf Of Robert<BR>&gt; &gt; Herriot<BR>&gt; 
  &gt; Sent: Tuesday, August 27, 2002 2:15 AM<BR>&gt; &gt; To: Hastings, Tom N; 
  ipp@pwg.org; ifx@pwg.org; Lewis, Harry<BR>&gt; &gt; Cc: pwg@pwg.org<BR>&gt; 
  &gt; Subject: IPP&gt; Re: IFX&gt; Attempt to close on the two Notification 
  specs at<BR>&gt; &gt; the face to face meetings<BR>&gt; &gt;<BR>&gt; 
  &gt;<BR>&gt; &gt; Tom,<BR>&gt; &gt;<BR>&gt; &gt; If we agree that we must keep 
  the redirection notion, then I<BR>&gt; &gt; agree (mostly)<BR>&gt; &gt; with 
  your proposed changes, but not with your reasoning.<BR>&gt; However, I 
  still<BR>&gt; &gt; think that most clients will not implement redirection, 
  so<BR>&gt; &gt; redirection ends<BR>&gt; &gt; up being effectively proprietary 
  and thus not a concept that<BR>&gt; &gt; should be in a<BR>&gt; &gt; standard. 
  &nbsp;Assuming that we will keep redirection, here are my<BR>&gt; thoughts 
  on<BR>&gt; &gt; your proposal.<BR>&gt; &gt;<BR>&gt; &gt; You propose a 
  possible implementation of a printer with a remote<BR>&gt; &gt; notification 
  server and imply that the existence of this<BR>&gt; solution somehow<BR>&gt; 
  &gt; changes the rules. &nbsp;This implementation may have led you to<BR>&gt; 
  this solution,<BR>&gt; &gt; but it is not the essence of your proposal or 
  important to it.<BR>&gt; &gt;<BR>&gt; &gt; The effect of what your proposed 
  change is that a printer must directly<BR>&gt; &gt; support ipp-get if it 
  supports event notification. That is, the cannot<BR>&gt; &gt; return nothing 
  and redirect the client to the real notification<BR>&gt; &gt; server. 
  Your<BR>&gt; &gt; proposal could have stopped there and said that the 
  redirection uri is<BR>&gt; &gt; eliminated.<BR>&gt; &gt;<BR>&gt; &gt; Instead, 
  you added an optional "alternate-target-uri" attribute, which I<BR>&gt; &gt; 
  think should be called "optimal-target-uri" (as that is what it<BR>&gt; &gt; 
  really is).<BR>&gt; &gt; The "redirect-uri" has the flaw that the client gets 
  nothing if<BR>&gt; it doesn't<BR>&gt; &gt; implement "redirect-uri". With 
  "optimal-target-uri", the client<BR>&gt; gets event<BR>&gt; &gt; notifications 
  even if it doesn't implement "optimal-target-uri". Its<BR>&gt; &gt; 
  implementation is an optimization only -- but perhaps not sufficiently<BR>&gt; 
  &gt; optimal to be worth the support of anyone. &nbsp;Once you realize, 
  that<BR>&gt; &gt; "optimal-target-uri" is just an optimal uri, it need not be 
  just<BR>&gt; &gt; some remote<BR>&gt; &gt; notification server. It could also 
  be a different uri in the<BR>&gt; same printer.<BR>&gt; &gt; It doesn't really 
  matter, but the presence of this attribute tells the<BR>&gt; &gt; client that 
  there is a better uri to use. If you keep this attribute, I<BR>&gt; &gt; would 
  leave the language open for the uri to be anywhere a<BR>&gt; &gt; printer 
  wants it<BR>&gt; &gt; to be.<BR>&gt; &gt;<BR>&gt; &gt; I also think that in 
  item 3, client support is a "MAY" rather than a<BR>&gt; &gt; "SHOULD". 
  &nbsp;It doesn't really matter whether a client supports this<BR>&gt; &gt; 
  attribute, especially almost no one will implement it.<BR>&gt; &gt;<BR>&gt; 
  &gt; I also would ask if the "optimal-target-uri" must be different from 
  the<BR>&gt; &gt; printer-uri. That is, could it always be returned by a 
  printer,<BR>&gt; &gt; even when it<BR>&gt; &gt; would be the same as the 
  printer uri. &nbsp;I think that the intention<BR>&gt; &gt; is that a<BR>&gt; 
  &gt; printer would only return it when there is an optimal uri that is<BR>&gt; 
  &gt; different<BR>&gt; &gt; from the printer, but that it need not be 
  different (i.e. the<BR>&gt; client need<BR>&gt; &gt; not check for 
  this).<BR>&gt; &gt;<BR>&gt; &gt; Bob Herriot<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; 
  &gt;<BR>&gt; &gt; ----- Original Message -----<BR>&gt; &gt; From: "Hastings, 
  Tom N" &lt;hastings@cp10.es.xerox.com&gt;<BR>&gt; &gt; To: 
  &lt;ipp@pwg.org&gt;; &lt;ifx@pwg.org&gt;; "Lewis, Harry" 
  &lt;harryl@us.ibm.com&gt;<BR>&gt; &gt; Cc: &lt;pwg@pwg.org&gt;<BR>&gt; &gt; 
  Sent: Monday, August 26, 2002 5:25 PM<BR>&gt; &gt; Subject: RE: IFX&gt; 
  Attempt to close on the two Notification specs<BR>&gt; &gt; at the 
  face<BR>&gt; &gt; to face meetings<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; &gt; 
  Harry et al,<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; In answering Ira's note, a 
  win-win approach occurred to me.<BR>&gt; &gt; This approach<BR>&gt; &gt; &gt; 
  will allow a Printer to use a notification server, but won't put any<BR>&gt; 
  &gt; burden<BR>&gt; &gt; &gt; on clients. &nbsp;I called Ira up and he is 
  enthusiastic as well.<BR>&gt; &gt; He helped me<BR>&gt; &gt; &gt; flesh out 
  the proposal. &nbsp;Here is the idea:<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; When 
  a Printer implements Get-Notifications using a<BR>&gt; Notification 
  Server,<BR>&gt; &gt; why<BR>&gt; &gt; &gt; not have the Printer just pass each 
  Get-Notifications request<BR>&gt; &gt; along to the<BR>&gt; &gt; &gt; 
  Notification Server, which returns the response to the Printer which<BR>&gt; 
  &gt; returns<BR>&gt; &gt; &gt; that response to the client. &nbsp;In protocol 
  terminology, the Printer is<BR>&gt; &gt; &gt; "relaying" the Get-Notifications 
  request to the notification<BR>&gt; &gt; server. &nbsp;Yes,<BR>&gt; &gt; &gt; 
  this are 4 hops, instead of 2, but its transparent to the client. 
  &nbsp;The<BR>&gt; &gt; &gt; Notification Server can return to the Printer 
  the<BR>&gt; &gt; "redirect-uri" operation<BR>&gt; &gt; &gt; attribute as an 
  advisory hint to the client (which the Printer<BR>&gt; &gt; passes 
  back<BR>&gt; &gt; &gt; to the client) to improve the performance, but clients 
  not<BR>&gt; knowing about<BR>&gt; &gt; &gt; that "redirect-uri" operation 
  attribute would simply keep doing<BR>&gt; &gt; subsequent<BR>&gt; &gt; &gt; 
  Get-Notifications to the Printer. &nbsp;The down side is that there are 
  4<BR>&gt; &gt; network<BR>&gt; &gt; &gt; hops, instead of 2, for the client 
  that didn't take the hint and go<BR>&gt; &gt; directly<BR>&gt; &gt; &gt; to 
  the Notification Server for subsequent Get-Notifications. &nbsp;In 
  fact,<BR>&gt; &gt; with<BR>&gt; &gt; &gt; this approach we even eliminate the 
  'redirection-other-site'<BR>&gt; &gt; status code,<BR>&gt; &gt; &gt; since the 
  Printer is REQUIRED to return an accurate and up to date<BR>&gt; &gt; &gt; 
  Get-Notifications response on the first (and all subsequent)<BR>&gt; &gt; &gt; 
  Get-Notifications returns (by relaying the request to the Notification<BR>&gt; 
  &gt; &gt; Server).<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Is this a way forward 
  for the IPPGET proposed standard?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; 
  &gt; &gt; So the changes to the IPPGET document would be as follows:<BR>&gt; 
  &gt; &gt;<BR>&gt; &gt; &gt; 1. Delete the 'redirect-other-site' status 
  code.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; 2. Clarify that the "redirect-uri" 
  operation attribute in the<BR>&gt; &gt; &gt; Get-Notifications response is 
  just a hint that the Printer returns to<BR>&gt; &gt; &gt; improve performance 
  when the Printer is implemented using a<BR>&gt; notification<BR>&gt; &gt; &gt; 
  server.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; 3. The client conformance section 
  will say that the client<BR>&gt; &gt; SHOULD observe<BR>&gt; &gt; &gt; 
  "redirect-uri" and try there (in order to improve performance by<BR>&gt; &gt; 
  eliminating<BR>&gt; &gt; &gt; extra hops), but the client doesn't have to. 
  &nbsp;When going to draft<BR>&gt; &gt; standard,<BR>&gt; &gt; &gt; if no one 
  has implemented "redirect-uri", we delete it from the<BR>&gt; &gt; 
  standard.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; 4. In order not to get our 
  feature confused with HTTP redirect, lets<BR>&gt; &gt; change<BR>&gt; &gt; 
  &gt; the operation attribute returned from "redirect-uri" to<BR>&gt; &gt; &gt; 
  "alternate-target-uri", since the client can perform the<BR>&gt; &gt; 
  Get-Notifications<BR>&gt; &gt; &gt; to either the original Printer or the 
  notification server for those<BR>&gt; &gt; Printers<BR>&gt; &gt; &gt; that use 
  a notification server. &nbsp;Our feature is really a<BR>&gt; "relay", not 
  a<BR>&gt; &gt; &gt; "redirect".<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Could this 
  win-win proposal be discussed briefly during the<BR>&gt; PWG Plenary<BR>&gt; 
  &gt; &gt; tomorrow (Tuesday, August 27) to see if we have consensus<BR>&gt; 
  there (and we<BR>&gt; &gt; will<BR>&gt; &gt; &gt; discuss it on the mailing 
  list to see if we have consensus there too)?<BR>&gt; &gt; &gt;<BR>&gt; &gt; 
  &gt; Comments?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Tom and Ira<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt; P.S. In the future, if we want to generalize the 
  relay<BR>&gt; &gt; mechanism for other<BR>&gt; &gt; &gt; operations, the same 
  operation attribute can be returned in any<BR>&gt; &gt; response.<BR>&gt; &gt; 
  &gt; For job operations, we probably would also need to return<BR>&gt; &gt; 
  &gt; "alternate-job-uri" and "alternate-job-id" operation attributes 
  in<BR>&gt; &gt; addition<BR>&gt; &gt; &gt; to the "alternate-target-uri" 
  operation attribute.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt; -----Original Message-----<BR>&gt; &gt; &gt; From: 
  McDonald, Ira [mailto:imcdonald@sharplabs.com]<BR>&gt; &gt; &gt; Sent: Monday, 
  August 26, 2002 14:26<BR>&gt; &gt; &gt; To: 'Hastings, Tom N'; ipp@pwg.org; 
  ifx@pwg.org<BR>&gt; &gt; &gt; Cc: pwg@pwg.org<BR>&gt; &gt; &gt; Subject: RE: 
  IFX&gt; Attempt to close on the two Notification<BR>&gt; specs at the<BR>&gt; 
  &gt; &gt; fa ce to fac e meetings<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; 
  &gt; &gt; Hi Tom,<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; First - I agree that it 
  would still be good to drop redirect<BR>&gt; from IPPGET<BR>&gt; &gt; &gt; and 
  design it IN GENERAL for IPP (any operation response could return<BR>&gt; &gt; 
  &gt; the redirect), including the fact that while it's nice for<BR>&gt; &gt; 
  interoperability<BR>&gt; &gt; &gt; IPP Clients do NOT need to honor and follow 
  redirects (any more than<BR>&gt; &gt; &gt; HTTP Clients need to do so - it's a 
  matter of client policy).<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Second - if we 
  publish IPPGET as a Proposed Std RFC (as you suggest)<BR>&gt; &gt; &gt; and 
  LATER add redirect, we MUST recycle at Proposed Std RFC - it's<BR>&gt; &gt; 
  &gt; illegal to add ANY new features when moving from Proposed Std to<BR>&gt; 
  &gt; &gt; Draft Std status - only dropping existing features is legal.</FONT> 
  <BR><FONT face="Courier New" size=2>&gt; &gt; &gt;<BR>&gt; &gt; &gt; 
  Cheers,<BR>&gt; &gt; &gt; - Ira McDonald<BR>&gt; &gt; &gt; &nbsp; High North 
  Inc<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; -----Original 
  Message-----<BR>&gt; &gt; &gt; From: Hastings, Tom N 
  [mailto:hastings@cp10.es.xerox.com]<BR>&gt; &gt; &gt; Sent: Friday, August 23, 
  2002 10:54 PM<BR>&gt; &gt; &gt; To: ipp@pwg.org; ifx@pwg.org<BR>&gt; &gt; &gt; 
  Cc: pwg@pwg.org<BR>&gt; &gt; &gt; Subject: IFX&gt; Attempt to close on the two 
  Notification specs<BR>&gt; at the face<BR>&gt; &gt; &gt; to fac e 
  meetings<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; The IPP WG Last 
  Call period closed July 31 on the two IPP Notification<BR>&gt; &gt; 
  specs<BR>&gt; &gt; &gt; that are required for IPP Notification:<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt; (1) IPP Event Notifications and Subscriptions<BR>&gt; 
  &gt; &gt; &lt;draft-ietf-ipp-not-spec-09.txt&gt;<BR>&gt; &gt; &gt; (2) The 
  'ippget' Delivery Method for Event Notifications<BR>&gt; &gt; &gt; 
  &lt;draft-ietf-ipp-notify-get-07.txt&gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; 
  and Carl-Uno declared that (1) was approved, since there were<BR>&gt; &gt; no 
  comments<BR>&gt; &gt; &gt; and that (2) achieved consensus to drop the 
  redirection<BR>&gt; &gt; mechanism entirely<BR>&gt; &gt; &gt; from the IPPGET 
  document.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; However, we have continued 
  discussion about the merits and<BR>&gt; &gt; problems of the<BR>&gt; &gt; &gt; 
  redirection mechanism because Harry Lewis has been the main<BR>&gt; objector 
  to<BR>&gt; &gt; &gt; removing the redirection mechanism from IPPGET. &nbsp;As 
  a result<BR>&gt; I have not<BR>&gt; &gt; yet<BR>&gt; &gt; &gt; produced a new 
  version of the document and Carl-Uno has not forwarded<BR>&gt; &gt; 
  either<BR>&gt; &gt; &gt; of the documents to Ned Freed, our Area 
  Director.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; &lt;...snip...&gt;<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt; Process considerations:<BR>&gt; &gt; &gt;<BR>&gt; &gt; 
  &gt; Could we delete the redirection mechanism for now from<BR>&gt; IPPGET? 
  &nbsp;Get our<BR>&gt; &gt; RFC<BR>&gt; &gt; &gt; published as a Proposed 
  standard. &nbsp;Implement IPPGET and do<BR>&gt; &gt; interoperability<BR>&gt; 
  &gt; &gt; testing. &nbsp;See if the burden in the Printer of supporting 
  the<BR>&gt; &gt; IPPGET method<BR>&gt; &gt; &gt; justifies offloading it to a 
  Notification Server using the redirect<BR>&gt; &gt; &gt; mechanism. &nbsp;If 
  the implementation experience shows that its not<BR>&gt; &gt; much of 
  a<BR>&gt; &gt; &gt; burden in the Printer we made the right decision to 
  delete<BR>&gt; redirection.<BR>&gt; &gt; If<BR>&gt; &gt; &gt; implementation 
  experience shows that having a Notification Server is<BR>&gt; &gt; &gt; 
  important to off-load the Printer's support of the IPPGET<BR>&gt; &gt; method, 
  then add<BR>&gt; &gt; &gt; the redirection back into the IPPGET spec before 
  progressing<BR>&gt; &gt; the document<BR>&gt; &gt; to<BR>&gt; &gt; &gt; a 
  Draft standard. &nbsp;Perhaps in the meantime, IBM can also implement 
  the<BR>&gt; &gt; &gt; Notification Server and see if it is really a win and 
  that the extra<BR>&gt; &gt; &gt; administrative effort is worth the benefit to 
  simplifying the Printer<BR>&gt; &gt; &gt; implementation.<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt; Comments?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; 
  Tom<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; &lt;...snip...&gt;<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; 
  &gt;<BR>&gt;<BR>&gt;<BR><BR><BR></FONT><BR><BR></BLOCKQUOTE></BODY></HTML>