Subject: Re: [Ltru] Proposed edits (davis)

From: "Mark Davis" <[email-masked]>
Date: Mon, 17 Mar 2008 16:48:35 -0700

These edits are missing from

http://inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html

Mark

On Fri, Feb 22, 2008 at 9:46 AM, Addison Phillips <[email-masked]>
wrote:

> Mark and I were working on a few edits. Herewith a summary of a couple
> things that we should put on-list.
>
> Mark Davis wrote:
> >
> >     DONE. Edited as follows:
> >
> ....
> >
> > I'd suggest the following change to your text, to make it pithier also.
> >
> > <t>For example: The Unicode Consortium defines a set of private
> > use extensions in LDML (<xref target="UTS35"></xref>, Locale Data
> > Markup Language, the Unicode standard for defining locale data) such as
> > in the tag "es-419-x-ldml-collation-traditio", which indicates Latin
> > American Spanish with traditional order for sorted lists.</t>
>
> Sounds good. I'll make that edit. I was a bit worried by having such a
> long example tag.
>
> >
> >     As technical contributor: I'm not sure we want to limit it this way.
> >     ietf-languages might register all sorts of weird general background
> >     information :-).
> >
> > I think the issue was to have a clear statement that we don't want tons
> > of text in the registry -- for that, people should look at other
> > sources. Can you think of an alternative?
>
> In RFC 4646 (during one of the drafts) we removed the warning:
>
> --
> Long screeds about a particular subtag are frowned upon.
> --
>
> It was felt that the word "screed" was both too obscure and too
> judgmental. Personally, I thought it did the job. Perhaps:
>
> --
> Large amounts of information about the use, history, or general
> background of a subtag are frowned upon: these generally belong and are
> encouraged in registration requests, but do not belong in the registry
> record proper.
> --
>
> Best Regards,
>
> Addison
>
> --
> Addison Phillips
> Globalization Architect -- Yahoo! Inc.
> Chair -- W3C Internationalization Core WG
>
> Internationalization is an architecture.
> It is not a feature.
>

-- 
Mark
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Addison Phillips <[email-masked]>
Date: Mon, 17 Mar 2008 17:28:45 -0700

Dang. I wonder what became of them? I know I did them to some copy of 
the text: the <t> markup is no accident in my response below.

Okay, this time for sure!

>     Sounds good. I'll make that edit. I was a bit worried by having such a

Done verbatim.

This one is slightly problematic. I couldn't find the original email 
specifying the location of the edit. I have therefore placed it into 
Section 3.1.10 Comments, where it appears to belong.

I also note that you and Doug later exchanged email on-list discussing 
alternate wordings. The last of these is here:

  http://www.ietf.org/mail-archive/web/ltru/current/msg09612.html

In incorporating this last suggested edit, I broke off the last sentence 
of the preceding (formerly sole) paragraph and did a smidge more editing 
to produce:

<t>The content of this field is not restricted, except by the need to 
register the information, the suitability of the request, and by 
reasonable practical size limitations. The primary reason for the 
Comments field is subtag identification: to help
distinguish the subtag from others with which it might be confused. In
particular, large amounts of information about the use, history, or
general background of a subtag are frowned upon as these generally
belong and are encouraged in registration request forms themselves, but 
do not belong in the registry record proper.</t>

---

