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@cp10.es.xerox.com
>
>