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 at underscore.com]
> Sent: Thursday, November 13, 1997 2:13 PM
> To: Turner, Randy; Robert.Herriot at Eng.Sun.COM> Cc: ipp at 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 at 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 at Eng.Sun.COM [SMTP:Robert.Herriot at Eng.Sun.COM]
> > > Sent: Thursday, November 13, 1997 12:36 PM
> > > To: ipp at pwg.org; lawrence at 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 at agranat.com Thu Nov 13 07:06:50 1997
> > > > To: ipp at 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 at agranat.com>
> > > > Sender: ipp-owner at 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 at agranat.com>
> > > > Agranat Systems, Inc. Engineering
> > > http://www.agranat.com/> > > >