Re: empty quoted strings and other oddities

Bruce Lilly <> Thu, 03 October 2002 23:02 UTC

Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g93N2hn24651 for ietf-822-bks; Thu, 3 Oct 2002 16:02:43 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g93N2gv24647 for <>; Thu, 3 Oct 2002 16:02:42 -0700 (PDT)
Received: from ([] by with esmtp (Exim 3.35 #1) id 17xEzU-0003i1-00 for; Thu, 03 Oct 2002 19:02:44 -0400
Received: from (localhost []) by with ESMTP id g93N2bII015428(8.12.3/8.12.3/SuSE Linux 0.6/2002-07-27 16:10:46); Thu, 3 Oct 2002 19:02:37 -0400
Received: from ( []) by with ESMTP id g93N2ZmZ015427(8.12.3/8.12.3/Submit/2002-06-01 20:08:15); Thu, 3 Oct 2002 19:02:36 -0400
Message-ID: <>
Date: Thu, 03 Oct 2002 19:02:35 -0400
From: Bruce Lilly <>
Organization: Bruce Lilly
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
X-Accept-Language: en-us, en, fr, ru, ja
MIME-Version: 1.0
Subject: Re: empty quoted strings and other oddities
References: <> <002001c26a0f$f05437a0$b7880fce@alice> <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavis-milter (
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

Arnt Gulbrandsen wrote:

> Well, assume for the sake of argument that it's relevant. Is it also
> valuable enough to justify changing email after 25 years of production
> use, with a user base presumably in the hundreds of millions, using god
> knows how many thousands of different programs?
> I personally think this particular syntax wart should've been killed at
> birth... but now it's too late.
> Each extra syntax check involves writing at least one more test in the
> code, at least two more test cases to verify the code's correctness, some
> documentation and some (UI and documentation) translations. And then
> there's the (slightly) increased cost of learning the code for the
> subsequent maintainers, and the UI for the users.

The suggestion was to relegate empty domain literals to an obs-
contruct, which means that parsing would not change, but it would
be come a MUST NOT generate construct.  There need not be any
syntax checks for any parser w.r.t. this issue; any software
generating a domain literal would need to take some appropriate

Moving it to obs- syntax doesn't kill it, but it does declare it
as a wart.