IPP> Re: Implications of introducing new scheme and port

IPP> Re: Implications of introducing new scheme and port

Scott Isaacson SISAACSON at novell.com
Mon Jun 1 16:50:16 EDT 1998


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



More information about the Ipp mailing list