I oppose making these changes, not because Debbie’s text wouldn’t
make things clearer, but rather because the point of this paragraph was
precisely that it did NOT forbid attempts to register primary language subtags.
Each such request would be judged on its own merits. But the WG wanted to give
clear-enough guidance that it was unlikely that such a registration attempt
would succeed.
In Debbie’s proposal:
• The Language Subtag Reviewer MUST closely
scrutinize any proposals rejected by ISO 639/ MA-JAC.
I laughed at this one. The LSR must closely scrutinize any
proposal, one would hope.
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
From:
ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of Debbie
Garside
Sent: Wednesday, June 10, 2009 7:03 AM
To: 'Mark Davis'
Cc: 'LTRU Working Group'; 'Doug Ewell'
Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language with
MUSTlanguage in 2.2.1 (Apps #12a)
That’s excellent! Adding in the 180 days part will also help
with the re-organization of the ISO 639 JAC and ISO 639 registration/change
request processes that is currently on-going. I am putting together
proposals that will hopefully see the time element of the registration/change
request process reduced to less than 6 months – at the moment there is no time
limit. This wording will support the need for a more streamlined ISO 639
process.
One final thought, to cover all eventualities we could add the
words “or its successor” after “ISO 639 JAC”.
Kind regards
Debbie
From: mark.edward.davis at gmail.com
[mailto:mark.edward.davis at gmail.com] On Behalf Of Mark Davis
Sent: 10 June 2009 14:58
To: debbie at ictmarketing.co.uk
Cc: Doug Ewell; LTRU Working Group
Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language with
MUSTlanguage in 2.2.1 (Apps #12a)
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
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
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