[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 4.2.3.2. 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).
Like:
Appendix A.10. COMBINING MARK
Code point:
0000..10FFFD
Overview:
String can not start with a COMBINING MARK.
Lookup:
True
Rule Set:
True;
If General_Catergory(FirstChar) .eq. "Mc" Then False;
If General_Catergory(FirstChar) .eq. "Mn" Then False;
If General_Catergory(FirstChar) .eq. "Me" Then False;
Patrik
> 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