Hello Addison,
At 13:43 09/02/09, Phillips, Addison wrote:
>I didn't make the change to the text in part because it was overlooked.
Okay, no problem.
>However, I'm also allergic to the text you propose. The reference to 4645
>used to be normative because, in fact, it was normative in precisely this
>spot. However, the Channel Islands related registrations were accomplished
>in the 4646 era, so having a bit of "MAY" for them seems redundant.
That's not my understanding. Three registrations have been made,
but a fourth is still outstanding.
If I put together section 4 of RFC 4645:
>>>>
4. Omitted Code Elements
The following code elements from [UN_M.49] were not associated with
[ISO3166-1] alpha-2 code elements. Consequently, they were not
assigned as subtags in the initial Language Subtag Registry, but were
valid candidates for registration as region subtags, using the
process in [RFC4646]:
830 Channel Islands
831 Guernsey
832 Jersey
833 Isle of Man
The last three became ineligible for registration in April, 2006,
when the [ISO3166-1] code elements GG, JE, and IM were assigned as
region subtags.
>>>>
with section 2.2.4, point 4.E, of draft-ietf-ltru-4646bis-20.txt
(as currently published):
>>>>
E. UN numeric codes and ISO 3166-1 alpha-2 codes for countries
or areas listed as eligible for registration in Section 4 of
[RFC4645] but not presently registered MAY be entered into
the IANA registry via the process described in Section 3.5.
Once registered, these codes MAY be used to form language
tags.
>>>>
then for me, the NET RESULT is that
830 Channel Islands
is currently still available for registration. This matches the last
paragraph of section 4 of RFC 4645, as well as the current IANA registry,
which shows GG, JE, and IM as registered, but no registration for
"Channel Islands".
My reading of both 4645/4646 as well as the new drafts as published
(i.e. up to version -20), is that if somebody had a need to tag some language
(let's say English) with a region of "Channel Islands", then s/he could
apply to ietf-languages and require the code 830 to be enterend into
the IANA registry, and would then use en-830 for "English as used in
the Channel Islands".
>I therefore propose putting a version of your text shaped thusly:
>
>E. A few ISO 3166-1 codes, representing the Channel Islands, for which no
>UN M.49 code was assigned are assigned in the registry. For historic
>details, see [RFC 4645].
>
>This eliminates the (formerly necessary) normative reference and the
>no-longer-appropriate normative languages.
In my reading, this eliminates too much, and is a (small but) substantive
change, for which it's way too late (unless somebody comes and claims
that this is really, really important and affects interoperability).
If you don't like the exact text I propose, please propose alternative
text that doesn't change the content.
Regards, Martin.
>Addison
>
>
>Addison Phillips
>Globalization Architect -- Lab126
>
>Internationalization is not a feature.
>It is an architecture.
>
>
>> -----Original Message-----
>> From: Martin Duerst [mailto:duerst at it.aoyama.ac.jp]
>> Sent: Sunday, February 08, 2009 6:06 PM
>> To: Phillips, Addison; LTRU Working Group
>> Subject: Re: [Ltru] draft-21 mod: move RFC 4645 reference to
>> informative
>>
>> Hello Addison,
>>
>> At 02:23 09/02/09, Phillips, Addison wrote:
>> >Issue: move RFC 4645 reference to informative
>> >
>> >Resolution: moved to the informative section from the normative
>> section.
>> >The "normative" material in 4645 in question isn't up to the
>> standard of
>> >having a normative reference.
>>
>> This is as requested by the chairs. However, it is incomplete.
>>
>> On February 2nd, I wrote:
>>
>> >>>>>>>>
>> I have looked at this and at the diff, and have run the idnits tool.
>>
>> However, we now have an informative reference in a normative
>> sentence:
>>
>> E. UN numeric codes and ISO 3166-1 alpha-2 codes for
>> countries
>> or areas listed as eligible for registration in Section
>> 4 of
>> [RFC4645] but not presently registered MAY be entered
>> into
>> the IANA registry via the process described in Section
>> 3.5.
>> Once registered, these codes MAY be used to form
>> language
>> tags.
>>
>> My understanding from previous discussions (both Randy and I had
>> the same idea) was that for this instance of referencing [RFC4645],
>> we would replace it inline with the only instance left, resulting
>> in something like:
>>
>> E. The UN numeric code or ISO 3166-1 alpha-2 code (once
>> assigned)
>> for the Channel Islands MAY be entered into the IANA
>> registry
>> via the process described in Section 3.5 (for historic
>> details, see [RFC4645]).
>>
>> Can you please make such an update to your staging draft,
>> so that we are ready to move forward when the copyright
>> issues are solved.
>> >>>>>>>>
>>
>> I haven't seen anybody reply to this except for Gerard Lang.
>>
>> Can you please make the requested edit, or tell me why you
>> think it's not appropriate?
>>
>> Regards, Martin.
>>
>>
>> >Addison Phillips
>> >Globalization Architect -- Lab126
>> >
>> >Internationalization is not a feature.
>> >It is an architecture.
>> >
>> >
>> >_______________________________________________
>> >Ltru mailing list
>> >Ltru at ietf.org
>> >https://www.ietf.org/mailman/listinfo/ltru
>>
>>
>> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>> #-#-# http://www.sw.it.aoyama.ac.jp
>> mailto:duerst at it.aoyama.ac.jp
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.