--------------53348DF451E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Attached is a short series of messages recently exchanged on the
LPRng mailing list discussing the notion of RFC1179 being a true
specification.
Since this issue arose at the IPP IETF BOF last Thursday, I thought
others might be interested in this info.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
--------------53348DF451E
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from uscore.underscore.com (uscore.underscore.com [199.125.69.1]) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA07322 for <pop-jkm@pwg.org>; Fri, 13 Dec 1996 01:09:54 -0500 (EST)
Received: from panther.Gsu.EDU by uscore.underscore.com with smtp
(Smail3.1.28.1 #5) id m0vYQpe-000US2C; Fri, 13 Dec 96 01:10 EST
Received: from localhost (sysjhy@localhost) by panther.Gsu.EDU (8.7.6/8.7.3) with SMTP id BAA25329 for <jkm@underscore.com>; Fri, 13 Dec 1996 01:10:47 -0500 (EST)
X-Authentication-Warning: panther.Gsu.EDU: sysjhy owned process doing -bs
Date: Fri, 13 Dec 1996 01:10:47 -0500 (EST)
From: "James H. Young" <sysjhy@gsu.edu>
To: JK Martin <jkm@underscore.com>
Subject: Re: diff for cleantext.c
In-Reply-To: <32AF9A27.5446@underscore.com>
Message-ID: <Pine.GSO.3.95.961213010227.22746B-100000@panther.Gsu.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Jay,
Are you sure you haven't been peeking in my private e-mail exchanges about
RFC1179? ;-) You stated my feelings SO clearly. I couldn't have said it
any better (and you saved me the trouble of trying to).
Great job.
Regards,
Jim Young
University Computing & Network Services
Georgia State University
Atlanta, GA 30303
email: jhy@gsu.edu
voice: 404.651.2639
On Thu, 12 Dec 1996, JK Martin wrote:
> Jost Krieger wrote:
>
> > I don't want to speak too much against this great piece of software,
> > but what is this strict checking of file names for, anyway? Is
> > anything needed beyond extracting a numeric job id ? Did I miss any
> > security implication ?
> >
> > RFC1179 says:
> >
> > The control file must be an ASCII stream...
>
> It's important for everyone to understand that RFC1179 is not really
> a specification...at least not the way you might *think* that it is.
>
> Unlike most "standards", RFC1179 was _only_ an attempt to document
> what that working group *thought* was the "typical" implementation
> of the LPR/LPD protocol. In other words, most LPD implementations
> you'll find today (at least on host systems) were developed *before*
> RFC1179 was written. And, as we've all witnessed, virtually no
> UNIX platform vendor has put any work into improving its LPD support.
>
> You're right, Jost, in stating that RFC1179 puts no limit on the
> hostname
> components of the control or data filenames. However, for those few
> remaining System V.3 platforms with 14-character filename limits, you
> might run into interoperability problems if you use longish filenames.
>
> One other note about RFC1179. In our experience, this RFC is one of the
> *worst* documents we've come across in terms of missing and/or ambiguous
> specifications. Anyone who has tried to implement an LPD server by
> using
> RFC1179 knows what I mean. Take RFC1179 with a grain of salt--the only
> real test for LPD interoperability is to simply try it and find out.
> :-(
>
> ...jay
>
> Underscore, Inc.
>
>
>
--------------53348DF451E--