attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-2022-KR">

<XETA 
CONTENT="text/html; charset=ISO-2022-KR" HTTP-EQUIV="Content-Type"><XETA 
name="GENERATOR" content="MSHTML 6.00.2600.0">
<META content="MSHTML 6.00.2712.300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=464032415-01082002><FONT face=Arial color=#0000ff 
size=2>Tom,</FONT></SPAN></DIV>
<DIV><SPAN class=464032415-01082002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=464032415-01082002><FONT face=Arial color=#0000ff size=2>I am 
neutral on the subject.&nbsp; But, Hitachi has no plans to implement this 
feature either in a printer or a client.</FONT></SPAN></DIV>
<DIV><SPAN class=464032415-01082002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=464032415-01082002>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>Ron</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hastings, Tom N 
  [mailto:hastings@cp10.es.xerox.com]<BR><B>Sent:</B> Tuesday, July 30, 2002 
  5:47 PM<BR><B>To:</B> Harry Lewis; Mike Sweet; Ron.Bergman@Hitachi-hkis.com; 
  Ted Tronson; McDonald, Ira; Robert Herriot; Hastings, Tom N<BR><B>Cc:</B> 
  ipp@pwg.org<BR><B>Subject:</B> RE: Last Call comment to remove redirect URL 
  and status code from IPPGET<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=620395720-30072002>So 
  I'm having trouble seeing whether we have consensus to remove the 
  Get-Notifications redirect or not.&nbsp; There were six comments in favor of 
  deleting the application layer IPP redirect from Get-Notifications and then 
  Harry responded that he was in favor of keeping it in the spec even though it 
  means that we have to add&nbsp;that&nbsp;conforming clients must support the 
  redirection.&nbsp; His contention is that that isn't very hard for a client to 
  have to do.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=620395720-30072002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=620395720-30072002>Could the six commenters (see the To: line) who 
  agreed to remove redirection, please respond as to whether they are still in 
  favor of deleting the Get-Notifications redirection or that they are now 
  willing to keep Get-Notifications redirection in the IPPGET spec in case 
  someone wants to implement IPPGET with a Notification 
  Server.&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=620395720-30072002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=620395720-30072002>As 
  Bob asks, is anyone planning to use a Notification Server or think that they 
  might want to?</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=620395720-30072002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=620395720-30072002>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=620395720-30072002>Tom</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr Xtyle="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Harry Lewis 
    [mailto:harryl@us.ibm.com]<BR><B>Sent:</B> Monday, July 22, 2002 
    08:45<BR><B>To:</B> Hastings, Tom N<BR><B>Cc:</B> Robert Herriot; Carl 
    Kugler; Hastings, Tom N; McDonald, Ira; ipp@pwg.org; 
    TTRONSON@novell.com<BR><B>Subject:</B> RE: IPP&gt; Re: FW: Last Call comment 
    to remove redirect URL and sta tus code from 
    IPPGET<BR><BR></FONT></DIV><BR><FONT face=sans-serif size=2>I agree. I don't 
    think it's a lot of extra work for Clients to honor redirection if indicated 
    by the Printer.<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>"Hastings, Tom N" 
          &lt;hastings@cp10.es.xerox.com&gt;</B></FONT> 
          <P><FONT face=sans-serif size=1>07/19/2002 03:46 PM</FONT> </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;Harry Lewis/Boulder/IBM@IBMUS, Robert 
          Herriot &lt;bob@herriot.com&gt;</FONT> <BR><FONT face=sans-serif 
          size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; 
          &nbsp;"Hastings, Tom N" &lt;hastings@cp10.es.xerox.com&gt;, "McDonald, 
          Ira" &lt;imcdonald@sharplabs.com&gt;, ipp@pwg.org, 
          TTRONSON@novell.com, Carl Kugler/Boulder/IBM@IBMUS</FONT> <BR><FONT 
          face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; 
          &nbsp; &nbsp; &nbsp;RE: IPP&gt; Re: FW: Last Call comment to remove 
          redirect URL and sta &nbsp; &nbsp; &nbsp; &nbsp;tus code from 
          IPPGET</FONT> <BR><BR><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; 
          &nbsp;</FONT></TD></TR></TBODY></TABLE><BR><BR><FONT face=Arial color=blue 
    size=2>This has been a good discussion. &nbsp;I can see how the redirect 
    *could* be used for just redirecting Get-Notifications without redirecting 
    anything else, so it is separate from the HTTP redirection. &nbsp;Also it 
    does seem that this redirection doesn't need any new job ids or anything, 
    since each Get-Notifications request always supplies the Subscription Id 
    which such a shared Notification Server can allocate in a single pool that 
    is used by all Printers that use the Notification Server.</FONT> <BR><FONT 
    size=3>&nbsp;</FONT> <BR><FONT face=Arial color=blue size=2>So the only 
    problem left with leaving redirection in, is that we really do need to add 
    another conformance requirement for clients that support IPP Notifications, 
    namely, that the client MUST honor the 'redirection-other-site' status code 
    if the Printer returns it in a Get-Notifications response and re-try the 
    Get-Notifications request on the indicated URL. &nbsp;And we should also add 
    that the client SHOULD remember the redirect-uri for subsequent 
    Get-Notifications requests for this Subscription object.</FONT> <BR><FONT 
    size=3>&nbsp;</FONT> <BR><FONT face=Arial color=blue size=2>If we agree to 
    keep this Get-Notifications redirection in the spec, then I suggest that we 
    add the following conformance requirement for clients in section 12.2 (if 
    the client supports Get-Notifications):</FONT> <BR><FONT 
    size=3>&nbsp;</FONT> <BR><FONT face="Times New Roman" size=3>4.</FONT><FONT 
    face="Times New Roman" size=2> &nbsp; &nbsp; &nbsp;</FONT><FONT 
