From ippdev-archive Wed Nov 5 20:31:48 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06433 for ippdev-outgoing; Wed, 5 Nov 1997 20:28:13 -0500 (EST) Mime-Version: 1.0 Date: Wed, 5 Nov 1997 13:43:40 -0500 Message-ID: <0002BCE7.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: IPPDEV> IBM's IPP implementation To: ippdev@pwg.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ippdev-owner@pwg.org Precedence: bulk RE: IBM's IPP prototype code at www.printers.com/ipp/ipp.html which OS/platform is it for? Philip Thambidurai From ippdev-archive Thu Nov 6 11:01:59 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12500 for ippdev-outgoing; Thu, 6 Nov 1997 11:01:08 -0500 (EST) From: Carl Kugler To: Subject: Re: IPPDEV> IBM's IPP implementation Message-ID: <5030100012630364000002L042*@MHS> Date: Thu, 6 Nov 1997 11:01:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ippdev-owner@pwg.org Precedence: bulk It's Java 1.1.x. Tested on Windows NT 4.0 and AIX 4.1.2. BTW, it's a client for the IPP as it was in August or September; no SS= L, some (now) mandatory internationalization not implemented. -Carl Kugler ippdev-owner@pwg.org on 11/05/97 06:32:22 PM Please respond to ippdev-owner@pwg.org @ internet To: ippdev@pwg.org @ internet cc: Subject: IPPDEV> IBM's IPP implementation RE: IBM's IPP prototype code at www.printers.com/ipp/ipp.html which OS/platform is it for? Philip Thambidurai = From ippdev-archive Thu Nov 6 11:16:59 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12663 for ippdev-outgoing; Thu, 6 Nov 1997 11:15:46 -0500 (EST) From: Carl Kugler To: Message-ID: <5030100012632065000002L052*@MHS> Date: Thu, 6 Nov 1997 11:15:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ippdev-owner@pwg.org Precedence: bulk I still wish we had some kind of magic number or string to identify val= id IPP messages with high confidence. Talking IPP through off-the-shelf Web s= ervers we sometimes see this kind of thing: HTTP/1.1 200 Document follows. \r\n Server: XXXXXXXXXXXXX\r\n Date: Wed, 05 Nov 1997 16:30:37 GMT\r\n Accept-Ranges: bytes\r\n Content-Type: text/html\r\n Content-Length: 190\r\n Last-Modified: Wed, 05 Nov 1997 16:30:37 GMT\r\n \r\n \n \n Error\n \n \n

Error 500

\n \n Internal error\n \n


XXXXXXXXXXX Server X.X.X.X \n \n \n Error

Error 501

The requ= est is not valid or not recognized "INVALID-METHOD"


XXXXXXXXXXXXXXXX Server XXXXX
Even though there was an Error 500 in the server, the response has been= wrapped in a document and sent with return code 200. So the IPP client has app= ly various heuristics to see if it has got a good IPP response. And even when there isn't an internal error in the server we often see = this: HTTP/1.1 200 OK\r\n Server: XXXXXXXXXXXXXXXXXXXX\r\n Date: Wed, 5 Nov 1997 16:40:10 GMT\r\n Content-Type: application/ipp\r\n Last-Modified: Wed, 5 Nov 1997 16:40:10 GMT\r\n Content-Length: 126\r\n \r\n \r\n \r\n \x01\x00\x00\x00\x02*\x00\bjob-name\x00\x04 Job1*\x00\tjob-state\x00\x04Job1*\x00\x00\x00\x04Job2*\x00\x11job-state= -reasons\x00\x04Job1*\x00\x11job-state-message\x00\x02YO\x05)\x00\x05si= des\x00\x0bunsupported\x03 Notice all the CRLF pairs following the HTTP header. So the client aga= in is forced to use heuristics, and I hope we never get to version 13.10, bec= ause the start of the IPP message will look just like another CRLF! Does anyone have a good algorithm worked out for determining the validi= ty of an IPP response and finding the true start of the message? Will this problem go away with mandatory SSL V3 "framing"? -Carl Kugler = From ippdev-archive Thu Nov 6 13:02:09 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17063 for ippdev-outgoing; Thu, 6 Nov 1997 13:01:20 -0500 (EST) Message-Id: <199711061757.MAA19633@intranet.xionics.com> X-Mailer: exmh version 1.6.9 8/22/96 To: ippdev@pwg.org cc: jperry@xionics.com Subject: IPPDEV> IBM prototype Reply-to: jperry@xionics.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Nov 1997 13:05:03 -0500 From: Jeffrey Perry Sender: ippdev-owner@pwg.org Precedence: bulk Is anyone else having problems reaching the website listed? http://www.printers.com/ipp/ipp.html Is the prototype still at this location? Jeffrey Perry Xionics Document Technologies From ippdev-archive Thu Nov 6 14:33:04 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20242 for ippdev-outgoing; Thu, 6 Nov 1997 14:17:40 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPPDEV> IBM prototype Message-ID: <5030100012652585000002L052*@MHS> Date: Thu, 6 Nov 1997 14:17:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ippdev-owner@pwg.org Precedence: bulk Should be: http://www.printers.ibm.com/ipp/ipp.html -Carl Kugler Please respond to jperry@xionics.com @ internet To: ippdev@pwg.org @ internet cc: jperry@xionics.com @ internet Subject: IPPDEV> IBM prototype Is anyone else having problems reaching the website listed? http://www.printers.com/ipp/ipp.html Is the prototype still at this location? Jeffrey Perry Xionics Document Technologies = From ippdev-archive Thu Nov 6 16:07:02 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21346 for ippdev-outgoing; Thu, 6 Nov 1997 16:02:51 -0500 (EST) From: dalew@truespectra.com (Dale Wick) Cc: ippdev@pwg.org Message-ID: <1997Nov06.145152.1896.58835@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Thu, 06 Nov 1997 16:11:32 -0500 Subject: Re: IPPDEV> IBM prototype Sender: ippdev-owner@pwg.org Precedence: bulk The correct URL is: http://www.printers.ibm.com/ipp/ipp.html Dale -- Dale Wick, Sr Programmer/Analyst TrueSpectra Inc., Toronto, Ontario, Canada "Excellence in Graphics" From ippdev-archive Thu Nov 6 16:37:15 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22277 for ippdev-outgoing; Thu, 6 Nov 1997 16:34:40 -0500 (EST) Date: Thu, 6 Nov 1997 13:32:43 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711062132.NAA02276@woden.eng.sun.com> To: ippdev@pwg.org, kugler@us.ibm.com Subject: IPPDEV> Re: magic number X-Sun-Charset: US-ASCII Sender: ippdev-owner@pwg.org Precedence: bulk I am surprised by your first example. When I snooped the network traffic for the same URL, I got a 500 error, though it came from a local proxy. If you got a 200 by snooping, then that seems like an error. If such is really possible then this seems like yet another problem with choosing to layer on top of HTTP. But even if this response can really happen, doesn't the string 'Content-Type: text/html' act as a magic number and indicate to the client that there something unexpected because the expected Content-Type is application/ipp? The client, without and HTML displayer cannot tell the user what the problem is, but it is certainly an error. Also, why were so many there so many '\r\n's in your second example? You imply that this is a real example, but my reading of RFC2068 is that the entity immediately follows the empty line, so the additional '\r\n' are part of the application/ipp entity which is an error. But I see your point that if there are buggy clients and servers out there, these extra characters would look like version 13.8 and might be valid eventually. So you may have a point about magic numbers. Bob Herriot > From kugler@us.ibm.com Thu Nov 6 08:15:56 1997 > > I still wish we had some kind of magic number or string to identify valid IPP > messages with high confidence. Talking IPP through off-the-shelf Web servers > we sometimes see this kind of thing: > > HTTP/1.1 200 Document follows. \r\n > Server: XXXXXXXXXXXXX\r\n > Date: Wed, 05 Nov 1997 16:30:37 GMT\r\n > Accept-Ranges: bytes\r\n > Content-Type: text/html\r\n > Content-Length: 190\r\n > Last-Modified: Wed, 05 Nov 1997 16:30:37 GMT\r\n > \r\n > \n > \n > Error\n > \n > \n >

