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

From: "Doug Ewell" <[email-masked]>
Date: Fri, 6 Feb 2009 21:26:25 -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:
>>
>> 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.

The problem isn't with the MUST, but with the MAY that precedes it.

As I remember the discussion from last year, we agreed that 
Preferred-Value references should -- nay, MUST -- be updated when 
necessary to get rid of these chains of pointers.  This was an 
intentional change from RFC 4646.  I can look up the discussion in the 
archives if needed.  I remembered that I would have to change my app to 
meet this new requirement.

The real problem is with the RFC 2119 MAY, which appears to contradict 
the MUST which follows, which would not have been seen as a problem if a 
regular old ordinary "may" had been used.  While I don't insist on 
changing any of this text at this phenomenally late date, the fact 
remains that "MAY" in the sense of "is allowed or permitted to" is not 
the same as "may" in the sense of "could happen, or could possibly 
result in."

It "may" snow in Denver this weekend.  That is not an RFC 2119 "MAY"; 
nobody is granting permission to the heavens to drop fluffy cold white 
stuff on us.

It is simply not correct to mechanically uppercase all occurrences of 
the word "may" in an Internet-Draft as though it always specifies an 
optional feature.

As long as the currently proposed draft-4646bis text allows and supports 
the change I proposed for draft-4645bis, to remove the Preferred-Value 
for 'YU' which currently points to another deprecated subtag, I am fine 
with it.  This is not a matter of editorial nitpicking; the 4645bis 
change raised a semantic question about the intent of the 4646bis 
passage.

--
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: Fri, 6 Feb 2009 21:12:43 -0800

Hi -

As a technical contributor...

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

:-) Look further back in the exchange, and you'll see I was responding
to a comment that the problem wasn't with the MAY, but with the MUST.

> meet this new requirement.

That would have been a powerful argument against making the change
in the first place.  However, something about the claim doesn't add up.
Code which is able to follow Preferred-Value chains will not have
a problem with a registry in which such chains do not happen.
 
> the same as "may" in the sense of "could happen, or could possibly 

True, but the statement that a change is permitted to impact others
is nonetheless true.
 
> the word "may" in an Internet-Draft as though it always specifies an 

True, but it does not cause a problem in this case, and I think it's
perfectly resonable to consider this an optional feature.
 
> change raised a semantic question about the intent of the 4646bis 

I think it's quite clear that the WG consensus was to permit changes
to Preferred-Value information in cases like this, to avoid requiring
implementations to walk pointer chains.  It's a change I think
we could have done without, but it was agreed and it's not time to
second-guess it.  I *still* don't see how the existing wording requires
anything we wish to prohibit, or prohibits anything we wish to allow.

Randy