Subject: Re: [Ltru] Geocoordinates (was: Re: Proposal to remove Preferred-Value field for region YU in LTRU)

From: Mark Davis <[email-masked]>
Date: Mon, 9 Mar 2009 11:17:38 -0700

See my message of April 12 2005 (was intended for April 1): "A Modest
Proposal"

http://www.ietf.org/mail-archive/web/ltru/current/msg01060.html

Since it is obvious that all applications in the world will require
extremely fine-grained approach to languages, here is an initial proposal
for development of a separate RFC to deal with them. The goal is to be able
to describe the variety of speech that each person on earth may be using at
a given time. Identification is by means of the location of the speaker and
the time at which the speech could have occurred. The language tag is given
by the following format (formal ABNF to follow).

XLanguageTag ::= latitude "-" longitude "-" altitude "-" time

Latitude and longitude are specified by radians, and be measured from 0 to
360 starting at the Prime Meridian going east, and from 0 to 180 starting at
the South Pole and going north. The numeric values below zero are avoided
because the use of the terms "positive" and "negative" when applied to
location can clearly be prejudicial to many of the peoples of the world.
Should in the course of the development of this RFC, the use of the Prime
Meridian be viewed as representative of an English-speaking hegemony, a
random longitude will be chosen as the origin. Use of latitude and longitude
does not, of course, imply in any way that those who believe in a flat earth
or the "four-elephant+turtle system" are in any way discouraged in the
observance of their faith, nor does the use of radians in any way denigrate
the goal of the Kansas State Education Board to recognize the value of π as
exactly 3.0.

Altitude is in meters above the center of the earth. While some may feel the
likelihood of two speakers being exactly overhead is low, we do -- of
course -- want to plan for all eventualities. By avoiding measurement
against sea level, we again celebrate the diversity of the world's
population, and do not discriminate against the proud inhabitants of Death
Valley and similar locations by in any way referring to them as "negative".

For location, since people rarely overlap in physical space, it will usually
be sufficient to have accuracy to within 10 cm. But since fractions can be
supplied, applications can have arbitrarily high degree of accuracy.

The time is specified by seconds since 0000-01-00T00:00:00Z (using the
proleptic Gregorian calendar as specified in XML Schema), plus an offset of
1,000,000,000,000,000,000. If finer granularity than seconds is desired,
then fractions can be specified. The reason for the offset is to again avoid
negative numbers, and their implied bias against historic inhabitants. The
offset is chosen as to be well before all current estimates of the Big Bang.
Note, however, that this in no way implies any denigration of creationism,
or that believers are in any way discouraged in the observance of their
faith. Nor does it imply that any one system of creationism, such as Greek
or Norse creation theory, is any way inferior to any other, such as that
espoused by the Kansas State Education Board.

Other parts of this proposal, such as security implications, will be
forthcoming.

‎Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 10 Mar 2009 10:31:27 +0100

On Mon, Mar 09, 2009 at 11:17:38AM -0700,
 Mark Davis <[email-masked]> wrote 
 a message of 149 lines which said:

> extremely fine-grained approach to languages, here is an initial
> proposal for development of a separate RFC to deal with them.

I fully support this proposal.

> Other parts of this proposal, such as security implications, will be

I'm too impatient to read them!

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Mar 2009 11:10:27 -0700

Hi -

As co-chair...

If you wish, you may include this as part of a proposal to re-charter
this working group.  However, I currently plan to recommend closing
the working group when its current deliverables are published.

As a technical contributor...

I've observed that accent can vary according to the number of
beers consumed.   Perhaps another subtag should be designed to
indicate the speaker's level of intoxication.  Or can we just use the
altitude parameter to indicate how high they are?   :-)

Randy

> From: "Stephane Bortzmeyer" <[email-masked]>
> To: "Mark Davis" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, March 10, 2009 2:31 AM
> Subject: Re: [Ltru] Geocoordinates (was: Re: Proposal to removePreferred-Value field for region YU in LTRU)
>
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Tue, 10 Mar 2009 14:46:02 -0400

> the working group when its current deliverables are published.

What about the variant and (genetic) collection codes from ISO 639-6?
That standard is at FDIS stage, and while we certainly shouldn't hold
4646bis on it, it seems to contain material for a 4646ter.

-- 
John Cowan    http://ccil.org/~cowan  [email-masked]
The Penguin shall hunt and devour all that is crufty, gnarly and
bogacious; all code which wriggles like spaghetti, or is infested with
blighting creatures, or is bound by grave and perilous Licences shall it
capture.  And in capturing shall it replicate, and in replicating shall
it document, and in documentation shall it bring freedom, serenity and
most cool froodiness to the earth and all who code therein.  --Gospel of Tux

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 10 Mar 2009 11:53:08 -0700

