Subject: [Ltru] Re: 3 - Simplified registry ABNF

From: "Doug Ewell" <[email-masked]>
Date: Tue, 3 May 2005 08:25:05 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> No, you've got that backwards again.  I didn't create the
>> format.
>
> Of course _you_ have created lstreg.txt.  There's absolutely
> nothing backwards with it.  You didn't use a space before the
> colon (allowed by the draft), you used a space after the colon
> (not required by the draft), you used a certain natural order
> of fields per record and of records per type (both AFAIK not
> required by the draft), and that is all perfect as it is.

I apologize for the tone of my response.  Let me put it this way: I
didn't dictate that there would be a space here and would not be a space
there, when the syntax allows a space but doesn't require it.  I hope
the syntax of lstreg.txt is correct according to the ABNF; if it isn't,
I hope someone will let me know.  Beyond that, any discretionary
stylistic choices I made were solely based on what I saw in the draft.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

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

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 3 May 2005 08:34:48 -0700

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

>> Addison is 100% correct: the field names should not be translated,
>> regardless of the location of the server.  This is a fundamental
>> database concept.  Table and column names are to be used internally
>> by the database, not displayed in user interfaces.
>
> grrr....
> not translated: transcripted or whatever funny term you may use to
> mean using different scripts.

Field names in databases should not be:

* translated into different languages
* transcribed (reversibly) into other scripts
* transliterated (non-reversibly) into other languages' writing systems

They are fixed.  It is the content, the field *values*, that changes in
different localized versions.

> When will you understand that multilingualism means different
> keyboards first.

End users don't have to type the field names.  Programmers, who do, have
access to a Latin-script keyboard.  If you can show me a programming
language or environment that does not require at least some use of the
Latin script, I will re-think my position.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 03 May 2005 18:35:13 +0200

>Latin script, I will re-think my position.

Dear Doug.
This is shocking under the pen of a global standadizer. I will not comment 
on the contempt for "end-users", non for the exclusion of non-Latin script 
programmers. Nor on its political and societal consequences. No on the fact 
this may be properly in violation of national laws.

I will certainly change my position if you can show me a programming 
language or environment which cannot be translated so it do requires at 
least some use of the Latin script, I will re-think my position. And please 
do not quote John's meaningless remark on Unicode coding of "0-9" numbers 
(did he heard about EBCDIC of too young for that?).

ASCII centrism was an old odd Internet feature, I am afraid you are 
beginning to make it a boring bug.
jfc

---

From: John Cowan <[email-masked]>
Date: Tue, 3 May 2005 13:15:49 -0400

JFC (Jefsey) Morfin scripsit:

> I will not comment 
> on the contempt for "end-users",

There is no contempt here, but a plain statement of fact.

> non for the exclusion of non-Latin script 
> programmers.

The needs of "non-Latin script programmers" have about as much weight as
the needs of Klingons, and for the same reason.

> Nor on its political and societal consequences. No on the fact 

Cite one such law, please.

> least some use of the Latin script, I will re-think my position.  

Programming languages *can* be transliterated or transcribed, but no one does
that, for sufficient reasons.

> And please

The coding is not the point.  Let me put it this way: there are at least
20 writing systems around the world where numbers are not written using "0-9",
so they are no more "global" than the Latin alphabet.  Your argument proves
too much.

> (did he heard about EBCDIC of too young for that?).

I am quite familiar with it.  The repertoire of EBCDIC encodings is
still a subset of Unicode, though the encodings are not.

-- 
John Cowan  [email-masked]  www.reutershealth.com  www.ccil.org/~cowan
If a soldier is asked why he kills people who have done him no harm, or a
terrorist why he kills innocent people with his bombs, they can always
reply that war has been declared, and there are no innocent people in an
enemy country in wartime.  The answer is psychotic, but it is the answer
that humanity has given to every act of aggression in history.  --Northrop Frye

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 3 May 2005 21:30:37 -0700

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

> 2.  The telephone numbering system is the oldest numbering system
> routing into Telex and ISO 3166 alpha-2 is the telex code.

I know this has been said before, but ISO 3166 alpha-2 is much more than
just the telex code by now.  It has been adopted in numerous contexts,
including (of course) TLDs.  If a previous solution has worked, choose
it again, right?

