Subject: [Ltru] Last open item

From: "Mark Davis" <[email-masked]>
Date: Thu, 10 Apr 2008 12:52:18 -0700

I went through all the pending comments to see which didn't have objections
raised on the list. The only open substantive issue I think we have left is
about whether to change the following lines:

The field 'Preferred-Value' MUST NOT be modified once created in the
registry. The field MAY be added to records according to the rules in
Section 3.3 (Maintenance of the
Registry)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#maintreg>
.

*(note: we don't have a similar phrase for Deprecated)*

Values in the fields 'Type', 'Subtag', 'Tag', 'Added', 'Deprecated' and
'Preferred-Value' MUST NOT be changed and are guaranteed to be stable over
time.

Here is my reasoning. We can't guarantee complete stability over time.
Whenever Deprecated or Preferred-Value are added, it changes the canonical
form; or if the target of a Preferred-Value is itself deprecated. Currently
if a subtag is deprecated in a source standard in favor of another, nothing
special needs to be done unless:

   1. there is a collision - the same subtag with a different meaning
   (like CS), OR
   2. the preferred subtag is an older deprecated code (eg BU => MM =>
   BU), OR
   3. the target of the Preferred-Value itself becomes deprecated (we
   want to resolve it so that users don't have to).

In the first 2 cases, we are forced to use a "special" code, eg change MM to
104. That's perfectly fine in the case of collisions (#1). However, it is
completely unnecessary in the case of older deprecated codes. So my proposal
is to change the above lines to drop the first one, and change the second
to:

Values in the fields 'Type', 'Subtag', 'Tag', and 'Added' MUST NOT be
changed and are guaranteed to be stable over time. Values in the
'Deprecated' and 'Preferred-Value' MUST NOT be changed unless the tag or
subtag in the Preferred-Value field is itself deprecated, or if a
deprecation is reversed in one of the source standards.

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

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 10 Apr 2008 16:32:40 -0700

Ok, not completely the last. Addison and I are trying to wrap this all up,
and ran across one other.

Before forwarding a new registration to IANA, the Language Subtag Reviewer
MUST ensure that values in the 'Subtag' field match case according to the
description in Section 3.1.
=>

Before forwarding a new registration to IANA, the Language Subtag Reviewer
MUST ensure that values in the 'Subtag' field match case according to the
description in Section 3.1, and that all other requirements of this
specification are followed.

Rationale. It has been implicit in all of our discussions and in the
document that the LSR must follow all of the policies in the document are
followed, *not just casing*. However, it isn't really explicit in the
document, and should be. This is a minimal change to that end (although
other wording would be possible).

Mark

On Thu, Apr 10, 2008 at 12:52 PM, Mark Davis <[email-masked]>
wrote:

> I went through all the pending comments to see which didn't have
> objections raised on the list. The only open substantive issue I think we
> have left is about whether to change the following lines:
>
> Section 3.3 (Maintenance of the Registry)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#maintreg>
> .
>
> In the first 2 cases, we are forced to use a "special" code, eg change MM
> to 104. That's perfectly fine in the case of collisions (#1). However, it is

---

From: Martin Duerst <[email-masked]>
Date: Fri, 11 Apr 2008 16:07:12 +0900

If Doug (and Michael) are fine with this change, I'm fine
with it, too.

Regards,   Martin.

At 08:32 08/04/11, Mark Davis wrote:
>Ok, not completely the last. Addison and I are trying to wrap this all up, and ran across one other.
>
>Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1.
>=>
>
>Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1, and that all other requirements of this specification are followed.
>
>Rationale. It has been implicit in all of our discussions and in the document that the LSR must follow all of the policies in the document are followed, not just casing. However, it isn't really explicit in the document, and should be. This is a minimal change to that end (although other wording would be possible).
>
>Mark
>
>On Thu, Apr 10, 2008 at 12:52 PM, Mark Davis <<mailto:[email-masked]>[email-masked]> wrote:
>>I went through all the pending comments to see which didn't have objections raised on the list. The only open substantive issue I think we have left is about whether to change the following lines:
>>
>>The field 'Preferred-Value' MUST NOT be modified once created in the registry. The field MAY be added to records according to the rules in <http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#maintreg>Section 3.3 (Maintenance of the Registry).
>>
>>(note: we don't have a similar phrase for Deprecated)
>>
>>Values in the fields 'Type', 'Subtag', 'Tag', 'Added', 'Deprecated' and 'Preferred-Value' MUST NOT be changed and are guaranteed to be stable over time.
>>
>>Here is my reasoning. We can't guarantee complete stability over time. Whenever Deprecated or Preferred-Value are added, it changes the canonical form; or if the target of a Preferred-Value is itself deprecated. Currently if a subtag is deprecated in a source standard in favor of another, nothing special needs to be done unless: 
>>    * there is a collision - the same subtag with a different meaning (like CS), OR 
>>    * the preferred subtag is an older deprecated code (eg BU => MM => BU), OR 
>>    * the target of the Preferred-Value itself becomes deprecated (we want to resolve it so that users don't have to). 
>>In the first 2 cases, we are forced to use a "special" code, eg change MM to 104. That's perfectly fine in the case of collisions (#1). However, it is completely unnecessary in the case of older deprecated codes. So my proposal is to change the above lines to drop the first one, and change the second to:
>>
>>Values in the fields 'Type', 'Subtag', 'Tag', and 'Added' MUST NOT be changed and are guaranteed to be stable over time. Values in the 'Deprecated' and 'Preferred-Value' MUST NOT be changed unless the tag or subtag in the Preferred-Value field is itself deprecated, or if a deprecation is reversed in one of the source standards.
>>
>>-- 
>>Mark 
>
>
>
>-- 
>Mark 

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: John Cowan <[email-masked]>
Date: Fri, 11 Apr 2008 09:24:13 -0400

> deprecation is reversed in one of the source standards.

+1

-- 
I now introduce Professor Smullyan,             John Cowan
who will prove to you that either               [email-masked]
he doesn't exist or you don't exist,            http://www.ccil.org/~cowan
but you won't know which.                               --Melvin Fitting
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 13 Apr 2008 15:06:08 -0600

Hi -

As a technical contributor...

> From: "Mark Davis" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Thursday, April 10, 2008 1:52 PM
> Subject: [Ltru] Last open item
>

I object to making this change.  Case (1) is already prohibited in sections
3.4(10) and 3.6 of RFC 4646.  Case (2) is already covered by 3.4(9) - but 
perhaps we should emphasize the optionality implied by the "MAY" in that
clause, because generally, in the interest of stability, one would not want
to put in a new preferred value.  Case (3) is a non-problem.  The "deprecated"
in the record only refers to the status in the source standard, not the
validity of the string as a language tag, as should be very clear from the
first sentence of 3.4(0)

Adopting this change would add instability without providing any value,
and the cases cited as motivations are already covered by the RFC 4646
rules.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 14 Apr 2008 08:15:27 -0700

On Sun, Apr 13, 2008 at 2:06 PM, Randy Presuhn <[email-masked]>
wrote:

> objections
> > Registry)<
> http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#maintreg>
> > .
> >
> 3.4(10) and 3.6 of RFC 4646.

Understood. I was summing up the position, and did not request any change in
#1. Note that I am talking about two different, interrelated fields:
Deprecated, and Preferred-Value.

> Case (2) is already covered by 3.4(9) - but
> to put in a new preferred value.

Case 2 is not covered by 3.4(9), and the fix that I am recommending would
change current text.

3.4(9) is: "Codes assigned by ISO 639-1 that do not conflict with existing
two-letter primary language subtags and which have no corresponding
three-letter primary defined in the registry are entered into the IANA
registry as new records of type 'language'." I'm not sure how it applies to
the cases I'm discussing, and it certainly doesn't apply to region codes.

Let me start again. I'll apologize for being a bit long-winded, but I think
it's important to have some specific examples. The situation I discuss in #2
is where there is a case like:

*Initial State
*
Subtag: X
Preferred-Value: Y
Deprecated: 1989-01-01
...
Subtag: Y

X and Y could be 'in' and 'id', OR 'BU' and 'MM', OR some script tag (no
instances yet). Note that both X and Y are valid, both with the same
meaning, and Y is preferred.

*The change.*

ISO restores X to being the correct tag, and deprecates Y.

*Our response.
*
There are three courses of action we could take. B2 is in the current text
(although not clearly -- see below).

*(A) Revert to old tag

*Subtag: X
*[removed old Preferred-Value and Deprecated]*
...
Subtag: Y
* Preferred-Value: X*
* Deprecated: 2010-01-01*

*(B1) Make new tag (and fix recursion)

*Subtag: X
Preferred-Value: *Z*
Deprecated: 1989-01-01
...
Subtag: Y
*Preferred-Value: Z*
* Deprecated: 2010-01-01*
...
Subtag: Z

Z will be of the form '666' for a region or 'zzzzz' for a language subtag.

*(B2) Make new tag (require users to do recursion)

* Subtag: X
Preferred-Value: Y****
Deprecated: 1989-01-01
...
Subtag: Y
* Preferred-Value: Z*
* Deprecated: 2010-01-01*
...
Subtag: Z

Z will be of the form '666' for a region or 'zzzzz' for a language subtag.

Note that in all of these cases both X and Y are still valid, both with the
same meaning.

If we do B1 or B2, we needlessly deviate from ISO, and are forced into using
an new, non-ISO code for something that is perfectly reasonable. Why is this
a good idea?

We still have stability in *all* of these cases. All codes before and after
any of these options are valid. The only difference is in the preferred
form. In the case of A, we are closer to ISO; for B we pointlessly depart
from ISO. And in case B2, we have the added disadvantage that if users don't
do the recursion correctly, they will end up with incorrect preferred
values.

Moreover, the current text is not clear with regard to the difference
between B1 and B2.

   - "If a tag or subtag has a 'Preferred-Value' field in its registry
   entry, then the value of that field SHOULD be used to form the language tag
   in preference to the tag or subtag in which the preferred value appears."
   (4.1(3))
   - "Subtags of type 'Region' that have a Preferred-Value mapping in the
   IANA registry (see Section 3.1 (Format of the IANA Language Subtag
   Registry)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#ianaformat>)
   MUST be replaced with their mapped value. Note: In rare cases, the mapped
   value will also have a Preferred-Value.". (4.4(1))

4.1(3) doesn't mention the possibility of recursion. If the user doesn't
realize that the registry doesn't already resolve the PV chains, he'll
happily substitute Y for X and think he's done, not realizing that he has to
go look at Y to see that it in turn should be replaced by Z.
4.4(1) does mention it, but could be clearer that the user must recurse.

> Case (3) is a non-problem.  The "deprecated"

I am talking about BOTH the Deprecated status and the Preferred-Value
status, in all of my original message if you look back at it. These are
distinct, yet intertwined.

> and the cases cited as motivations are already covered by the RFC 4646

I disagree. Can you go into more detail -- with examples -- of how you think
approach (A) would add instability with regard to codes?

Because both codes X and Y are valid before and after any of these
alternatives, the only instability that I think you might be referring to is
the canonical form. But the canonical form is changing *all* of these cases:
A, B1, and B2; Y is no longer the canonical form in any of them. I don't see
why B2 is any "more" stable than A, not in any way that matters.

As to the recursion, although it wouldn't apply in this case if we allow A,
it does in other cases. And resolving the recursion for the user in the
registry just prevents needless mistakes.

---

From: John Cowan <[email-masked]>
Date: Mon, 14 Apr 2008 11:47:14 -0400

> an new, non-ISO code for something that is perfectly reasonable. Why is this

I agree: it is not a good idea.  We should restore the original tag as the
preferred value in such cases.

> registry just prevents needless mistakes.

+1.  The only arguments I can see against doing the recursion for the user
are:

1) Too much risk of error; but we have plenty of vigilant eyes in ietf-languages.

2) The ability to reconstruct the registry as of a given point in time is lost;
but Doug Ewell has argued that this ability does not exist anyhow.

-- 
John Cowan  [email-masked]   http://ccil.org/~cowan
Consider the matter of Analytic Philosophy.  Dennett and Bennett are well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett.
There is also one Dummett.  By their works shall ye know them.  However, just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the function
of this and other e-mail messages, therefore, to do what they can to create him.
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 14 Apr 2008 10:21:03 -0600

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Monday, April 14, 2008 9:15 AM
> Subject: Re: [Ltru] Last open item
...
> the cases I'm discussing, and it certainly doesn't apply to region codes.

Read the rest of 3.4(9).  Important part says:
|       If a new record of the same type is added that represents a
|       replacement value, then a 'Preferred-Value' field MAY also be
|        added.  The registration process MAY be used to add comments
|        about the withdrawal of the code by the respective standard.

In other words, the registry is *NOT* required to put in a new preferred-value.
Indeed, if the code is just a replacement, I'd think the normal course of
action would for the Preferred-Value in the NEW subtag to refer to the
ORIGINAL code.  This is simpler and better-behaved from a stability perspective.

> meaning, and Y is preferred.

MM should have had a Preferred-Value of "BU" according to the procedure,
rather than the other way around, but that's too late to fix now.

> (although not clearly -- see below).

Disagree.  The current procedure would require us to add a "deprecated" to
the newly deprecated tag.  Since the old (new) tag is already in the registry,
and means the same thing, no further action is needed.

...
...

That is precisely why the original RFC 4646 text is better.  If followed carefully,
MM would have a Preferred-value of BU, and the canonical form would never
have changed.
 
Randy

---

From: John Cowan <[email-masked]>
Date: Mon, 14 Apr 2008 15:32:12 -0400

Randy Presuhn scripsit:

> Disagree.  The current procedure would require us to add a "deprecated"
> to the newly deprecated tag.  Since the old (new) tag is already in
> the registry, and means the same thing, no further action is needed.

Then we wind up with both the original tag and its temporary replacement
marked deprecated.  That's undesirable.

> That is precisely why the original RFC 4646 text is better.  If followed
> carefully, MM would have a Preferred-value of BU, and the canonical
> form would never have changed.

Unfortunately, the BU->MM change was grandfathered in, so MM is the
canonical value at present.  So if MM were to be deprecated by ISO in
favor of BU, we wind up with Deprecated fields for both tags, making it
decidedly unclear which the canonical form is.

-- 
MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
John Cowan      [email-masked]      http://www.ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 14 Apr 2008 19:03:21 -0600

Hi -

> From: "John Cowan" <[email-masked]>
> Sent: Monday, April 14, 2008 1:32 PM

It would merely reflect what had happened in the source standards.

> decidedly unclear which the canonical form is.

No, if the Preferred-Value in BU refers to MM, then the logical thing to
do is to *not* add a preferred-value to MM if it is ever deprecated in
favor of something that would, for purposes of language tagging,
identify the same thing. 

Randy

---

From: John Cowan <[email-masked]>
Date: Mon, 14 Apr 2008 22:11:54 -0400

> It would merely reflect what had happened in the source standards.

All too "merely".    What, in such circumstances, would a naive reader
of the registry conclude was the un-deprecated value, and by what process?

> favor of something that would, for purposes of language tagging,

So then BU would be deprecated with a P-V of MM, and MM would be
deprecated without a P-V, leading the user to conclude that there is no
current value at all.

-- 
Evolutionary psychology is the theory           John Cowan
that men are nothing but horn-dogs,             http://www.ccil.org/~cowan
and that women only want them for their money.  [email-masked]
        --Susan McCarthy (adapted)
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 14 Apr 2008 20:41:08 -0600

Hi -

As a technical contributor..

> Sent: Monday, April 14, 2008 8:11 PM
...
> of the registry conclude was the un-deprecated value, and by what process?

MM, since the only other possibility would have a Preferred-value pointing to it.
However, I agree that this would be suboptimal, since a validating processor
would be prohibited from generating it.

> deprecated without a P-V, leading the user to conclude that there is no

That would not be good.  Perhaps it would make sense to avail ourselves of
RFC 4646 3.1:  "The field 'Deprecated' MAY be added to any record via the
maintenance process described in Section 3.3 or via the registration process
described in Section 3.5."  That is, in a pathological situation like the hypothetical
withdrawal of MM in favor of BU, the LSR could simply NOT add a "Deprecated"
to MM.

I think the heart of the problem here is attempting to blindly adopt changes originating
from the source standards.  Doing so works counter to one of our key goals, that
of ensuring a reasonable level of stability.    What happened with BU -> MM is
in my opinion an example of what we'd like to avoid, so if we're twiddling the
procedures, we should do so in a way which makes such cases less likely, not
more so.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 15 Apr 2008 08:29:48 -0700

I think we should make a sensible change here. The BU/MM hypothesis (and the existence of actual cases such as CD/ZR with "advantageous dates"), suggests that we should:

1. Allow region subtags to become undeprecated, provided they are assigned their original meaning by ISO 3166. ISO 3166 is a special case because of the limited namespace. Other subtag types don't show this sort of mutation. I think the text required to do this will have to be carefully crafted, though. I have to get my editing environment back online before I propose some [the change in email address and footer are not an accident] :-).

2. Allow P-V to be modified. This follows from the idea that registry maintenance should include removing "preferred value chains".

I think these changes are minor and should be incorporated. I also think that a subtag being deprecated with no P-V should be considered unusual, although cases do exist (as when a territory splits into a number of regions, none of which claim the original identity---see "SU").

Addison

Addison Phillips
Globalization Architect -- Lab126 (Amazon)
Chair -- W3C Internationalization Core WG

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Cowan
> Sent: lundi 14 avril 2008 19:12
> To: Randy Presuhn
> Cc: LTRU Working Group

---

From: John Cowan <[email-masked]>
Date: Tue, 15 Apr 2008 13:04:48 -0400

Randy Presuhn scripsit:

> I think the heart of the problem here is attempting to blindly
> adopt changes originating from the source standards.  Doing so works
> counter to one of our key goals, that of ensuring a reasonable level of
> stability.    What happened with BU -> MM is in my opinion an example
> of what we'd like to avoid, so if we're twiddling the procedures, we
> should do so in a way which makes such cases less likely, not more so.

Stability in the preferred value isn't the sort of stability that we
can either expect or preserve, particularly in ISO 3166 code elements.
What we can and do stabilize is the meaning of subtags: if a source
standard attempts to assign a code element to a different meaning than
it once had, we provide a replacement subtag instead of reusing that
code element.

Countries will go on changing their names, and 3166/MA (in accordance
with its mandate) will change their codes accordingly; in order not to
get out of sync with the rest of the code-using world, we need to track
those changes insofar as possible.

-- 
LEAR: Dost thou call me fool, boy?      John Cowan
FOOL: All thy other titles              http://www.ccil.org/~cowan
             thou hast given away:      [email-masked]
      That thou wast born with.
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Tue, 15 Apr 2008 13:06:43 -0400

Phillips, Addison scripsit:
> I think we should make a sensible change here. 

+1 to the details

-- 
John Cowan   [email-masked]    http://ccil.org/~cowan
Original line from The Warrior's Apprentice by Lois McMaster Bujold:
"Only on Barrayar would pulling a loaded needler start a stampede toward one."
English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to
lose support instead of finding it when you threat with the charged weapon."
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 15 Apr 2008 10:42:24 -0600

Hi -

> Sent: Tuesday, April 15, 2008 11:04 AM
...
> with its mandate) will change their codes accordingly;

Strongly agree, but....

> in order not to
...

Strongly disagree.

One of the motivations for the formation of this working group was to provide
a way to insulate language tags from what was perceived as excessive instability
in some of the code sources.  As I see it, stability, particularly the stability of
the canonical form of a language tag, is dramatically more important than
staying in sync with other uses of codes coming from the standards we used
to initially populate our registry.  After all, if we're just going to blindly track
the ISO code du jour for every little piece of dirt, there's really little point
to even bothering to put these things in our registry.  If consistency with
other uses of those source specifications trumps stability as a consideration,
then we should throw out our current procedures and registry, just say "see
ISO registry mumble for these codes", and limit our registry and procedures
exclusively to codes for things that ISO hasn't coded.

Otherwise, we will find ourselves in the situation that a tag found to be OK
be a validating processor will suddenly become not OK.  That's simply
not acceptable.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 15 Apr 2008 10:59:07 -0700

> we will find ourselves in the situation that a tag found to be OK
> be a validating processor will suddenly become not OK

That is a red herring. There appears to be a fundamental misperception here.
The key issue is that canonical form is NOT the same as is valid, and never
has been. Moreover:

1. The canonical form is not, and never has been "stable" in the sense you
mean. Any time a subtag is deprecated in favor of another, we make the
change, which will change the canonical form. True of our process before,
and still true in the latest draft.

2. However, the key notion of stability that we have striven for is that
once a tag is valid, it will always stay valid. *That is true even if the
canonical form changes.*

3. This drives the main stabilizing principle in BCP 47, which is that once
in the registry, we never change the meaning of a subtag in a way that would
narrow the denotation of a tag (or change it completely, like CS was handled
by ISO). THAT is the area where we stabilize the ISO codes, and where we do
not accept changes from ISO.

If you have a math bent, think of it this way. The domain of valid tags is
partitioned into equivalence classes. Each equivalence class has one
distinguished member, the canonical form. Over time, only certain changes
are allowed:

   - Tags never disappear (each of the tags, once valid, will always
   remain valid).
   - New tags and equivalence classes may be added.
   - The canonical form for a given class may change, but the old
   canonical form remains valid and remains the same in meaning as the new one.
   - Equivalence classes may grow, and may merge (unlikly but possible),
   but will never split.

Mark

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 15 Apr 2008 11:01:04 -0700

"Canonical" != "valid"

We are not proposing to ever make a tag invalid. We are proposing to allow the canonical form of the tag to change reflecting changes in the world. There is even a warning in 4647 about being overly aggressive in canonicalizing tags.

Addison

Addison Phillips

> Randy Presuhn
> Sent: mardi 15 avril 2008 09:42
> To: LTRU Working Group

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 15 Apr 2008 11:23:53 -0600

Hi -

> Sent: Tuesday, April 15, 2008 11:59 AM

RFC 4646 is quite clear: "Although valid in language tags, subtags and tags
with a 'Deprecated' field are deprecated and validating processors SHOULD
NOT generate these subtags."  Thus my statement that something that would have
once been fine will suddenly become "not OK".

> and still true in the latest draft.

I could understand this as part of the process of constructing RFC 4646 to
deal with historical mistakes.  I think continuing down that path would be
a really bad idea.

> once a tag is valid, it will always stay valid. *That is true even if the

Somehow the notion that the canonical form for an entity would change
over time seems contrary to the very notion of "canonical."

>    - Equivalence classes may grow, and may merge (unlikly but possible),

All fine, except for permitting the canonical form to change.
 
However, since I seem to be the only person bothered by this kind
of instability, and since I'd love to see this work finished so we
can close down this WG, I'll give up.

Randy

---

From: John Cowan <[email-masked]>
Date: Tue, 15 Apr 2008 15:10:22 -0400

Randy Presuhn scripsit:

> One of the motivations for the formation of this working group was
> to provide a way to insulate language tags from what was perceived as
> excessive instability in some of the code sources.

That is to say, we couldn't at the time trust ISO 3166/MA not to reassign
code elements to new meanings; in addition, there was no one-stop shop
for subtags (see below).

> After all, if we're just going to blindly track the ISO code du jour
> for every little piece of dirt, there's really little point to even
> bothering to put these things in our registry.

I would be slow to call a sovereign nation a "little piece of dirt".

> If consistency with other uses of those source specifications trumps
> stability as a consideration, then we should throw out our current
> procedures and registry, just say "see ISO registry mumble for these
> codes", and limit our registry and procedures exclusively to codes
> for things that ISO hasn't coded.

I disagree entirely: even if it weren't stable (in my sense), the
convenience of having a single registry to look at in a machine-readable
format, instead of four registries in random prose formats, is
considerable.

> Otherwise, we will find ourselves in the situation that a tag found
> to be OK be a validating processor will suddenly become not OK.
> That's simply not acceptable.

Are you under the impression that either RFC 4646 or the current draft
requires a validating processor to reject deprecated subtags?  That is not
so.  There is language in 3.1.5 (of either version) that says validating
processors SHOULD NOT *generate* them, but that's a different story.

-- 
A poetical purist named Cowan           [that's me: [email-masked]]
Once put the rest of us dowan.          [on xml-dev]
    "Your verse would be sweeter        http://www.ccil.org/~cowan
    If it only had metre
And rhymes that didn't force me to frowan."     [overpacked line!] --Michael Kay
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 16 Apr 2008 12:46:20 +0200

On Tue, Apr 15, 2008 at 11:23:53AM -0600,
 Randy Presuhn <[email-masked]> wrote 
 a message of 69 lines which said:

> Somehow the notion that the canonical form for an entity would
> change over time seems contrary to the very notion of "canonical."

-1 for me. "Canonical" never implied "once canonical, always
canonical". 

Every standard which performs canonicalization has the same
issues. For instance, NFC in Unicode is not stable (a string of
Unicode characters which is in NFC form today may not be in the
future). You have to add a few constraints, as the RFC 5198 does, to
have a "stable NFC".
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 16 Apr 2008 12:04:43 -0600

Hi -

> From: "Stephane Bortzmeyer" <[email-masked]>
> Sent: Wednesday, April 16, 2008 4:46 AM
> Subject: Re: Last open item
...
> future). You have to add a few constraints, as the RFC 5198 does, to

Wandering close to off-topic...

"Every" is a bit of an over-statement.

Some sets of ASN.1 encoding rules don't have this problem.
If one is worried about instance naming (as in SNMP, SMUX, 
AgentX or with CMIP in a sub-agent architecture) having an
utterly stable canonical form is essential.  The SNMP-family
protocols are particularly dependent on there being exactly one
representation for an instance name.  Consider the GetNext 
and GetBulk operations, for example.  It is such a strong
assumption that the topic never even comes up in most
discussions of these protocols.

But since I'm clearly the only one on this list who thinks this weak
sense of "canonical" is broken, I've already given up arguing the point.

Randy