I haven't followed ISO 639-6 since there were (premature?) announcements of its possible demise. It might make a suitable extension (in which case no WG is needed). Or, when it is mature, couldn't we just create a new instance of LTRU with a new charter at that time? 

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Cowan
> Sent: Tuesday, March 10, 2009 11:46 AM
> To: Randy Presuhn
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Geocoordinates
> 
> Randy Presuhn scripsit:
>

---

From: John Cowan <[email-masked]>
Date: Tue, 10 Mar 2009 16:03:54 -0400

Phillips, Addison scripsit:

> I haven't followed ISO 639-6 since there were (premature?) announcements
> of its possible demise. It might make a suitable extension (in which
> case no WG is needed). Or, when it is mature, couldn't we just create
> a new instance of LTRU with a new charter at that time?

I don't know if that's more or less expensive (in people time, mostly)
than letting LTRU go dormant and then revivifying it.

FWIU, 639-6 codes form a Big Tree, from "all languages" at the top down
through genetic groups, languages, and variants of all sorts (including
script variants).  The codes for languages are harmonized with 639-3's,
so they're already in; the codes for groups are or will be harmonized
with 639-5's.  So what's left is:

(a) codes for language collections that aren't in 639-5, which could
be added to BCP 47 as 4-letter primary language subtags (that size is
currently reserved);

(b) codes for variants other than script and national variants, which
could be added to BCP 47 as 5-character variant subtags by adding a 5th
character (I propose prefixing '6').

Of course the Registry would become bigger than ever, and some of
He Who Must Not Be Named's concerns would actually become realities,
like whether authorized mirrors would be needed to hold down on the
number of downloads.  On the other hand, we could pretty well shut down
ietf-languages@, since there would be little or nothing left to approve
outside the 639 framework.

-- 
Even a refrigerator can conform to the XML      John Cowan
Infoset, as long as it has a door sticker       [email-masked]
saying "No information items inside".           http://www.ccil.org/~cowan
        --Eve Maler

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 10 Mar 2009 13:30:58 -0700

> On the other hand, we could pretty well shut
> down ietf-languages@, since there would be little or nothing left to
> approve outside the 639 framework.

... assuming that there is only one way to classify languages meeting the needs of all audiences. :-)

I'm sure that some audiences will find value in 639-6 and that incorporating the 639-6 codes into BCP 47 may have some merit--just has the various changes we've wrought have value. In fact, some people have said it has merit on this list, so that's hardly speculation.

Personally, I don't see incorporating other collections as a high priority: the ones we have are more for completeness than actual utility. The other variants might be addressed by permitting "random" registration and requiring a reference field in the registry for the ISO 639-6 code that corresponds (allowing a creeping mnemonicity to develop). For that matter, if they're going to be variants anyway, an extension (-6- seems like an appropriate singleton) seems like a practical solution with some benefits to recommend it.

But I speculate recklessly. Since it seems pretty easy to create an IETF WG, I guess the real question is whether the chairs, AD, and such would want to maintain a moribund group for a year or so while this standard bakes instead of just creating a new one at the appropriate juncture. Or it 639-6 that close?

Addison

Addison Phillips

