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 at manros.com
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Tuesday, August 27, 2002 1:35 PM
> To: Carl; Robert Herriot; Lewis, Harry
> Cc: ipp at pwg.org; ifx at 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 at manros.com]
> Sent: Tuesday, August 27, 2002 07:45
> To: Robert Herriot; Hastings, Tom N; ipp at pwg.org; ifx at 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 at manros.com>> > -----Original Message-----
> > From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Robert
> > Herriot
> > Sent: Tuesday, August 27, 2002 2:15 AM
> > To: Hastings, Tom N; ipp at pwg.org; ifx at pwg.org; Lewis, Harry
> > Cc: pwg at 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 at cp10.es.xerox.com>
> > To: <ipp at pwg.org>; <ifx at pwg.org>; "Lewis, Harry" <harryl at us.ibm.com>
> > Cc: <pwg at 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 at sharplabs.com]
> > > Sent: Monday, August 26, 2002 14:26
> > > To: 'Hastings, Tom N'; ipp at pwg.org; ifx at pwg.org> > > Cc: pwg at 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 at cp10.es.xerox.com]
> > > Sent: Friday, August 23, 2002 10:54 PM
> > > To: ipp at pwg.org; ifx at pwg.org> > > Cc: pwg at 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...>
> > >
> > >
> >
> >
> >
>>