Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA09051; Tue, 29 Oct 1996 05:37:25 -0500 Received: by CS.UTK.EDU (bulk_mailer v1.7); Tue, 29 Oct 1996 05:37:13 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id FAA08965; Tue, 29 Oct 1996 05:37:06 -0500 Received: from muenster.westfalen.de (root@muenster.westfalen.de [193.174.5.2]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA08819; Tue, 29 Oct 1996 05:36:30 -0500 Received: by muenster.westfalen.de (/\oo/\ Smail3.1.29.1 #29.3) id ; Tue, 29 Oct 96 11:00 MET Received: by khms.westfalen.de (CrossPoint v3.1 R/C435); 29 Oct 1996 10:23:52 +0200 Date: 29 Oct 1996 10:10:00 +0200 From: kai@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <6JlBqVPzcsB@khms.westfalen.de> In-Reply-To: Subject: Re: Goals of ABNF discussions X-Mailer: CrossPoint v3.1 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. dcrocker@brandenburg.com (Dave Crocker) wrote on 28.10.96 in : > At 5:11 PM -0800 10/28/96, Pete Resnick wrote: > >orig-date = ("D" / "d") ("A" / "a") ("T" / "t") ("E" / "e") ":" date-time > >CRLF > > oh. > > oh my. Indeed. And what do we want the default to be - case significant or insignificant? In all of 821 and 822, the *specific* text is case insignificant. The user- supplied text isn't in some cases (local part, subject, ...). > Playing around, here are two thoughts, in the contenxt of a rule: > > rule = a / >"foo"< / b > > rule = a / <=>"foo" / b > > rule = a / +"foo"+ / b > > Not in love with or disgusted by them. I think I am biased to a notation > that involves both sides of the string. How do other folks feel and what > other suggestions do they have? Similar to that, except we should think some more about what I wrote above. > Your attitude is exactly I'm concerned about. Defining a > (meta)language with the idea of trying to prohibit bad behavior doesn't > work. Adding features to enable a major win is very different from > removing them to prevent a major loss. The way we should fix the laziness > problem is to fix the laziness problem. So don't remove it, but argue against it. MfG Kai