Error 500

\n > \n > Internal error\n > \n >


XXXXXXXXXXX Server X.X.X.X
\n > \n > \n > Error

Error 501

The request is > not valid or not recognized "INVALID-METHOD"


XXXXXXXXXXXXXXXX Server > XXXXX
> > Even though there was an Error 500 in the server, the response has been wrapped > in a document and sent with return code 200. So the IPP client has apply > various heuristics to see if it has got a good IPP response. > > And even when there isn't an internal error in the server we often see this: > > HTTP/1.1 200 OK\r\n > Server: XXXXXXXXXXXXXXXXXXXX\r\n > Date: Wed, 5 Nov 1997 16:40:10 GMT\r\n > Content-Type: application/ipp\r\n > Last-Modified: Wed, 5 Nov 1997 16:40:10 GMT\r\n > Content-Length: 126\r\n > \r\n > \r\n > \r\n > \x01\x00\x00\x00\x02*\x00\bjob-name\x00\x04 > Job1*\x00\tjob-state\x00\x04Job1*\x00\x00\x00\x04Job2*\x00\x11job-state-reasons\x00\x04Job1*\x00\x11job-state-message\x00\x02YO\x05)\x00\x05sides\x00\x0bunsupported\x03 > > Notice all the CRLF pairs following the HTTP header. So the client again is > forced to use heuristics, and I hope we never get to version 13.10, because the > start of the IPP message will look just like another CRLF! > > Does anyone have a good algorithm worked out for determining the validity of an > IPP response and finding the true start of the message? > > Will this problem go away with mandatory SSL V3 "framing"? > > -Carl Kugler From ippdev-archive Fri Nov 7 12:52:15 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21728 for ippdev-outgoing; Fri, 7 Nov 1997 12:48:28 -0500 (EST) From: Carl Kugler To: Cc: Subject: IPPDEV> Re: magic number Message-ID: <5030100012744899000002L092*@MHS> Date: Fri, 7 Nov 1997 12:48:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ippdev-owner@pwg.org Precedence: bulk My first example results from a feature of our web server that allows administrators to customize the error messages the server returns to cl= ients when an error condition is encountered. Instead of returning a raw err= or 500 to the client, the server generates an HTML document describing the err= or. I agree that verifying Content-Type =3D=3D application/ipp is a useful va= lidity check in this case. The second example, HTTP/1.1 200 OK\r\n Server: XXXXXXXXX\r\n Date: Fri, 7 Nov 1997 17:27:48 GMT\r\n Content-Type: application/ipp\r\n Last-Modified: Fri, 7 Nov 1997 17:27:48 GMT\r\n Content-Length: 126\r\n \r\n \r\n \r\n \x01\x00\x00\x00\x02*\x00\bjob-name\x00\x04Job1*\x00\t job-state\x00\x04Job1*\x00\x00\x00\x04Job2*\x00\x11job-state-reasons\x0= 0\x04Job1*\x00\x11job-state-message\x00\x02YO\x05)\x00\x05sides\x00\x0b= unsupported\x03 seems to be the kind of thing RFC2068 is talking about here: In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, i= f the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. Fielding, et. al. Standards Track [Page 30= ]*, RFC 2068 HTTP/1.1 January 199= 7 Note: certain buggy HTTP/1.0 client implementations generate an extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client must not preface or follo= w a request with an extra CRLF. except that in this case it's the server generating extra CRLF's. I ag= ree that it shouldn't, but this is an example of a real-world problem encountere= d with a commercial off-the-shelf web server. -Carl Robert.Herriot@Eng.Sun.COM on 11/06/97 02:34:51 PM Please respond to Robert.Herriot@Eng.Sun.COM @ internet To: Carl Kugler/Boulder/IBM@ibmus, ippdev@pwg.org @ internet cc: Subject: Re: magic number I am surprised by your first example. When I snooped the network traffic for the same URL, I got a 500 error, though it came from a local proxy. If you got a 200 by snooping, then that seems like an error. If such is really possible then this seems like yet another problem with choosing to layer on top of HTTP. But even if this response can really happen, doesn't the string 'Content-Type: text/html' act as a magic number and indicate to the client that there something unexpected because the expected Content-Type is application/ipp? The client, without and HTML displayer cannot tell the user what the problem is, but it is certainly= an error. Also, why were so many there so many '\r\n's in your second example? You imply that this is a real example, but my reading of RFC2068 is that the entity immediately follows the empty line, so the additional '\r\n' are part of the application/ipp entity which is an error. But I= see your point that if there are buggy clients and servers out there, these extra characters would look like version 13.8 and might be valid eventually. So you may have a point about magic numbers. Bob Herriot > From kugler@us.ibm.com Thu Nov 6 08:15:56 1997 > > I still wish we had some kind of magic number or string to identify v= alid IPP > messages with high confidence. Talking IPP through off-the-shelf Web= servers > we sometimes see this kind of thing: > > HTTP/1.1 200 Document follows. \r\n > Server: XXXXXXXXXXXXX\r\n > Date: Wed, 05 Nov 1997 16:30:37 GMT\r\n > Accept-Ranges: bytes\r\n > Content-Type: text/html\r\n > Content-Length: 190\r\n > Last-Modified: Wed, 05 Nov 1997 16:30:37 GMT\r\n > \r\n > \n > \n > Error\n > \n > \n >

