[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] Issue #59: replace RECOMMENDED language with MUST languagein 2.2.1 (Apps #12a)



Hi -

> From: "Alexey Melnikov" <alexey.melnikov at isode.com>
> To: "LTRU Working Group" <ltru at ietf.org>
> Cc: "Martin J. Dürst" <duerst at it.aoyama.ac.jp>; "Randy Presuhn" <randy_presuhn at mindspring.com>
> Sent: Saturday, June 06, 2009 1:14 PM
> Subject: Re: Additional issues with 4646bis raised by an Apps Review Team review
....
> 12). In Section 2.2.1:
>
> >    5.  Any language subtags of 5 to 8 characters in length in the IANA
> >        registry were defined via the registration process in Section 3.5
> >        and MAY be used to form the primary language subtag. An example
> >        of what such a registration might include: one of the
> >        grandfathered IANA registrations is "i-enochian".  The subtag
> >        'enochian' could be registered in the IANA registry as a primary
> >        language subtag (assuming that ISO 639 does not register this
> >        language first), making tags such as "enochian-AQ" and "enochian-
> >        Latn" valid.
> >
> >        At the time this document was created, there were no examples of
> >        this kind of subtag and future registrations of this type are
> >        discouraged: primary languages are strongly RECOMMENDED for
> >        registration with ISO 639,
>
> I suggest that the RECOMMENDED is changed to a MUST, i.e. an attempt to
> register it with ISO 639 must be made. Even if the outcome might be
> known, arguments given by ISO 639 might provide useful input to the
> Language Subtag Expert.
>
> >       and proposals rejected by ISO 639/ RA-
> >        JAC will be closely scrutinized by the Language Subtag Reviewer
> >        before they are registered with IANA.
...

As a technical contributor, I can agree with this proposal, as long as the case
of non-response or negative response is covered.

Randy



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.