> ITU and ISO tend to consider it quite stabilized in its principle. Its
> advantage is that it covers everyone down to every individual. It is
> necessarily related to populations evolution (subscribers) who tend to
> have a very good knowledge of it. In this it is better than post codes
> (which also are good candidates except the Bristish alphanumeric
> system and the geography oriented US system [you have many post codes
> with no population]).

You must be talking about ZIP codes (our term for postal codes) assigned
to post office boxes, military bases, and major companies.  Those
certainly do serve a "population" of sorts.  I can't think of any
residential ZIP codes assigned to empty areas.  Of the 100,000 possible
five-digit ZIP codes, less than 43% are assigned.

> The problems you rise come from an equivalent ignorance of E.164 and
> of ISO 3166 and probably of X.121 at that time, and from a non-network
> point of view.

My need at the time was for indexing.  A "network point of view" would
have been completely irrelevant to that project.

> People do not think for the world in ASCII as you do,

<blinks>
I don't know what brought that on.  Are you suggesting that language
tags should be localized to other scripts?

> they think for themselves in their own language, with their own needs,
> and their own numbers they know (usually telephone number and post-
> code, plus whatever universal number anyone could give them they would
> really use - experience and studies show that people can collectively
> remember at least 3 figures, average 5, never more than seven - same
> for names).

The studies you are thinking of show that people can only remember five
to seven *random, meaningless* digits or names.  I'm sure that both you
and I can recall dozens of 10-digit telephone numbers and street
addresses, and know perhaps hundreds of people by name.  That doesn't
mean we have superior memory skills; it means we have something to
connect those numbers and names to.

> This WG has a charter and belongs to the IETF, not to UNICODE nor to
> W3C.

Has anyone suggested otherwise?  Where do you get this about Unicode?

> The first work is to establish a chronological correspondance table
> between all these systems. This is needed in different areas.
> - universal telephone directory (which is to be multilingual)
> - same about whois and their convergence
> - some digital protocol with human protocols implications
> - multilingual internet or multilingual NGN or whatever avatar IETF/
> ITU and others may come with
> - CRC and contexts
> - applications (operating systems: locales, DNS: mlnames, network
> control/statistics, mails, web, opes/ones, etc.)

This is nice.  Over here, we are working on language tagging.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 04 May 2005 12:43:52 +0200

>including (of course) TLDs.  If a previous solution has worked, choose

This is why we can expect and work on some convergence. Including in the 
ISO committees. Again IANA is a dormant Member (ICANN holds the site). Our 
indications in that area should go to the IANA section for action.

>five-digit ZIP codes, less than 43% are assigned.

The official term is "postcode". "postal code" is Franglish (mix of "code 
postal" and of "post code"). The fact that you cannot think of something, 
does not prevent it to be effective. I suggest that:
1. access the http://www.upu.int site and document yourself on postcodes 
(in term of density of population, some ISO 3166 aslo have very low 
densities, I do not understand the remark). 
http://www.escapeartist.com/global10/zip.htm may also help you.
2. IRT the US zip codes, I suggest you do not just make a quick google 
search. The issue is more complex and changing. I have enough worked on 
them a few years ago to risk that suggestion.

>have been completely irrelevant to that project.

If you found interest in E.164 and ISO 3166, DCCs would probably have 
helped you.
Anyway today our interest is in a "network point of view" (network-centric) 
to match the US doctrine. IMHO we should be in a network-user-centric point 
of view.

>tags should be localized to other scripts?

Obviously yes.

>connect those numbers and names to.

I am afraid you use to respond fast. Please reread what I wrote.
"collectively
adv : in conjunction with; combined; "Our salaries put together couldn't 
pay for the damage"; "we couldn`t pay for the damages with all out salaries 
put together" [syn: jointly, conjointly, together, put together]
Source: WordNet ® 2.0, © 2003 Princeton University"

>Has anyone suggested otherwise?

Everyone which does not does not make sure this WG has collectively 
understood and accepted the Charter.

>Where do you get this about Unicode?

Please read the Charter.

>This is nice.  Over here, we are working on language tagging.

Precisely. And if this tagging does not match the above needs the Draft 
will not be accepted. The Draft did not failed two last calls due to poor 
wording on a few points (this can be clarified by the Editor). It has 
failed because its proposition is not the one applications above (and 
probably many other ones) expect.

Let discuss the Charter first, after having made sure that all the 
concerned authoritative parties have been made aware of this WG. I suggest 
each of us describes his concerns as I just did.
jfc