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

From: [email-masked] (Robert Herriot)
Date: 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 [email-masked] Thu Nov 13 07:06:50 1997
> To: [email-masked]
> 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" <[email-masked]>
> Sender: [email-masked]
> 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       <[email-masked]>
> Agranat Systems, Inc.        Engineering            http://www.agranat.com/
>

---

From: "Turner, Randy" <[email-masked]>
Date: 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:[email-masked]]
> Sent:	Thursday, November 13, 1997 2:13 PM
> To:	Turner, Randy; [email-masked]
> Cc:	[email-masked]
> 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:   [email-masked]          --
> --  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: [email-masked] [SMTP:[email-masked]]
> > > Sent: Thursday, November 13, 1997 12:36 PM
> > > To:   [email-masked]; [email-masked]
> > > Subject:      Re: IPP> Minutes of IPP Weekly Conference call -
> Nove.
> > > 12, 1997
> > >
> > > > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove.
> 12,
> > > 1997
> > > > RKD> 9) If a client somehow derives a URI and tries to connect
> and
> > > the
> > > >   error.  Just let TCP do the right thing - if they've
> constructed
> > > an