Message-Id: <6.1.2.0.2.20050326210800.043a07e0@mail.jefsey.com>
Date: Sat, 26 Mar 2005 22:06:26 +0100
To: "Doug Ewell" <dewell@adelphia.net>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] Re: Registry in record-jar format
In-Reply-To: <000801c53227$3ba04640$030aa8c0@DEWELL>
References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org>
	<000801c53227$3ba04640$030aa8c0@DEWELL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ltru@ietf.org
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Doug,
I will certainly be polite and address all your points, but I hope that at 
the end of the day you will read and accept what I say in responding your 
first part. We are both accustomed to the political aspects and tricks of 
normalization.

On 18:14 26/03/2005, Doug Ewell said:
>JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:
>
> > I extensively use my footer to evangelize about this WG's work (it
> > informs people and leave them free to make their mind). I would
> > appreciate (as well as anyone else maintaining a file on line of
> > relevance to this work) to give the exact wording they wish I add for
> > their file.
>
>"Extensive" is the word, all right.  I have other words for it as well.

"Of or relating to the cultivation of vast areas of land with a minimum of 
labor or expense". Yes.

>Your signature block:
>* is 33 lines and almost 2000 characters long, far beyond the accepted 
>limits for Internet mail;

Reference?
1869 bytes isn't all that much in comparison to the things we store and 
pass around nowadays.

>* implies that we are trying "to standardize languages and to unify the
>world under a dominant culture," which is not only demonstrably
>inaccurate but highly offensive as well;

It implies nothing. It is a very lenient form of the comments I hear all 
the day long about this work. I am not sure why you oppose it?

>* includes a Jon Postel quote, the relevance of which is puzzling at
>best, since region subtags *are* based on ISO 3166 codes, at least as
>much so as ccTLDs;

So, I do not see why it is puzzling?

>* includes a Brian Carpenter quote, also with dubious relevance, since
>ccTLDs and regions in language tags are not "the same problem," and do
>not therefore require the same solution, especially in the context of
>"protocol functionality";

IMHO this is inaccurate and highly offensive as well, if you accept to 
think about what you say implies.

>* makes a comparison between ISO 3166 and ISO "693" [sic] which is
>puzzling and obscure even without the lingering typo.

Thank you for correcting the typo. This remark is puzzling and obscure to me.

>Instead of adding even more wording, I would suggest a simple signature
>block of no more than four lines (some say six is acceptable), with your
>name, e-mail address, affiliation, maybe a single short quote, and
>probably a link to the LTRU archive so interested people can visit,
>join, and make their own judgments.  They don't need "evangelizing."

Thank you, dad, for your advise. We really live in two worlds appart :-)

>Now, back on topic.
>
> >> (BTW, nobody has commented yet on my recipe for populating the
> >> language subtags, so I assume there's nothing dreadfully wrong with
> >> it.  I'll do the other sections in similar fashion, perhaps this
> >> weekend.)
> >
> > Could you please make it a clean part that we could include in our
> > Draft?
>
>I'm working on it.  Easter weekend activities may prevent me from osting 
>additional installments in the next few days, but it is on its way.

Yes. Thank you. Same for me. I may have an extra week delay, because a lot 
of printing I ordered for our work is delayed: the printing shop closed for 
the Easter WE ....

>I think the current theory is indeed to put the description in the draft, 
>rather than relying on the pre-built registry.

IMHO it would be better in a second RFC. To preserve the weight of the main 
RFC (when quoted, printed). To permit to update that RFC separately.

> > The problem as usual is the usage made of it, and the load imposed on
> > IANA and private mirrors...
> >
> > Another point we try to consider is the developing countries and
> > islands problems. ADSL US or European or Korean traffic costs nothing.
> > But 600,0000 at real 500 characters per second or less is 1200
> > seconds. When you know that in some countries one hour of internet
> > equals one day work salary, you see the digital divide this represents
> > for some of the really most involved searchers.
>
>Happily, nobody will be required to download a fresh copy of the
>registry every time they wish to read or write a language tag.  Section
>4, "Security Considerations," says:
>
>"Although the specification of valid subtags for an extension MUST be
>available over the Internet, implementations SHOULD NOT mechanically
>depend on it being always accessible, to prevent denial-of-service
>attacks."
>
>This applies to cost-of-access concerns as well as security concerns.

I am afraid you missed the concern. SHOULD NOT is not a MUST NOT. You 
should understand that the format will make a lot of difference. If the 
presentation is in XML the unnecessary usage will probably be 10 times 
larger. There is a good example: the http://ref-editor.org In 1200 days 
there have been 1.800.000, ie 1500 accesses a day. What is far lower. But 
you understand that 600.000 bytes are not the 3 to 10 000 bytes of an RFC.

This Draft must define all that in detail in IANA considerations. The 
solution requested must be workable. I know that our Chairs do not want 
Doug Barton to share in this WG, but we would certainly need to have 
precise inputs.

I want also to underline that the figure I quote are not for "every time", 
but very conservative (1 a year) as you call for.

> > Permitting people to exchange in different languages over real time
> > information is of the essence for international assistance for
> > example. So languages, terminology, etc. are an important elements.
> > But at the same time we need to qualify that information, to keep it
> > as dense as possible, to "culturalize it" to that end (because a DoS
> > costs too much - and this is why IP is not a proper vehicle, and
> > IPSec is costly). This is where you find that ISO 3166 is of
> > importance but it does not address the diaspora, the immigration, de
> > cultural, the corporate, the reader/viewers classes, etc. This is
> > where you understand that Governments on_the_network are also
> > perceived through their e-regalian embodiment of services - and
> > possible interference with CRCs.
>
>I don't see what 90% of this has to do with language tags -- surprise --
>but I would suggest that ISO 3166-based region subtags used to indicate
>"language variations used in a specific region, geographic, or political
>area" apply equally well to a diaspora or to other types of immigrants.
>That is, if you were a Frenchman living in Canada, your language variety
>might well be "fr-FR" rather than "fr-CA", and in some cases it might be
>important to tag that distinction.
>
>Newer versions of Windows include a "region" setting in Control Panel,
>distinct from the traditional "language variant/locale" setting that has
>always been there.  The idea is that (assuming the above scenario) you
>could set your language and other locale preferences to "French as used
>in France," but still specify that you are physically in Canada for
>applications where that matters.

Thank you for the 10% (in standardization, there are not such a way as %, 
if there is a need it must be supported 100% or not). What you quote about 
Microsoft is interesting. But it looks like a way to tune an obligation 
imposed elsewhere? (if you speak French and are in Canada you are supposed 
to speak fr-CA?). But this is a good point. I recall you that my lang5tag 
proposition is not only in line with every dictionary, but also with Word 
and with the "preferences" quoted in the Charter.

jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru