If we are using HTTP we should say so in the URL - i.e. http:.............
What is the point of saying IPP:.... if we are actually sending HTTP. This
seems to be neither one thing or another.
> -----Original Message-----
> From: Scott Isaacson [SMTP:SISAACSON@novell.com]
> Sent: Monday, June 01, 1998 1:50 PM
> To: manros@cp10.es.xerox.com; http-wg@hplb.hpl.hp.com; Josh Cohen;
> hardie@nic.nasa.gov
> Cc: moore@cs.utk.edu; ipp@pwg.org
> Subject: RE: IPP> Re: Implications of introducing new scheme and port
> for existing HTTP servers
>
> 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: sisaacson@novell.com
> web: http://www.novell.com
> ************************************************************
>
>
> >>> Josh Cohen <joshco@microsoft.com> 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: hardie@thornhill.arc.nasa.gov
> > [mailto:hardie@thornhill.arc.nasa.gov]
> > Sent: Monday, June 01, 1998 10:31 AM
> > To: Carl-Uno Manros; http-wg@hplb.hpl.hp.com
> > Cc: ipp@pwg.org
> > 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.
> >