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