Subject: RE: [Ltru] follow-up of an exchange on [email-masked]

From: "Addison Phillips" <[email-masked]>
Date: Fri, 18 Mar 2005 08:42:35 -0800

> But I need
> first to review the draft (I said I will do it early next week).

You send us all this without having actually read the draft? 

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of JFC (Jefsey) Morfin
> Sent: vendredi 18 mars 2005 08:00
> To: LTRU Working Group
> Subject: [Ltru] follow-up of an exchange on [email-masked]
> 
> I have been questioned on the ietf-languages mailing list. The dialog lead
> to a threat which belongs to this WG. We agreed to transfer it. Here is
> the status of the current relevant exchange.
> 
> 
> 
> 		[I respond to one question] ... they are/this is more related
> to the 5 levels/points underlaying a multilingual internet (I am not sure
> they are layers, they just are necessary)
> 
> 
> Addison comments them and obviously we are in rough agreement (these
> points are in the Charter as "identifying languages and language
> preferences" - like in the Word tools menu. We only disagree on scope and
> application of the RFC. I think there are many ways to make the two
> positions converging and to see new synergy resulting from it. But I need
> first to review the draft (I said I will do it early next week). Responses
> from Addison and Mark to these comments will help, as weel as comments of
> this WG.
> 
> On 19:29 17/03/2005, Addison Phillips said:
> 
> 
> 	> - identification of the language (ISO 693 or the like) ->
> interrelation
> 	> between people - we can talk
> 	RFC 3066 and 3066bis call this "primary language"
> 
> 
> Correct. However a general remark: this is an analysis. It permits the use
> of the words we agree upon, but it is more general. I am interested in the
> users needs and in the network systems' answer to support them in the way
> applications/developers may want to perform them. My priority is to the
> users, to the network and to the applications, not to the RFC or ISO
> document. And I live in a real world. I am not interested in good document
> you cannot implement due to (may be stupid but real) external objections.
> 
> - as a user I consider myself (the need I know the best), the people I
> develop/consult for in my position of "super IANA like" (CRC) project, the
> Governments I relate with and most of all multilingualism in naming, e-
> government, day to day life as per the various ITU, WSIS, UNESCO unanimous
> declarations.
> 
> - as far as network are concerned I consider the Internet current
> architecture, the Interbox architecture I work on (first guidelines a
> delayed by all this and current debates, presented to Govs and ITU last
> months: roughly a virtual user centric NGN permitting the transition from
> current Internet), the management of the few extended services of the
> Internet architecture (name space - DNS, ONS, Handles, PAD, OPES, ONES),
> the dramatic architectural impact on a robust yet rustic end to end
> oriented architecture of multilingualism.
> 
> - as far as applications are concerned I am interested in the consistency
> of the different existing tools, but I am also interested in all the
> applications delayed by the limitations of the current systems. I am
> advocating the most robust, simple and open common basis to permit to
> develop compatible tools rather than standardizing one single application
> which will become overloaded with incompatible demands. A good example of
> a success in that direction is the DNS which has well resisted since 1983
> (RFC 920).
> 
> - as a Registry Manager involved for 30 years in the international public
> and private real intergovernance.
> 
> 
> 
> 	> - internationalization (what discusses RFC 3066 - ISO 15924) ->
> 	> interoperation between machines - we can write
> 	RFC 3066bis calls this "script"
> 
> 
> Yes. Same as above.
> Also, users are not bond to scripting. Other supports (voice, signals,
> commands, icons, images, fax, Minitel, music, etc.) are OK with this
> analysis. In your context we agree.
> 
> 
> 
> 	> > - multinationalization (taking into account ISO 3166 or other
> geopolitical
> 	> attribute) -> interculturization between communities - we can
> share same
> 	> cultural references, the same meanings (for example, what may be
> missing
> 	> in
> 	> here).
> 	RFC 3066 and 3066bis call this "region"
> 
> 
> Yes. Same as above. But in your context you refer to a region. IAnalysis
> is not limited only to that. It can be a Diaspora, a Church, a culture,
> etc. Look at Tamils for example, as a population.
> 
> 
> 
> 	> - multilingualization (semantic, grammar, dictionary, syntax, etc.)
> ->
> 	> interintelligibility -> we can understand each other
> 
> 	RFC 3066bis calls this a "variant"--variations within a language,
> which may take many forms (orthography, dialect, etc. etc.). RFC 3066
> allows entries that represent this to be registered (but doesn't identify
> them explicitly with a name). Both allow multiple variations to be applied
> to a text.
> 
> 
> Here I think we have a real difference.
> 
> If I read you correctly, you discuss of variation _within_ a language. I
> discuss of what describes a language. I suppose that you will translate
> this into a different code/description permitting someone to qualify a
> text with a different tag. I will translate that into a CD including all
> the data necessary to describe the language to a computer, to permit to
> authenticate the origin of the text and to write and edit the text.
> 
> 
> 
> 	> - vernacularization (procedures, styles, tools, etc.) ->
> interusability ->
> 	> we can do something together
> 
> 	Language tags identify text, not the processes that are applied to
> them.
> 
> 
> This is the contentious point we have from the very beginning. Would you
> have included that sentence in the RFC 3066 bis it would be an applauded
> RFC by everyone. I will come back below on this key point.
> 
> 
> 
> 	A French text that has had French hyphenation rules applied to it is
> just a French text. Particular vernacular distinctions may be candidates
> for registration, though, although this dives into more difficulty: is it
> another language or merely stylistic license? Merriam-Webster defines
> vernacular thus:
> 
> 	1 a : using a language or dialect native to a region or country
> rather than a literary, cultured, or foreign language b : of, relating to,
> or being a nonstandard language or dialect of a place, region, or country
> c : of, relating to, or being the normal spoken form of a language.
> 
> 
> The interest of this langtag is to show that the questions you rise are
> structurally well addressed by our common analysis. The lang3tag you
> propose relates to a region and matches (a) and (b). But these are old
> description outdated by the current world which is more generally
> described in (c). Here you have a problem because your tag could (but your
> ISO 3166 oriented approach prevents that) to use virtual regions.
> 
> Obviously we lack the common usage of a model where we could spot these
> issues as I am accustomed in my working groups. But you are in W3C and you
> know about web services. When two web services interacts they actually use
> a vernacular and their Man/machine interface will try to accommodate it to
> the users' language and brainware (the way people commonly use a network
> system). This results in a web vernacular, in a mail vernacular which
> currently is an ASCII vernacular but should multilingualize (and RVC 3066
> is a key building block). When I see To: From: these are vernacular terms.
> This is very interesting to see when people know/can change the mail
> answer back line to see the formula they use from English "said" to Latin
> "Scripsit".
> 
> Obviously vernacular with that meaning includes a quasi illimited type of
> procedures.
> 
> 
> 
> 	In other words, Twain's "Pudd'nhead Wilson" is written in a
> particular vernacular form of U.S. English. One can register a variant
> (under 3066bis--or a tag under 3066) that conveys this distinction
> (perhaps "en-US-twain"):
> 
> 	"Say it ag'in! En keep on sayin' it! It's all de pay a
> 	body kin want in dis worl', en it's mo' den enough.
> 	Laws bless you, honey, when I's slav' aroun', en dey 'buses me,
> 	if I knows you's a-sayin' dat, 'way off yonder somers,
> 	it'll heal up all de sore places, en I kin stan' 'em."
> 
> 	Generally though this is considered unnecessary. There are many
> vernaculars in the world. Only in exceptional cases does it become
> necessary to identify a particular language variation as distinct. But
> this does not obviate the point that RFC 3066 (and its proposed successor)
> already provide a mechanism for doing exactly that to identify text in the
> cases where the differences matter.
> 
> 
> I do not dispute the case. I just document an analysis. I am glad to see
> that even if we may have slight differences, we are basically in agreement.
> And that you testify that what I say is in RFC 3066. I documented that in
> telling that I could encapsulate the RFC 3066 in my own approach. And
> asked if the way I was doing it was reducing in anyway your proposition.
> The only objections I received were on my own part, not on my support of
> yours.
> 
> 
> 
> 	(For that matter, 3066bis relaxes strictures surrounding the use of
> private use subtags so that specialists can identify various dialects or
> vernacular usages among themselves without the use of registration: "en-
> US-x-twain".)
> 
> 
> This is internal to your proposition. I am glad you increase flexibility.
> The only remarks I have is that I am not only concerned in specialists but
> in every Internet user. I have observed that what is supposed to be
> reserved to specialists is quickly used by everyone with easy to use tools
> and support. This is what RFCs call scalability. Everything has to be
> documented and planned in a standard as if it was going to be used by
> everyone all the time. RFC 1958.
> 
> 
> 
> 	So how is what you're saying different from RFC 3066bis? Heck, how
> is it different from RFC 3066?!?
> 
> 
> In the way RFC 3066 is actually used, it is not. This is what we are
> trying to tell you for two months. The problem is:
> - if we are perfectly happy with RFC 3066 as it is applied today and we
> can stay happy for ever.
> - you documented you are not. And we certainly want your needs to be
> satisfied, but in making us unsatisfied.
> And I extensively documented what is detrimental, I can come back again on
> it.
> 
> I will use some HTML to make the presentation clearer. I hope all the
> readers can use it.
> 
> 
> 
> RFC 3066 IS NOT APPLIED
> RFC 3066 works well because it is not really applied. What you want will
> make it applied and will show its lacks and the lacks of its
> implementation. This lacks are to be corrected. There are mainly three.
> 
> 1. the ietf-language mailing list
> 
> The ietf-languages mailing list is not the IANA list presented in the RFC
> 3066. It should be managed and archived by IANA and documented on the IANA
> site to get the necessary exposure, participation and recognition by the
> international community. This would most probably help it to self correct
> what I reproach to it. One of the things it would probably have permitted
> to evaluate is its moderation and the reviewer which should probably be a
> three persons committee selected as two linguistic experts of English and
> of French culture and one network expert.
> 
> 2. a consistency with the considered (ISO) lists
> The RFC 3066 confuse the process and the deliverable. Up to now this is
> not too much notice because RFC 3066 is only occasionally used and the
> tables updated. It will change when it is extensively used.
> 
> The deliverable is the IANA added code. It should be consistent with the
> ISO lists it intend to complete. There is too much confusing information
> (name of the referent, documentation of the language). And there is no
> French translation. If someone needs the additional subtag she will know
> what it is. All the subtags must be of same weight and definition. How do
> I know that an ISO 693 code is really what I mean and if someone is not
> going to introduce a new IANA code which will better define my need? How
> do I know what ISO meant when I know what IANA means. On an other end what
> should I do when the IANA added code match my need but not the description?
> How do I make its use consistent with the use of the other ISO codes?
> 
> 3. the default format being unique
> RFC 3066 to my knowledge is used by your W3C applications, by Unicode, etc.
> outside of Internet documents and IANA except for IDNs. This obviously
> does not help to identify this problem and I am taxed to underline it,
> people focusing in the only example at hand, rather than on the
> fundamental problem.
> 
> RFC 3066 starts with the conclusion. The format proposed format should be
> tone of the conclusion of the analysis. As the use, as the registration
> procedure, etc. Because you use a given format in a certain kind of
> applications, you want to use that format for ever. By this token UNIX
> would use DOS which would use DEC file format. Life is more flexible and
> innovation comes from flexibility. The format you propose does not suit my
> needs. It should not be a big deal to stay compatible.
> 
> 4. You do not care about others' needs
> The lack of RFC 3066 apparent use in other areas than your current
> applications gives the feeling that RFC 3066 can conduct the world. The
> idea that Countries may be taught to ask for ISO 3166 langtag compliant
> codes from other countries experience seems odd.
> 
> This also does not help to understand that you are shaking an existing
> stable situation and status quo. But you actually come and propose changes,
> you do not care about those who are affected ("you" - at large - even want
> to expel them).
> 
> Multilingual Internet
> 
> The status quo is based upon the very low interest in multilingualism by
> IAB. Demonstrated by the only RFC 3066, the low consideration of  Paul
> Hoffman's initial work, and the clear disinterest signal of the IAB's RFC
> 3869 (which lists the development priorities to be funded by the
> Governments - of every nations and languages - and does not even allude to
> multilingualism). Now, you want to make it a core issue interfering with
> the core issue of country codes through your ability to discuss ISO 3166,
> but more questioning the entire Internet architecture!
> 
> To understand this, you have remember how a network is built. Every
> network. Even if it is quite buried in the Internet defaults. A network
> permits a class of users to relate with a group of resources in using
> common identifier they register and manage in a registry (NIC) and
> parameters they store in a common repository (IANA, CRC). The initial
> international public network technology (1971) we deployed fully supported
> classes and groups and permitted to support an unlimited number of
> national, linguistic, corporate, public interest externets (a class, a
> group, a registry, a context supported by reference center). OSI
> principles (1975?) reduced externets to the notion of closed user groups,
> making the class (users) and the group a single list. Internet (1978-83)
> as a private network internetting (Vint Cerf/Bob Khan) into a DoD catenet
> (Louis Pouzin) only considered the Internet users class ("IN" and the
> "CHAOS" test class) and did not really mind about groups (DNS views can
> very partly reproduce, as well as intra/extranets). This permitted to
> dramatically reduce the intelligence expected from the network and to
> build a robust (but quite rustic!) network based upon the two "core
> values": dumb network, end to end.
> 
> Now, multilingualism was initially started (Japan, EBCDIC and
> France/Minitel) in using classes of non ASCII users interacting with group
> of resources able to respond them. This would correspond in the Internet
> to create 1.600.000 classes and to implement a group support which is
> totally inexplored today. A totally new DNS technology. Also, to speed up
> routing the group support would probably call for a different IPv6
> structuring such as the one proposed for the ITU-T /3 block. We will have
> to come to that, but not now! Let experiment the transition first.
> 
> IDN introduced the idea of supporting multilingualism in the ASCII class
> in using internationalization. But this does not work because the analysis
> is not correct. It just focused on the DN and not on the FQDN and
> introduced a hierarchy (punycode or not are filtered) in the label rather
> than in the namespace. This means that they did not identified the need
> for virtual zones (sub-classes in the IN class) and the need of
> consistence of the vernacular (IDN Tables) used in that virtual zones.
> Result: the current homographs problem. The correct solution consists in
> respecting the standard network architecture in a scalable way and to
> force the multilingual FQDN (FQMLDN) to be consistent from the TLD to the
> last level. Due to the inclusion on the IN class and its existing number
> of TLD there must be a _presentation_ of the zone (lingual SLD) as a
> single label (ex nnn.chinesetag.cn being displayed as
> nnn.chinese_printing_of_cn) and a filtering of all the codes which are not
> permitted in a correct FQMLDN. For that all the concerned machine must
> have the necessary (limited) information of how to present a lingual SLD
> as a lingual TLD, and the corresponding IDN Table. There are three places
> to distribute them: either the IANA and the CRCs, either a dynamic
> repository like Akamai, or the Locales.
> 
> So, you understand that langtags are actually the names of the lingual
> externets or their aliases. Also, that depending on the way they are
> organized, they may fit or not into the DNS as it is managed today. Also,
> that while the WSIS is discussing the intergovernance there are a lot of
> interest to play it clearly, not to confuse the issues.
> 
> Applications
> you consider only the applications you know. But you disregard the
> applications others are/should be (:-) working on (like OPES at the WG-
> OPES and ONES in other places, the CRCs as far I am concerned). And all
> those a correct support of multilingualism and vernacular could unlock.
> The web is a dazibao. One does spend our life reading. As Hitch says: 90%
> of the human communication is not with words. This leaves   a large number
> of applications  to develop. Their tagging needs are as much important
> than any other.
> 
> 
> THE KEY ISSUE
> 
> The key issue is what the langtag for?
> The charter says: they are necessary from (a) cataloging to (b) processing.
> You say: "Language tags (c) identify text, (d) not the processes that are
> applied to them".
> The Draft says:  "This document describes the structure, content,
> construction, and semantics of language tags for use in cases where it is
> desirable to (e) indicate the language used in an information object. "
> Introduction of the draft says: "(f) Information about a user's language
> preferences commonly needs to be identified (g) so that appropriate
> processing can be applied"
> 
> Dictionary.com says:
> "indicate":
> (h) to show the way to or the direction of; point out: an arrow indicating
> north; indicated the right road by nodding toward it.
> (i) to serve as a sign, symptom, or token of; signify: "The cracking and
> booming of the ice indicate a change of temperature" (Henry David Thoreau).
> (j) to suggest or demonstrate the necessity, expedience, or advisability
> of: The symptoms indicate immediate surgery.
> (k) to state or express briefly: indicated his wishes in a letter;
> indicating her approval with a nod.
> 
> If the purpose is informative, the way I read (a), (c), (d), (e), (f), (i),
> things are OK with me.
> If the purpose is normative, the way I read (b), (g), (h), (j) and
> possibly (k), things are not in the present status of the document.
> 
> Due to the limited use of RFC 3066  discusses above the question was not
> risen. They were used the way you say, to qualify/catalog texts in
> different applications and for IDN Tables.
> 
> But RFC 3066 - and you and Charter - uses a wording and you use examples
> (Introduction) which creates ambiguity and confusion about the intended
> use of the langtags. You can qualify a text with any descriptor you want,
> this creates no problem. You can use the langtags as a search key the way
> you want.
> 
> But to document the definition of the way a text is to be processed, you
> need at least all the five the descriptors we described. This is not
> something you can dispute or you kill the analysis you described as being
> also the RFC 3066 analysis.
> 
> If you do not provide these 5 elements, you actually imply the defaults
> are to be used. There is no default documented in the RFC 3066 and in your
> draft, except the name of the registrant/referent. He the becomes the
> default to tell what are the missing parameters. If the name is of a
> person, the opposition to that person will unnecessarily creates an
> opposition of the lingual community - even if the tag is correct. If the
> name is of a corporation or associated to a corporation this may be worse
> and detrimental to the interest of the voluntaries who carried the effort.
> 
> 
> 
> 			 didn't think any Microsoft product dealt with "style"
> or "authority"
> 			attributes, nor in script except to the extent that is
> covered by
> 			registered RFC 3066 tags.
> 
> 
> 		Name the reference/authority, etc. the way you want.
> Authoritative in its domain is an usual concept in the Internet culture.
> You can certainly find other words. This is what says a computer that when
> I write in French this is not Greek, or what make you sure that when I
> write in Provencal it is not Berrichon.
> 
> 		I gave in my response to Peer how and where the Word system
> does that.
> 		- tools - languages : language, script, country  (you can
> qualify even if you do not understand).
> 		- tools - options (preferences?) : dictionary, style (you need
> them to understand and write).
> 		Which system do you use? Does it support the same descriptors?
> 
> 
> This addresses an objection you made in another email, saying that these 5
> points were not covered by Word and that your Word 2003 was great because
> it did not support RFC 3066 which was not yet published. Actually, I do
> use Word. My copy is Word 97, and even in these ancient times, these
> points we identified/share are here. It only add the proof of the age.
> 
> 
> 
> 		This being said, I understand your remark about what I name
> the multilingualization level. You say English is not defined. I belong to
> a culture where definition is known and supported for 4 centuries. This
> makes me more aware of this point. Actually English, in a way is more
> defined than French. When we introduce a computer in a culture, we do in a
> few months, a few years, what Richelieu and France did a long ago and
> matured over centuries: we create an "Académie de cette Langue".
> 
> 
> BTW this is probably a very interesting and exciting field of work.
> 
> 
> 
> 		What I object is that this Académie may belong to anyone else
> than to the people sharing that culture. And naming is already a way to
> own. As long as it is to qualify the culture it is OK because there is a
> need. When it comes to enter in its definition this is - IMHO - an
> intrusion. And I refuse to share in that kind of intrusion.  To the
> contrary my approach is to say we are here to serve, help, educate so they
> can first share in this process, comment it and eventually conduct it for
> themselves.
> 
> 
> I fully understand and support (with may be some tunings, like the support
> of namespace related information) the Unicode CLDR project - which is in
> the IESG charter but not documented - I wonder why. But I would strongly
> object to it if it was not carried under the supervision of Members of the
> concerned communities. Frank hates Governments. I tend to think they are
> our only protectors against e-colonization. Each of us have our fancies.
> 
> 
> 
> 		I note that three days ago this list had 2 Greek languages.
> Now 3 and probably 4. Because Greek persons stepped in and documented
> _their_ own languages. This is the way it should happen for every language,
> the request should come from each Internet community. This is the spirit
> of the text of RFC 3066. I fully understand that people may want urgently
> scan the cultural patrimonies of others, to sell it or to protect it from
> being merchandized, want to speed up the process. I do not think it is
> commercially or charity advisable to by-pass their future
> customers/friends in this process (as the reactions to the Google's
> annoucement show it). To the contrary they should help empowering the
> language and help their cultural, linguistic, political authorities
> through the registration process.
> 
> 		For example, I fully agree with you that the name of the
> langtag registrant is not necessary. But I would suggest to remove it only
> when the registration is by an outsider.
> 
> 
> I note that if two languages are used at ISO (while UNESCO and ITU use 6
> languages) there is probably good reasons, which may be to make sure that
> several and at least two cultures shared into the analysis (for defining
> the tag and when using it). This forces an openness of mind we often need.
> It means alternative thinking, searching, etc. Back-up is always a good
> thing. Two languages help also help the user to make sure the code she
> wants to use is the good one. Acceptance of a bilingual table will be far
> higher in a multilingual context than an ASCII only table.
> 
> Coopetition tends to foster quality.
> 
> I hope that this will eventually help.
> jfc
> 
> 
> 
> 
> 
> 
> 
> =====================================================
> For your convenience:
> Draft:  http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-
> 00.txt
> Charter: http://ietf.org/html.charters/ltru-charter.html
> gmane: http://dir.gmane.org/gmane.ietf.ltru
> If you were Bcced for information and not familliar with the IETF process:
> http://www.ietf.org/rfc/rfc2026.txt
> http://www.ietf.org/rfc/rfc2418.txt
> http://www.ietf.org/rfc/rfc3934.txt
> http://www.ietf.org/rfc/rfc3669.txt
> http://www.ietf.org/rfc/rfc3160.txt
> http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
> =====================================================
> Jon Postel (RFC 1591): "The IANA is not in the business of deciding
> what is and what is not a country. The selection of the ISO 3166 list
>  as a basis for country code top-level domain names was made with
>  the knowledge that ISO has a procedure for determining which
> entities should be and should not be on that list."
> =====================================================
> Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
> same thing, choose one. If a previous design, in the Internet context
> or elsewhere, has successfully solved the same problem, choose the
> same solution unless there is a good technical reason not to.
> Duplication of the same protocol functionality should be avoided as far as
> possible, without of course using this argument to reject improvements."
> =====================================================
> It seems that what works for countries and ISO 3166 since 1978 should
> apply to languages and to ISO 693.
> =====================================================

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 19 Mar 2005 21:28:24 +0100

>You send us all this without having actually read the draft?

I do not understand how I must take this?

If you read me, you know I am only interested in correcting the flaws of 
RFC 3066 your new use will highlight. I trust you for your own needs. I 
wish I could only have to go into detail into your final draft to make sure 
all what would harm us/others has been removed.

jfc

======================================================
Standardizing Tags for the Identification of Languages should not be a way
to standardize languages and to unify the world under a dominant culture.
======================================================
For your convenience:
RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066
Draft: 	http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt
Charter: http://ietf.org/html.charters/ltru-charter.html
gmane: http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
======================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
  as a basis for country code top-level domain names was made with
  the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
======================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
======================================================
It seems that what works for countries and ISO 3166 since 1978, should
apply to languages and to ISO 693.
======================================================

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 19 Mar 2005 13:10:39 -0800

Hi -

(Co-chair hat ON)

> From: "JFC (Jefsey) Morfin" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, March 19, 2005 12:28 PM
> Subject: RE: [Ltru] follow-up of an exchange on [email-masked]
>

> I do not understand how I must take this?

IETF working group participants are strongly encouraged to read and
comment on the working group's drafts.  Making comments without
having read the document under discussion is likely to waste time and
energy.  All should take to heart advice in section 5.3 of the Tao update
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt

   The most important thing that everyone (newcomers and seasoned
   experts) should do before coming to a face-to-face meeting is to read
   the Internet Drafts and RFCs beforehand.  WG meetings are explicitly
   not for education:  they are for developing the group's documents.
   Even if you do not plan to say anything in the meeting, you should
   read the group's documents before attending so you can understand
   what is being said.

This isn't just true of face-to-face meetings; it's true of WG mailing list
discussions as well.  Prefacing a statement with "I haven't read the drafts,
but..." is a sure-fire way to ensure that anything you write will be taken
cum grano salis, if not ignored.

> all what would harm us/others has been removed.
...

Waiting until last call to make comments is a good way to ensure that your
comments are not addressed in the way you might like, particularly if they
are at odds with the WG consensus in place at that time.

So, and this goes for everyone, READ THE DRAFT!   If there is material
that you think needs to be added: please send suggested text.  If there is
material that you think needs to be deleted: identify the specific passages.
If there is material that you think needs to be modified: please identify the
text to be changed, and supply suggested replacement material for discussion.
The time for discussing change proposals  is NOW.

(Co-chair hat OFF)

Not ltru-specific, but of general interest to IETF WG participants:

A quick read that some participants on this list might find helpful is
http://www.ietf.org/internet-drafts/draft-eastlake-prominence-02.txt
There's a lot of sound advice there, even for those not interested
in prominence.  Its author is looking for feedback, especially from
those with experience outside the IETF.

Randy

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 20 Mar 2005 00:23:26 +0100

At 22:10 19/03/2005, Randy Presuhn wrote:
>comment on the working group's drafts.

Dear Randy,
shhhh...... this teasing starts being tiring and totally counter productive.
I suggest you  _read_ the exchange above.

Obviously I read the draft ... and make it read! My question was precisely 
about the hurting supposition that I did not _read_ the draft when I said 
that I will _review_ it. I am surprised you add your own: the line you 
removed also added "I will go into details".

I do not use to formally comment without having carefully studied the 
things. I have no intent to waste time in reviewing the draft and propose 
an alternative draft if Addison has modified it, considers others needs and 
stops hurting the rest of the planet.

This being said I still have not all the feed-backs from the people I 
polled. I will also wait for the feed-backs from the WG. I only hope that 
we can reach a consensus.

In case we have some misunderstanding between en-FR, en-UK and en-US:

Review, v tr.
    * To look over, study, or examine again.
    * To consider retrospectively; look back on.
    * To examine with an eye to criticism or correction: reviewed the 
research findings.
    * To write or give a critical report on (a new work or performance, for 
example).
    * Law. To reexamine (an action or determination) judicially, especially 
in a higher court, in order to correct possible errors.
    * To subject to a formal inspection, especially a military inspection.
v. intr.
    * To go over or restudy material: reviewing for a final exam.
    * To write critical reviews, especially for a newspaper or magazine.
I observe that to date the debate of this WG only concerns minor editing 
while important structural points are at stake.
But it seems that JFC teasing is a priority. If it pleases you .... but in 
the meanwhile it does not make the things to progress.
Take care.
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 19 Mar 2005 18:45:26 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Saturday, March 19, 2005 3:23 PM
> Subject: Re: [Ltru] follow-up of an exchange on [email-masked]
>

...

I'm not teasing.  I'm deadly serious when I write that IETF working group
participants are strongly encouraged to read and comment on the working
group's drafts.  We are here to get some work done.  If you care to make
relevant contributions to the effort, e.g. specific comments on the drafts,
they would be welcome.  Whining and antagonistic posturing are not.

Randy