Error 500

\n > \n > Internal error\n > \n >


XXXXXXXXXXX Server X.X.X.X \n > \n > \n > Error

Error 501

The re= quest is > not valid or not recognized "INVALID-METHOD"


http://karlk.penn.boulder.ibm.com:8080/">XXXXXXXXXXXXXXXX Server > XXXXX
> > Even though there was an Error 500 in the server, the response has be= en wrapped > in a document and sent with return code 200. So the IPP clie= nt has apply > various heuristics to see if it has got a good IPP response. > = > And even when there isn't an internal error in the server we often see this= : > > HTTP/1.1 200 OK\r\n > Server: XXXXXXXXXXXXXXXXXXXX\r\n > Date: Wed, 5 N= ov 1997 16:40:10 GMT\r\n > Content-Type: application/ipp\r\n > Last-Modified: W= ed, 5 Nov 1997 16:40:10 GMT\r\n > Content-Length: 126\r\n > \r\n > \r\n > \r\n > \x01\x00\x00\x00\x02*\x00\bjob-name\x00\x04 > Job1*\x00\tjob-state\x00\x04Job1*\x00\x00\x00\x04Job2*\x00\x11job-state= -reasons\ x00\x04Job1*\x00\x11job-state-message\x00\x02YO\x05)\x00\x05sides\x00\x= 0bunsuppo rted\x03 > > Notice all the CRLF pairs following the HTTP header. So t= he client again is > forced to use heuristics, and I hope we never get to = version 13.10, because the > start of the IPP message will look just like anoth= er CRLF! > > Does anyone have a good algorithm worked out for determining the val= idity of an > IPP response and finding the true start of the message? > > Will t= his problem go away with mandatory SSL V3 "framing"? > > -Carl Kugler = From ippdev-archive Fri Nov 7 16:12:19 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22536 for ippdev-outgoing; Fri, 7 Nov 1997 16:10:29 -0500 (EST) Message-ID: <3463838A.B89A4174@underscore.com> Date: Fri, 07 Nov 1997 16:09:30 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Carl Kugler CC: Robert.Herriot@Eng.Sun.COM, ippdev@pwg.org Subject: Re: IPPDEV> Re: magic number References: <5030100012744899000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippdev-owner@pwg.org Precedence: bulk Carl, Please don't leave us hanging: > except that in this case it's the server generating extra CRLF's. I agree that > it shouldn't, but this is an example of a real-world problem encountered with a > commercial off-the-shelf web server. Which "off-the-shelf" web server is exhibiting this rogue behavior? ...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 -- ---------------------------------------------------------------------- From ippdev-archive Fri Nov 7 18:32:27 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27530 for ippdev-outgoing; Fri, 7 Nov 1997 18:30:04 -0500 (EST) Date: Fri, 7 Nov 1997 15:28:21 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711072328.PAA06903@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, kugler@us.ibm.com Subject: Re: IPPDEV> Re: magic number Cc: ippdev@pwg.org X-Sun-Charset: US-ASCII Sender: ippdev-owner@pwg.org Precedence: bulk In your first example below, you justify its behavior by saying that it provides some HTML text to describe the error, but the proxy I deal with generated similar HTML but it also returned a status of 500 which seems more accurate than a 200 status that yours generates. With regard to your quote about extra CRLF before Request-Lines, that quote applies to CRLFs preceding the "HTTP/1.1 200 OK CRLF" and not to extra CRLFs before the message body. All the language that I can find in RFC 2068 says that the message-body must start immediately after an empty line (i.e. one with just CRLF). So it would seem to me that this server is nonconforming. Bob Herriot > From kugler@us.ibm.com Fri Nov 7 09:48:50 1997 > > My first example results from a feature of our web server that allows > administrators to customize the error messages the server returns to clients > when an error condition is encountered. Instead of returning a raw error 500 > to the client, the server generates an HTML document describing the error. I > agree that verifying Content-Type == application/ipp is a useful validity check > in this case. > > The second example, > > HTTP/1.1 200 OK\r\n > Server: XXXXXXXXX\r\n > Date: Fri, 7 Nov 1997 17:27:48 GMT\r\n > Content-Type: application/ipp\r\n > Last-Modified: Fri, 7 Nov 1997 17:27:48 GMT\r\n > Content-Length: 126\r\n > \r\n > \r\n > \r\n > \x01\x00\x00\x00\x02*\x00\bjob-name\x00\x04Job1*\x00\t > job-state\x00\x04Job1*\x00\x00\x00\x04Job2*\x00\x11job-state-reasons\x00\x04Job1*\x00\x11job-state-message\x00\x02YO\x05)\x00\x05sides\x00\x0bunsupported\x03 > > seems to be the kind of thing RFC2068 is talking about here: > > In the interest of robustness, servers SHOULD ignore any empty > line(s) received where a Request-Line is expected. In other words, if > the server is reading the protocol stream at the beginning of a > message and receives a CRLF first, it should ignore the CRLF. > Fielding, et. al. Standards Track [Page 30]*, > RFC 2068 HTTP/1.1 January 1997 > Note: certain buggy HTTP/1.0 client implementations generate an > extra CRLF's after a POST request. To restate what is explicitly > forbidden by the BNF, an HTTP/1.1 client must not preface or follow > a request with an extra CRLF. > > except that in this case it's the server generating extra CRLF's. I agree that > it shouldn't, but this is an example of a real-world problem encountered with a > commercial off-the-shelf web server. > > -Carl > > > > > > Robert.Herriot@Eng.Sun.COM on 11/06/97 02:34:51 PM > Please respond to Robert.Herriot@Eng.Sun.COM @ internet > To: Carl Kugler/Boulder/IBM@ibmus, ippdev@pwg.org @ internet > cc: > Subject: Re: magic number > > I am surprised by your first example. When I snooped the network > traffic for the same URL, I got a 500 error, though it came from a > local proxy. If you got a 200 by snooping, then that seems like an > error. If such is really possible then this seems like yet another > problem with choosing to layer on top of HTTP. > > But even if this response can really happen, doesn't the string > 'Content-Type: text/html' act as a magic number and indicate to the > client that there something unexpected because the expected > Content-Type is application/ipp? The client, without and HTML > displayer cannot tell the user what the problem is, but it is certainly > an error. > > Also, why were so many there so many '\r\n's in your second example? > You imply that this is a real example, but my reading of RFC2068 is > that the entity immediately follows the empty line, so the additional > '\r\n' are part of the application/ipp entity which is an error. But I > see your point that if there are buggy clients and servers out there, > these extra characters would look like version 13.8 and might be valid > eventually. So you may have a point about magic numbers. > > Bob Herriot > > From kugler@us.ibm.com Thu Nov 6 08:15:56 1997 > > > > I still wish we had some kind of magic number or string to identify valid IPP > > messages with high confidence. Talking IPP through off-the-shelf Web servers > > we sometimes see this kind of thing: > > > > HTTP/1.1 200 Document follows. \r\n > > Server: XXXXXXXXXXXXX\r\n > > Date: Wed, 05 Nov 1997 16:30:37 GMT\r\n > > Accept-Ranges: bytes\r\n > > Content-Type: text/html\r\n > > Content-Length: 190\r\n > > Last-Modified: Wed, 05 Nov 1997 16:30:37 GMT\r\n > > \r\n > > \n > > \n > > Error\n > > \n > > \n > >

