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=283221221-19072002>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&nbsp;request always&nbsp;supplies the Subscription Id 
which&nbsp;such a shared&nbsp;Notification Server can allocate in a single pool 
that is used by all Printers that use the Notification 
Server.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=283221221-19072002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=283221221-19072002><FONT size=2><FONT face=Arial 
color=#0000ff>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></FONT></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=283221221-19072002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=283221221-19072002>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):</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=283221221-19072002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=283221221-19072002>
<P class=MsoList2 
style="MARGIN: 0in 0in 12pt 0.75in; mso-list: l13 level1 lfo41; tab-stops: list .75in"><FONT 
face="Times New Roman"><FONT color=#000000><SPAN 
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=3><SPAN 
class=283221221-19072002>4</SPAN>.</FONT><SPAN 
style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></SPAN><FONT size=3><SPAN 
style="mso-fareast-font-family: 'MS Mincho'">MUST honor the 
</SPAN>&#8216;redirection-other-site&#8217; 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 &#8220;redirect-uri&#8221; (uri) 
operation attribute (see section 5.2.3).<SPAN style="mso-spacerun: yes">&nbsp; 
</SPAN>In such cases, the client SHOULD retain this URL for subsequent 
Get-Notification requests for the same Subscription object.<SPAN 
style="mso-fareast-font-family: 'MS Mincho'"><?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" 
/><o:p></o:p></SPAN></FONT></FONT></FONT></P></SPAN></FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2><SPAN 
class=283221221-19072002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#000000 size=2><SPAN 
class=283221221-19072002>So OK to keep redirection in the IPPGET spec, as long 
as clients MUST support it (in case the Printer does)?</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2><SPAN 
class=283221221-19072002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#000000 size=2><SPAN 
class=283221221-19072002>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.</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2><SPAN 
class=283221221-19072002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#000000 size=2><SPAN 
class=283221221-19072002>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2><SPAN 
class=283221221-19072002>Tom</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <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> Thursday, July 18, 2002 
  15:48<BR><B>To:</B> Robert Herriot<BR><B>Cc:</B> Hastings, Tom N; McDonald, 
  Ira; ipp@pwg.org; TTRONSON@novell.com; Carl Kugler<BR><B>Subject:</B> Re: 
  IPP&gt; Re: FW: Last Call comment to remove redirect URL and status code 
  fromIPPGET<BR><BR></FONT></DIV><BR><FONT face=sans-serif size=2>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><BR><BR><FONT 
  face=sans-serif size=2>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><BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>"Robert Herriot" 
        &lt;bob@herriot.com&gt;</B></FONT> <BR><FONT face=sans-serif size=1>Sent 
        by: owner-ipp@pwg.org</FONT> 
        <P><FONT face=sans-serif size=1>07/18/2002 03:42 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;"McDonald, Ira" &lt;imcdonald@sharplabs.com&gt;, "'Ted 
        Tronson'" &lt;TTRONSON@novell.com&gt;, &lt;ipp@pwg.org&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;</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 
        status code fromIPPGET</FONT> <BR><BR><FONT face=Arial size=1>&nbsp; 
        &nbsp; &nbsp; &nbsp;</FONT></TR></TBODY></TABLE><BR><BR><FONT size=2><TT>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><BR></TT></FONT><BR></BLOCKQUOTE></BODY></HTML>