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

From: "Doug Ewell" <[email-masked]>
Date: Tue, 4 Nov 2008 07:12:39 -0700

Peter Constable <petercon at microsoft dot com> wrote:

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

And yes, this does mean we are using language subtags in a somewhat 
different way from the ISO 639 code elements from which they are derived 
(which, according to the title of the standard, are intended to 
represent language names).  And yes, we are aware of this, and 
comfortable with it.

--
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: "Mark Davis" <[email-masked]>
Date: Tue, 4 Nov 2008 11:28:27 -0800

As far as I'm concerned, we'd have better interoperability if we never
changed codes for just a name change. That is, in fact, the reason why we
normalized to 'iw' in Java.
However, this would be a major departure from the current BCP47 at a late
date, without time to consider all the ramifications. So I agree with
Addison that this is really not an issue to be discussed at this point; it
should wait for a possible future revision.

That is a separate issue from how the text is structured; if there are
specific changes that can be made to the text that clarify it, without
making a substantive technical change, then I'm ok with such changes.

Mark

On Tue, Nov 4, 2008 at 6:12 AM, Doug Ewell <[email-masked]> wrote:

>  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.
>>
>
> (which, according to the title of the standard, are intended to represent
> language names).  And yes, we are aware of this, and comfortable with it.
>
> --

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Nov 2008 12:21:27 -0800

Hi -

> From: "Mark Davis" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, November 04, 2008 11:28 AM
> Subject: Re: [Ltru] rfc4646bis-18 "SHALL NOT be rejected"
>

> changed codes for just a name change.

As a technical contributor, I strongly agree, and I think that was
the point of Section 3.4 (15) (D) for region subtags, and would
hope the rules for primary language codes would work out to have
the same net effect, modulo the dates of the versions of the standards
used as sources for the codes.

...
> should wait for a possible future revision.

As co-chair: we're supposed to be checking that what we have before us
  (1) reflects the WGLC discussions
  (2) is self-consistent
  (3) makes technical sense

Issues in (2) and (3) are sometimes at odds with WG consensus.  When such
things crop up, we as co-chairs need to make judgment call whether
  (1) the consistency / technical problem is in fact an editorial
      problem that can be corrected by fixing a typo, clarifying
      and explanation, or something like that
  (2) if there is a real technical problem with the direction taken by
      the WG, whether it is an acceptible trade-off to live with the
      problem in the interest of getting a workable solution published

As a technical contributor, I think the "SHALL NOT be rejected" language
is problematic from both the self-consistency and technical sense perspective,
and that it could be substantially mitigated by editorial changes, but
I also have a nagging concern that there is an underlying technical problem
with regard to stability.

However, as co-chair, I think that what we have is sufficiently workable
that it's better to get this thing published than to spend more time
on it.

> making a substantive technical change, then I'm ok with such changes.

As co-chair:

My inclination is suggest we hand what we have to our AD for the IESG,
queue up the nits we've accumulated in the last days as IETF last-call
comments, and see whether anyone finds the motivation / inspiration to address
this concern.  I get the feeling that we to a large extent want the
same things here, and that the problem is that the overarching philosophy
is difficult to discern amongst the detailed rules.

The slightly-more-prim-and-proper alternative is to incorporate the
accumulated nits into a new I-D and submit *that* to the IESG.  The
downside is that I-D submissions don't re-open until November 17th.

The choice before us now seems to be:
  (A) hand off what we have in the next day or so to our AD.  Martin
      and I need to hear from people who can say they have *read*
      the drafts.  A simple post to the wg mailing list would suffice.
      The risk is immediate push-back for the accumulated nits.
  (B) incorporate the nits into a new I-D, to be sumitted November 17th.
      Use the time between now and then to see whether we can find
      an editorial way to address the concerns.  Shortly thereafter,
      hand it off to our AD.

As I said above, I'm leaning toward (A), but am willing to listen to
reason.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 4 Nov 2008 12:53:06 -0800

I lean strongly towards A as well. My feeling is that, *as with any spec, *the
longer we look at this document the more issues we will turn up. But we have
to draw the line somewhere, and this version is vastly better than the
previous one, and brings a great deal of functionality to the table that
people are really waiting on.

So we are better off (especially in view of the timing) to get this version
out, and then (*after some suitable period of recuperation!!*) turning to
the next version.

Mark

On Tue, Nov 4, 2008 at 12:21 PM, Randy Presuhn <[email-masked]
> wrote:

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 4 Nov 2008 12:57:24 -0800

I lean strongly towards A as well. My feeling is that, as with any spec, the longer we look at this document the more issues we will turn up. But we have to draw the line somewhere, and this version is vastly better than the previous one, and brings a great deal of functionality to the table that people are really waiting on.
+1. Note that the various changes other than “SHALL NOT” are all of the minor editorial flavor.
So we are better off (especially in view of the timing) to get this version out, and then (after some suitable period of recuperation!!) turning to the next version.
“suitable period of recuperation”… hmm… would that be measured in years? :-).
Addison
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 5 Nov 2008 07:00:42 -0700

Mark Davis wrote:

> changed codes for just a name change. That is, in fact, the reason why 
> we normalized to 'iw' in Java.

I think this takes the principle too far.  'iw' was deprecated in favor 
of 'he' almost 20 years ago, when the use of ISO 639 in computer 
applications was much less common than ad-hoc coding systems, and well 
before Java was created.  The goal is to avoid churn, and standardizing 
on an already-deprecated code at the time more new data is being created 
with the new code than existed with the old code would probably increase 
churn.

Of course, that's all in the past now, but I prefer the "Date A/Date B" 
approach we took in LTRU.

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 5 Nov 2008 06:36:44 -0800

'iw' was an example - I was not suggesting going back that far for BCP 47.
But remember that Java internationalization was developed from Taligent
internationalization, which had started not long after the switch between
'iw' and 'he', so 'iw' was still in use. So the same *principle* was being
applied way back then - use the original code, rather than track changes
that were simply in name only.
Mark

On Wed, Nov 5, 2008 at 6:00 AM, Doug Ewell <[email-masked]> wrote:

> I think this takes the principle too far.  'iw' was deprecated in favor of
> 'he' almost 20 years ago, when the use of ISO 639 in computer applications
> was much less common than ad-hoc coding systems, and well before Java was
> created.  The goal is to avoid churn, and standardizing on an
> already-deprecated code at the time more new data is being created with the
> new code than existed with the old code would probably increase churn.
>