IPP Mail Archive: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997

Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997

Robert Herriot (Robert.Herriot@Eng.Sun.COM)
Thu, 13 Nov 1997 12:36:00 -0800

My recollection of the discussion was that we agreed that the client
should get standard TCP/IP and HTTP behavior for situations best
handled by those layers.

> From lawrence@agranat.com Thu Nov 13 07:06:50 1997
> To: ipp@pwg.org
> Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997
> In-reply-to: <5030100013266059000002L092*@MHS>
> Date: Thu, 13 Nov 1997 09:41:24 -0500
> From: "Scott Lawrence" <lawrence@agranat.com>
> Sender: ipp-owner@pwg.org
> Content-Length: 1051
> X-Lines: 21
>
>
> The agreement Roger describes sounds good; one minor nit...
>
> RKD> 9) If a client somehow derives a URI and tries to connect and the
> RKD> service (e.g. Printer-URI) has been turned-off, an appropriate
> RKD> http error code will be returned.
>
> Why impose that requirement? That would mean that a printer without
> security (for whatever reason) would need to listen on the TLS port
> and implement enough of the handshake to negotiate no security so
> that it can send an HTTP error. Similarly, a secure-only server
> would need to listen on the unsecured port just to send an HTTP
> error. Just let TCP do the right thing - if they've constructed an
> invalid URI (one with the wrong scheme or port number in it), then
> it won't work, which is what should happen. It really isn't the
> business of the IPP spec to say what will happen on a TCP port on
> which IPP is not available.
>
> --
> Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com>
> Agranat Systems, Inc. Engineering http://www.agranat.com/
>