attachment

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