Subject: RE: IPP> MOD - Outside the box resolution for the two URIs issue

From: "Turner, Randy" <[email-masked]>
Date: Mon, 5 Jan 1998 16:19:33 -0800

If you read my earlier more detailed proposal you will
see that I put the redirection mechanism into IPP, so
it is not dependent on HTTP-specific redirection
mechanisms.

Randy

> -----Original Message-----
> From:	Carl-Uno Manros [SMTP:[email-masked]]
> Sent:	Monday, January 05, 1998 4:00 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked];
> [email-masked]
> 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: [email-masked]

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 5 Jan 1998 16:37:30 -0800

Another comment...

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

---

From: [email-masked] (Robert Herriot)
Date: Tue, 6 Jan 1998 19:40:53 -0800

You ask a question that I have wondered about too.  I think that
the attribute for the other URI is there "just in case" some
client needs it. But we aren't sure that any client will ever need it.

Perhaps our reasoning should instead be: "leave it out until we find a
problem needing this solution". In that case, we don't need either
printer-alt-uri or printer-uri-supported. Printer-uri suffices.

Bob Herriot

> From [email-masked] Tue Jan  6 18:10:25 1998
> Date: Tue, 6 Jan 1998 18:11:22 PST
> From: Larry Masinter <[email-masked]>
> Organization: Xerox PARC
> X-Mailer: Mozilla 4.04 [en] (Win95; U)
> MIME-Version: 1.0
> To: Robert Herriot <Robert.Herriot@Eng>
> CC: [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked]
> Subject: Re: IPP> MOD - Outside the box resolution for the two URIs
> 	  issue
> References: <[email-masked]>
> Content-Transfer-Encoding: 7bit
> X-Lines: 9
> 
> You know, I still haven't understood why you need more than one
> URI. A printer is a resource. The URI is a resource identifier.
> A URL is a resource locator, and determines the access method
> by the scheme. So why do you need a resource to know about other
> access methods for the same resource?
> 
> Larry
> -- 
> http://www.parc.xerox.com/masinter
>

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 06 Jan 1998 19:12:45 -0800

>access methods for the same resource?

Larry,

The problem is that HTTP without TLS and HTTP with TLS are using two 
different schemes. We have specified that the URL resource locator part 
of the URI SHOULD be the same, but you might for instance have different 
ports for the two schemes, which would result in differences.

BTW has there been any discussion in the W3C HTTP NG project about
whether it would share the scheme with the current HTTP or be a totally
new scheme?

Carl-Uno