draft-05: (mostly) editorial comments (3)

[Addison Phillips [wM]]

Peter wrote:
>
>
> > > What happens if an ID is added to ISO 639? E.g.
> > > "i-navaho" was registered, but later obsoleted by
> > > addition of a code in ISO 639. Will that continue to
> > > be the case or not? If not, then I would state that
> > > explicitly.
> >
> > AP> That would be the last sentence. Grandfathered tags
> > (like "i-navaho") become deprecated due to registration
> > of subtags (like 'nv'). I'll add an example.
>
> My example fit because it describes something that actually
> happened before, but was less than ideal since it involves a
> grandfathered tag. Let me try again: suppose I register a
> registered-lang subtag "afnoric", and then later ISO 639 gets a
> code "afn" (say) for the same language. In the past, the
> registered item would have been deprecated. If that's not the
> case now, I'm suggesting that be stated explicitly so that nobody
> gets the wrong impression from past practice.

It won't happen that way (we hope) because of this clause in Section 2.2:

<quot>All language subtags of 4 to 8 characters in length in the IANA
registry were defined via the registration process in Section 3.3  and MAY
be used to form the primary language subtag. At the time this document was
created, there were no examples of this kind of subtag and future
registrations of this type will be discouraged: primary languages are
STRONGLY RECOMMENDED for registration with ISO 639 and subtags rejected by
ISO 639 will be closely scrutinized before they are registered with
IANA.</quot>

In other words, one of the qualifications for being a registered primary
language subtag is that you've collected a rejection slip from ISO 639 RA
(in effect saying it isn't a language worthy of a code). How many
registrations will get created with that qualification?

The problem in the past (apparently) is that folks registered with IANA
*first* because it was easier and faster. Here we close off that loophole.
>
>
>
>
> PC>>Section 3.1: The structure of records isn't documented within
> the most recent version of the draft registry Doug Ewell has
> done. I think it should be included there as well as here. 
>  
> AP> Do we need text to that effect?
>
> No, not at all; just a suggestion for the data file only. It
> doesn't have to be a long description; just a line showing what
> each of the fields are would be appreciated.

Cool. We can do that.
>
>
>
> PC>>I had suggested when RFC 3066 was being drafted that
> reference to entries in Ethnologue should be suggested...
>
> AP> Is it really necessary? Endorsing particular references
> invites unnecessary criticism of the draft. Getting the
> references has never posed a problem in the past.
>
> If you're concerned it will invite criticism, leave it as it is.
>
I'm looking to close this document off as much as possible, so I will leave
it as is (unless Mark feels strongly otherwise).

Thanks again for your comments.

Best Regards,

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.