Subject: [Ltru] rfc4646bis-18 "SHALL NOT be rejected"

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 2 Nov 2008 03:11:25 -0700

Hi -

As a technical contributor...

On page 46 we have:
   Registrations initiated due to the provisions of Section 3.3 or
   Section 3.4 SHALL NOT be rejected altogether (since they have to
   ultimately appear in the registry) and SHOULD be completed as quickly
   as possible.  The review process allows list members to comment on
   the specific information in the form and the record it contains and
   thus help ensure that it is correct and consistent.  The Language
   Subtag Reviewer MAY reject a specific version of the form, but MUST
   propose a suitable replacement, extending the review period as
   described above, until the form is in a format worthy of reviewer's
   approval and meets with rough consensus of the list.

The phrase "SHALL NOT be rejected" really seems broken, since we
have specific conditions under which registrations MUST be rejected.
Propose deleting the first sentence.  Likewise, the "MUST propose
a suitable replacement" assumes such a thing is possible.  Suggest
replacing "MUST" with "SHOULD", and deleting everything from "until"
to the end of the sentence.

I think this is a fairly significant bug, but would like to hear
what others think the intended meaning is.

Randy

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

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 2 Nov 2008 16:53:07 -0800

(editor hat OFF)
> have specific conditions under which registrations MUST be rejected.

Actually, we don't. We have specific cases in which the reviewer might not accept a specific version of the proposed record. However, the I-D compels him/her to make the registration. That's the point.

> a suitable replacement" assumes such a thing is possible. 

Such a thing must be possible: this section covers cases which are all ISO changes required by the I-D. Technically unacceptable records are already dealt with.

> Suggest
> replacing "MUST" with "SHOULD", and deleting everything from
> "until" to the end of the sentence.

Actually, I would say that I don't care for the text that permits indefinite extensions, except to note that this is what the appeals process is for.

> what others think the intended meaning is.

Is there a case where a compulsory registration cannot be suitably formatted for inclusion? Is there a case in which the reviewer (or his/her "official proxy" and/or Doug) cannot provide a suitable substitute? I think that's really what you're asking here.

Addison

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 2 Nov 2008 19:12:04 -0800

Hi -

> From: "Phillips, Addison" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Sunday, November 02, 2008 4:53 PM
> Subject: RE: [Ltru] rfc4646bis-18 "SHALL NOT be rejected"
>
> (editor hat OFF)
> > 
> Actually, we don't. We have specific cases in which the reviewer
> might not accept a specific version of the proposed record. However,
> the I-D compels him/her to make the registration. That's the point.

But we do - duplicates (obvious or not-so-obvious) of existing
registrations being one obvious case.

> Such a thing must be possible: this section covers cases which are all
> ISO changes required by the I-D. Technically unacceptable records are
> already dealt with.

I still think this is not quite right, since this skews the process in
the direction of favoring what I called "subtag churn", rather than
stability.  If an ISO change (or any other change, for that matter)
does not provide a way of identifying something that previously could
not be identified (other than the numeric region codes) then, in my
opinion, the LSR generally SHOULD NOT accept the request.  But I guess
Doug and I are the only ones that feel this way.

> Actually, I would say that I don't care for the text that permits
> indefinite extensions, except to note that this is what the appeals process is for.
> 
> > 
> Is there a case where a compulsory registration cannot be suitably
> formatted for inclusion? Is there a case in which the reviewer
> (or his/her "official proxy" and/or Doug) cannot provide a suitable
> substitute? I think that's really what you're asking here.

No, it's more that I have a problem with the whole concept of compulsory
registration.  We've seen enough cases where new codes assignments have
worked against the goals of having a subtag registry, in particular that
of providing a measure of insulation for language tagging applications
from ISO code assignment churn.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 2 Nov 2008 19:47:50 -0800

(editor hat OFF)

> registrations being one obvious case.

The text here is important, though. It says:

--
Registrations initiated due to the provisions of Section 3.3 (Maintenance of the Registry) or Section 3.4 (Stability of IANA Registry Entries) SHALL NOT be rejected altogether (since they have to ultimately appear in the registry) and SHOULD be completed as quickly as possible.
--

This includes all of the obvious and not-so-obvious cases. If a record is required, it will be entered into the registry. We do have rules to "second guess" ISO---in cases where we would encounter subtag churn, etc. But when there is no other conflict, we do register ISO changes.

> opinion, the LSR generally SHOULD NOT accept the request.  But I
> guess Doug and I are the only ones that feel this way.

Well... not exactly. And it can never be "exactly". There are region codes or script codes that ISO bodies can register that have no practical use in language tags. Aside from stability provisions already provided for, we register them anyway.

