Randy
> -----Original Message-----
> From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM]
> Sent: Thursday, November 13, 1997 12:36 PM
> To: ipp@pwg.org; lawrence@agranat.com
> Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove.
> 12, 1997
>
> 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/
> >