Message-Id: <6.1.2.0.2.20050412203555.055667a0@mail.jefsey.com>
Date: Tue, 12 Apr 2005 21:07:52 +0200
To: "Mark Davis" <mark.davis@jtcsv.com>,
	"LTRU Working Group" <ltru@ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] A Modest Proposal
In-Reply-To: <017c01c53f8d$21e1c530$ab703009@sanjose.ibm.com>
References: <017c01c53f8d$21e1c530$ab703009@sanjose.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Mark should be praised for this long overdue proposition.
It however rises some questions.

At 20:26 12/04/2005, Mark Davis wrote:
>Since it is obvious that all applications in the world will require
>extremely fine-grained approach to languages, here is an initial proposa=
l
>for development of a separate RFC to deal with them.

Is this a private Draft or suggested by this WG-ltru?

>The goal is to be able to describe the variety of speech that each perso=
n=20
>on earth may be using at a given time. Identification is by means of the=
=20
>location of the speaker and the time at which the speech could have occu=
rred.

"using" is imprecise. "spoken", "read", "though", etc. should be document=
ed.
Is the "could" voluntary, as it introduces a interesting complexity.=20
Obviously this one language can be tough, a second spoken, a third read a=
t=20
the same time (real time translation, considering the directory of an=20
international meeting).

>The language tag is given by the following format (formal ABNF to follow=
).
>
>XLanguageTag ::=3D latitude "-" longitude "-" altitude "-" time

I thank you for disclosing your ultimate target. This implies a default=20
language, a default script.
This is not compliant with the charter is you do not specify the ISO=20
standard being used?

The real value of this proposition is its immediate support of IPv6=20
reference. There is already several propositions to allocate a /3 Block t=
o=20
a geographic addressing in /64. The time value will be OK as an interface=
=20
value. The interest is that the XLanguageTag can be encrypted. This means=
=20
that you can have a protected hidden language tag, fully BCP 047 complian=
t.

>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 startin=
g at
>the South Pole and going north.

Sorry, wrong. A radian is equal to 360/2 pi. So, you mean 2 pi and pi.

>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.

Radian cannot be negative.

>Should in the course of the development of this RFC, the use of the Prim=
e
>Meridian be viewed as representative of an English-speaking hegemony, a
>random longitude will be chosen as the origin.

Conforming to the IANA randomization process. But this process is biased =
as=20
it uses the Wall Street Journal.

>  Use of latitude and longitude
>does not, of course, imply in any way that those who believe in a flat e=
arth
>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 denigr=
ate
>the goal of the Kansas State Education Board to recognize the value of =CF=
=80 as
>exactly 3.0.

Fair enough.


>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 Dea=
th
>Valley and similar locations by in any way referring to them as "negativ=
e".

This obviously creates a problem, since the value of the Earth radius=20
varies with the move of people on Earth. There should be a function to=20
relate the language being used to the local position of the reviewer at t=
he=20
time the language is heard.

>For location, since people rarely overlap

This seems to condemn the system in short delay if human cannot reproduce=
.=20
A large part of the Hollywood industry may oppose.

>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.

I am relieved.

>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 a=
void
>negative numbers, and their implied bias against historic inhabitants.

I am afraid there is a problem with the quantum decoherence. You seem to=20
imply that the four dimensions can be simultaneously known? This will not=
=20
scale. Please refer to RFC 1958.

>The offset is chosen as to be well before all current estimates of the B=
ig=20
>Bang.

Which Big Bang, in which universe? Please consult=20
http://superstringtheory.com/

>Note, however, that this in no way implies any denigration of creationis=
m,
>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 Gre=
ek
>or Norse creation theory, is any way inferior to any other, such as that
>espoused by the Kansas State Education Board.

This constant reference to the Kansas dominance is not acceptable as it=20
introduces a single point of failure in this otherwise excellent=20
improvement on the previous Draft. Bravo!

>Other parts of this proposal, such as security implications, will be
>forthcoming.

Please do not forget IANA and multilingual considerations. As Misha=20
indicated it, it will not fly the Last Call as Vint Cerf will certainly=20
object that it does not support space.

>=E2=80=8EMark

You see that at the end of the day we could reach a consensual position.
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru