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

[Mark Davis <mark at macchiato.com>]

I could live with no change, but Debbie's change would also be ok, with some changes. The advantage of Debbie's approach is that we can make it much clearer who has the responsibility for what, and how the process works; and it does accommodate Alexey's request. The disadvantage is that the current language is good enough, and people are tired of this kind of tuning.

My suggested changes are below.

<old>
> >        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, and proposals rejected by ISO 639/ RA-
> >        JAC will be closely scrutinized by the Language Subtag Reviewer
> >        before they are registered with IANA.

</old>
<new style="broken into separate sentences for review">

At the time this document was created, there were no examples of this kind of subtag. Future registrations of this type are discouraged:

• Before a primary language subtag request could be accepted, the requester MUST supply evidence that a request for a language code was made to the ISO 639 JAC at least 180 days previously, and that the request was not accepted.
• The Language Subtag Reviewer MUST closely scrutinize any proposals rejected by ISO 639/ MA-JAC.

</new>

Changes were in grammar (simplify and make more direct), remove dependency on particular agents, and to account for the JAC not responding within a reasonable period (no problem currently, but we've all seen cases with ISO or IETF that just hang).


Mark

On Wed, Jun 10, 2009 at 06:11, Debbie Garside <debbie at ictmarketing.co.uk> wrote:

Not wishing to hold this up... but it would be better to have a MUST and it
is perfectly simple to enforce. Proposed text:

---

In order for a primary language subtag request to be considered for
registration within the Language Subtag Registry, the requester MUST supply
evidence that they have previously applied to the ISO 639 JAC to encode the
entity and that the request has been rejected.

---

I do see the need to go to ISO 639 JAC first.  We really do not want to
register primary language subtags and then find that after the event the ISO
639 JAC allocate their own subtag - which means ours would have to be
deprecated.

Thus I agree with Alexey and think it advisable to make the change.  Never
leave room for doubt unless you need to.

That said, I think we all know what we are about here and I would not hold
up this document for a lengthy discussion on this.

Kind regards

Debbie

-----Original Message-----
From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of Doug
Ewell
Sent: 10 June 2009 13:25
To: LTRU Working Group

Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language with
MUSTlanguage in 2.2.1 (Apps #12a)

Martin J. Dürst <duerst at it dot aoyama dot ac dot jp> wrote:

> Please express your preference (and the reasons for it) if you haven't
> already done so.

I agree that there is no need to change this RECOMMENDED to a MUST,
because I don't see any particular advantage to requiring the requester
to go to ISO 639 first instead of strongly encouraging her to do so, nor
any way to enforce such a requirement anyway.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru

Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.557 / Virus Database: 270.12.11/2089 - Release Date: 30/04/2009
17:53


Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.557 / Virus Database: 270.12.11/2089 - Release Date: 30/04/2009
17:53

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru