What's wrong with accepting the spec like it is (was?)?
I certainly hope that "IBM is ahead of the curve" with redirection and
that others will find it useful... but even if that doesn't come to
pass... since when has an "anomaly" test been the guiding light for IPP?
For example, how many vendors have implemented PDL override? (PWG f2f
informal show of hands yesterday tally = 1). What about document and page
exceptions? Do we want to begin listing all the IPP "features" that were
not unanimous or are not found to be practical in the majority of vendor
minds? That would be revealing.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Robert Herriot" <bob at herriot.com>
08/28/2002 03:42 AM
To: "Carl" <carl at manros.com>, Harry Lewis/Boulder/IBM at IBMUS
cc: "Hastings, Tom N" <hastings at cp10.es.xerox.com>, <ipp at pwg.org>
Subject: Re: IPP> Re: IFX> Attempt to close on the two Notification specs at
theface to face meetings
We seem to be going in circles. So, the question is where do we go from
here?
Carl Kugler gives an excellent scenario that requires both printer and
client to support redirection.
It would seem that other printer vendors should have the same issue as
IBM. Yet no one has mentioned it. Why is that? Has no other vendor begun
implementing ipp-get? Do other printers not have the connection
limitations?
Michael Sweet has said that his software does not support redirection (I
assume this includes the client and server). If most printer vendors were
finding redirection a necessity, would he reconsider his position for
clients?
The "optimal-target-uri" solution proposed by Tom and Ira doesn't solve
Carl Kugler's problem. I think that it should be dropped.
So, there is one essential issue that we need to resolve in order make
progress. Is IBM's ipp-get implementation an anomaly that is unlike all
other vendors, or is IBM ahead of the curve and has discovered what every
other printer vendor will discover during the implementation of ipp-get --
the need for redirection?
Bob Herriot
----- Original Message -----
From: Harry Lewis
To: Carl
Cc: Robert Herriot ; Hastings, Tom N ; ipp at pwg.org
Sent: Tuesday, August 27, 2002 10:27 PM
Subject: RE: IPP> Re: IFX> Attempt to close on the two Notification specs at
theface to face meetings
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
----------------------------------------------
"Carl" <carl at manros.com>
Sent by: owner-ipp at pwg.org
08/27/2002 04:45 PM
To: "Hastings, Tom N" <hastings at cp10.es.xerox.com>, "Robert Herriot" <bob at herriot.com>, Harry Lewis/Boulder/IBM at IBMUS
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
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...>
> > >
> > >
> >
> >
> >
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/20020828/a4587e97/attachment-0001.html