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

From: "Doug Ewell" <[email-masked]>
Date: Mon, 2 Feb 2009 20:21:43 -0700

"Phillips, Addison" <addison at amazon dot com> wrote:

> I notice, however, that there may be a consistency problem in Section 
> 3.1.7 of 4646bis-21, though. Specifically, it allows (MAY) a 
> Preferred-Value to "migrate forward". But then uses 
> perhaps-inappropriate normative language in the example covering 
> regions:
>
> --
> 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'.
> --

Indeed, this is the reason I suggested the change.  While CS doesn't 
have a Preferred-Value of its own, it is deprecated, so it seemed wrong 
to have YU point to CS.

I'm not eager to continue gilding this lily either, but this seemed like 
a possible conformance problem.  And God knows we have time, with these 
endless procedural delays.

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

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Edith Whitehead <[email-masked]>
Date: Fri, 6 Feb 2009 08:55:26 -0800 (PST)

Randy, Addison,

I agree with Randy that the text Addision cited does not need changing at this time, but at the same time I see Addison's point that the keyword 'MAY' is confusing here.  Here the draft is talking about an event that might/may/can happen as a result of changes to the registry.  It is not anything that anyone must or should or could do.  No one does anything.  It happens.  (The wind blows; you could turn a fan on and make it blow of course but you get my point  So the keyword MAY is confusing I think)

Nitpicking I guess but . . .

(Sorry to write from this account; unfortunately for some reason I can only log into help central of my hotmail account this morning; I cannot display my mail or send any or retrieve addresses from that account--which is a pain as I have an urgent/worry email to get to someone and can't remember the email address--which is in the other account)

Thanks.

(I do have a few corrections to the grammar; will send separately.)

From: "Randy Presuhn" <randy_presuhn at mindspring.com> 

Date: Thu, 5 Feb 2009 12:23:14 -0800 

> Hi -

> As a technical contributor...

>> From: "Phillips, Addison" <addison at amazon.com>
>> To: "Randy Presuhn" <randy_presuhn at mindspring.com>; "LTRU Working Group" <ltru at ietf.org>
>> Sent: Thursday, February 05, 2009 7:15 AM
>> 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"?
>>
>> 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'.

>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
I don't see this because this is not a 'must;' there are 2 issues:
(1), changes to one subtag MAY (or CAN) affect other subtags
(2), because of this, when a subtag changes, the language subtag reviewer MUST review the registry

The first is a MAY.
The second is a MUST.

However I tend to agree with Addison that the first may not need a keyword; it's not something anyone does; it's something that happens (on its own).

The keyword MAY seems out of place and confusing and I agree with Addison that it may be best replaced with 'can.'

Thanks.

--C. E. Whitehead
[email-masked]

> Randy

---

From: CE Whitehead <[email-masked]>
Date: Sat, 7 Feb 2009 10:34:16 -0500

Hi, I tend to agree with Doug here that the problem is with "MAY;" however I do not support lower-casing it, preferring Addison's suggestion to replace it with "can" (which is not a keyword) to avoid any confusion (otherwise it will look like a typo I think).
Substituting "can" for "may" eliminates the "may" issue here; unless we want to insist that we are granting permission for one change to affect others, then I see no reason whatsoever for "MAY" here; "can" will do.
From: "Randy Presuhn" <randy_presuhn at mindspring.com> 
Date: Fri, 6 Feb 2009 21:12:43 -0800 > Hi-

>> 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 
>> > unintended behaviour or forbids anything we wanted to happen.  This 
>> > "MUST" is still congruent with the RFC 2119 sense.
Agreed "MUST" is what we want to say I think. 
>> The problem isn't with the MUST, but with the MAY that precedes it.
I think so too.
>:-) 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 makes sense.
> 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 I like Addison's "can" here.
>> 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.Hmm.  This is a fine point here.
 
>> 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.This is my opinion too.
> 
>> 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.
Again substituting "can" for "may" eliminates the "may" issue here; unless we wantto insist that we are granting permission for one change to affect others, then I see no reason whatsoever for "MAY" here;"can" will do. 
--C. E. [email-masked]  (ah my email is back working; hope the different account did not cause confusion)

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 7 Feb 2009 09:24:26 -0700

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

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

Sorry, I wasn't clear about which app I was referring to.  I meant the 
one I use to take the current 4646 Registry and the ISO 639-3 files and 
generate the new 4646bis Registry, which I then incorporate into 
successive draft-4645bis versions.  That one needed to be taught to snap 
the pointers.

I could have also chosen to treat the "no chains" passage as a 
validation point in my tag-generating app, and reject the Registry if 
P-Vs pointed to subtags with other P-Vs, but I think I decided not to do 
that.  I put that app largely on hold after the back-and-forth 
experience with extlangs, pending publication

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

Who's doing the permitting?

In any case, as I said, I don't think it's something for which we need 
to hold up the IETF Last Call.  I don't see any reason to hold up the 
IETF Last Call, since the IETF is surely aware that the IPR boilerplate 
may have to be changed before publication anyway, but I suppose this 
group will find a reason to continue dragging its feet.