I have a concern about the proposal for printer-uri-supported.
In our current model, there are at most 2 URIs, one for HTTP and the
other for HTTPS. With my proposed printer-alt-uri, the client knows
that it can access the URI specified by printer-alt-uri via the
alternate mechanism, e.g. TLS if the client obtained the URI via HTTP.
With the new more general mechanism that you are suggesting, a printer
could have many URIs, but a client has no way to determine what
mechanism should be used for each member of the printer-uri-supported.
So this is an incomplete mechanism which I don't suggest we complete at
this stage. In addition, for the current HTTP/HTTPS model, the client
must determine the alternate printer URI by finding the URI not equal
to the one it knows about. This is more difficult than getting the value of
printer-alt-uri.
So, printer-uri-supported is certainly the more general solution and
it may be better in the future if we add another attribute to
indicate the mechanism associated with the URI. But, in the context
of version 1.0, it just adds complexity.
Bob Herriot
> From hastings at cp10.es.xerox.com Tue Jan 6 13:14:44 1998
> X-Sender: hastings at garfield> X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
> Date: Tue, 6 Jan 1998 12:40:48 PST
> To: Carl-Uno Manros <cmanros at cp10.es.xerox.com>, ipp at pwg.org> From: Tom Hastings <hastings at cp10.es.xerox.com>
> Subject: Re: IPP> MOD - Outside the box resolution for the two URIs
> issue
> Cc: masinter at parc.xerox.com, manchala at cp10.es.xerox.com,
>xriley at cp10.es.xerox.com> In-Reply-To: <3.0.1.32.19980105155939.00ae8c90 at garfield>
> Mime-Version: 1.0
> Sender: ipp-owner at pwg.org> X-Lines: 58
>> Refining this proposal a bit (after discussions with Scott and Carl-Uno):
>> The changes to the current Model document would be:
>> 1. Remove the "printer-tls-uri" attribute from the Printer object and
> the directory.
> 2. Rename the "printer-uri" Printer and Directory attribute to
> "printer-uri-supported" and make it multi-valued, i.e., 1setOf uri.
> 3. Keep the "printer-uri" Operation attribute as a single-valued
> attribute that is the uri being used on this operation. Thus its single
> value is just like the single value of the "document-format" operation
> attribute, i.e., one of the values of the curresponding "xxx-suported"
> attribute ("printer-uri-supuported" in this case).
>>> At 15:59 01/05/1998 PST, Carl-Uno Manros wrote:
> >
> >I got some private feedback from Larry Mainter on this issue, which
> >triggered some further thoughts that I wanted to share with you.
> >
> >I like Bob's approach because it provides the functionality within IPP,
> >while Randy's approach might be easier to implement, but makes us dependent
> >on HTTP functionality for redirects, which may not be available in other
> >transfer protocols.
> >
> >Maybe we should think outside the box instead. Larry asked why do we limit
> >ourselves to TWO URIs? Thinking about extensibility, I think Larry has a
> >point.
> >
> >If we want to add a new mapping for IPP on top of HTTP NG or whatever and
> >the IPP server can support both that and the current HTTP and HTTPS
> >mappings, where do we put the additional URI in the IPP protocol? If
> >instead, we made the Printer URI a MULTI-VALUED attribute, we could add any
> >number of future transfer protocols for the same IPP Printer without having
> >to revise our model. The IPP client would probably need to understand the
> >scheme part of the URI, but could then choose any of the offered URI
> >alternatives, with more or less security etc. We would probably need to add
> >some rules about whether the same transfer protocol has to be used for a
> >particular IPP Job, or if the client can use different ones, provided that
> >the same level of security is maintained. Another question is whether the
> >IPP Server would always return Job URIs with the same scheme as the one
> >with which the job request was submitted. A consequence of this propoal is
> >that directory entries might have multiple URIs for the same IPP Printer.
> >
> >Is this approach worth further discussion?
> >
> >Carl-Uno
> >
> >
> >
> >
> >Carl-Uno Manros
> >Principal Engineer - Advanced Printing Standards - Xerox Corporation
> >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> >Phone +1-310-333 8273, Fax +1-310-333 5514
> >Email: manros at cp10.es.xerox.com> >
> >
>