Error 500

\n > > \n > > Internal error\n > > \n > >


XXXXXXXXXXX Server X.X.X.X
\n > > \n > > \n > > Error

Error 501

The request is > > not valid or not recognized "INVALID-METHOD"


XXXXXXXXXXXXXXXX Server > > XXXXX
> > > > Even though there was an Error 500 in the server, the response has been > wrapped > in a document and sent with return code 200. So the IPP client has > apply > various heuristics to see if it has got a good IPP response. > > And > even when there isn't an internal error in the server we often see this: > > > HTTP/1.1 200 OK\r\n > Server: XXXXXXXXXXXXXXXXXXXX\r\n > Date: Wed, 5 Nov 1997 > 16:40:10 GMT\r\n > Content-Type: application/ipp\r\n > Last-Modified: Wed, 5 Nov > 1997 16:40:10 GMT\r\n > Content-Length: 126\r\n > \r\n > \r\n > \r\n > > \x01\x00\x00\x00\x02*\x00\bjob-name\x00\x04 > > Job1*\x00\tjob-state\x00\x04Job1*\x00\x00\x00\x04Job2*\x00\x11job-state-reasons\ > x00\x04Job1*\x00\x11job-state-message\x00\x02YO\x05)\x00\x05sides\x00\x0bunsuppo > rted\x03 > > Notice all the CRLF pairs following the HTTP header. So the > client again is > forced to use heuristics, and I hope we never get to version > 13.10, because the > start of the IPP message will look just like another CRLF! > > > > Does anyone have a good algorithm worked out for determining the validity of > an > IPP response and finding the true start of the message? > > Will this > problem go away with mandatory SSL V3 "framing"? > > -Carl Kugler > > From ippdev-archive Fri Nov 7 19:12:32 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29017 for ippdev-outgoing; Fri, 7 Nov 1997 18:52:36 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPPDEV> Re: magic number Message-ID: <5030100012782386000002L062*@MHS> Date: Fri, 7 Nov 1997 18:51:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ippdev-owner@pwg.org Precedence: bulk Re: error 500 wrapped in document with code 200 header: I'm don't mea= n to justify it -- I'm just reporting what I've observed. Re, CRLFs: agreed, it's non-conforming. But in the interest of robust= ness, an implementation might need to allow for it. -Carl Please respond to ippdev-owner@pwg.org @ internet To: Carl Kugler/Boulder/IBM@ibmus, Robert.Herriot@Eng.Sun.COM @ interne= t cc: ippdev@pwg.org @ internet Subject: Re: IPPDEV> Re: magic number In your first example below, you justify its behavior by saying that it= provides some HTML text to describe the error, but the proxy I deal wit= h generated similar HTML but it also returned a status of 500 which seems= more accurate than a 200 status that yours generates. With regard to your quote about extra CRLF before Request-Lines, that quote applies to CRLFs preceding the "HTTP/1.1 200 OK CRLF" and not to extra CRLFs before the message body. All the language that I can find in RFC 2068 says that the message-body must start immediately after an empty line (i.e. one with just CRLF). So it would seem to me that this server is nonconforming. Bob Herriot > From kugler@us.ibm.com Fri Nov 7 09:48:50 1997 > > My first example results from a feature of our web server that allows= > administrators to customize the error messages the server returns to = clients > when an error condition is encountered. Instead of returning a raw e= rror 500 > to the client, the server generates an HTML document describing the e= rror. I > agree that verifying Content-Type =3D=3D application/ipp is a useful = validity check > in this case. > > The second example, > > HTTP/1.1 200 OK\r\n >= Server: XXXXXXXXX\r\n > Date: Fri, 7 Nov 1997 17:27:48 GMT\r\n > Conten= t-Type: application/ipp\r\n > Last-Modified: Fri, 7 Nov 1997 17:27:48 GMT\r\n >= Content-Length: 126\r\n > \r\n > \r\n > \r\n > \x01\x00\x00\x00\x02*\x00\bjob-name\x00\x04Job1*\x00\t > job-state\x00\x04Job1*\x00\x00\x00\x04Job2*\x00\x11job-state-reasons\x0= 0\x04Job1 *\x00\x11job-state-message\x00\x02YO\x05)\x00\x05sides\x00\x0bunsupport= ed\x03 > > seems to be the kind of thing RFC2068 is talking about here: > > In t= he interest of robustness, servers SHOULD ignore any empty > line(s) re= ceived where a Request-Line is expected. In other words, if > the server is= reading the protocol stream at the beginning of a > message and receives a C= RLF first, it should ignore the CRLF. > Fielding, et. al. Standar= ds Track [Page 30]*, > RFC 2068 HTTP/1.1 January 1997 > Note: certain buggy HTTP/1.0 client implementations= generate an > extra CRLF's after a POST request. To restate what is explici= tly > forbidden by the BNF, an HTTP/1.1 client must not preface or follow > = a request with an extra CRLF. > > except that in this case it's the serve= r generating extra CRLF's. I agree that > it shouldn't, but this is an e= xample of a real-world problem encountered with a > commercial off-the-shelf web = server. > > -Carl > > > > > > Robert.Herriot@Eng.Sun.COM on 11/06/97 02:34:51 = PM > Please respond to Robert.Herriot@Eng.Sun.COM @ internet > To: Carl Kugler/Boulder/IBM@ibmus, ippdev@pwg.org @ internet > cc: > Subject: Re= : magic number > > I am surprised by your first example. When I snooped the ne= twork > traffic for the same URL, I got a 500 error, though it came from a > lo= cal proxy. If you got a 200 by snooping, then that seems like an > error. = If such is really possible then this seems like yet another > problem with choo= sing to layer on top of HTTP. > > But even if this response can really happen, = doesn't the string > 'Content-Type: text/html' act as a magic number and indic= ate to the > client that there something unexpected because the expected > Con= tent-Type is application/ipp? The client, without and HTML > displayer cannot te= ll the user what the problem is, but it is certainly > an error. > > Also, why= were so many there so many '\r\n's in your second example? > You imply that thi= s is a real example, but my reading of RFC2068 is > that the entity immediatel= y follows the empty line, so the additional > '\r\n' are part of the application/= ipp entity which is an error. But I > see your point that if there are bug= gy clients and servers out there, > these extra characters would look like= version 13.8 and might be valid > eventually. So you may have a point about mag= ic numbers. > > Bob Herriot > > From kugler@us.ibm.com Thu Nov 6 08:15:56= 1997 > > > > I still wish we had some kind of magic number or string to identi= fy valid IPP > > messages with high confidence. Talking IPP through off-the-she= lf Web servers > > we sometimes see this kind of thing: > > > > HTTP/1.1 200 D= ocument follows. \r\n > > Server: XXXXXXXXXXXXX\r\n > > Date: Wed, 05 Nov 1997 = 16:30:37 GMT\r\n > > Accept-Ranges: bytes\r\n > > Content-Type: text/html\r\n > = > Content-Length: 190\r\n > > Last-Modified: Wed, 05 Nov 1997 16:30:37 GM= T\r\n > > \r\n > > \n > > \n > > Error\n > > \n= > > \n > >

