attachment-0001


<br><font size=2 face="sans-serif">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 &quot;ipp-get&quot; 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 size=2 face="sans-serif">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%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Robert Herriot&quot; &lt;bob@herriot.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-ipp@pwg.org</font>
<p><font size=1 face="sans-serif">07/18/2002 03:42 PM</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;McDonald, Ira&quot; &lt;imcdonald@sharplabs.com&gt;, &quot;'Ted Tronson'&quot; &lt;TTRONSON@novell.com&gt;, &lt;ipp@pwg.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Hastings, Tom N&quot; &lt;hastings@cp10.es.xerox.com&gt;</font>
<br><font size=1 face="sans-serif">&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 size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></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: &quot;McDonald, Ira&quot; &lt;imcdonald@sharplabs.com&gt;<br>
To: &quot;'Ted Tronson'&quot; &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; &quot;Hastings, Tom N&quot; &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; &quot;redirect-uri&quot;<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 &quot;redirect-uri&quot; 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 &quot;redirect-uri&quot; 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 &quot;redirect-uri&quot; 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 &quot;redirection-other-site&quot; 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 &quot;redirect-uri&quot;<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 &quot;redirect-uri&quot;, 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 &quot;(IPP): Event<br>
&gt; &gt; Notifications and Subscriptions&quot; and &quot;(IPP): The 'ippget'Delivery<br>
&gt; Method<br>
&gt; &gt; for Event Notifications &quot; 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 &quot;Internet Printing<br>
&gt; &gt; Protocol (IPP):<br>
&gt; &gt; Event Notifications and Subscriptions&quot; and the &quot;Internet Printing<br>
&gt; Protocol<br>
&gt; &gt; (IPP): The 'ippget'Delivery Method for Event Notifications&quot;.<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. &quot;Internet Printing Protocol (IPP):<br>
&gt; &gt; Event Notifications and Subscriptions&quot; and the &quot;Internet Printing<br>
&gt; Protocol<br>
&gt; &gt; (IPP): The 'ippget' Delivery Method for Event Notifications&quot;, 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 &quot;speak<br>
&gt; now or<br>
&gt; &gt; forever hold your peace&quot; 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>