[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] Preferred-Value for YU?



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.

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


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.