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

Turner, Randy (rturner@sharplabs.com)
Thu, 13 Nov 1997 14:28:10 -0800

There was a proposal to handle situations like the one
expressed by Roger in his minutes, but others on
the conference felt like we were trying to spec too
much on how the servers handle every possible
error (or error code). So we just said that the server
will do the appropriate thing, depending upon which
layer of the overall protocol stack at which a particular
problem occurred...I think this is where we left it.

Randy

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