$)C    face="Times New Roman" size=3>MUST honor the !.redirection-other-site!/ status 
    code (see section 10.2), if the Printer returns it in the Get-Notifications 
    response, and re-try the Get-Notifications operation using the URL returned 
    by the Printer in the !0redirect-uri!1 (uri) operation attribute (see section 
    5.2.3). &nbsp;In such cases, the client SHOULD retain this URL for 
    subsequent Get-Notification requests for the same Subscription 
    object.</FONT> 
    <P><FONT size=3></FONT><BR><FONT face="Courier New" size=2>So OK to keep 
    redirection in the IPPGET spec, as long as clients MUST support it (in case 
    the Printer does)?</FONT> <BR><FONT size=3>&nbsp;</FONT> <BR><FONT 
    face="Courier New" size=2>And it would be good to explain the redirection 
    idea a little more and how it could be used by a Notification Server that 
    many Printers could use. &nbsp;If there is consensus to keep it in, I'll 
    draft some suggested explanatory text to explain its intended usage.</FONT> 
    <BR><FONT size=3>&nbsp;</FONT> <BR><FONT face="Courier New" 
    size=2>Thanks,</FONT> <BR><FONT face="Courier New" size=2>Tom</FONT> 
    <BR><FONT face=Tahoma size=2>-----Original Message-----<B><BR>From:</B> 
    Harry Lewis [mailto:harryl@us.ibm.com]<B><BR>Sent:</B> Thursday, July 18, 
    2002 15:48<B><BR>To:</B> Robert Herriot<B><BR>Cc:</B> Hastings, Tom N; 
    McDonald, Ira; ipp@pwg.org; TTRONSON@novell.com; Carl 
    Kugler<B><BR>Subject:</B> Re: IPP&gt; Re: FW: Last Call comment to remove 
    redirect URL and status code fromIPPGET<BR></FONT><BR><FONT face=sans-serif 
    size=2><BR>Sorry, I'm just catching up on this thread. Redirect was a 
    concept Carl and I introduced in our original write-up for the native 
    in-band IPP notifications (which later became "ipp-get" with a lot of good 
    content and rigor added by Bob, Tom and others. &nbsp;Bob's recollection is 
    accurate. HTTP redirection is more general than intended for our purposes. 
    IPP Notification redirect was intended to allow the normal IPP subscription 
    process (i.e. a subscription for job progress notification could be 
    associated with print job submission) but facilitate the actual management 
    of notifications occurring on a proxy or server. Something like the Job MIB, 
    for example, could actually be used by the server to track job progress at 
    the printer. </FONT><FONT size=3><BR></FONT><FONT face=sans-serif 
    size=2><BR>I really don't see any reason to remove this feature. I do think 
    it should be optional (and maybe a better explanation of it's purpose 
    added). &nbsp;<BR>---------------------------------------------- <BR>Harry 
    Lewis <BR>IBM Printing Systems 
    <BR>---------------------------------------------- </FONT><FONT 
    size=3><BR><BR></FONT>
    <TABLE width="100%">
      <TBODY>
      <TR vAlign=top>
        <TD width="1%">
        <TD width="26%"><FONT face=sans-serif size=1><B>"Robert Herriot" 
          &lt;bob@herriot.com&gt;</B></FONT><FONT size=3> </FONT><FONT 
          face=sans-serif size=1><BR>Sent by: owner-ipp@pwg.org</FONT><FONT 
          size=3> </FONT>
          <P><FONT face=sans-serif size=1>07/18/2002 03:42 PM</FONT><FONT 
          size=3> </FONT></P>
        <TD width="72%"><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;"McDonald, Ira" 
          &lt;imcdonald@sharplabs.com&gt;, "'Ted Tronson'" 
          &lt;TTRONSON@novell.com&gt;, &lt;ipp@pwg.org&gt;</FONT><FONT size=3> 
          </FONT><FONT face=sans-serif size=1><BR>&nbsp; &nbsp; &nbsp; &nbsp;cc: 
          &nbsp; &nbsp; &nbsp; &nbsp;"Hastings, Tom N" 
          &lt;hastings@cp10.es.xerox.com&gt;</FONT><FONT size=3> </FONT><FONT 
          face=sans-serif size=1><BR>&nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; 
          &nbsp; &nbsp; &nbsp;Re: IPP&gt; Re: FW: Last Call comment to remove 
          redirect URL and status code fromIPPGET</FONT><FONT size=3> 
          <BR></FONT><FONT face=Arial size=1><BR>&nbsp; &nbsp; &nbsp; 
      </FONT></TD></TR></TBODY></TABLE><BR><FONT size=3><BR></FONT><FONT 
    size=2><TT><BR>I don't remember who advocated the redirect feature, but I 
    think that it was<BR>put in to<BR>solve a problem that the HTTP layer cannot 
    deal with.<BR><BR>As I remember the assumption was that a printer (the URI 
    target) might<BR>support<BR>the normal IPP operations, but might not support 
    ipp-get (e.g. it doesn't<BR>retain the<BR>event history). Instead the 
    printer would rely on some other server to<BR>handle ipp-get --<BR>hence the 
    need for the ipp-get redirect. &nbsp;At the HTTP level, all 
    ipp<BR>operations would<BR>be redirected. With the ipp-get redirect, only 
    ipp-get would be redirected.<BR><BR>I don't believe that the presence of 
    HTTP redirect is a reason to delete the<BR>feature. Rather<BR>we need to 
    know that no one implements the feature and no one plans to<BR>implement it 
    in the<BR>future. &nbsp;If that is the case, then there is a good reason to 
    delete the<BR>feature from the document.<BR><BR><BR>Bob 
    Herriot<BR><BR><BR>----- Original Message -----<BR>From: "McDonald, Ira" 
    &lt;imcdonald@sharplabs.com&gt;<BR>To: "'Ted Tronson'" 
    &lt;TTRONSON@novell.com&gt;; &lt;ipp@pwg.org&gt;<BR>Sent: Thursday, July 18, 
    2002 11:45 AM<BR>Subject: RE: IPP&gt; Re: FW: Last Call comment to remove 
    redirect URL and<BR>status code fromIPPGET<BR><BR><BR>&gt; 
    Hi,<BR>&gt;<BR>&gt; Thanks Ted Tronson, Ron Bergman, Carl-Uno Manros, and 
    others.<BR>&gt;<BR>&gt; To clarify: &nbsp;All IPP operations (present and 
    future) will still have<BR>&gt; HTTP-level support for 'redirect'. &nbsp;Tom 
    and I are merely proposing<BR>&gt; to discard (before the RFC) what we think 
    is a duplicate 'redirect'<BR>&gt; mechanism at the 
    IPP-level.<BR>&gt;<BR>&gt; If we ever bind IPP over another 
    transport/session protocol in<BR>&gt; the future, we'll probably want to add 
    to the IPP Model an<BR>&gt; in-band 'redirect-uri' and 'redirect-job-id' 
    pair of operation<BR>&gt; response attributes.<BR>&gt;<BR>&gt; 
    Cheers,<BR>&gt; - Ira McDonald<BR>&gt; &nbsp; High North Inc<BR>&gt;<BR>&gt; 
    -----Original Message-----<BR>&gt; From: Ted Tronson 
    [mailto:TTRONSON@novell.com]<BR>&gt; Sent: Thursday, July 18, 2002 12:08 
    PM<BR>&gt; To: ipp@pwg.org<BR>&gt; Subject: IPP&gt; Re: FW: Last Call 
    comment to remove redirect URL and<BR>&gt; status code 
    fromIPPGET<BR>&gt;<BR>&gt;<BR>&gt; I see no reason to have the redirection 
    URL. &nbsp;In the past in might have<BR>&gt; been a good idea, but in our 
    present implementation I don't think it<BR>&gt; would be 
    needed.<BR>&gt;<BR>&gt; Ted Tronson<BR>&gt; Sr. Software Engineer<BR>&gt; 
    iPrint Engineering<BR>&gt; 801-861-3338<BR>&gt; Novell, Inc., the leading 
    provider of Net services software<BR>&gt; www.novell.com<BR>&gt;<BR>&gt; 
    &gt;&gt;&gt; "Hastings, Tom N" &lt;hastings@cp10.es.xerox.com&gt; 07/18/02 
    09:23AM<BR>&gt; &gt;&gt;&gt;<BR>&gt; Harry, Carl, Hugo, and 
    Ted,<BR>&gt;<BR>&gt; Do any of you want to keep the redirection URL 
    attribute and status<BR>&gt; code in<BR>&gt; IPPGET, or can we delete it 
    from IPPGET? &nbsp;Ira and I were guessing that<BR>&gt; maybe<BR>&gt; the 
    idea of redirection may have come from the Novell idea of using a<BR>&gt; 
    separate Notification Server for a number of Printers. &nbsp;On the 
    other<BR>&gt; hand,<BR>&gt; maybe with IPPGET where the Notification 
    Recipient is going the<BR>&gt; Get-Notifications operation that maybe each 
    Printer would be more<BR>&gt; likely to<BR>&gt; do the notification, rather 
    than handing the responsibility off to a<BR>&gt; separate Notification 
    Server.<BR>&gt;<BR>&gt; Please see the reasons that Ira and I gave in our 
    Last Call comment on<BR>&gt; IPPGET for deleting this application layer 
    redirection from IPPGET.<BR>&gt;<BR>&gt; If you need redirection, you can 
    always use the HTTP redirection.<BR>&gt;<BR>&gt; Thanks,<BR>&gt; Tom and 
    Ira<BR>&gt;<BR>&gt; -----Original Message-----<BR>&gt; From: Carl 
    [mailto:carl@manros.com]<BR>&gt; Sent: Wednesday, July 17, 2002 
    23:15<BR>&gt; To: Hastings, Tom N<BR>&gt; Cc: Ira McDonald; Carl-Uno 
    Manros<BR>&gt; Subject: RE: Last Call comment to remove redirect URL and 
    status code<BR>&gt; from IPPGET<BR>&gt;<BR>&gt;<BR>&gt; Tom,<BR>&gt;<BR>&gt; 
    Can you still remember who wanted this in there in the first place?<BR>&gt; 
    IBM<BR>&gt; perhaps? Or Novell?<BR>&gt;<BR>&gt; Would be good to find that 
    out before we delete it, but otherwise I am<BR>&gt; for<BR>&gt; the 
    simplification.<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-310-251-7103<BR>&gt; Email carl@manros.com<BR>&gt;<BR>&gt; &gt; 
    -----Original Message-----<BR>&gt; &gt; From: Hastings, Tom N 
    [mailto:hastings@cp10.es.xerox.com]<BR>&gt; &gt; Sent: Wednesday, July 17, 
    2002 6:21 PM<BR>&gt; &gt; To: ipp@pwg.org<BR>&gt; &gt; Cc: Carl<BR>&gt; &gt; 
    Subject: Last Call comment to remove redirect URL and status code<BR>&gt; 
    from<BR>&gt; &gt; IPPGET<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; Ira McDonald 
    and I were talking about the IPPGET which has a<BR>&gt; &gt; 
    "redirect-uri"<BR>&gt; &gt; operation attribute that MAY be returned in a 
    Get-Notifications<BR>&gt; response<BR>&gt; &gt; when the 
    'redirection-other-site' status code returned. &nbsp;Here is<BR>&gt; &gt; 
    all of the<BR>&gt; &gt; text in the document that deals with 
    redirection:<BR>&gt; &gt;<BR>&gt; &gt; 5.2 Get-Notifications 
    Response<BR>&gt; &gt;<BR>&gt; &gt; redirection-other-site: The Printer does 
    not handle this operation<BR>&gt; and<BR>&gt; &gt; requests the Notification 
    Recipient to perform the operation<BR>&gt; &gt; again with the<BR>&gt; &gt; 
    uri specified by the "redirect-uri" Operation Attribute in the<BR>&gt; 
    response.<BR>&gt; &gt; See section 10.2.<BR>&gt; &gt;<BR>&gt; &gt; 5.2.3 
    redirect-uri (uri)<BR>&gt; &gt;<BR>&gt; &gt; The value of this attribute is 
    the uri that the Notification<BR>&gt; &gt; Recipient MUST<BR>&gt; &gt; use 
    for a subsequent Get-Notifications operation. &nbsp;The Printer MAY<BR>&gt; 
    support<BR>&gt; &gt; this attribute. &nbsp;This attribute MUST be returned 
    in the Operation<BR>&gt; &gt; Attributes<BR>&gt; &gt; Group if and only if 
    the Printer returns the<BR>&gt; &gt; 'redirection-other-site' status<BR>&gt; 
    &gt; code (see section 10.2).<BR>&gt; &gt;<BR>&gt; &gt; 10.2 
    redirection-other-site (0x0300)<BR>&gt; &gt;<BR>&gt; &gt; This status code 
    means that the Printer doesn't perform that<BR>&gt; &gt; Get-Notifications 
    operation and that the "redirect-uri" operation<BR>&gt; &gt; 
    attribute<BR>&gt; &gt; (see section 5.2.3) in the response contains the uri 
    that the<BR>&gt; Notification<BR>&gt; &gt; Recipient MUST use for performing 
    the Get-Notifications operation.<BR>&gt; If the<BR>&gt; &gt; client issues 
    subsequent Get-Notifications operations, it MUST<BR>&gt; &gt; use the 
    value<BR>&gt; &gt; of the "redirect-uri" operation attribute returned by the 
    Printer as<BR>&gt; the<BR>&gt; &gt; target of the operation.<BR>&gt; 
    &gt;<BR>&gt; &gt; 12.1 Printer Conformance<BR>&gt; &gt;<BR>&gt; &gt; 8. MUST 
    support the "redirection-other-site" status code defined<BR>&gt; 
    10.2,<BR>&gt; &gt; if it redirects Get-Notifications operations;<BR>&gt; 
    &gt;<BR>&gt; &gt; Presumably a client MUST support the 
    'redirection-other-side'<BR>&gt; &gt; status code if<BR>&gt; &gt; it ever is 
    returned by a Printer in a Get-Notifications response,<BR>&gt; 
    though<BR>&gt; &gt; section 12.2 Client Conformance doesn't mention 
    this.<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; We suggest that we delete all 
    of the above text from the IPPGET spec,<BR>&gt; so<BR>&gt; &gt; that there 
    is no redirect status code and no "redirect-uri"<BR>&gt; operation<BR>&gt; 
    &gt; attribute for the following reasons:<BR>&gt; &gt;<BR>&gt; &gt; 1. The 
    HTTP Layer already has redirect for all operations, not just<BR>&gt; &gt; 
    Get-Notifications. &nbsp;Introducing a competing redirection 
    mechanism<BR>&gt; into the<BR>&gt; &gt; application layer seems a mistake. 
    &nbsp;What happens if they both occur?<BR>&gt; &gt;<BR>&gt; &gt; 2. 
    Redirection has a number of problems for Get-Notifications, in<BR>&gt; &gt; 
    that if a<BR>&gt; &gt; Printer is using a Notification Server to return 
    events, along with<BR>&gt; other<BR>&gt; &gt; Printers, then getting job 
    attributes from the Job object on a job<BR>&gt; event<BR>&gt; &gt; means 
    that the job-ids for each of the Printers have to be allocated<BR>&gt; in 
    a<BR>&gt; &gt; non-conflicting way for each of the Printers. &nbsp;Or 
    alternatively,<BR>&gt; &gt; the Printer<BR>&gt; &gt; needs to return not 
    only a "redirect-uri", but also possibly a<BR>&gt; new-job-id,<BR>&gt; &gt; 
    if the job id has changed.<BR>&gt; &gt;<BR>&gt; &gt; 3. If we ever wanted to 
    put IPP semantics on another transport, we<BR>&gt; can<BR>&gt; &gt; decide 
    then whether to introduce the redirection concept into IPP<BR>&gt; &gt; 
    application layer for all operations (and fix the problems listed<BR>&gt; 
    &gt; above) or<BR>&gt; &gt; use the transport's redirect mechanism.<BR>&gt; 
    &gt;<BR>&gt; &gt; 4. Removing this redirect mechanism makes it simpler for a 
    client<BR>&gt; using<BR>&gt; &gt; Get-Notifications, since the client won't 
    have to deal with it. &nbsp;And<BR>&gt; since<BR>&gt; &gt; IPPGET is 
    proposed to be the REQUIRED notification method,<BR>&gt; simplifying<BR>&gt; 
    &gt; IPPGET for clients is a good idea.<BR>&gt; &gt;<BR>&gt; &gt; 
    Comments?<BR>&gt; &gt;<BR>&gt; &gt; Tom<BR>&gt; &gt;<BR>&gt; &gt; 
    -----Original Message-----<BR>&gt; &gt; From: Carl 
    [mailto:carl@manros.com]<BR>&gt; &gt; Sent: Saturday, July 13, 2002 
    13:37<BR>&gt; &gt; To: ipp@pwg.org<BR>&gt; &gt; Subject: IPP&gt; ADM - IPP 
    Working Group Last Call for "(IPP): Event<BR>&gt; &gt; Notifications and 
    Subscriptions" and "(IPP): The 'ippget'Delivery<BR>&gt; Method<BR>&gt; &gt; 
    for Event Notifications " by July 31, 2002<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; 
    &gt; All,<BR>&gt; &gt;<BR>&gt; &gt; This is a working group Last Call for 
    the "Internet Printing<BR>&gt; &gt; Protocol (IPP):<BR>&gt; &gt; Event 
    Notifications and Subscriptions" and the "Internet Printing<BR>&gt; 
    Protocol<BR>&gt; &gt; (IPP): The 'ippget'Delivery Method for Event 
    Notifications".<BR>&gt; &gt; Versions of these documents have been forwarded 
    to the Internet<BR>&gt; &gt; Draft directory as 
    &lt;draft-ietf-ipp-not-spec-09.txt&gt; and<BR>&gt; &gt; 
    &lt;draft-ietf-ipp-notify-get-07.txt&gt;.<BR>&gt; &gt;<BR>&gt; &gt; PDF and 
    Word versions of the drafts are also posted at the ietf-ipp<BR>&gt; 
    web<BR>&gt; &gt; site:<BR>&gt; &gt;<BR>&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; ftp://ftp.pwg.org/pub/pwg/ipp/<BR>&gt; &gt;<BR>&gt; &gt; The Last 
    Call notice follows:<BR>&gt; &gt;<BR>&gt; &gt; This is a formal request for 
    final comments within the IETF IPP<BR>&gt; &gt; Working Group for two 
    documents. "Internet Printing Protocol (IPP):<BR>&gt; &gt; Event 
    Notifications and Subscriptions" and the "Internet Printing<BR>&gt; 
    Protocol<BR>&gt; &gt; (IPP): The 'ippget' Delivery Method for Event 
    Notifications", which<BR>&gt; have<BR>&gt; &gt; earlier been forwarded to 
    the IESG for consideration as Standards<BR>&gt; Track<BR>&gt; &gt; RFCs. 
    These are IPP Working Group products, which have been<BR>&gt; 
    thoroughly<BR>&gt; &gt; discussed since mid 1998. The latest revisions are 
    the result of<BR>&gt; feedback<BR>&gt; &gt; from our Area Director Ned Freed 
    and Working Group discussions<BR>&gt; earlier<BR>&gt; &gt; this year. The 
    most significant change is that the 'ippget'<BR>&gt; &gt; delivery 
    method<BR>&gt; &gt; is now mandated for all implementations of the IPP 
    Event<BR>&gt; Notifications,<BR>&gt; &gt; while additional delivery methods 
    can be used as an option.<BR>&gt; &gt;<BR>&gt; &gt; The purpose of a working 
    group Last Call is in the style of "speak<BR>&gt; now or<BR>&gt; &gt; 
    forever hold your peace" in case there are fundamental objections,<BR>&gt; 
    which<BR>&gt; &gt; have not gotten previous or adequate discussion, or minor 
    errors<BR>&gt; &gt; which need<BR>&gt; &gt; correction.<BR>&gt; &gt;<BR>&gt; 
    &gt; Last Calls are for a minimum of 2 weeks. The period for the 
    Working<BR>&gt; Group<BR>&gt; &gt; comments will close on July 31, 2002(US 
    Pacific time reference).<BR>&gt; &gt;<BR>&gt; &gt; The relevant documents 
    are:<BR>&gt; &gt;<BR>&gt; &gt; Title : Internet Printing Protocol (IPP): IPP 
    Event<BR>&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Notifications and Subscriptions<BR>&gt; 
    &gt; Author(s) : R. Herriot, T. Hastings<BR>&gt; &gt; Filename : 
    draft-ietf-ipp-not-spec-09.txt<BR>&gt; &gt; Pages : 101<BR>&gt; &gt; Date : 
    03-Jul-02<BR>&gt; &gt;<BR>&gt; &gt; This document describes an OPTIONAL 
    extension to the Internet<BR>&gt; &gt; Printing Protocol/1.1: Model and 
    Semantics (RFC 2911, RFC 2910).<BR>&gt; &gt; This extension allows a client 
    to subscribe to printing related<BR>&gt; &gt; Events. &nbsp;Subscriptions 
    are modeled as Subscription Objects. &nbsp;The<BR>&gt; &gt; Subscription 
    Object specifies that when one of the specified Events<BR>&gt; &gt; occurs, 
    the Printer sends an asynchronous Event Notification to the<BR>&gt; &gt; 
    specified Notification Recipient via the specified Push or Pull<BR>&gt; &gt; 
    Delivery Method (i.e., protocol).<BR>&gt; &gt; A client associates 
    Subscription Objects with a particular Job by<BR>&gt; &gt; performing the 
    Create-Job-Subscriptions operation or by submitting a<BR>&gt; &gt; Job with 
    subscription information. &nbsp;A client associates Subscription<BR>&gt; 
    &gt; Objects with the Printer by performing a<BR>&gt; 
    Create-Printer-Subscriptions<BR>&gt; &gt; operation. &nbsp;Four other 
    operations are defined for Subscription<BR>&gt; &gt; Objects: 
    Get-Subscriptions-Attributes, Get-Subscriptions, Renew-<BR>&gt; &gt; 
    Subscription, and Cancel-Subscription.<BR>&gt; &gt;<BR>&gt; &gt; A URL for 
    this Internet-Draft is:<BR>&gt; &gt; 
    http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-09.txt<BR>&gt; 
    &gt;<BR>&gt; &gt; -----<BR>&gt; &gt;<BR>&gt; &gt; Title : Internet Printing 
    Protocol (IPP): The<BR>&gt; 'ippget'<BR>&gt; &gt; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    Delivery Method for Event Notifications<BR>&gt; &gt; Author(s) : R. Herriot, 
    T. Hastings<BR>&gt; &gt; Filename : draft-ietf-ipp-notify-get-07.txt<BR>&gt; 
    &gt; Pages : 37<BR>&gt; &gt; Date : 03-Jul-02<BR>&gt; &gt;<BR>&gt; &gt; This 
    document describes an extension to the Internet Printing<BR>&gt; &gt; 
    Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). &nbsp;This<BR>&gt; 
    &gt; document specifies the 'ippget' Delivery Method for use with 
    the<BR>&gt; &gt; 'Internet Printing Protocol (IPP): Event Notifications 
    and<BR>&gt; &gt; Subscriptions' specification. &nbsp;When IPP Notification 
    [ipp-ntfy] is<BR>&gt; &gt; supported, the Delivery Method defined in this 
    document is the<BR>&gt; &gt; REQUIRED Delivery Method for clients and 
    Printers to support. &nbsp;They<BR>&gt; &gt; MAY support additional Delivery 
    Methods.<BR>&gt; &gt; The 'ippget' Delivery Method is a Pull Delivery 
    Method. &nbsp;When an<BR>&gt; &gt; Event occurs, the Printer saves the Event 
    Notification for a period<BR>&gt; &gt; of time called the Event Life. 
    &nbsp;The Notification Recipient fetches<BR>&gt; &gt; (pulls) Event 
    Notifications using the Get-Notifications operation.<BR>&gt; &gt; If the 
    Notification Recipient has selected the Event Wait Mode<BR>&gt; 
    option<BR>&gt; &gt; to wait for additional Event Notifications, the Printer 
    continues to<BR>&gt; &gt; return Event Notifications to the Notification 
    Recipient as Get-<BR>&gt; &gt; Notification responses as Events occur using 
    the connection<BR>&gt; &gt; originated by the Notification 
    Recipient.<BR>&gt; &gt; Either the Notification Recipient or the Printer can 
    terminate Event<BR>&gt; &gt; Wait Mode without closing the 
    connection.<BR>&gt; &gt;<BR>&gt; &gt; A URL for this Internet-Draft 
    is:<BR>&gt; &gt; 
    http://www.ietf.org/internet-drafts/draft-ietf-ipp-notify-get-07.txt<BR>&gt;<BR>&gt; 
    &gt;<BR>&gt; &gt; Sincerely,<BR>&gt; &gt;<BR>&gt; &gt; Carl-Uno 
    Manros<BR>&gt; &gt; Chair of the IETF IPP WG<BR>&gt; &gt;<BR>&gt; &gt; 10701 
    S Eastern Ave #1117<BR>&gt; &gt; Henderson, NV 89052, USA<BR>&gt; &gt; Tel 
    +1-702-617-9414<BR>&gt; &gt; Fax +1-702-617-9417<BR>&gt; &gt; Mob 
    +1-310-251-7103<BR>&gt; &gt; Email carl@manros.com<BR>&gt; &gt;<BR>&gt; 
    &gt;<BR>&gt;<BR>&gt;<BR><BR></TT></FONT><FONT 
  size=3><BR></FONT><BR></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>