Subject: [Ltru] Getting back on track

From: "Mark Davis" <[email-masked]>
Date: Tue, 22 Mar 2005 13:38:20 -0800

The discussion has meandered around a bit: I'd like to see us get back on
track. Here is how I suggest we proceed.

Within the next week, anyone who has any issues with the text of the current
draft does the following:

a. Composes a separate message on each issue, with a meaningful title.
b. Suggests exact replacement text, with clear instructions on where to make
the change.
c. Describes the pros and cons of making the change.

We review by email each request. If there is consensus for if, then we
record that. If not, we leave it alone. Once we have processed all the
issues, we issue a new draft that incorporates all the changes. We circulate
that, and if there are no problems with the incorporation of all the
changes, then we advance the document.

‎Mark

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 22 Mar 2005 23:15:51 +0100

>changes, then we advance the document.

As indicated we will not be in a position to issue a draft before at least 
two weeks. It will certainly substantially differ from the current draft. 
And will probably be amended during its further international review. But 
the support of your propositions should be as much possible included in it. 
So this schedule seems OK if the Chairs agree. We should have your elements 
in time.

I have however two missing information:
- when do you/Addison intend to comment the inputs he required from me, so 
I can organize our schedule?
- we have discussed nothing on the CLDR aspect. You are the best suited to 
tell us what are the requirements of the CLDR project in the RFC 3066 
context and how we can best address them? I am also obviously concerned 
about the copyright issue as the RFC should indicate that the CLDR is 
public domain. Or we would have to investigate a public domain alternative.

Thank you for your cooperation.
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.
======================================================