Ira, If you look at my solution 2b (way below in this email), you will see
that it does not require the subscription-id space be partitioned. Instead,
each printer can forward to a different URI, which in all cases go to the
same server. However, the URI tells the server which printer did the
forwarding.
In any case, the more I think about this feature, the more it seems to me
that it should be viewed as a proprietary extension. I say this because the
communication between the printer and the notification server is not
specified by IPP. So that part is proprietary. As a result, customers will
not be able to buy a brand A printer and a brand B notification server and
have them to work together.
Only the communication between client and printer/server is potentially
interoperable, and only if all clients perform redirection when they receive
the redirection error code (as opposed to treating it as an error.) But what
is the incentive for client implementers to support this feature? The PWG
seal of approval? It is my guess that IBM will implement a full solution
with a client, a printer and a notification server. I also expect that no
other vendor will implement this feature in either a client, printer or
notification server.
Standard or no standard, if my guess is right, this feature is in reality a
de facto propietary extension --- and an IETF roadblock.
Bob Herriot
----- Original Message -----
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Harry Lewis'" <harryl@us.ibm.com>; "Robert Herriot" <bob@herriot.com>
Cc: "Dennis Carney" <dcarney@us.ibm.com>; <hastings@cp10.es.xerox.com>;
<ipp@pwg.org>
Sent: Friday, August 02, 2002 10:02 AM
Subject: RE: IPP> Re: Last Call comment to remove redirect URL and status
code from IPPGET
> Hi Harry,
>
> You're forgetting how Get-Notifications works. You get back that
> 'printer-uri'
> to the (pseudo-printer) Notification server and _that_ server MUST contain
a
> Subscription object that is still references by the 'subscription-id'
> returned
> by the original simple job subscription.
>
> But the solution is simple - let all of the managed printers that are
> supported
> by one configured Notification server partition their 'subscription-id'
> space
> (each gets say 65,000 subscriptions, which supports 65,000 federated
> printers).
>
> This business of the Subscription object referring to a 'printer-uri' and
> 'job-id' that are NOT on the Notification server is perhaps a bit odd.
>
> Cheers
> - Ira McDonald
>
> PS - Can you guys possibly stop sending HTML email? It takes a _long_
time
> (more than 30 seconds) to open here in MS Outlook 2000 and often gets
> scrambled
> anyway.
>
>
> -----Original Message-----
> From: Harry Lewis [mailto:harryl@us.ibm.com]
> Sent: Thursday, August 01, 2002 5:26 PM
> To: Robert Herriot
> Cc: Dennis Carney; hastings@cp10.es.xerox.com; ipp@pwg.org
> Subject: Re: IPP> Re: Last Call comment to remove redirect URL and status
> code from IPPGET
>
>
>
> 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@herriot.com>
> Sent by: owner-ipp@pwg.org
> 08/01/2002 03:14 PM
> To: <ipp@pwg.org>, Dennis Carney/Boulder/IBM@IBMUS
> cc: <hastings@cp10.es.xerox.com>, Harry
> Lewis/Boulder/IBM@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@us.ibm.com>
> To: <ipp@pwg.org>
> Cc: <hastings@cp10.es.xerox.com>; "Harry Lewis" <harryl@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
> >
> >
> >
> >
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 03:04:21 EDT