[Editorial Errata Reported] RFC5891 (3969)

Patrik Fältström patrik at frobbit.se
Mon Apr 21 08:01:54 CEST 2014

On 20 apr 2014, at 19:16, John C Klensin <john-ietf at jck.com> wrote:

> (adding Harald, Patrik, Cary, and Paul for reasons that will, I
> hope, be obvious)

FWIW, I am on idna-update at alvestrand.no list, so I did get the earlier messages as well.

> --On Sunday, 20 April, 2014 10:33 -0400 Barry Leiba
> <barryleiba at computer.org> wrote:
>>> Section 2.11 of the Unicode Standard explains what combining
>>> characters are only in general terms. Section 3.6 contains
>>> the actual definition.
>> Peter, I see what you're saying, but I don't think a reference
>> to Unicode 5.2, Section 3.6, at least not alone, is what was
>> meant here in Section  If anything, perhaps this is a
>> more appropriate change:
>> OLD
>>  The Unicode string MUST NOT begin with a combining mark or
>> combining    character (see The Unicode Standard, Section 2.11
>> [Unicode] for an    exact definition).
>> NEW
>>  The Unicode string MUST NOT begin with a combining mark or
>> combining    character.  See The Unicode Standard, Section
>> 2.11 [Unicode] for an    explanation of combining characters,
>> and Section 3.6, definition D52 (et    seq) for an exact
>> definition.
>> END
>> John will likely have some memory of what he intended here, so
>> let's see what he says.
> I'm away from my notes, so this is based on failing memories.  I
> might have more to say when I'm closer to them mid-week.  My
> recollection is that we wanted to point to what, in Barry's
> words above, are the "explanation", rather than the precise
> definition, in part because the former is much less
> Unicode-version-sensitive than Section 3.6 def D52.

In reality I think neither 2.11 nor 3.6 D52 are what we in IETF would call "definitions", except the first sentence of 3.6 D52:

> Combining character: A character with the General Category of Combining Mark (M).

> I have started a 5891bis draft to reflect Barry's suggested
> change.
> FWIW, with the possible exception of the choice of "exact
> definition" rather than "explanation", I don't see this as
> properly an erratum.  I believe that Barry's proposed text is an
> improvement, but a "hold for future update" improvement not a
> correction to a substantive error in the document.   

What is needed IF we do this is to add a contextual rule that actually forbid all M codepoints as first codepoint of a string. I.e. an update to 5892 (that include the base seed for the contextual rule registry).


Appendix A.10.  COMBINING MARK

  Code point:

     String can not start with a COMBINING MARK.


  Rule Set:


     If General_Catergory(FirstChar) .eq. "Mc" Then False;
     If General_Catergory(FirstChar) .eq. "Mn" Then False;
     If General_Catergory(FirstChar) .eq. "Me" Then False;


> Barry and Pete, one way of thinking about this as an erratum is
> whether, if you received a request in the next several days to
> advance IDNA (RFCs 5890-5894 and 6452) to full standard, would
> it be blocked on the basis of this comment?  I think the
> document is worth a revision to adjust this (and maybe update
> the references to 6.x or even 7.0), but others may disagree.
> Peter, I can't speak for others, but one of the reasons I
> haven't made that request yet is because I haven't done enough
> of a recent review of the documents to form an opinion as to
> whether a document update is needed to clarify things and, if
> so, to which of the documents in the set (possibly including
> 5984 and 5985).  If you have an opinion on that subject and/or
> want to influence mine (or ours), the most efficient way to do
> so would be to post a list of proposed changes to the
> IDNA-update mailing list so that those who are interested in the
> WG's work can review and comment on them.  See below for
> information about that list if you haven't found it.
> best,
>  john
> p.s. Why isn't RFC 6452 identified as updating 5892?  It seems
> to me that is a real error.
> Mailing list info:
> To Subscribe:
> http://www.alvestrand.no/mailman/listinfo/idna-update
>    Archive: http://www.alvestrand.no/pipermail/idna-update/

More information about the Idna-update mailing list