Re: [Ltru] Preferred-Value for YU?

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

As a technical contributor...

> From: "Doug Ewell" <doug at ewellic.org>
> To: "LTRU Working Group" <ltru at ietf.org>
> Sent: Friday, February 06, 2009 8:26 PM
> Subject: Re: [Ltru] Preferred-Value for YU?
>
> 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.

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

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

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

True, but the statement that a change is permitted to impact others
is nonetheless true.
 
> 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.

True, but it does not cause a problem in this case, and I think it's
perfectly resonable to consider this 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.

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