Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA29180; Wed, 10 Jun 1998 17:00:59 -0400 (EDT) Received: by cs.cs.utk.edu (bulk_mailer v1.10); Wed, 10 Jun 1998 17:00:47 -0400 Received: by CS.UTK.EDU (cf v2.9s-UTK) id RAA29135; Wed, 10 Jun 1998 17:00:46 -0400 (EDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA29122; Wed, 10 Jun 1998 17:00:43 -0400 (EDT) Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id RAA07050; Wed, 10 Jun 1998 17:00:41 -0400 (EDT) Message-Id: <199806102100.RAA07050@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: kaih@khms.westfalen.de (Kai Henningsen) cc: drums@cs.utk.edu, moore@cs.utk.edu Subject: Re: Moving ABNF to Draft Status In-reply-to: Your message of "03 Jun 1998 10:25:00 +0200." <6vBarrmHw-B@khms.westfalen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Jun 1998 17:00:41 -0400 Sender: moore@cs.utk.edu > What are the chances to declaring ABNF to be an exception to the rules, > insofar as it, in and of itself, doesn't represent any on-the-wire > protocol, so there won't be implementations in the usual sense anyway? If people are really worried about such things, we can do a variance procedure. Otherwise, I'd just as soon move ABNF forward with no major changes. I don't want to have multiple versions of ABNF, and I don't think we should stand on our heads too much to try to make the "multiple implementations" case fit. It would probably be easier to get two people to implement ABNF parser-generators, than it would to deal with all of the process mess that people seem eager to create. Keith