Subject: Re: [Ltru] Preferred-Value for YU?

From: "Doug Ewell" <[email-masked]>
Date: Wed, 4 Feb 2009 21:32:26 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

>> Changes to one subtag MAY affect other subtags as well: when 
>> proposing changes to the registry, the Language Subtag Reviewer will 
>> review the registry for such effects and propose the necessary 
>> changes using the process in Section 3.5 (Registration Procedure for 
>> Subtags), although anyone MAY request such changes. For example:
> ...
>
> As a technical contributor, I think the current language,
> while not ideal, is tolerable.  One can read that first
> "MAY" with its strict RFC 2119 sense without anything
> "breaking."  Consequently, I'd prefer to leave the text
> as-is.

I think what it shows is that not every "may" should be a "MAY."  The 
sentence is supposed to say that changes to one subtag might affect 
other subtags, which is true.  Turning it into a 2199 MAY makes it look 
normative, which is not right.

--
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: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Feb 2009 20:54:13 -0800

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, February 04, 2009 8:32 PM
> Subject: Re: [Ltru] Preferred-Value for YU?
>
...

As a technical contributor:  I don't see how a strict RFC 2119 reading
of that text causes any problems.  It says that it is permitted, but not
required, for a change to one to have consequences for others.  That is
absolutely within the intent of the language.  Though it might have
started out as an "observation", the behavior is a logical consequence
of other normatively specified behaviours.  Putting the observation
in normative terms is, at worst, redundant.  If we were to eliminate
all the redundant stuff from this document, we'd have a much
slimmer specification, but doing so would not be worth the delay.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 4 Feb 2009 21:35:08 -0800

The problem isn't that is says "MAY"... But to have something say "MAY" enclose an example that says "MUST" makes no sense. It isn't "MAY" if you're required to do it. 

I think what is intended... and what makes sense... would be to change the 2119 keyword "MAY" to the regular word "can" (which is basically what I suggested before).

It's a bug. It's not a critical bug. And since we're stuck waiting for the IETF to figure out IPR issues, why not change the one word to fix it?

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Wednesday, February 04, 2009 8:54 PM
> To: LTRU Working Group
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Feb 2009 21:51:39 -0800

Hi -

As a technical contributor...

> From: "Phillips, Addison" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, February 04, 2009 9:35 PM
> Subject: RE: [Ltru] Preferred-Value for YU?
>
> The problem isn't that is says "MAY"... 
> But to have something say "MAY" enclose an example
> that says "MUST" makes no sense. It isn't "MAY" if
> you're required to do it. 

There currently is no "MUST" there.  Do you mean we should
replace the existing "will" with "MUST"?
 
> I think what is intended... and what makes sense... would
> be to change the 2119 keyword "MAY" to the regular word "can"
> (which is basically what I suggested before).

That has absolutely no effect on the normative requirements
of the spec.  Consequently, I could live with the change,
though it seems quite pointless to me.
 
> It's a bug. It's not a critical bug.

I still don't see a bug there.  What does the normative reading
permit (or not permit) that is any different from what would
(or would not) be permitted if the "MUST" were a "can"?

> And since we're stuck waiting for the IETF to figure out
> IPR issues, why not change the one word to fix it?

As a co-chair...

Because if we start making these sorts of trivial adjustments
at this point, all sorts of other non-changes will come out
of the woodwork.  I've seen late-stage "editorial cleanup"
introduce bugs too many times to be comfortable with that,
and I'm extremely reluctant to ask people to read yet another
version. At this stage my strong preference is to make
changes only if something is demonstrably broken.  Not
merely ugly, but broken as in "it cannot possibly work"
or "it does something the Internet cannot survive."
But perhaps co-chair Martin might be persuaded...

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 5 Feb 2009 07:15:02 -0800

> replace the existing "will" with "MUST"?

The "MUST" is in the example:

--
Changes to one subtag MAY affect other subtags as well: when proposing changes to the registry, the Language Subtag Reviewer will review the registry for such effects and propose the necessary changes using the process in Section 3.5 (Registration Procedure for Subtags), although anyone MAY request such changes. For example:

    Suppose that subtag 'XX' has a Preferred-Value of 'YY'. If 'YY' later changes to have a Preferred-Value of 'ZZ', then the Preferred-Value for 'XX' MUST also change to be 'ZZ'.
--
> But perhaps co-chair Martin might be persuaded...

I'm also fine with not changing it. It isn't that important.

Addison

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 5 Feb 2009 12:23:14 -0800

Hi -

> Sent: Thursday, February 05, 2009 7:15 AM
> Changes to one subtag MAY affect other subtags as well: when proposing changes to the registry, the Language Subtag Reviewer will
review the registry for such effects and propose the necessary changes using the process in Section 3.5 (Registration Procedure for
Subtags), although anyone MAY request such changes. For example:
>
>     Suppose that subtag 'XX' has a Preferred-Value of 'YY'. If 'YY' later changes to have a Preferred-Value of 'ZZ', then the
Preferred-Value for 'XX' MUST also change to be 'ZZ'.

I still see no real problem.  Though it would have been incrementally
better from a "standards stylistic" perspective to have not used
"MUST" there, I do not see how its presence either requires any
unintended behaviour or forbids anything we wanted to happen.
This "MUST" is still congruent with the RFC 2119 sense.

> I'm also fine with not changing it. It isn't that important.

I'm not as concerned about whether this one change does or does not
happen, as I am about fairness in process.  If we incorporate this one,
we need to work through all the other alleged typos, wording
improvements, and related churn that anyone on the list might bring up.
Our primary responsibility is to make sure that what we put out is
technically correct, and that any changes reflect operational experience
and other improvements / fixes called out in our charter.  Frankly,
editorial stuff worries me at this stage only if we have a situation
where an ambiguity or error in the text has led to implementation or
interoperability problems.  If the WG (and my co-chair) feel that another
round of editorial polishing would be time well spent, I can't overrule
y'all.  But I'd really like to keep the priority on making sure all the
technical stuff has been dealt with.

Randy