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:=20
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=20
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: sisaacson at novell.com
web: http://www.novell.com
************************************************************
>>> Josh Cohen <joshco at microsoft.com> 06/01 11:51 AM >>>
I think its fine to have a new default dest port=20
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: hardie at thornhill.arc.nasa.gov=20
> [mailto:hardie at thornhill.arc.nasa.gov]=20
> Sent: Monday, June 01, 1998 10:31 AM
> To: Carl-Uno Manros; http-wg at hplb.hpl.hp.com=20
> Cc: ipp at pwg.org=20
> Subject: IPP> Re: Implications of introducing new scheme and port for
> existing HTTP servers
>=20
>=20
> 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
>=20
> > 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=20
> would like to
> > get some advice from the HTTP WG on the implications of=20
> such a change.
> > In particular, we want some feedback on how easy or=20
> difficult it would be
> > to configure existing web servers to accomodate the=20
> suggested changes.
>=20