IPP> Re: Last Call comment to remove redirect URL and status code from IPPGET

IPP> Re: Last Call comment to remove redirect URL and status code from IPPGET

Harry Lewis harryl at us.ibm.com
Thu Aug 1 17:26:24 EDT 2002


2b is OK but not necessary. The printer and the redirect location can have 
whatever private understanding they wish to determine how to concoct the 
redirect uri.
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 




"Robert Herriot" <bob at herriot.com>
Sent by: owner-ipp at pwg.org
08/01/2002 03:14 PM
 
        To:     <ipp at pwg.org>, Dennis Carney/Boulder/IBM at IBMUS
        cc:     <hastings at cp10.es.xerox.com>, Harry Lewis/Boulder/IBM at IBMUS
        Subject:        Re: IPP> Re: Last Call comment to remove redirect URL and status code from 
IPPGET

 

You raise valid points on this issue.  It is best not to revisit closed
issues so late in the process unless there is a bug. I think that the
time-out issue is NOT a bug (details below), but there may be another 
issue
that needs clarification (details at the end of this email).

Some people have commented that the IPP redirection is lacking a time-out
which HTTP does have. However, if I understand RFC 2616 correctly, a
redirection URI is cached by the client only when a Cache-Control or 
Expires
header is present. So the default behavior is that a client does not cache 
a
redirection URI. We could simply add language to ipp-get that redirection
URIs SHOULD NOT be cached. An Expires attribute would make a better
solution, but since only IBM wants this feature, we should keep the 
solution
simple and not change past agreements.

Now that Harry has said that he plans to support this feature, he removes 
my
claim about the feature having no value to anyone. If we keep this feature
then we should leave the ipp-get document unchanged except for the
clarification that I suggested in the previous paragraph and the one I
suggest in the next paragraph.

Now for the other issue with redirection. The Get-Notifications operations
has a printer-uri argument. What is its value for the Get-Notifications
operation to the redirected URI. The ipp-get document is silent on this
issue. Also how does the redirected server know what printer the
subscription-ids apply to? There are two possible solutions.

1) The printer-uri attribute's value is the original printer URI that
responded with the redirection URI. This value tells the redirected server
what printer the subscription-id belong to.

2) The printer-uri attribute's value is the redirection URI (of the
redirected server). In this case either

2a) the subscription-ids must be unique across all printers served by the
redirected server or

2b) the redirection URI must encode the name of the original printer in 
its
URI.

Solution 2b fits in best with the existing architecture.

Bob Herriot





----- Original Message -----
From: "Dennis Carney" <dcarney at us.ibm.com>
To: <ipp at pwg.org>
Cc: <hastings at cp10.es.xerox.com>; "Harry Lewis" <harryl at us.ibm.com>
Sent: Thursday, August 01, 2002 8:20 AM
Subject: IPP> Re: Last Call comment to remove redirect URL and status code
from IPPGET


> At the risk of looking like I'm simply taking Harry's side since he and 
I
> work together, I'm going to comment nonetheless.
>
> This process *does* seem a bit arbitrary to me.  I could probably go 
back
> through (well, maybe not me, but I'm sure Tom could ;-) any document the
> PWG has produced looking for things that "don't look right".  Then I 
could
> bring them up, and possibly get significant support in their
> "not-looking-right-ness".  However, in theory, whatever it is I'm 
bringing
> up has already been discussed and decided upon in the past, by a number 
of
> people who had their heads clearly focused on the task at hand, unlike
now,
> where probably fewer people are paying attention, and even those people
> might not have really had their minds focused on the subject for months
> (years?).
>
> I think if a "problem" is discovered in a document, it should be brought
> up, as Tom did.  However, even if only one person pipes up to explain 
why
> it is not a problem (it's a feature! :-), I would think the conversation
> should end there--a conscious decision was made on the subject and 
opening
> up documents to continual re-editing would seem to be a bad precedent.
>
> If there is real consensus that this redirect mechanism is a "problem",
> sure, let's consider getting rid of it.  But if the consensus is simply
> that we're not sure whether anyone is going to use it, I believe we must
> have more useful things to do with our time than debate this.
>
> Just my 2 cents worth...
>
> Dennis Carney
> IBM Printing Systems
>
>
>
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/20020801/e0398f5d/attachment-0001.html


More information about the Ipp mailing list