In my opinion, the IPP redirect mechanism should still
be included because there are alot of cases and scenarios
where it could be used; security is just one of those
scenarios. I also think that redirection does not constrain
the number of URIs that are supported to just "2". The
server can elect to redirect to whatever URI the server feels
is appropriate for access to the "resource". Of course, the
client can choose not to support the redirected URI, but this
possibility exists in any method we choose wherein a client
may have to deal with a server supporting multiple URIs.
The other scenarios (besides security) involve job redirection,
and/or load balancing scenarios, etc. While we do not have
to specify these capabilities in version 1.0, including the
basic redirect mechanism from the outset in version 1.0 will
allow us to expand in these directions (and others) if we
see a need.
I do agree with the overall need for scalability when it comes
to supporting additional transport mappings, however, but I
feel that redirection will naturally support this, and still allow
publishing of a single URI in directory entries; neither would
it preclude publishing multiple URIs per server if the
administrator wishes to manage this type of situation.
Randy
> -----Original Message-----
> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com]
> Sent: Monday, January 05, 1998 4:00 PM
> To: ipp@pwg.org
> Cc: masinter@parc.xerox.com; manchala@cp10.es.xerox.com;
> xriley@cp10.es.xerox.com
> Subject: IPP> MOD - Outside the box resolution for the two URIs
> issue
>
>
> 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