> From: John Cowan [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 1:04 PM
> To: Phillips, Addison
> Cc: John Cowan; Randy Presuhn; LTRU Working Group

---

From: John Cowan <[email-masked]>
Date: Tue, 10 Mar 2009 16:37:17 -0400

Phillips, Addison scripsit:

> For that matter, if they're going to be variants anyway, an extension
> (-6- seems like an appropriate singleton) seems like a practical
> solution with some benefits to recommend it.

I wasn't proposing a singleton, but a convention: variant code abcd
would come into BCP 47 as variant subtag 6abcd, to avoid confusing it
with script subtags.

> But I speculate recklessly. Since it seems pretty easy to create an
> IETF WG, I guess the real question is whether the chairs, AD, and such
> would want to maintain a moribund group for a year or so while this
> standard bakes instead of just creating a new one at the appropriate
> juncture. Or it 639-6 that close?

IIRC, it's in FDIS (Final Draft International Standard) state, so about
as close as we are.

-- 
Normally I can handle panic attacks on my own;   John Cowan <[email-masked]>
but panic is, at the moment, a way of life.      http://www.ccil.org/~cowan

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Mar 2009 15:46:33 -0700

Hi -

> From: "John Cowan" <[email-masked]>
> To: "Phillips, Addison" <[email-masked]>
> Cc: "John Cowan" <[email-masked]>; "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, March 10, 2009 1:37 PM
> Subject: Re: [Ltru] ISO 639-6 and LTRU continuation [was: Geocoordinates]
...
> IIRC, it's in FDIS (Final Draft International Standard) state, so about
...

As a technical contributor...
Truly supporting the concept of collections would require some serious
work on an update to RFC 4647, among other things.  I think we'd want
to see some serious use cases and requirements from the protocol
community before rechartering / spinning up a new WG.  How would
these be employed in existing IETF protocols?  Do any new protocol
proposals require this facility?  I would not support the idea of keeping
a WG around until we figured out how we were going to use such things.

As co-chair...
Those interested in pursuring further work should prepare a charter update
(with clearly identified deliverables and dates) for discussion.  Expect to be
asked whether we're past the point of diminishing returns.  Iff there is
(rough) consensus in support of that proposal, we can ask our AD to take
it to the IESG.   If not, we'll wrap up the WG after our current deliverables
are published as RFCs, probably with a recommendation to leave the
mailing list active. 

Randy

---

From: Peter Constable <[email-masked]>
Date: Tue, 10 Mar 2009 20:36:38 -0700

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Cowan

> So what's left is:

I'd be resistant to 4-letter primary language subtags. I have made derivative use of BCP 47 tag syntax with the modification that the only obligatory subtag is the script subtag. Introducing different 4-letter subtags within BCP 47 syntax would create conflicts with this or other similar derivative uses of our language tag syntax.

Peter

---

From: Martin Duerst <[email-masked]>
Date: Wed, 11 Mar 2009 13:34:18 +0900

At 05:30 09/03/11, Phillips, Addison wrote:

>But I speculate recklessly. Since it seems pretty easy to create an IETF 
>WG,

It is pretty easy if the proposed WG meets the relevant criteria,
such as relevance to the Internet, critical mass,...

>I guess the real question is whether the chairs, AD, and such would 
>want to maintain a moribund group for a year or so while this standard 
>bakes instead of just creating a new one at the appropriate juncture.

It is very clear that the IETF prefers groups to be shut down
when there's nothing much to do, not excluding the potential
to form a new group again when there is new work to be done.

In the mean time, the custom at the IETF is to keep the mailing
list open, but a mailing list and a WG aren't the same.

>Or it 639-6 that close?

My preference would be to wait for it to be a full ISO standard,
and in the mean time to collect experience with the actual use
of 4646bis.

Regards,    Martin.

#-#-#  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: Wed, 11 Mar 2009 11:27:53 -0400

Peter Constable scripsit:

> I'd be resistant to 4-letter primary language subtags. I have made
> derivative use of BCP 47 tag syntax with the modification that the only
> obligatory subtag is the script subtag. Introducing different 4-letter
> subtags within BCP 47 syntax would create conflicts with this or other
> similar derivative uses of our language tag syntax.

You can easily return to compliance by changing all ill-formed wxyz tags
to und-wxyz tags.

-- 
John Cowan    <[email-masked]>     http://www.ccil.org/~cowan
But no living man am I!  You look upon a woman.  Eowyn I am, Eomund's daughter.
You stand between me and my lord and kin.  Begone, if you be not deathless.
For living or dark undead, I will smite you if you touch him.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 11 Mar 2009 10:31:49 -0700

Hi -

> From: "Peter Constable" <[email-masked]>
> To: "John Cowan" <[email-masked]>; "Phillips, Addison" <[email-masked]>
> Sent: Tuesday, March 10, 2009 8:36 PM
> I'd be resistant to 4-letter primary language subtags.
> I have made derivative use of BCP 47 tag syntax 
> with the modification that the only obligatory subtag
> is the script subtag.
> Introducing different 4-letter subtags within BCP 47 syntax 
> would create conflicts with this or other similar derivative
> uses of our language tag syntax.

I find this line of argument unpersuasive.  We should only
concern ourselves with compatibility with conformant
implementations.  If someone implements something
"derived from" the spec which does not follow it to the
letter, they're on their own.

Randy

---

From: Mark Davis <[email-masked]>
Date: Wed, 11 Mar 2009 10:41:39 -0700

It is not necessarily non-conformant. I could define a field as follows:

   - if it has 4 characters and no hyphen, it means X
   - otherwise it is interpreted as a BCP 47 language tag.

That is perfectly conformant usage of BCP 47, and would work with the
current spec. The disadvantage is that if BCP47 ever uses 4-letter base
language codes, then you can't represent the full range of BCP47 at that
point. So you definitely take a risk in using such a definition in terms of
future compatibility, but such a definition is not non-conformant.

Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 11 Mar 2009 10:54:20 -0700

Hi -

> From: "Mark Davis" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Sent: Wednesday, March 11, 2009 10:41 AM
> current spec.

As a technical contributor...
I disagree.  The field's definition would result in well-formed
tags being analyzed incorrectly.

> The disadvantage is that if BCP47 ever uses 4-letter base
> point.

They are *already* in the grammar.  That's the whole point of
"reserved for future use".

Randy