Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-rfc3536bis-02.txt> (Terminology Used in Internationalization in the IETF) to BCP

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 17 Jun 2011 06:21:30 +0300

Hello all,

I have an only concern with regard to this document which I expressed 
before, during WG discussions, and which I'd like to bring to IESG's 
attention now.

For a number of times I proposed improving the "control character" 
definition in Section 4.1:

>     control character
>
>        The 65 characters in the ranges U+0000..U+001F and U+007F..U+009F.
>        The basic space character, U+0020, is often considered as a
>        control character as well, making the total number 66.  They are
>        also known as control codes.  In terminology adopted by Unicode
>        from ASCII and the ISO 8859 standards, these codes are treated as
>        belonging to three ranges: "C0" (for U+0000..U+001F), "C1" (for
>        U+0080...U+009F), and the single control character "DEL" (U+007F).
>        <UNICODE>
My proposals included 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02558.html 
and 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02589.html.  The 
main justification I provided is that, in accordance with Abstract: 
"This document provides a glossary of terms [...]" so we need to specify 
"what does the control character mean" but not "what Unicode codepoints 
are assigned for control characters".  Yet, on the apps-discuss mailing 
list there were some concerns regarding the fact that control characters 
are unfamiliar to internalization so my proposed definition is not an 
option (one of the authors shares this opinion).  Thus, why does it 
occur in its current form?  So, there are two possible variants, I 
think: (1) remove the "control character" definition from the document 
as irrelevant to internalization or (2) produce a really good definition 
of this term (consider we're trying to give the terms normative meaning 
within IETF, since the intended status is BCP).  I didn't manage to 
persuade the authors or WG to undertake any of the aforementioned 
options and I hope IESG should decide on this.

Also, as a minor remark on references.  The document makes normative 
reference to an obsolete document - ISO/IEC 10646:2003 whereas ISO/IEC 
10646:2011 is published.  The reference should be corrected.

Thanks,
Mykyta Yevstifeyev

16.06.2011 16:04, The IESG wrote:
> The IESG has received a request from the Applications Area Working Group
> WG (appsawg) to consider the following document:
> - 'Terminology Used in Internationalization in the IETF'
>    <draft-ietf-appsawg-rfc3536bis-02.txt>  as a BCP
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-06-30. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document provides a glossary of terms used in the IETF when
>     discussing internationalization.  The purpose is to help frame
>     discussions of internationalization in the various areas of the IETF
>     and to help introduce the main concepts to IETF participants.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 Jun 2011 23:41:13 -0400

> definition in Section 4.1:

And in the WG discussions, Mykyta was in the rough when it came to a
consensus judgment.  I, as chair and doc shepherd, actually supported
some change initially, but was convinced that the final text that's in
the document is best.  The document isn't meant to be a history
lesson, but to make it clear what certain terms refer to.  The current
"control character" text accomplishes that, and there's been no
support for Mykyta's suggested change.

Barry, appsawg chair

---

From: SM <[email-masked]>
Date: Sat, 25 Jun 2011 12:27:06 -0700

>[email-masked] mailing lists by 2011-06-30. Exceptionally, comments may be

This document uses an unusual format to show the source of a 
definition (Section 1.2).  It's clearer (to me) if the document used 
the regular format for references.

The anchor9 comment in Section 3.2, minus the last sentence, could be 
folded in as part of the I-D.  Pointing out that the definition is 
not precisely correct is correct in itself.

In Section 4:

   "Code Point order is usually not how any human educated by a local
    school system expects to see strings ordered; if one orders to the
    expectations of a human, one has a language-specific sort."

This is generally referred to as natural language sort.

There is a view within the IETF that a BCP comes with the obligatory 
RFC 2119 key words.  This old school "BCP" was a pleasant read.

Regards,
-sm

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 26 Jun 2011 07:46:55 +0300

> the regular format for references.
RFC 3536 itself, which this document tries to follow, was Independent 
stream document, whereas we have a number of evidences of unusual 
formatting within such documents.  My personal opinion is that your 
comment is quite reasonable, and this should be fixed. <NONE>s should be 
removed then.
> folded in as part of the I-D.  Pointing out that the definition is not 
> precisely correct is correct in itself.
Another comment to Section 3.2:

     "and defined in The Unicode Standard
       (Sections 3.9 
<http://tools.ietf.org/html/draft-ietf-appsawg-rfc3536bis-02#section-3.9> and 
16.8 
<http://tools.ietf.org/html/draft-ietf-appsawg-rfc3536bis-02#section-16.8> 
of Version 5.2)"

Such instances of text should be reverified to suit Unicode 6.0 and 
ISO/IEC 10646:2011.

I also don't think definition of BMP should not go in Section 3.2, but 
somewhere else.

As for SM's comment, I'd recommend the draft's 1st paragraph of Section 
3.2 with anchor9 were rewritten to suit the new editions of Standards 
and, as a result, didn't mention transformation formats but rather 
encoding forms.  This is also as ISO/IEC 10646:2011 does.
> RFC 2119 key words.  This old school "BCP" was a pleasant read.
My personal opinion is that use of RFC 2119 in glossaries isn't 
appropriate.  As they give definitions, I don't think requirement levels 
are fine here.

An additional comment to Section 8 I didn't expressed before.

     "private use

      ISO/IEC 10646 code points from U+E000 to U+F8FF, U+F0000 to"

I'd better use "private use character" or "private use codepoint" as a 
name of term.

Please also verify many of your Informative references to see whether 
they didn't get obsoleted by other document.  Eg. ISO/IEC TR 
11017:1997(E) has :2003 edition now, etc.

Thanks,
Mykyta Yevstifeyev

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>