Doesnt changing scheme from 'HTTP' to 'IPP' mean that we should stop using
HTTP wire representation.
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 at novell.com]
> Sent: Monday, June 01, 1998 1:50 PM
> To: manros at cp10.es.xerox.com; http-wg at hplb.hpl.hp.com; Josh Cohen;
>hardie at nic.nasa.gov> Cc: moore at cs.utk.edu; ipp at 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 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
> 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> > [mailto:hardie at thornhill.arc.nasa.gov]
> > Sent: Monday, June 01, 1998 10:31 AM
> > To: Carl-Uno Manros; http-wg at hplb.hpl.hp.com> > Cc: ipp at 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.
> >