Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

From: "Doug Ewell" <[email-masked]>
Date: Wed, 10 Jun 2009 06:21:30 -0600

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

> Please express your preference

For the record, I have no opinion on this matter, since my understanding 
of the capitalized RFC 2119 keyword "MAY" does not agree with other WG 
members.  I thought it referred only to that which processes were 
permitted, but not required, to do, but it turns out that it is also 
acceptable for stating simple possibility as well.

--
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  ˆ

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 10 Jun 2009 06:24:58 -0600

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.

---

From: Marion Gunn <[email-masked]>
Date: Wed, 10 Jun 2009 13:30:39 +0100

That MAY use is a fuzziness specific to English, Doug - all languages 
have their own features, so readers of this doc will be well aware of 
the uses of MAY, etc. Might I suggest, at this stage, that, since the 
rate of LTRU msgs coming in during the time allocated for this work made 
it impossible for anyone otherwise gainfully employed to read and 
comment on all issues, big and small. You may rest assured that experts 
reading this group's final document will make allowance for the fact 
that most who contributed to its compilation have never studied English, 
or any other language, to any depth, so their principal responsibilites 
were (a) to consult those who have and (b) not to add any more to the 
number of errors already contained in the documents referenced 
internally in said document. Please let it go now, as the best that 
could be done with the brief and the team available, without causing 
further delay up the line, where it is awaited.

Sincerely,
mg

-- 

Marion Gunn * eGteo (Estab.1991)

27 Páirc an Fhéithlinn, Baile an

Bhóthair, An Charraig Dhubh,

Co. Átha Cliath, Éire/Ireland

* [email-masked] * [email-masked] *

Scríobh Doug Ewell:

> For the record, I have no opinion on this matter, since my 
> understanding of the capitalized RFC 2119 keyword "MAY" does not agree 
> with other WG members.  I thought it referred only to that which 
> processes were permitted, but not required, to do, but it turns out 
> that it is also acceptable for stating simple possibility as well.
>
> -- 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

---

From: Kent Karlsson <[email-masked]>
Date: Wed, 10 Jun 2009 14:47:27 +0200

The process of maintaining the registry is permitted, but not
required, to change Description fields. I agree that the
current text could be formulated better. Peter suggested
redrafted text.

    /kent k

> express your preference

For the record, I have no opinion on this matter,
> since my understanding 
of the capitalized RFC 2119 keyword "MAY" does not
> agree with other WG 
members.  I thought it referred only to that which
> processes were 
permitted, but not required, to do, but it turns out that it
> is also 

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

Ltru mailing
> list
[email-masked]

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 10 Jun 2009 06:55:20 -0600

> current text could be formulated better. Peter suggested

Fine.  I do not object.

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 10 Jun 2009 14:11:00 +0100

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: [email-masked] [mailto:[email-masked]] 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)

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

---

From: Peter Constable <[email-masked]>
Date: Wed, 10 Jun 2009 06:50:36 -0700

Would that language get interpreted as saying IETF-languages can't even discuss the details of a request until that has been done?

