I-D Action:draft-faltstrom-5892bis-01.txt

[Mark Davis ☕]

Mark

*— Il meglio è l’inimico del bene —*


On Wed, Dec 22, 2010 at 08:17, Paul Hoffman <phoffman at imc.org> wrote:

> At 12:14 PM -0800 12/21/10, Mark Davis ? wrote:
> >In addition to the previous comments:
> >
> >When the algorithm presented in RFC 5892 is applied to Unicode 6.0
> >the result will be different from when it is applied to Unicode 5.2
> >for the three codepoints discussed in this document.
> >
> >It should be something like:
> >
> >When the algorithm presented in RFC 5892 is applied using the property
> definitions of Unicode Standard Version 6.0, the result will be different
> from when it is applied using the property definitions of Version 5.2. There
> are 2,088 new characters in Version 6.0 which change from UNASSIGNED to
> another value. In addition, 3 characters defined in Unicode 5.2 have
> different values, as described in Section 1.
>
> I like the addition of "property definitions" to make the existing sentence
> more precise. I do not like the implication of "UTC added thousands of
> characters, so changing a few is no big deal".
>
> >The next sentence is also untrue (as well as ungrammatical).
> >
> >
> >IETF consensus
> >
> >is though that the changes are minor, and that it is important IDNA
> >
> >standard is aligned with the Unicode Standard.
>
>
>
> The IETF has not had a consensus call on this document, so it is premature
> to say that the statement is untrue.



I'll clarify:

Suppose we have the sentence:

"Paul said that he is not going to fix his roof because the leaks are minor,
and he can't fix it according to his homeowner's agreement."

Because that sentence bundles up a slew of clauses together, when I say
"that sentence is untrue", I could mean many things:

a) Paul didn't say that, or
b) He said it, but he is actually going to fix his roof, or
b) The leaks are not minor, or
c) His homeowner's agreement doesn't forbid him from fixing his roof.
d) and so on.

I was not speaking about whether the IETF had such a consensus: my
assumption was that Patrik would know that far better than I would. What I
meant was the clause that "and that it is important IDNA standard is aligned
with the Unicode Standard" was incorrect,. I'm sorry that wasn't clear from
my very next sentence.



>
> >The IETF had two choices for each of the 3 characters: add it to section G
> or let the value change. Both of these choices are "aligned with the Unicode
> Standard", because the use of section G to preserve stability is in
> alignment with the Unicode Standard. What would be more accurate would be
> something like:
> >
> >
> >IETF consensus is though that the characters are minor, and strict
> backwards compatibility of IDNA2008 is not important for minor characters.
>
> That could also be IETF consensus; we don't know yet.


So nobody should comment on any of the sentences having to do with the
rationale for the backwards incompatibility? I realize that the IETF has
decided to break compatibility, that was my best shot at an explanation --
after listening to this list -- for why they are breaking it, which is why I
suggested it.

Should I have withheld comment on it?


>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20101222/459d8366/attachment.html>