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