What problem is being fixed here? (I don't know that we have an existing problem.)

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Debbie Garside
Sent: Wednesday, June 10, 2009 6:11 AM
To: 'Doug Ewell'; 'LTRU Working Group'
Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language with MUSTlanguage in 2.2.1 (Apps #12a)

--- 

---

Kind regards

Debbie

-----Original Message-----

--
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  ^

---

From: Mark Davis <[email-masked]>
Date: Wed, 10 Jun 2009 06:58:21 -0700

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

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 10 Jun 2009 07:53:26 -0600

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> 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 guess the evidence would be in the form of an e-mail trail.

> 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.

This is a good point.  But I can imagine JAC turning down a request at 
first, when presented by an individual with a few Web references (who 
proceeds to persuade the Reviewer to register it), and then subsequently 
approving a later request for the same entity when presented by a 
national standards body citing more "serious" references.  That would 
cause ietf-languages to have to deprecate the primary language subtag 
anyway.  There is already considerable churn in ISO 639-3, certainly 
more than we've seen with the other parts (although perhaps commensurate 
with the difference in scope).

I wouldn't fight hard against making this change, I just didn't see it 
as necessary.

I do feel, as others do, that it is highly unlikely that ietf-languages 
and the Reviewer will ever approve a non-639 primary language subtag, 
either one that has not been presented to 639 or one that has been 
rejected.

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 10 Jun 2009 15:03:13 +0100

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Davis
Sent: 10 June 2009 14:58
To: [email-masked]
Cc: Doug Ewell; LTRU Working Group
Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language with
MUSTlanguage in 2.2.1 (Apps #12a)

<old>

</old>

*	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>

Mark

On Wed, Jun 10, 2009 at 06:11, Debbie Garside <HYPERLINK
"mailto:[email-masked]"[email-masked]> wrote:

---

---

Kind regards

Debbie

-----Original Message-----
From: HYPERLINK "mailto:[email-masked]"[email-masked]
[mailto:HYPERLINK "mailto:[email-masked]"[email-masked]] On
Behalf Of Doug
Ewell
Sent: 10 June 2009 13:25
To: LTRU Working Group

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

_______________________________________________
Ltru mailing list
HYPERLINK "mailto:[email-masked]"[email-masked]
HYPERLINK "https://www.ietf.org/mailman/listinfo/ltru"
\nhttps://www.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
HYPERLINK "mailto:[email-masked]"[email-masked]
HYPERLINK "https://www.ietf.org/mailman/listinfo/ltru"
\nhttps://www.ietf.org/mailman/listinfo/ltru

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 10 Jun 2009 15:15:31 +0100

Peter wrote:

>> Would that language get interpreted as saying IETF-languages can't even
discuss the details of a request until that has been done?

I don't see any reason why a requester could not notify the list that a
change request has been made and I also see no reason why IETF-languages
could not discuss such a request.  

In fact, given the new processes that we are hoping to introduce within ISO
it would be an excellent forum for the ISO management and verification teams
to reference.  ISO needs input from the relevant communities in order to
support the decision making process - linguistic/stakeholder/industry.  

>>What problem is being fixed here? (I don't know that we have an existing
problem.)

It is a matter of clarity.  If we do not state that a requester MUST first
apply to the ISO 639 JAC there will always be the awkward cuss who comes
along and causes a huge rumpus - we have had our fair share of these and
sometimes it is better to dot the i's and cross the t's.  It could save us a
lot of time in the future.

Kind regards

Debbie 

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Debbie Garside

--- 

---

Kind regards

Debbie

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 10 Jun 2009 15:22:07 +0100

>>I guess the evidence would be in the form of an e-mail trail.

All change requests are publicized by the RA's in question (I believe).

Kind regards

Debbie

-----Original Message-----
From: Doug Ewell [mailto:[email-masked]] 
Sent: 10 June 2009 14:53
To: LTRU Working Group
Cc: [email-masked]
Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language with MUST
language in 2.2.1 (Apps #12a)

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 10 Jun 2009 08:21:28 -0700

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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: 10 June 2009 14:58
To: [email-masked]
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.

<old>

</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 <[email-masked]<mailto:[email-masked]>> 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:

---

---

Kind regards

Debbie

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 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)

[email-masked]<mailto:[email-masked]>

_______________________________________________
Ltru mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: Peter Constable <[email-masked]>
Date: Wed, 10 Jun 2009 08:23:47 -0700

"...at least 180 days previously..."

Does that mean if a request was made to the JAC ten years ago and rejected then it can proceed in IETF-languages? Or did you, rather, mean that the request should have gone to the JAC _within the past 180 days_?

Btw, I'm worried that we're going to rat-hole on getting the wording right to fix a problem that, AFAICT, doesn't exist.

Peter

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

<old>

</old>

Mark

---

---

Kind regards

Debbie

---

From: Peter Constable <[email-masked]>
Date: Wed, 10 Jun 2009 08:25:55 -0700

From: Debbie Garside [mailto:[email-masked]] 

> lot of time in the future.

You say, "we have had our fair share of these", but in over ten years participating in IETF-languages I don't recall any serious problems having arisen of the type we're discussing.

Peter

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 10 Jun 2009 08:36:29 -0700

> 
> >>What problem is being fixed here? (I don't know that we have an
> existing
> problem.)
> 
> You say, "we have had our fair share of these", but in over ten
> years participating in IETF-languages I don't recall any serious
> problems having arisen of the type we're discussing.
> 

We do have some examples. For example, 'no-nyn' and 'no-bok' -> nn/nb

Note that ALL of these predate 4646, when the rules were changed. It is a benefit of subtag (vs whole-tag) registration that we're more likely to deprecate a variant (not really that painful) than come into conflict with ISO 639. Our current text effectively says that we won't register any of these special primary language subtags, while preserving an escape hatch "just in case" we turn out to be wrong to prohibit it. There is certainly an intention that requesters should go to ISO 639 first and part of making the LSR "king of all subtags" is that s/he can effectively reject such requests on the basis that the requester doesn't have any evidence of a rejection slip from 639... without getting into the question of whether the request has merit. If 639 rejected it, the LSR would then have to consider the merit issue.

Like Peter, I don't see that we're actually fixing anything broken here.

Addison

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 10 Jun 2009 17:18:22 +0100

>>I laughed at this one. The LSR must closely scrutinize any proposal, one
would hope.

This was not my proposal, but I think the intention was to say that
proposals rejected by the JAC would have the reasons for rejection closely
scrutinised by the Language Subtag Reviewer.

I don't want this to become a show stopper.  I think if we could word
something during the course of the next 12 hours that gains consensus then
we make the change otherwise I think we can all live with the text as is.

Kind regards

Debbie

  _____  

From: Phillips, Addison [mailto:[email-masked]] 
Sent: 10 June 2009 16:21
To: [email-masked]; 'Mark Davis'
Cc: 'LTRU Working Group'; 'Doug Ewell'
Subject: RE: [Ltru] Issue #59: replace RECOMMENDED language withMUSTlanguage
in 2.2.1 (Apps #12a)

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

It is an architecture.

Kind regards

Debbie 

  _____  

<old>

</old>

</new>

Mark

On Wed, Jun 10, 2009 at 06:11, Debbie Garside <[email-masked]>
wrote:

---

---

Kind regards

Debbie

---

From: Mark Davis <[email-masked]>
Date: Wed, 10 Jun 2009 09:54:22 -0700

Oh, ask Mike Ksar about trying to get a response from the IETF charset
registry!

But as I said, because the likelyhood of the text being invoked is so low,
I'm ok with the current language, as imprecise as it is.

Mark

On Wed, Jun 10, 2009 at 08:25, Peter Constable <[email-masked]>wrote:

> You say, "we have had our fair share of these", but in over ten years
> participating in IETF-languages I don't recall any serious problems having
> arisen of the type we're discussing.
>
>
>
> Peter

---

From: Peter Constable <[email-masked]>
Date: Wed, 10 Jun 2009 10:06:31 -0700

We have examples of tags that got registered. But as you say, that was before 4646, and I don't think there have been cases in which someone was advised to start with the JAC and created difficulties by refusing to do so.

Peter

-----Original Message-----
From: Phillips, Addison [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2009 8:36 AM
To: Peter Constable; [email-masked]; 'Doug Ewell'; 'LTRU Working Group'
Subject: RE: [Ltru] Issue #59: replace RECOMMENDED language withMUSTlanguage in 2.2.1 (Apps #12a)

Addison

---

From: Peter Constable <[email-masked]>
Date: Wed, 10 Jun 2009 10:15:09 -0700

Problems with the charset registry does not imply problems with the langtag registry. The problems that a change in wording *would* solve would be a case in which someone wants to register a primary language subtag and the LST Reviewer fails to ask that they go first to the JAC, or a case in which the requester is advised to check first with the JAC but they refuse to do so and IETF-languages doesn’t care, or a case in which they refuse to do that, IETF-languages rejects their request and the requester escalates to IESG. I don’t think there’s a real risk of these scenarios happening. (And the last would simply be a temporary inconvenience, not a lasting problem.)

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Wednesday, June 10, 2009 9:54 AM
To: Peter Constable
Cc: [email-masked]; Doug Ewell; LTRU Working Group
Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language withMUSTlanguage in 2.2.1 (Apps #12a)

Oh, ask Mike Ksar about trying to get a response from the IETF charset registry!

But as I said, because the likelyhood of the text being invoked is so low, I'm ok with the current language, as imprecise as it is.

Mark

On Wed, Jun 10, 2009 at 08:25, Peter Constable <[email-masked]<mailto:[email-masked]>> wrote:
From: Debbie Garside [mailto:[email-masked]<mailto:[email-masked]>]

Peter

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 10 Jun 2009 19:53:22 -0600

> “or its successor” after “ISO 639 JAC”.

When I read this, I thought of how much effort and text we have already 
devoted to trying to cover all eventualities.

Even if there are concrete plans to overhaul the ISO 639 administration, 
I think it would take a creative mind to read "ISO 639 JAC" in the RFC 
as not applying to a successor body.  But if the rest of Debbie's 
proposal (or someone else's) is approved, these three additional words 
probably wouldn't hurt.

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 10 Jun 2009 19:55:27 -0600

> I laughed at this one. The LSR must closely scrutinize any proposal, 

Not only that, it's a redundancy.  "Scrutinize" means to look at 
something closely.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 11 Jun 2009 11:34:33 +0900

> Oh, ask Mike Ksar about trying to get a response from the IETF charset

I think that was years and years ago. Also, as far as I remember, he 
didn't understand very well how the process worked. Anyway, I think it's 
irrelevant for the current discussion.

Regards,    Martin. [now, but not then, an expert reviewer for charsets]

> On Wed, Jun 10, 2009 at 08:25, Peter Constable<[email-masked]>wrote:
>
> ------------------------------------------------------------------------
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 11 Jun 2009 11:47:52 +0900

[hats on]

> 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 prima…

It also seems to be my recollection that we didn't want to forbid 
attempts to register primary language subtags, but wanted to make clear 
that the chances of a direct registration would be extremely small.

The way I judge the current consensus is that we have a rough consensus 
against any changes on this issue, despite some recent textual 
proposals. I will close this issue in this way tomorrow unless we get 
additional input and evidence. I instruct the editors to produce the 
next version of the draft without changes unless they hear from me 
otherwise.

Please note that
1) This issue did not come from Alex (our AD), but from a third-party 
reviewer. Alex, as far as I understand, wants to make sure that we 
discuss it and either reconfirm what we have done or adopt some changes 
along the lines proposed.
2) Introducing new features (such as a timespan,...) shouldn't be done 
at this stage unless absolutely necessary.

Regards,    Martin.

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 11 Jun 2009 10:35:02 -0700

(editor hat on)

I do not have more current guidance on this issue, so I am treating it as resolved as 'wontfix'.

Addison

Addison Phillips

> From: "Martin J. Dürst" [mailto:[email-masked]]
> Sent: Wednesday, June 10, 2009 7:48 PM
> To: Phillips, Addison
> Cc: [email-masked]; 'Mark Davis'; 'LTRU Working Group';
> 'Doug Ewell'
> > 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.
>