Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers

From: "Scott Isaacson" <[email-masked]>
Date: Mon, 01 Jun 1998 14:50:16 -0600

I agree with Josh that the introduction of a new URL scheme (ala "ipp:") would be problematic.  The key here is that IPP has a new "default" port, not a new "must-only-use-the-new-port" port.  As he points out, IPP really is HTTP.  Form processing with HTTP POST does not require a new "form:" URL scheme.

As I understand it, an httpd server is always listening on one or more ports.  The URL for a resource behind that server advertises what the port is: either the default port (no port is included in the URL) or some other port (the port included in the URL).  Therefore, it is up to the client to attempt a connection on the correct port.  You may ask: "If there is a default for IPP and a default for HTTP, then how will the client know which to use?"   I claim that it will never be ambiguous.  The client will always be in the context of making a generic HTTP request or an IPP request and it will be very clear which default to use.

For example, take a URL that does not explicitly specify a port: 

       http://my.domain.com/printer1

- If the client is in the act of printing (browser that is printing or a print only client) the the port to use is the new IPP default port.

- Any other client will use the HTTP default port

Scott

************************************************************
Scott A. Isaacson
Corporate Architect
Novell Inc., M/S PRV-C-121 
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: [email-masked]
web: http://www.novell.com
************************************************************

>>> Josh Cohen <[email-masked]> 06/01 11:51 AM >>>
I think its fine to have a new default dest port 
associated with IPP, but a new URL scheme seems like more
trouble than may be apparent.

For one, even though IPP is a different service than HTTP,
an IPP client *is* speaking HTTP, IMHO.  HTTP is used as
a layer underneath IPP.  So, I think the URL scheme
should continue to be http://..

Using a new URL scheme will certainly break compatibility
with existing proxies.  Proxy server's encountering a new
scheme will fail unless they are modified to understand it.

As I've stated before, I think the best way to differentiate
the service and remain compatible with existing proxy servers
is to use a new method on the request line.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Monday, June 01, 1998 10:31 AM
> To: Carl-Uno Manros; [email-masked] 
> Cc: [email-masked] 
> Subject: IPP> Re: Implications of introducing new scheme and port for
> existing HTTP servers
> 
> 
> Carl-Uno,
> 	By "scheme" in the text below, do you mean a
> new HTTP method, parallel to GET and POST, or something
> else?
> 		regards,
> 			Ted Hardie
> 			NASA NIC
> 
> > 1) the introduction of a new scheme called "ipp"
> > 2) the introduction a new default port number for IPP servers.
> >
> > Before the IPP WG responds to those suggestions, the IPP WG 
> would like to
> > get some advice from the HTTP WG on the implications of 
> such a change.
> > In particular, we want some feedback on how easy or 
> difficult it would be
> > to configure existing web servers to accomodate the 
> suggested changes.
>

---

From: Robert Herriot <[email-masked]>
Date: Mon, 01 Jun 1998 17:01:29 -0700

I have done a few tests with the Java WebServer to see how it works with an 
IPP scheme.  The results are mixed.

I dicovered that the request line has to be of the form:
     POST /servlet/printServer?killtree HTTP/1.0

and the POST fails if it of the form: 
     POST http://woden/servlet/printServer?killtree HTTP/1.0

I found that I can change HTTP/1.0 to IPP/1.0 and things continue to work.  
The method getProtocol returns 'IPP/1.0' instead of 'HTTP/1.0', but the 
value of getScheme remains 'http' regardless of the protocol.   

Since there is no way to specify the scheme, except implicitly in the 
protocol name, the server seems to assume the scheme is http  regardless of 
protocol.

This indicates to me that there is some danger in changing to an IPP scheme 
if we still expect things to work with web servers.

This also raises an important question. If we are changing to an "ipp" 
scheme and a different port, then we have fundamentally changed the protocol 
and that opens up many issues, such as 

    1) do we need for HTTP request line and headers or is everything in IPP?
    2) do we need MIME syntax for wrapping the application/ipp?
    3) should we add separate port for sending data since we are no longer
dependent on HTTP?

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 3 Jun 1998 22:58:26 PDT

> - If the client is in the act of printing (browser that is printing 
> or a print only client) the the port to use is the new IPP default port.
> 

This suggestion is completely unworkable. The default port for
the "http" scheme is 80. It isn't "80 when you use it one way
and something else when you use it another".

I think you can define a new scheme "ipp" and just define it quite
simply:
       ipp://host/path  ===  http://host:ippport/path (used for ipp) 

E.g., if the IPP port is "187" then
        ipp://printer.xerox.com/doit

would be interpreted _exactly_ as

        http://printer.xerox.com:187/doit

This equivalence can be done in the client, and need not be handled
by the proxies at all. Since an ipp client has to know about the rest
of the ipp protocol anyway, requiring the ipp client to do the translation
is not a burden.

---

From: Robert Herriot <[email-masked]>
Date: Thu, 04 Jun 1998 13:04:24 -0700

Larry,

I am still confused about your suggestion, even after much discussion on the 
DL.

When you talk about using an ipp scheme, do you still expect the protocol to 
be HTTP with a request line containing something like "POST  
/servlet/ippservlet/foo  HTTP/1.1"?

If I am correct, then the ipp scheme is not seen by the server (as in my 
example above where it has been stripped).  Does the client strip the ipp or 
does the proxy do it?

It would help if you would state the step by step process for a client to 
send an operation using an ipp scheme to an HTTP server.

Bob Herriot