Subject: [Ltru] Re: status? last call?

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Jul 2005 23:07:09 -0700

r&d afrac <rd at afrac dot org> wrote:

> No. I say directly or indirectly you cannot reference an third party.

I've never heard of a requirement for RFCs, or even BCPs, that says
informative references may only consist of ISO standards and other RFCs.
Can you point me to a reference?

> Unicode is a consortium of private interets, the same as W3C, etc.

I don't see how this is relevant, but would it make a difference if we
referenced ISO/IEC 10646 instead?

Can you point me to a reference that says the work of an industry
consortium may not be cited in an RFC?

> This WG is to deal with ISO 639, 3166 and 15924, plus UN M.49 (in a
> way I partly disagree with because the format is confusing). Outside
> of that no other code has been accepted: because no other maintainer
> has committed to stay compatible with these codes and her commitment
> accepted by the IETF.

Both Unicode and ISO 10646 are referenced in numerous RFCs.

>> I don't see what ISO 639-4 has to do with any of this.
>
> ISO 639-4 is the ISO document which commits on the consistency of ISO
> 639 series, 15924 and 3166 series.

ISO 639-4 is a committee draft.  We can't be required to adhere to a
standard that doesn't exist yet.

> The author of ISO 639-3 being at the origin of all this effort, I
> undersnand that he insisted on ISO 639-3.

This comment is not relevant to the document under discussion, which
does not support ISO 639-3.  (It can't, since that standard is also in
draft stage.)

--
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: Fri, 8 Jul 2005 23:10:30 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> I can't support (2) in its current form, but could live with a
> modified version of (2) that I'll call (2a):
>
> (2) "Private-use subtags require private agreement between parties
>     intending to use them. Use great caution if employing them in
>     content or protocols intended for general use. Private-use subtags
>     MUST conform to the format contraints specified in the ABNF.
>     Private-use subtags are useless for information exchange without
>     prior arrangement."

Stop right there.  That one is great; let's go with it.  (Well, OK,
let's spell "constraint" correctly and then go with it.)

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Jul 2005 23:34:31 -0700

r&d afrac <rd at afrac dot org> wrote:

> So, when challenged they say the DNS is odious, the dont want to
address
> Java, they dont really respond to LDAP, they ignore OPES, they say
that
> CRCs are inflammatory, etc.

Several fine examples of misrepresenting the words and intents of
others.  Addison wrote on 2005-01-04 on ietf-languages:

> Asking the IESG to abandon the Last Call because you don't like the
> draft or because you don't care for our responses to you is, frankly,
> odious. Let the process play out.

r&d continued:

> As a brainware person, I think you were right in a way, but as an
> English mother tongue person, you do not relate your culture as other
> people often do to your language (you probably see the American
> culture as more attached to the nation, the flag, the history, the
> literature). There are all the variations on Earth: as a French
> speaking person, I relate my culture to the capabilities of my
> language and my nation and history are more examples of the capacity
> of the language than the other way around. Great authors did not build
> French, they are natural by-products of the common people language and
> effort. There is no Shakespeare in French: there are millions of
> co-speakers. This certainly influenced our values. Franck could tell,
> but I suppose German is similar? Try to understand the African culture
> if you do not understand the coexistance of language, family, economy,
> poetry, in a quasi geographical continuity. What are going to mean
> there "sn, co, iv, bn, etc.???".

A person who knows not a single word of Shona and knows nothing of the
culture of the Shona-speaking people can still work to develop a tagging
mechanism by which Shona text can be indicated by use of the string
"sn".

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 9 Jul 2005 00:09:43 -0700

Hi Doug -

The technical content of your message pertains to issue #881, the
request to remove registrant information from the registry.  This
was rejected long ago; there's no need to belabor the point.  Let's
wrap up the open issues instead.  If you feel compelled to address
an issue already closed, please include the issue number in the subject.
That helps me sort through things more quickly, which will help bring
us all to last call sooner.

Randy

----- Original Message ----- 
> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Friday, July 08, 2005 11:34 PM
> Subject: [Ltru] Re: status? last call?
>

---

From: r&d afrac <[email-masked]>
Date: Sat, 09 Jul 2005 15:54:33 +0200

I am sorry I have to go to the Luxembourg meeting where I will not have 
email access, my battery just having failed me. I just see from that 
collection of mails that the IETF process has advantages but also meets its 
problems. This is certainly not easy to address. This may be why it is 
better at maintaining/reducing than at developping (cf. Harald Alvestrand, 
RFC 3774, etc.)

The two quotes below I think denote that kind of difficulty.

> > odious. Let the process play out.

The Last Call process is precisely to permit to ask IESG to abandon a 
document in documenting why.

> > Try to understand the African culture

This, I believe, describes perfectly why the Draft doctrine adds to the 
basic error of RFC 3066 attenuated by its lose application (that IETF has 
the capacity to correlate non protocol parameters). Jon Postel had clearly 
established it: this is none of the IANA business. Not only it seems that 
cultural empowerment is ignored by the author of this text. But, since the 
topic here is ISO 3166, it shows a remakable confusion between Senegal and 
Zimbabwe which precisely document my point and the difficulty to establish 
general rules in a world made of particulars.

Please, let save time. Let not wait for another negative last call and 
start from a clean sheet analysis of the Charter at the light of the world 
and Internet reality. Call this a non-starter, I call this a new-starter. 
Let understand where and why RFC 3066 may be wrong. How to correct it - 
probably in a totally different way from the current Draft. Let build the 
Global Lingual Codification Framework the Internet community needs. Then 
use the Draft relevant parts to support the XML, HTML, CLDR needs for those 
wanting to stay compatible with the old RFC 3066 approach.

jfc

PS. I do not see much success with call for a consensus. Too bad.

---

From: Martin Duerst <[email-masked]>
Date: Sun, 10 Jul 2005 17:30:04 +0900

[chair hat off]

I don't see why RFC 1766, RFC 3066, and RFC 3066 would ignore cultural 
empowerment.
After all, these specs allow for people (anybody with an email account!) to apply
for a registration. This is much more flexible than ISO process (which 
fortunately
has become somewhat more flexible recently).

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Mon, 11 Jul 2005 10:14:21 +0900

empowerment.
fortunately
 >has become somewhat more flexible recently).

Sorry, a small correction. In the first line of my paragraph, it should read
"RFC 1766, RFC3066, and RFC 3066bis".

Regards,   Martin.