IPP Mail Archive: Re: IPP> Re: IFX> Attempt to close on t

IPP Mail Archive: Re: IPP> Re: IFX> Attempt to close on t

Re: IPP> Re: IFX> Attempt to close on the two Notification specs at the face to face meetings

From: Robert Herriot (bob@herriot.com)
Date: Tue Aug 27 2002 - 17:41:19 EDT

  • Next message: Hastings, Tom N: "RE: IPP> Re: IFX> Attempt to close on the two Notification specs at the face to face meetings"

    I discussed issue 1 that you raise, though perhaps I wasn't as clear as I
    hoped. I used the word "proprietary" to describe the relationship between
    the printer and its companion notification server, implying that the ipp-get
    spec should be silent on that relationship.

    On issue 2, you do raise a good point. The notification server would
    presumably support ipp-get but no other IPP operation. So it would be a new
    kind of IPP server that conforms only to a small part of the other IPP
    specs. This would seem to create a lot of thorny problems.

    I am concerned about creating a last minute solution that will come back to
    haunt us in the future. I think the best solution is to drop the redirection
    and proposed substitutions for it.

    Bob Herriot

    ----- Original Message -----
    From: "Carl" <carl@manros.com>
    To: "Robert Herriot" <bob@herriot.com>; "Hastings, Tom N"
    <hastings@cp10.es.xerox.com>; <ipp@pwg.org>; <ifx@pwg.org>; "Lewis, Harry"
    <harryl@us.ibm.com>
    Sent: Tuesday, August 27, 2002 7:45 AM
    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.
    >
    > 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.
    >
    > 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?
    >
    > 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...>
    > > >
    > > >
    > >
    > >
    > >
    >
    >
    >
    >



    This archive was generated by hypermail 2b29 : Tue Aug 27 2002 - 16:35:51 EDT