> from ISO code assignment churn.

Yes, we have. And I think we've provided for such cases. Section 3.4, in particular, has fairly complex rules for when something is admitted (or not). But what we have not done---have never done, in fact---is second-guess ISO when their registrations are not in conflict with existing registrations. And we provide for the argument to be made that such a conflict exists. Absent a valid reason why not to register a subtag, though, we do mirror ISO as closely as allowed. This is intentional and by design. It would be a problem, I think, if we did not.

Addison

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 2 Nov 2008 19:55:58 -0800

Hi -

> Sent: Sunday, November 02, 2008 7:47 PM
...
> Yes, we have. And I think we've provided for such cases.
> Section 3.4, in particular, has fairly complex rules for
> when something is admitted (or not). But what we have not
> done---have never done, in fact---is second-guess ISO when
> their registrations are not in conflict with existing
> registrations. And we provide for the argument to be made
> that such a conflict exists. Absent a valid reason why not
> to register a subtag, though, we do mirror ISO as closely
> as allowed. This is intentional and by design. It would
> be a problem, I think, if we did not.
...

I think our examples show that this isn't working as it should.
For purposes of language tagging, the ZR/CD change in 3.1.7,
the TL/TP change, and the hypothetically oscillating BU/MY
are all cases where changes add no value whatsoever, and
consequently, in my opinion, should not have propagated from
ISO into the subtag registry.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 2 Nov 2008 21:01:53 -0800

> > It would

ZR/CD and TL/TP are not necessarily Bad Changes. And BU/MY is not necessarily a bad oscillation. The people involved certainly have feelings about what their country should be called and, while this has nothing to do with linguistic reality, it is not necessarily "wrong". Yes, purely political and/or administrative changes are a real problem. But getting the "right" choice is wrapped up in external considerations that we probably don't want to tangle with. 

I guess the question is: how would you suggest we react? Making the LSR make purely political decisions is rife with really ugly potential problems. If we force the LSR to track ISO (with some exceptions), we avoid having to decide if one country name or another is "best". This is not ideal, but it hasn't proved that distressing in practice.

I won't claim this is perfect. I claim that this is what we've always done and for good reason too. Have you considered what would happen if competing claims were made about ISO registrations?

Addison

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 2 Nov 2008 21:52:15 -0800

Hi -

As technical contributor...

> Sent: Sunday, November 02, 2008 9:01 PM
...
> ZR/CD and TL/TP are not necessarily Bad Changes.
> And BU/MY is not necessarily a bad oscillation.
> The people involved certainly have feelings about
> what their country should be called and, while
> this has nothing to do with linguistic reality,
> it is not necessarily "wrong". Yes, purely political
> and/or administrative changes are a real problem.
> But getting the "right" choice is wrapped up in
> external considerations that we probably don't
> want to tangle with. 

Agreed, though that leads me to the conclusion that
it's preferable to stick with the originally assigned code,
since we're not making any claims about what a country
should be called, but rather are merely using a code
originally allocated by ISO.
 
> I guess the question is: how would you suggest we
> react? Making the LSR make purely political decisions
> is rife with really ugly potential problems. If we
> force the LSR to track ISO (with some exceptions),
> we avoid having to decide if one country name or
> another is "best". This is not ideal, but it hasn't
> proved that distressing in practice.

We don't say anything about country name is "best",
nor should we.  My preference would be to always
stick with the code originally assigned in the
case of name changes.  I have no problem with including
the new name in an (updated) description.

> I won't claim this is perfect. I claim that this is
> what we've always done and for good reason too.
> Have you considered what would happen if competing
> claims were made about ISO registrations?

My preference would be for stability to trump all else.
The question of "competing" claims doesn't arise.

As Co-chair...

There doesn't seem to be any support for changing this
text, so we should leave it as-is.  However, I am
concerned that we'll end up having to explain it
again to whoever reviews it next.  We can cross
that bridge when we come to it, but it might
be helpful to have a concise and persuasive
explanation why "SHALL NOT be rejected" is necessary
for the registry / protocol to function correctly,
because that is ultimately the kind of justification
we should be prepared to give for any MUST/SHALL
language.

Randy

---

From: Peter Constable <[email-masked]>
Date: Mon, 3 Nov 2008 22:04:07 -0800

From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn

> originally allocated by ISO.

That's been my inclination in language coding: we are coding the concept of a language (or some range of language variation), not a particular expression used to refer to that concept. In the text for 639-3, we explicitly tried to steer people away from reading mnemonic value into the symbol used because it simply wasn't practical to be mnemonic with 7000+ coded entities, but an added benefit we saw was that it avoided (and is the only way to avoid) the politics of names.

Peter