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

From: [email-masked] (Robert Herriot)
Date: Thu, 13 Nov 1997 14:30:44 -0800

I am agreeing with Scott.

> From [email-masked] Thu Nov 13 14:27:22 1997
> Date: Thu, 13 Nov 1997 17:13:22 -0500
> From: Jay Martin <[email-masked]>
> Organization: Underscore, Inc.
> X-Mailer: Mozilla 4.02 [en] (WinNT; I)
> MIME-Version: 1.0
> To: "Turner, Randy" <[email-masked]>, Robert.Herriot@Eng
> CC: [email-masked]
> Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997
> References: <[email-masked]>
> Content-Transfer-Encoding: 7bit
> Sender: [email-masked]
> X-Lines: 73
> 
> 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
> > >
> > > 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: "Steve Zilles" <[email-masked]>
Date: Thu, 13 Nov 1997 15:19:37 PST

At the risk of muddying the waters and in an attempt to agree with
Scott, Randy and Bob, I offer the following statement for clarification:

If an IPP printer responds to any protocol when an attempt to use the
protocol is made, then the responses to that protocol should be
conforming responses.

By this it is meant that
(a) a printer does not need to respond to any attempt to use any
protocol on any port that the printer is not supporting.
(b) if the printer is capable of doing the protocol (say HTTP), but an
administrator has configured the printer to not authorized use of that
protocol, then the printer may either refuse to participate in the
protocol or give an appropriate error message for that protocol. In the
case of HTTP, the printer might respond with an error message 401 - Not
Authorized.