Re: [EAI] [Technical Errata Reported] RFC6531 (4996)

ned+ima@mrochek.com Tue, 18 April 2017 18:20 UTC

Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039371292F4 for <ima@ietfa.amsl.com>; Tue, 18 Apr 2017 11:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bsv7SEiL9sP for <ima@ietfa.amsl.com>; Tue, 18 Apr 2017 11:20:30 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D4612EB20 for <ima@ietf.org>; Tue, 18 Apr 2017 11:20:30 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDBJCIW2KW005J37@mauve.mrochek.com> for ima@ietf.org; Tue, 18 Apr 2017 11:14:58 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD64433M0W00005B@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 18 Apr 2017 11:14:47 -0700 (PDT)
From: ned+ima@mrochek.com
Cc: Vitaliy T <vitaliy.tokarev@gmail.com>, yaojk <yaojk@cnnic.cn>, ben <ben@nostrum.com>, aamelnikov <aamelnikov@fastmail.fm>, alissa <alissa@cooperw.in>, ima <ima@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Message-id: <01QDBJCDNVXI00005B@mauve.mrochek.com>
Date: Tue, 18 Apr 2017 10:22:30 -0700 (PDT)
In-reply-to: "Your message dated Tue, 18 Apr 2017 12:57:43 -0400" <D581A31CD3909B93072726D7@PSB>
References: <20170416203054.74AB5B8190E@rfc-editor.org> <2017041814264072046595@cnnic.cn> <CABDkf7_RJLXZ_vtOWNoSgMV8YDdmW54r_JTYjaJfsdAz-moRVQ@mail.gmail.com> <D581A31CD3909B93072726D7@PSB>
To: John C Klensin <john-ietf@jck.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/Hsg-NIK7Z3Hs4JkoLnexOokhCu8>
Subject: Re: [EAI] [Technical Errata Reported] RFC6531 (4996)
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ima/>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2017 18:20:32 -0000

> > > Because  "UTF-8 string " is used everywhere in EAI RFCs, in
> > > order to avoid the possible misunderstanding,  I remembered
> > > that the WG  suggested to add this sentence " That string
> > > MUST NOT contain any
> > > of the ASCII graphics or control characters." when discussing
> > > this issue.

> > Sorry, but there is no clear definition what the "ASCII
> > graphics [characters]" is.

> Sure there is.   It is in the ASCII Standard, cited as [ASCII]
> in the document.  If that is inconvenient to find, see SeIf
> nothing else, see Section 4.2 of RFC 20.

John, the problem is that by that definition, the sentence shifts from being
confusing to flat-out incorrect. The definition of atext is RFC 5322 is:

atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"

But according to section 4.2 of RFC 20, everything in atext other than ALPHA
and DIGIT qualifies as a "graphics character". So the assertion that when atext
is composed of a "UTF8 string" it MUST NOT contain "graphics characters"
directly contradicts the ABNF definition of atext. The fact is, only
the specials subset of graphics characters are excluded.

And FWIW, I also stand by my assertion that the term "ASCII graphics
characters" is not well defined - although perhaps "no longer well defined"
would be a better way to put it. There is nothing in the terminology section
that points a reader to the definition in ASCII or RFC 20. And based on what I
see in other documents, the common use definition has shifted away from what's
in the ASCII specification to something which has more utility in the
modern world.

In any case, IMO there are multiple technical problems with the bullet
point in question - WG consensus on the text notwithstanding.

				Ned