Subject: [I18nrp] editorial comments on draft-faltstrom-unicode11-04.txt

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 10 Oct 2018 19:12:58 +0000

I looked at rev04 and have some editorial comments and nits. One such general comment is that there is a lack of commas in the text, which makes for difficult reading.

Abstract:

s/IDNA2008 do give/IDNA2008 gives/
s/document suggests/document suggest/

Introduction:

Points out that IDNA2008 "is specified in a series of documents (see Section Section 3.1). " That still leaves unanswered what a reasonable overview is for those of us who are absolute IDNA newbs. So may I suggest something like "is specified in a series of documents (see Section Section 3.1), but for an overview see XXXX." [I suppose rfc5894 is the proper overview doc here?]

Section 3.1:

s/DISSALOWED/DISALLOWED/
s/changes where acceptable/changes were acceptable/

Section 3.2:

s/implies stayed at Unicode Standard/implies staying at Unicode Standard/ 
[Here, I suppose it's staying, but "stayed" sounds wrong, please double-check.]

s/having a very diverse/having very diverse/

Can't parse: "that registry operators to based on the IDNA2008 specification create additional rules...". 
Perhaps you meant "that led registry operators to (based on the IDNA2008 specification) create additional rules..."?

s/characters permissable/characters permissible / 

section 4.3:

s/ZANABZAR/ZANABAZAR

Gabriel

> -----Original Message-----
> From: IAB <[email-masked]> On Behalf Of Patrik Fältström
> Sent: 6 October, 2018 22:54
> To: [email-masked]; [email-masked]
> Subject: [IAB] draft-faltstrom-unicode11-04.txt
> 
> All,
> 
> Version -04 of this draft was just posted.
> 
> Background: As we all know IDNA2008 is an algorithm that applied to Unicode
> gives a subset of code points which are permissible for in turn registries and
> others to create subsets from to be used in their respective policies.
> 
> Being the appointed expert for the IANA registry I have flagged for IAB changes
> made to Unicode that I feel must be discussed in IETF, and here is the
> document with my proposal (details are in the draft).
> 
> In short the draft proposes (just like RFC 6452) IETF continue to follow Unicode
> Standard without adding exceptions to the IDNA2008 algorithm, EVEN IF
> changes are made that are incompatible to earlier versions of Unicode.
> 
> The choices for IETF when things like this happens are:
> 
> 1. Keep IDNA2008 with no exceptions
> 
> 2. Keep IDNA2008 with exceptions
> 
> 3. Stop referring (directly) to Unicode as it is not stable enough
> 
> Probably more choices than these...
> 
> My proposal is [1], together with a more forceful push to strict IDNA2008
> adoption. No IDNA2003, no UTS#46, no homebrew mixes. Including that
> registries really do a careful conservative selection of code points to be used in
> whatever context it is to be used.
> 
> 
> The problem though is that this is *my* view. Sure, a few others have
> randomly and "by pure luck" told me "this is ok".
> 
> But is this a stable informed decision by IETF?
> 
> This very fast turn into a process issue where IAB have asked for progress, and
> IETF is to deliver.
> 
> And this is where I take a step back, and want IESG and IAB to make up their
> mind. This group was created for I18N issues, we have a charter, but then
> what? Is this where drafts like these should be discussed?
> 
> Maybe...
> 
>    Patrik

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 Oct 2018 21:15:38 -0400

I assume Patrik has not answered because, being sensible, he is
likely sleeping.  In the interest of saving a bit of time, I've
responded to the more substantive of your comments/questions
below...

--On Wednesday, October 10, 2018 19:12 +0000 Gabriel Montenegro
<[email-masked]> wrote:

>...
> Points out that IDNA2008 "is specified in a series of
> documents (see Section Section 3.1). " That still leaves
> unanswered what a reasonable overview is for those of us who
> are absolute IDNA newbs. So may I suggest something like "is
> specified in a series of documents (see Section Section 3.1),
> but for an overview see XXXX." [I suppose rfc5894 is the
> proper overview doc here?]

Almost.  You will find that RFC 5894 is hard or impossible to
understand without some of the material in 5890, which I would
recommend at least looking through first.  The combination is
still not a tutorial.  There are several of those around, but,
unfortunately, a large fraction of them contain serious errors
or are, however unintentionally, a little misleading.  Some day,
some of us will have time.

>...
> Can't parse: "that registry operators to based on the IDNA2008
> specification create additional rules...".  Perhaps you meant
> "that led registry operators to (based on the IDNA2008
> specification) create additional rules..."?

You might find part of the note I posted earlier today (about
the same time as yours) helpful in regard to what is going on in
that section (although I agree that the current text in the I-D
needs work).

best,
   john

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 11 Oct 2018 11:35:27 +0200

Thanks, will take care of these editorial issues...

   Patrik

> On 10 Oct 2018, at 21:12, Gabriel Montenegro <[email-masked]> wrote:
>