Error 500

\n > > \n > > Internal error\n > > \n > = >


XXXXXXXXXXX Server X.X.X.X \n > > \n > > \n > > Error

Error 501

The requ= est is > > not valid or not recognized "INVALID-METHOD"


> http://karlk.penn.boulder.ibm.com:8080/">XXXXXXXXXXXXXXXX Server > > XXXXX
> > > > Even though there was an Erro= r 500 in the server, the response has been > wrapped > in a document and sent wi= th return code 200. So the IPP client has > apply > various heuristics to see if= it has got a good IPP response. > > And > even when there isn't an internal er= ror in the server we often see this: > > > HTTP/1.1 200 OK\r\n > Server: XXXXXXXXXXXXXXXXXXXX\r\n > Date: Wed, 5 Nov 1997 > 16:40:10 GMT\r\n > Content-Type: application/ipp\r\n > Last-Modified: Wed, 5 Nov > 1997 16= :40:10 GMT\r\n > Content-Length: 126\r\n > \r\n > \r\n > \r\n > > \x01\x00\x00\x00\x02*\x00\bjob-name\x00\x04 > > Job1*\x00\tjob-state\x00\x04Job1*\x00\x00\x00\x04Job2*\x00\x11job-state= -reasons\ > x00\x04Job1*\x00\x11job-state-message\x00\x02Y O\x05)\x00\x05sides\x00\x0bunsuppo > rted\x03 > > Notice all the CRLF pairs following the HTTP header. So t= he > client again is > forced to use heuristics, and I hope we never get to = version > 13.10, because the > start of the IPP message will look just like anoth= er CRLF! > > > > Does anyone have a good algorithm worked out for determining the= validity of > an > IPP response and finding the true start of the message? > > W= ill this > problem go away with mandatory SSL V3 "framing"? > > -Carl Kugler > >= = From ippdev-archive Fri Nov 14 12:44:15 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22245 for ippdev-outgoing; Fri, 14 Nov 1997 12:41:38 -0500 (EST) From: "Zehler,Peter" To: "IPP Development List (E-mail)" Subject: IPPDEV> Anyone want to try an internet test with my IPP server and client ? Date: Fri, 14 Nov 1997 09:44:56 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Nov14.094121pst."54396(3)"@alpha.xerox.com> Sender: ippdev-owner@pwg.org Precedence: bulk All, I am ready to see how a test across the internet would work. I have tested it with my own code. The test I would like to try would be a simple print. I have not implemented localization yet. The printer I have is very low end, so the attributes supported is minimal. Give me a call and we can set up a time and discuss the objective in detail. The results will be posted to this list. Any issues/misunderstandings will be captured and forwarded to the IPP list and the appropriate individuals. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________ From ippdev-archive Fri Nov 14 12:59:32 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22772 for ippdev-outgoing; Fri, 14 Nov 1997 12:55:16 -0500 (EST) Message-Id: <199711141755.JAA02846@rbi.rbi.com> Subject: IPPDEV> IBM's IPP Client Prototype Problems Date: Fri, 14 Nov 97 09:55:40 -0800 x-sender: bhasting@rbi.rbi.com x-mailer: Claris Emailer 2.0v2, June 6, 1997 From: Bill Hastings To: "ipp Dev" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ippdev-owner@pwg.org Precedence: bulk We are developing an IPP server (actually a servlet) and are trying to use IBM's IPP Client Prototype to aid in that development. Unfortunately, we are not able to use the client because it appears to be sending out bogus data to the server. It seems that just prior to the HTTP header, it is incorrectly sending out the protocol type and domain name. Here is a specific example: If the server domain is , what should be sent is, POST / HTTP 1.0 The IBM client is sending, POST http://www.ippserver.com/ HTTP 1.0 which is refused by the server. Any help is appreciated. Bill Hastings RBI Software Systems bhastings@rbi.com From ippdev-archive Fri Nov 14 13:34:16 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA23514 for ippdev-outgoing; Fri, 14 Nov 1997 13:30:51 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPPDEV> IBM's IPP Client Prototype Problems Message-ID: <5030100013389166000002L062*@MHS> Date: Fri, 14 Nov 1997 13:29:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ippdev-owner@pwg.org Precedence: bulk The GUI for IBM's IPP Client Prototype expects a non-standard format fo= r the "Printer URL". The Printer URL must be specified with the leading "htt= p://" stripped off. So, if the full URL of your Printer is http://www.ippserver.com/servlet/IPPServlet you should enter the Printer URL as www.ippserver.com/servlet/IPPServlet and the client should send something like POST /servlet/IPPServlet HTTP/1.1\r\n Accept: application/ipp\r\n Content-type: application/ipp\r\n Host: www.ippserver.com\r\n Content-length: 6261\r\n \r\n \x01\x00\x00\x02\x01)\x00\bjob-name\x00...... Maybe that's the problem? Also, the version at the download site won't allow you to specify a por= t number in the URL. If that's a problem contact me for a fix. Carl Kugler IBM 303-924-5060 Please respond to ippdev-owner@pwg.org @ internet To: ippdev@pwg.org @ internet cc: Subject: IPPDEV> IBM's IPP Client Prototype Problems We are developing an IPP server (actually a servlet) and are trying to use IBM's IPP Client Prototype to aid in that development. Unfortunatel= y, we are not able to use the client because it appears to be sending out bogus data to the server. It seems that just prior to the HTTP header, = it is incorrectly sending out the protocol type and domain name. Here is a= specific example: If the server domain is , what should be sent is, POST / HTTP 1.0 The IBM client is sending, POST http://www.ippserver.com/ HTTP 1.0 which is refused by the server. Any help is appreciated. Bill Hastings RBI Software Systems bhastings@rbi.com = From ippdev-archive Fri Nov 14 14:04:16 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA23641 for ippdev-outgoing; Fri, 14 Nov 1997 14:00:06 -0500 (EST) Message-Id: <199711141900.OAA12075@devnix.agranat.com> To: Bill Hastings cc: "ipp Dev" Subject: Re: IPPDEV> IBM's IPP Client Prototype Problems In-reply-to: <199711141755.JAA02846@rbi.rbi.com> Date: Fri, 14 Nov 1997 14:00:03 -0500 From: "Scott Lawrence" Sender: ippdev-owner@pwg.org Precedence: bulk >>>>> "BH" == Bill Hastings writes: BH> [...] IBM's IPP Client Prototype [...] appears to be sending out BH> bogus data to the server. It seems that just prior to the HTTP header, it BH> is incorrectly sending out the protocol type and domain name. Here is a BH> specific example: BH> If the server domain is , what should be sent is, BH> POST / BH> HTTP 1.0 BH> BH> The IBM client is sending, BH> POST http://www.ippserver.com/ BH> HTTP 1.0 BH> Neither of those is quite right; the first line of a request should be: POST http://www.ippserver.com/ HTTP/1.1 ^ ^ ^ ^ | | | | Method ---+ | | | URI -----------------------+ | | Protocol Revision ---------------------------+ | carriage return & line feed -------------------------+ In HTTP/1.0 the URI is only allowed to be fully qualified (that is, include the scheme and host parts) if the request is made to a proxy, so this would seem to be incorrect. In HTTP/1.1, which is what IPP is supposed to run over, the full URI MUST be supported by all servers, but only the path part is required. The protocol identifier on a second line is wrong, and it should have a slash between 'HTTP' and the version number - no whitespace allowed there. Any number of spaces (>=1) is allowed in each of the places above where I've used space. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ippdev-archive Mon Nov 17 15:15:00 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA01497 for ippdev-outgoing; Mon, 17 Nov 1997 15:11:33 -0500 (EST) From: "Zehler,Peter" To: Keith Moore Cc: IPP@pwg.org, "IPP Development List (E-mail)" Subject: IPPDEV> RE: IPP> Re: IPP developers mailing list established Date: Mon, 17 Nov 1997 11:21:19 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Nov17.113647pst."72233(5)"@alpha.xerox.com> Sender: ippdev-owner@pwg.org Precedence: bulk Keith, The main reason for a separate mailing list for the developers was to keep the main list free of tedious details. The implementers mailing list was intended to be a forum for very detailed discussions of implementation specific aspects of IPP clients/servers. This list would also be where individuals would post invitations to engage in pairwise testing across the internet. An additional side benefit of a separate list is it identifies the subset of individuals in IPP that have some type of interest in IPP prototyping. Previous request for interested individuals to step forward have not been as fruitful as establishing a mailing list. One of my responsibilities as whip of the IPP TES subgroup is to identify and track any issues identified during pairwise internet testing. Any issues would be posted to the general IPP list. The issues would also be forwarded to the appropriate whip. I would continue to monitor the issue to its resolution. If you feel this activity should be handled on the main list I have no objection. I will bring this matter up at the weekly phone conference. This email is intended to get feedback from the IPP community at large. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________ > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Thursday, November 06, 1997 4:31 PM > To: pzehler@channels.mc.xerox.com > Cc: moore@cs.utk.edu; IPP@pwg.org > Subject: IPP> Re: IPP developers mailing list established > > > Jeff Schnitzer created an mailing list for us. > > (thanks Jeff) This discussion list is for the exchange of > > information related to the development and implementation > > of IPP clients or servers/printers. > > Traditionally, discussion of development and implementation > happens on the main IETF working group list, to keep a tight > feedback loop. Also, customary IETF practice is to keep a > WG's mailing list open even after the WG is finished, to > facilitate discussion by implementors. > > Especially given that IPP's work is almost finished, > is there some reason this needs to be a separate list? > > Keith From ippdev-archive Tue Nov 18 02:55:10 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA08084 for ippdev-outgoing; Tue, 18 Nov 1997 02:53:10 -0500 (EST) Message-Id: <199711180751.CAA19220@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Zehler,Peter" cc: Keith Moore , IPP@pwg.org, "IPP Development List (E-mail)" Subject: IPPDEV> Re: IPP> Re: IPP developers mailing list established In-reply-to: Your message of "Mon, 17 Nov 1997 11:21:19 PST." <97Nov17.113642pst."72228(3)"@alpha.xerox.com> Date: Tue, 18 Nov 1997 02:51:05 -0500 Sender: ippdev-owner@pwg.org Precedence: bulk Peter, If the main IPP list has a high percentage of non-developers, the list has serious problems. Keith From ippdev-archive Tue Nov 18 14:00:15 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11466 for ippdev-outgoing; Tue, 18 Nov 1997 13:57:26 -0500 (EST) Message-ID: <3471E432.BC16679D@underscore.com> Date: Tue, 18 Nov 1997 13:53:38 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Keith Moore CC: "Zehler,Peter" , IPP@pwg.org, ippdev@pwg.org Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established References: <199711180751.CAA19220@spot.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippdev-owner@pwg.org Precedence: bulk Keith, > If the main IPP list has a high percentage of non-developers, > the list has serious problems. As of yesterday, the IPP mailing list has 303 subscribers, while the IPPDEV list has only 38 subscribers. Clearly these lists are not duplicates of each other. I'm not sure what you mean about "serious problems" in your above statement. Many, many folks monitor the IPP list for a number of different reasons, not all having to do with the technology itself. There are many people, for instance, who monitor the progress of IPP to better understand and plan for product delivery schedules. Most of us in the PWG welcome this kind of public observation, even if it means some of those folks are *marketing* types. ;-) As the official list-keepers for the PWG, we here at Underscore monitor all changes to all PWG-oriented mailing lists. All too many times we see folks unsubscribe from the IPP when a sudden rash of messages are posted that deal with some very fine technical point. As Peter Zehler has pointed out in a previous message, we wish to segregate finely detailed implementation discussions from the higher-level aspects of IPP. Hope this approach doesn't give you or the other Area Directors substantial heartburn. ...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 -- ---------------------------------------------------------------------- From ippdev-archive Tue Nov 18 15:25:16 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12915 for ippdev-outgoing; Tue, 18 Nov 1997 15:22:31 -0500 (EST) Message-Id: <9711182019.AA07836@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jay Martin Cc: Keith Moore , "Zehler, Peter" , IPP@pwg.org, ippdev@pwg.org Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established In-Reply-To: Your message of "Tue, 18 Nov 1997 13:53:38 EST." <3471E432.BC16679D@underscore.com> Date: Tue, 18 Nov 1997 15:19:58 -0500 Sender: ippdev-owner@pwg.org Precedence: bulk > I'm not sure what you mean about "serious problems" in your above > statement. Many, many folks monitor the IPP list for a number of > different reasons, not all having to do with the technology itself. There's no problem with people monitoring a WG list. There is a problem if the WG list is deliberately dumbed down to faciliate such monitoring. The purpose of the WG list is to do technical work, and such work is best accomplished when a high percentage of those doing the work are implementors. > As the official list-keepers for the PWG, we here at Underscore > monitor all changes to all PWG-oriented mailing lists. All too > many times we see folks unsubscribe from the IPP when a sudden > rash of messages are posted that deal with some very fine technical > point. That's a good sign! The list should be open to anyone, of course, but most people who aren't interested in doing the work will eventually get bored and unsubscribe. Keith From ippdev-archive Tue Nov 18 17:35:22 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA16115 for ippdev-outgoing; Tue, 18 Nov 1997 17:31:50 -0500 (EST) Date: Tue, 18 Nov 1997 12:51:16 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711182051.MAA19039@woden.eng.sun.com> To: jkm@underscore.com, moore@cs.utk.edu Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established Cc: pzehler@channels.mc.xerox.com, IPP@pwg.org, ippdev@pwg.org X-Sun-Charset: US-ASCII Sender: ippdev-owner@pwg.org Precedence: bulk Although I understand Jay's point about the large audience of the IPP mailing list, I share Keith's concern about two separate mailing lists with little overlap. I am particulary concerned that there is no simple rule for determining whether an issue is large enough that it should go to the IPP mailing list rather than IPPDEV. In my experience, when architects of a standard are not closely involved in implementations (e.g. on the same mailing list), the implementations diverge from the standard. Bob Herriot > From moore@cs.utk.edu Tue Nov 18 12:22:47 1997 > X-Uri: http://www.cs.utk.edu/~moore/ > From: Keith Moore > To: Jay Martin > Cc: Keith Moore , > "Zehler, > Peter" , IPP@pwg.org, > ippdev@pwg.org > Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established > In-Reply-To: Your message of "Tue, 18 Nov 1997 13:53:38 EST." > <3471E432.BC16679D@underscore.com> > Date: Tue, 18 Nov 1997 15:19:58 -0500 > Sender: ippdev-owner@pwg.org > Content-Length: 959 > X-Lines: 21 > > > I'm not sure what you mean about "serious problems" in your above > > statement. Many, many folks monitor the IPP list for a number of > > different reasons, not all having to do with the technology itself. > > There's no problem with people monitoring a WG list. > There is a problem if the WG list is deliberately dumbed down > to faciliate such monitoring. The purpose of the WG list is to do > technical work, and such work is best accomplished when a high > percentage of those doing the work are implementors. > > > As the official list-keepers for the PWG, we here at Underscore > > monitor all changes to all PWG-oriented mailing lists. All too > > many times we see folks unsubscribe from the IPP when a sudden > > rash of messages are posted that deal with some very fine technical > > point. > > That's a good sign! The list should be open to anyone, of course, > but most people who aren't interested in doing the work will eventually > get bored and unsubscribe. > > Keith > From ippdev-archive Tue Nov 18 19:05:22 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19898 for ippdev-outgoing; Tue, 18 Nov 1997 19:03:56 -0500 (EST) Date: Tue, 18 Nov 1997 14:58:13 -0800 (PST) From: Ned Freed Subject: IPPDEV> RE: IPP> Re: IPP developers mailing list established In-reply-to: "Your message dated Mon, 17 Nov 1997 11:21:19 -0800 (PST)" <"97Nov17.113647pst.72233(5)"@alpha.xerox.com> To: "Zehler,Peter" Cc: Keith Moore , IPP@pwg.org, "IPP Development List (E-mail)" Message-id: <01IQ5SYFLDDW9LUYEY@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Sender: ippdev-owner@pwg.org Precedence: bulk > The main reason for a separate mailing list for the developers was to > keep the main list free of tedious details. The implementers mailing > list was intended to be a forum for very detailed discussions of > implementation specific aspects of IPP clients/servers. This list would > also be where individuals would post invitations to engage in pairwise > testing across the internet. I'm sorry, but I agree with Keith about this. The _entire_ purpose of an IETF list is to have such discussions. We are building protocols here and details are everything. If someone isn't comfortable with that, then they don't belong on the list. And if that then causes nontechnical looky-lous to unsubscribe, then that's a good thing, not a bad thing that warrants the creation of another list. My personal opinions about what discussions should happen where aside, I know of no rule in the IETF that WGs can't have more than one list. So if you want to do things this way then you can. However -- and now we're leaving personal opinion and getting into matters of formal procedure -- if protocol details and implementation experience are to be discussed elsewhere then that "elsewhere" is an IETF list. Period. And this then means that IETF rules apply to this other list. It therefore has to be mentioned in the WG charter and it has to be archived in accordance with IETF archiving practices. Neither of these conditions are being met for the IPPDEV at the present time as far as I can tell. Does any of this matter? The answer is yes, it most certainly does. Speaking as a member of the IETF directorate, and one who might well be asked to review this WG's output at some point by the Application ADs, I frequently review the details of the technical discussions that have taken place when I review a document, especially if I didn't participate in the discussion at the time. I normally do this by reviewing my own archives of the WG list. However, I didn't pick up on the 5-Nov-1997 announcement of the formation of this separate list, so now my archive of this WG's lists is incomplete. (I just took steps to rectify this.) And given that there are no other archives, at least as far as I can tell, I will say that should I be called upon to review this WGs output and I find that I cannot track down the specifics of some decision in the archives I have I would have no choice but to formally object to the advancement of the specification. In short, this is far from a laughing matter. This group has already seen fit to do much of its work in phone conversations rather than via email. That's fine as long as those conversations are summarized on the list (and as far as I can tell they have been), but it means even less documentation is present in the list archives and makes any additional of this sort even more problematic. Ned From ippdev-archive Tue Nov 18 22:31:26 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA23034 for ippdev-outgoing; Tue, 18 Nov 1997 22:21:15 -0500 (EST) Message-ID: <34725B10.22914633@parc.xerox.com> Date: Tue, 18 Nov 1997 19:20:48 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: "Zehler,Peter" CC: Keith Moore , IPP@pwg.org, "IPP Development List (E-mail)" Subject: IPPDEV> Re: IPP> Re: IPP developers mailing list established References: <97Nov17.113647pst."72233(5)"@alpha.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippdev-owner@pwg.org Precedence: bulk For what it's worth, the W3C insisted on sponsoring a separate "HTTP implementors group" independent of the HTTP working group, in which implementation issues were supposed to be discussed. In truth, not much happened on the HTTP implementors mailing list, because we established that no decisions got made on the private list. There was a little bit of traffic about testing, but not much. Larry -- http://www.parc.xerox.com/masinter From ippdev-archive Wed Nov 19 14:40:36 1997 Return-Path: ippdev-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA27831 for ippdev-outgoing; Wed, 19 Nov 1997 14:36:56 -0500 (EST) Message-Id: <3.0.1.32.19971119104836.00ad9990@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Nov 1997 10:48:36 PST To: ipp@pwg.org, ippdev@pwg.org From: Carl-Uno Manros Subject: IPPDEV> Separate IPPDEV list will cease to exist as of tomorrow Cc: Ned.Freed@innosoft.com, moore@cs.utk.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ippdev-owner@pwg.org Precedence: bulk All, The somewhat animated discussion that have taken place lately about the separate IPPDEV list is not worth spending our time to debate. In consultation with Peter Zehler (who owns the IPPDEV list) and Jay Martin (who runs our list service), I have decided that the IPPDEV list will be taken out of service as of tomorrow November 20, 1997. Attempts to send messages to that list will result in an error message. Please use the main IPP list for any future discussions about implementation and testing issues. In line with our existing WG rules, please start up the subject line with "TES -" for such messages to allow people to automatically sort out this kind of messages, if they so wish and their mail client has such a capability. The few messages that have been run over the IPPDEV list so far have mainly pointed out some errors in IBM client (to be fixed), and do not seem to qualify for resending over the main list again. I consider this discussion closed. Carl-Uno Manros IETF IPP WG Co-chair Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com