Re: [Ltru] draft-davis-t-langtag-ext

Mark Davis ☕ <mark@macchiato.com> Fri, 26 August 2011 18:28 UTC

Return-Path: <mark.edward.davis@gmail.com>
X-Original-To: ltru@ietfa.amsl.com
Delivered-To: ltru@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F150921F8B98 for <ltru@ietfa.amsl.com>; Fri, 26 Aug 2011 11:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.393
X-Spam-Level:
X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_MEDS=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXMD2mqKwwEb for <ltru@ietfa.amsl.com>; Fri, 26 Aug 2011 11:28:49 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5A8221F8A55 for <ltru@ietf.org>; Fri, 26 Aug 2011 11:28:48 -0700 (PDT)
Received: by bkar4 with SMTP id r4so3204232bka.31 for <ltru@ietf.org>; Fri, 26 Aug 2011 11:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ziYBa8j+Cp9Snd7i4x/hZYdVBo3YaV1iJSDjtzhqN9s=; b=NaweL16ZyugPry99LoOeWNJIhPKnKdC0OwTAPFx9vpJznB68uFShNxiM8nHTsktCjJ kzdde4UNa8omHr6bZJV+Oeb3tBQy27Ag7oDY9qWauytF+pMOjCmYVuVqJ39H0iZwYNX+ 6XkTwWo8qSris5lB3TnR72FbFYOR+UpZmqXMQ=
MIME-Version: 1.0
Received: by 10.204.130.92 with SMTP id r28mr807909bks.108.1314383404824; Fri, 26 Aug 2011 11:30:04 -0700 (PDT)
Sender: mark.edward.davis@gmail.com
Received: by 10.204.121.193 with HTTP; Fri, 26 Aug 2011 11:30:04 -0700 (PDT)
In-Reply-To: <CAH4e3M7UPVxFexjrSVYyXYgz3RSVyWYUtBV7xygk9h1sQr9yZQ@mail.gmail.com>
References: <20110823101708.665a7a7059d7ee80bb4d670165c8327d.35d98b2f35.wbe@email03.secureserver.net> <CAJ2xs_F8QHqBBWb_R+JLoKYptGPOfG1PZa85d-OFYVbfs5iDNg@mail.gmail.com> <CAH4e3M7UPVxFexjrSVYyXYgz3RSVyWYUtBV7xygk9h1sQr9yZQ@mail.gmail.com>
Date: Fri, 26 Aug 2011 11:30:04 -0700
X-Google-Sender-Auth: hAbyksQUcvDy5gTctV58hkZOALE
Message-ID: <CAJ2xs_EFT-G+vL+LDUx3S29xMV5MgvoKRQkOARF+QbE25_e9nQ@mail.gmail.com>
From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= <mark@macchiato.com>
To: "Gordon P. Hemsley" <gphemsley@gmail.com>
Content-Type: multipart/alternative; boundary=001517477fb6f17a4404ab6cbb5d
Cc: ltru@ietf.org, Doug Ewell <doug@ewellic.org>
Subject: Re: [Ltru] draft-davis-t-langtag-ext
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2011 18:28:54 -0000

Thanks for the feedback!

Updated working drafts:

   - draft-davis-t-langtag-ext.html<http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.html>
   - draft-davis-t-langtag-ext.txt<http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.txt>
   - draft-davis-t-langtag-ext.xml<http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.xml>

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


On Fri, Aug 26, 2011 at 06:41, Gordon P. Hemsley <gphemsley@gmail.com>wrote;wrote:

> On Tue, Aug 23, 2011 at 2:32 PM, Mark Davis ☕ <mark@macchiato.com> wrote:
> > Updated working drafts:
> >
> > draft-davis-t-langtag-ext.html
> > draft-davis-t-langtag-ext.txt
> > draft-davis-t-langtag-ext.xml
>
> Editorial nits:
>
> The second to last paragraph in section 2.1 contains a sentence that reads:
> "Extension subtags, once defined by LDML, are never retracted or
> change in meaning in a substantial way."
>
> I presume that the 'never' is supposed to scope over 'change', but it
> doesn't, as currently written.
>
> I suggest rephrasing that sentence to something like these:
> "Extension subtags, once defined by LDML, are never retracted or
> changed in meaning in a substantial way."
> "Extension subtags, once defined by LDML, are never retracted nor
> changed in meaning in a substantial way."
> "Extension subtags, once defined by LDML, are never retracted and do
> not change in meaning in a substantial way."
> "Extension subtags, once defined by LDML, are never retracted or
> substantially changed in meaning."
>

done


> "Extension subtags, once defined by LDML, are never retracted nor
> substantially changed in meaning."
>
> My preference would probably be one of the last two.
>
> Also, and maybe I missed it, but I thought it was agreed to change the
> registration description (section 2.4) to "Specifying Transformed
> Content" or one of many other suggested changes?
>

Whoops, missed that in the title. fixed.


>
> I would also recommend separating "but not limited to" from the other
> text using commas on either side... but maybe that's just a personal
> preference of mine.
>

That would be too many commas, but added : after "to"

BTW, This will also undergo review by the RFC editor, so it is probably not
worth focusing too much on the lower-level typographical issues, especially
those that are a matter of preference.


>
> Also, could you clarify to me the purpose of the last paragraph of
> section 2.5? If a request is made for 'ja-t-it-m0-xxx-v21a-2007' and
> the recipient has content corresponding to that exact request, why
> would it ever even consider serving 'ja-t-it-m0-xxx-v21a-2009'?
> Wouldn't it make more sense to use an example where the recipient of
> the request does not have an exact match and thus must actually choose
> what it considers to be the closest equivalent?
>

good point. fixed.


>
> Fourth paragraph of section 2.9:
> "The XML structure lists the keys, such as <key extension="t"
> name="m0" alias="collation" description="Transliteration extension
> mechanism">,with subelements for the types, such as <type
> name="ungegn" description="United Nations Group of Experts on
> Geographical Names"/>."
>
> There is a space missing after the second comma.
>

Fixed ",with"


>
> And in section 4, the citation of "Section 3.7. Extensions and the
> Extensions Registry of "Tags for Identifying Languages" in [BCP47]" is
> inconsistent with the format used by similar citations throughout the
> document. I would recommend changing 'in' to 'of' and eliminating the
>

done


> period after '3.7', possibly couching the description in commas
> instead.
>

done, but we'll see what the RFC editor does with this, since it is a copy
of a similar section that is now an RFC.


>
> Hope that helps.
>

Yes, thanks!

Note to others: also fixed Yoshito=>Umaoka in

[RFC6067]Davis, M., Ed., Phillips, A., Ed., and Y. Yoshito, Ed., “BCP 47
Extension U,” September 2010.


>
> Gordon
>
> --
> Gordon P. Hemsley
> me@gphemsley.org
> http://gphemsley.org/http://gphemsley.org/blog/
>