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