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

Jay Martin (jkm@underscore.com)
Thu, 13 Nov 1997 17:13:22 -0500

Sorry, but I can't tell whether both Randy and Bob are agreeing
with Scott or not.

Can someone make a *brief* statement on this issue in which the
comments made by Scott are addressed? Thanks in advance.

...jay

----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------

Turner, Randy wrote:
>
> My recollection is the same as Bob's....
>
> 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/
> > >