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 at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.