I clicked "save" twice on draft-13 (editor's copy) and will post it 
shortly to inter-locale.

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 17 Mar 2008 17:31:50 -0700

It appears that we had consensus on this (from the thread), but I don't see
it in draft 13.

Mark

On Wed, Feb 13, 2008 at 2:19 PM, Randy Presuhn <[email-masked]>
wrote:

> Hi -
>
> As co-chair, I'm splitting this item into a separate thread since it
> calls for what in my judgement could be understood to be a technical
> change.
>
> Randy
>
> > From: "Mark Davis" <[email-masked]>
> > To: "LTRU Working Group" <[email-masked]>
> > Sent: Wednesday, February 13, 2008 11:01 AM
> > Subject: [Ltru] Proposed edits (davis)
> ...
> > MD11
> >    2.  Subtags of type 'Region' that have a Preferred-Value mapping in
> >        the IANA registry (see Section 3.1) SHOULD be replaced with their
> >        mapped value.  Note: In rare cases, the mapped value will also
> >        have a Preferred-Value.
> >
> >    3.  Redundant or grandfathered tags that have a Preferred-Value
> >        mapping in the IANA registry (see Section 3.1) MUST be replaced
> >        with their mapped value.  These items either are deprecated
> >        mappings created before the adoption of this document (such as
> >        the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are
> >        the result of later registrations or additions to this document
> >        (for example, "zh-hakka" was deprecated in favor of the ISO 639-3
> >        code 'hak' when this document was adopted).
> >
> >    4.  Other subtags that have a Preferred-Value mapping in the IANA
> >        registry (see Section 3.1) MUST be replaced with their mapped
> >        value.  These items consist entirely of clerical corrections to
> >        ISO 639-1 in which the deprecated subtags have been maintained
> >        for compatibility purposes.
> > =>
> >    2.  Subtags of type 'Region' that have a Preferred-Value mapping in
> >        the IANA registry (see Section 3.1) are recursively replaced with
> their
> >        mapped value.  Note: In rare cases, the mapped value will also
> >        have a Preferred-Value.
> >
> >    3.  Redundant or grandfathered tags that have a Preferred-Value
> >        mapping in the IANA registry (see Section 3.1) are recursively
> replaced
> >        with their mapped value.  These items either are deprecated
> >        mappings created before the adoption of this document (such as
> >        the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are
> >        the result of later registrations or additions to this document
> >        (for example, "zh-hakka" was deprecated in favor of the ISO 639-3
> >        code 'hak' when this document was adopted).
> >
> >    4.  Other subtags that have a Preferred-Value mapping in the IANA
> >        registry (see Section 3.1) are recursively replaced with their
> mapped
> >        value.  These items consist entirely of clerical corrections to
> >        ISO 639-1 in which the deprecated subtags have been maintained
> >        for compatibility purposes.
> > [We are defining 'canonical order'. MUST and SHOULD are inappropriate
> > in a definition -- and were inconsistently used, since #1 and #5 don't
> > use them. Also, we have to have recursive replacement of tags in order
> > to get an idempotent result!]
>
>
> http://www.ietf.org/mailman/listinfo/ltru
>

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 17 Mar 2008 17:36:15 -0700

It appears that we had consensus on this, but I don't see it in the text of
#13.

Mark

On Wed, Feb 13, 2008 at 2:26 PM, Mark Davis <[email-masked]>
wrote:

> +1
>
>
> On Feb 13, 2008 1:13 PM, Randy Presuhn <[email-masked]>
> wrote:
>
> > Hi -
> >
> > As a technical contributor...
> >
> > > MD8
> > >    replace the content of the source standard itself.  The
> > descriptions
> > >    are not intended to be the localized English names for the subtags.
> > >    Localization or translation of language tag and subtag descriptions
> > >    is out of scope of this document.
> > > =>
> > >    replace the content of the source standard itself.  The
> > descriptions
> > >    are not intended to be the localized English names for the subtags.
> > >    Localization or translation of language tag and subtag descriptions
> > >    is out of scope of this document.
> > >
> > >    Descriptions should contain all and only that information necessary
> > >    to distinguish one subtag from others that it might be confused
> > with.
> > >    They are not intended to provide general background information,
> > >    nor to provide all possible alternate names or designations.
> > >
> > > [add more guidance on scope of descriptions]
> >
> > "should" -> "SHOULD" (since this really is a normative usage)
> > otherwise the proposal looks ok to me.
> >
> > Randy
> >

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 17 Mar 2008 17:44:16 -0700

looks good.