Subject: [Ltru] RFC 2277 - considerations

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 08 May 2005 03:58:53 +0200

This is not a position. Just a thinking and a call for comments.

----

RFC 2277 says: "This document uses the term "charset" to mean a set of 
rules for mapping from a sequence of octets to a sequence of characters, 
such as the combination of a coded character set and a character encoding 
scheme; this is also what is used as an identifier in MIME "charset=" 
parameters, and registered in the IANA charset registry [REG].  (Note that 
this is NOT a term used by other standards bodies, such as ISO).".

The point is that if the term is not used elsewhere, it may mean that the 
concept is adapted to the network dynamic environment and others are less 
or not. It charset=encording_scheme+character_set.

I first considered that W3C was right in having identified its need of 
"scripts" support, however the idea of making them dependent from languages 
seemed to be strange.

But the more I think of them,  the more I have difficulty understanding 
what the "script" notion, introduced in the Draft, brings in addition to 
the charsets: it belongs to it. The more I see sources of conflicts if this 
is not respected. The more I see that the script is one of the rules which 
shares in the definition of the charcter set, and the more I fail to see 
where the W3C has a problem (except may be in confusing charset with 
encording scheme only, however http://www.w3.org/TR/REC-html40/charset.html 
starts with a clear "character set" part where it specifically quote Latin 
and Cyrilic)).

I come back to a normal process of access to a page/document.

1. to be able to read it I need to know the charset. This is the first 
information. It tells me the rules for mapping from a sequence of bytes to 
a sequence of characters (character encoding scheme: ex. UTF-8 and 
combination of coded characters, ex: ISO 15924). Ex: UTF-8-Latin

2. then when I read I need to understand. I have the language. And possible 
region. As per RFC 3066 existing scheme and not calling for a modification 
of the existing libraries.

3. the interest is that this is compatible with IDN tables (and permits to 
address the high level IDN homograph problem, since charsets are documented 
everywhere). I also note that RFC 2277 and 3066 seem to address the locales 
need (however CLDR may have some proprietary special needs, authors have 
not documented?)

I therefore tend to think the "script" information is to be located in the 
charset tag. I suppose they are able to understand UTF-8.latin as UTF-8 and 
that legacy is transparent?

Comments?
jfc

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

---

From: Martin Duerst <[email-masked]>
Date: Sun, 08 May 2005 16:01:16 +0900

The term 'charset' got to where it is because when the MIME spec was created,
the people creating it were thinking in terms of 7-bit and 8-bit encodings,
and in addition just (most probably inconciously) shortened "coded character
set" to "character set". So the term is there mostly by accident.

It wasn't W3C which identified the need for scripts support. Some
people that you associate with W3C may have been involved, but
that doesn't mean that it was W3C.

The need for scripts in language tags (or separate) is an old issue.
I remember a discussion with Michael Everson, who proposed an HTTP
header Accept-Script (or some such) years ago on the ietf-languages
list. The discussion at that time came to the conclusion that this
(having script orthogonal to language) might be a nice idea in principle,
but that in practice, the connection is extremely strong, and in most
cases, script info isn't necessary because it can easily be implied.

what the "script" notion, introduced in the Draft, brings in addition to 
the charsets: it belongs to it.

There is some connection, in that many "charset"s only encode one script,
or to be more precise, one script + basic ASCII + some symbols.
But there are some important "charset"s (in particular UTF-8 and
UTF-16,...) where this doesn't apply. Also, there are many other
encodings that contain multiple scripts (e.g. you can write
Greek with iso-2022-jp, and so on).

 >The more I see sources of conflicts if this is not respected.

If you see such conflicts, could you give an actual example?

 >The more I see that the script is one of the rules which shares in the 
definition of the charcter set, and the more I fail to see where the W3C 
has a problem (except may be in confusing charset with encording scheme 
only, however http://www.w3.org/TR/REC-html40/charset.html starts with a 
clear "character set" part where it specifically quote Latin and Cyrilic)).
information. It tells me the rules for mapping from a sequence of bytes to 
a sequence of characters (character encoding scheme: ex. UTF-8

Yes indeed. Having the correct 'charset' is extremely important.

 >and combination of coded characters, ex: ISO 15924). Ex: UTF-8-Latin

No. If you know it's UTF-8, you can just look inside the document, and
check what script(s!) are used.

 >2. then when I read I need to understand. I have the language. And 
possible region. As per RFC 3066 existing scheme and not calling for a 
modification of the existing libraries.
 >
 >3. the interest is that this is compatible with IDN tables (and permits 
to address the high level IDN homograph problem, since charsets are 
documented everywhere). I also note that RFC 2277 and 3066 seem to address 
the locales need (however CLDR may have some proprietary special needs, 
authors have not documented?)
 >
 >I therefore tend to think the "script" information is to be located in 
the charset tag.

The Web, email, and a lot of other things have worked extremely well without
script information in charset tags, and I don't see why this would not
continue.

 >I suppose they are able to understand UTF-8.latin as UTF-8 and that 
legacy is transparent?

Definitely not. For language tags, quite a few applications understand
subtag-based prefixes, as the specs have been defined with subtags in mind
from the start. For charsets, they do not. Charsets do not have and
never had subtags.

Regards,    Martin.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 09 May 2005 12:05:03 +0200

Dear Martin,
what is confusing with IETF vs. other standardisation organisations is that 
they deal with networks (what means complexity and changes) and do not 
produce structured updated documents. So, the only way to deal with its 
deliverables is to consider them as the center of their own world, with 
their own logic and to confront their various expressions. Not to dwell on 
outside considerations, internal arfceology being enough.

For thee good reasons:
- this network centric approach has done well for the last 30 years and 
produced a consistent system even if sometimes complex.
- the user approach is user-centric. The user has his machine and his ADSL 
plug, and looks in the manual expecting the authors have resolved all the 
issues/confusion/conflicts.
- this is most probably the secret for scalability.

Le reveiw this. There is a concept named "charset", with five 
understandings plus one comment (may be more ??)
:
1. yours: "The term 'charset' got to where it is because when the MIME 
specifications was created, the people creating it were thinking in terms 
of 7-bit and 8-bit encodings, and in addition just (most probably 
unconsciously) shortened "coded character set" to "character set". So the 
term is there mostly by accident."

- unconscious for a particular encoding scheme.

2. one which seems to be the one of the W3C, Unicode, ISO members of this 
WG. I suppose that Misha will not oppose to my quote of him 
http://czyborra.com/charsets/iso8859.html#ISO-8859-3 . This quote is 
independent to this debate, is dated 1998 and covers IMHO the whole issue 
(charset/ISO 10646).

"The ISO 8859 charsets are not even remotely as complete as the truly great 
Unicode but they have been around and usable for quite a while (first 
registered Internet charsets for use with MIME) and have already offered a 
major improvement over the plain 7bit US-ASCII. Unicode (ISO 10646) will 
make this whole chaos of mutually incompatible charsets superfluous because 
it unifies a superset of all established charsets and is out to cover all 
the world's languages. But I still haven't seen any software to display all 
of Unicode on my Unix screen. We're working on it. "

- limited lists of characters, an improvement over US ASCII, but smaller 
than ISO 19646.

3. RFC 2879 says: The term "charset" (referred to as a "character set" in 
previous versions of this document) is used here to refer to a method of 
converting a sequence of octets into a sequence of characters.  This 
conversion may also optionally produce additional control information such 
as directionality indicators. 
http://www.iana.org/assignments/character-sets (last updated on January 
28th, 2005)

- N. Freed (Jon Postel) is consciously defining it as a generally encoding 
system and implicitly acknowledge the multiplicity of lists in defining a 
IANA registry for them.

4. RFC 2277 which says: "This document uses the term "charset" to mean a 
set of rules for mapping from a sequence of octets to a sequence of 
characters, such as the combination of a coded character set and a 
character encoding scheme; this is also what is used as an identifier in 
MIME "charset=" parameters, and registered in the IANA charset registry 
[REG].  (Note that this is NOT a term used by other standards bodies, such 
as ISO).".

- Harald Alvestrand gives a very clear comprehensive definition: "a set of 
rules" which permits to build any of them, with examples: your first 
example (MIME) and the IANA registry.

5. The IANA definition: "These are the official names for character sets 
that may be used in the Internet and may be referred to in Internet 
documentation.  These names are expressed in ANSI_X3.4-1968 which is 
commonly called US-ASCII or simply ASCII.  The character set most commonly 
use in the Internet and used especially in protocol standards is US-ASCII, 
this is strongly encouraged.  The use of the name US-ASCII is also 
encouraged.// The character set names may be up to 40 characters taken from 
the printable characters of US-ASCII.  However, no distinction is made 
between use of upper and lower case letters."

- follows a list of 250 charsets.

Comment is by RFC 2130 (a Californian Workshop with Harald, Crispin, +) : 
"The term 'language tag' should be reserved for the short identifier of RFC 
1766 [RFC-1766] that only serves to identify the language. While there may 
be other text attributes intimately associated with the language of the 
document, such as desired font or text direction, these should be specified 
with other identifiers rather than overloading the language tag." It then 
confirms the duality of:
"3.4.2:  Default Coded Character Set: The default Coded Character Set is 
the repertoire of ISO-10646.
"3.4.3:   Default Character Encoding Scheme: "For text-oriented protocols, 
new protocols should use UTF-8, and protocols that have a backwards 
compatibility requirement should use the default of the existing protocol, 
e.g. US-ASCII for mail, and ISO-8859-1 for HTTP"

Further to this I understand the global picture as follows.

1. there are several partial complementary understandings of the term 
"charset". Harald's is the most comprehensive and interesting one. It does 
not conflict with any of them and enrich them. I stick to it.

2. there are two approaches:
- one is by ISO 10646 which is to get a global charset.
- one is by the IANA registry which is the specialised charset.

3. there is a problem which is three consistency between these two 
approaches which is a flexible partition between these two approaches. I 
think Harald's definition permits to address this: a global charset results 
from the application of an encoding rule on every characters (ISO 10646) 
and a specialised charset results from the application of additional rules.

4. new charsets can be registered through an RFC or through a regstration 
procedure.
     - I see no reason why ISO 15924 as well as many other standard 
character sets could not be registered as UTF-8-15924_CODES/NRs and permit 
a complete support of the language.
     - I agree with Harald Alvestrand, M. Crispin, etc. in not overloading 
the langtag with information which does not really belong here. Actually I 
do not seen the reason why layout information would be included there.

I comment your other remarks in the text:

On 09:01 08/05/2005, Martin Duerst said:
> "scripts" support, however the idea of making them dependent from 
> languages seemed to be strange.
>

Addison documented the problem he wants to solve as an XML problem and the 
non discussed charter only quote HTML, XML and CLDR. I see no other 
documented need. I only see objections from other applications which are 
responded as "not our concern". I also see a pressure by Unicode for 
reasons I do not understand since they do not want to document CLDR needs.

>The need for scripts in language tags (or separate) is an old issue.

Yes. I first had to address it in 1982 for French Videotex, Katakana, etc. 
This does not make it a good point. It was ruled out by RFC 2130.

>list.

His privilege. I understand it since he is the Unicode proponent for ISO 
15924. This WG Charter proposed to use ISO 15924, but I do not think it is 
to be used in the langtag (this calls to replace RFC 227 and 2130, to 
discuss several other RFC for compatibility etc.). This should be discussed 
on [email-masked].

>The discussion at that time came to the conclusion that this

There is an obvious confusion between charset and script here (at least if 
you consider that "script" is attached to a language as you seem to imply 
it, ISO 15924 does it, and this WG's debate lead to think others do).

There may be many different charsets to support a language. In French only 
I can quote obvious ones:
- legal
- non-accented upper cases
- upper cases only
- AFNIC

>or to be more precise, one script + basic ASCII + some symbols. But there 
>are some important "charset"s (in particular UTF-8 and UTF-16,...) where 
>this doesn't apply. Also, there are many other encodings that contain 
>multiple scripts (e.g. you can write Greek with iso-2022-jp, and so on).

We may discuss that at length... the important is that you acknowledge 
"there is some connection" while langage and scripts are "orthogonal", this 
can only lead to conflicts ...

>If you see such conflicts, could you give an actual example?

Latin-1 does not fully support French. There is a conflict between charset: 
8859-1 and langtag: fr-Latn-FR.

> information. It tells me the rules for mapping from a sequence of bytes 
> to a sequence of characters (character encoding scheme: ex. UTF-8
>

Orthogonal to the discussion. You can do that with any RFC 3066 langtag. 
This is what is supposed to be corrected by the Draft.

> documented everywhere). I also note that RFC 2277 and 3066 seem to 
> address the locales need (however CLDR may have some proprietary special 
> needs, authors have not documented?)
> >

True. This is why the question is "what is the script information"? A real 
novelty, or an additional rule to better tune existing parameters. And 
which parameter. If a novelty, why to not to discuss the langtag (however 
opposed by RFC 2031). If an additional rule to refine an existing info, 
better to put it with that info, rather then in an orthogonal container.

>from the start. For charsets, they do not. Charsets do not have and

OK. Then it is UTF-8-Latn and 100 charset registrations, either through 
[email-masked] or through an appendix to RFC 2277 bis.

jfc

---

From: [email-masked]
Date: Mon, 09 May 2005 07:23:16 -0700 (PDT)

> set" to "character set". So the term is there mostly by accident.

I'm sorry, but this simply isn't true. The term "charset" was carefuly and
intentionlly chosen, as was the way the term is defined. The terms "coded
character set" and "character encoding scheme" were just as intentionally
rejected for use in MIME. And none of this has anything to do with 7bit versus
8bit encoding issues.

I won't bother getting into the hows and whys of this choice since it is in no
way relevant to the present discussion on this list, but I did want to point
out that this position, although often stated, is incorrect.

> ...

> Greek with iso-2022-jp, and so on).

And since the trend is (hopefully) towards using all-inclusive charsets like
utf-8, the ability to determine script from the charset label alone, which as
you say never worked all that well, is going to disappear over time. OTOH, as
things coalesce around Unicode (irrespective of encoding), the need to know
lots of charsets in order to dig script information out of the actual content
is going to decrease.

> script information in charset tags, and I don't see why this would not

Absolutely. Charsets were carefully defined to provide the information 
necessary to display or process a given object. It is very intentionally NOT
defined to be a label describing the specific content of a particular document.

> from the start.

And those which do not at least ignore subtags are therefore broken.

 For charsets, they do not. Charsets do not have and
> never had subtags.

Absolutely. And moreover, the rules for what constitutes a "charset" are
intentionally pretty narrow, so as to prevent creep of stuff into charset-space
that properly belongs elsewhere. (Sadly, there was a period during which the
rules weren't being properly applied to the charset registration process, so
there is some amount of cruft in the registry.)

				Ned

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 10 May 2005 00:53:22 +0200

Dear Ned,
I thank you to confirm the definition of the charset, as including two 
information:
- coded character set: with the repertoire ISO 10646 as a default
- character encoding scheme: with UTF-8 as a default.
is a stable and well accepted matter.

This means that one can build from here.

At 16:23 09/05/2005, [email-masked] wrote:
>utf-8,

Yeap. Using a default all-inclusive charsets permits define easily 
specialised charsets. Scripts.txt (if correct?) documents the ISO 15924 
based charsets.

>the ability to determine script from the charset label alone, which as

Let not confuse standardisation with uniformisation. The strength of ISO 
10646 is to permit an unlimited number of charsets without problem. ISO 
15924 gives the names of 102 of them. But there are much more.

>necessary to display or process a given object. It is very intentionally 
>NOT defined to be a label describing the specific content of a particular 
>document.

Correct. Languages and contents are orthogonal to layout.  We have a good 
example with IDN Tables and the anti-phishing lists discussed on the IDN 
list. They define charsets. The [email-masked] list and RFC 
3066 bis, refuse to discuss IDNs however the DNS is affected by  the Draft.

This is because scripts do not belong to RFC 3066 but to RFC 2277.

>And those which do not at least ignore subtags are therefore broken.

We will then have to use registered charsets UTF-8-XXX. It calls for a list 
of registered charsets. But subtags will be necessary anyway for 3rd level 
IDNs, to filter out the code points used for phishing. They will be used by 
some applications.

>that properly belongs elsewhere.

Right. This is what is good: this is clean. No confusion as trying to 
locate the information in the langtag.

>(Sadly, there was a period during which the rules weren't being properly 
>applied to the charset registration process, so there is some amount of 
>cruft in the registry.)

The Unicode scripts may not fully match ISO 15924, I quote Mark Davis 
(http://www.unicode.org/reports/tr24/tr24-7.html) : "In some cases the 
match between these script values and the ISO 15924 codes is not precise, 
because the goals are somewhat different. ISO 15924 is aimed primarily at 
the bibliographic identification of scripts; consequently it occasionally 
identifies varieties of scripts that may be useful for book cataloging, but 
which are not considered distinct scripts in the Unicode Standard. For 
example, ISO 15924 has separate script codes for the Fraktur and Gaelic 
varieties of the Latin script. Where there are no corresponding ISO 15924 
codes, the private use ones starting with Q are used."

However, Mark continues "Such values are likely to change in the future. In 
such a case, the Q-names will be retained as aliases in the [PropValue] for 
backwards compatibility.".

So, we may expect that at the end of the day, Unicode script.txt will 
exactly define the ISO 15924 described UTF-8 charsets ("partitions" of the 
UCS in Unicode wording).

I therefore have some difficulty to understand why we should discuss non 
content oriented scripts info within content oriented langtags (while they 
could not support the content oriented referent/style info?) while users 
are fully able to understand, chose and document the 102 charsets (i.e. a 
102x102 multilingual matrix):

UTF-8-ARAB
UTF-8-ARMN
UTF-8-BALI
UTF-8-BATK
UTF-8-BENG
UTF-8-BLIS
UTF-8-BOPO
UTF-8-BRAH
UTF-8-BRAI
UTF-8-BUGI
UTF-8-BUHD
UTF-8-CANS
UTF-8-CHAM
UTF-8-CHER
UTF-8-CIRT
UTF-8-COPT
UTF-8-CPRT
UTF-8-CYRL
UTF-8-CYRS
UTF-8-DEVA
UTF-8-DSRT
UTF-8-EGYD
UTF-8-EGYH
UTF-8-EGYP
UTF-8-ETHI
UTF-8-GEOK
UTF-8-GEOR
UTF-8-GLAG
UTF-8-GOTH
UTF-8-GREK
UTF-8-GUJR
UTF-8-GURU
UTF-8-HANG
UTF-8-HANI
UTF-8-HANO
UTF-8-HANS
UTF-8-HANT
UTF-8-HEBR
UTF-8-HIRA
UTF-8-HMNG
UTF-8-HRKT
UTF-8-HUNG
UTF-8-INDS
UTF-8-ITAL
UTF-8-JAVA
UTF-8-KALI
UTF-8-KANA
UTF-8-KHAR
UTF-8-KHMR
UTF-8-KNDA
UTF-8-LAOO
UTF-8-LATF
UTF-8-LATG
UTF-8-LATN
UTF-8-LEPC
UTF-8-LIMB
UTF-8-LINA
UTF-8-LINB
UTF-8-MAND
UTF-8-MAYA
UTF-8-MERO
UTF-8-MLYN
UTF-8-MONG
UTF-8-MYMR
UTF-8-NKOO
UTF-8-OGAM
UTF-8-ORKH
UTF-8-ORYA
UTF-8-OSMA
UTF-8-PERM
UTF-8-PHAG
UTF-8-PHNX
UTF-8-PLRD
UTF-8-QAAA
UTF-8-QABX
UTF-8-RORO
UTF-8-RUNR
UTF-8-SARA
UTF-8-SHAW
UTF-8-SINH
UTF-8-SYLO
UTF-8-SYRC
UTF-8-SYRE
UTF-8-SYRJ
UTF-8-SYRN
UTF-8-TAGB
UTF-8-TALE
UTF-8-TALU
UTF-8-TAML
UTF-8-TELU
UTF-8-TENG
UTF-8-TFNG
UTF-8-TGLG
UTF-8-THAA
UTF-8-THAI
UTF-8-TIBT
UTF-8-UGAR
UTF-8-VAII
UTF-8-VISP
UTF-8-XPEO
UTF-8-XSUX
UTF-8-YIII

which have no problem of default, implied, etc. ?

jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 13 May 2005 16:40:32 -0700

Hi -

> From: "JFC (Jefsey) Morfin" <[email-masked]>
> To: <[email-masked]>; "Martin Duerst" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Monday, May 09, 2005 3:53 PM
> Subject: Re: [Ltru] RFC 2277 - considerations
...
...

Our charter clearly directs us to address the question of script identification
in our update to 3066.

Randy

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 10 May 2005 03:27:46 +0200

>Our charter clearly directs us to address the question of script 

Hi! Randy,
Glad you noted that, since the review of the Charter has not been carried yet!

The Charter says:
"- For extensibility, it is expected that the document will describe how 
generative mechanisms could use ISO 15924 and UN M.49 codes without 
explicit registration of all combinations. The current registry contains 
pairs like uz-Cyrl/uz-Latn and sr-Cyrl/sr-Latn, but RFC 3066 contains no 
general mechanism or guidance for how scripts should be incorporated into 
language tags; this replacement document is expected to provide such a 
mechanism."

1. "extensibility" is a W3C key requirement, where IETF uses more usually 
"scalability". From what the authors have documented  (their initial Draft 
being the Bible of this WG) they are interested in a single need (other 
concerns [DNS, Java, OPES, LDAP, etc.] being out of scope) which is a 
problem of the W3C about XML Addison fully documented. This problem was 
presented as resulting from the langtag libraries limitations. There may be 
tens of existing or future applications. IETF being mainly interested in 
network architecture, I did not pay a special attention, trusting Addison; 
and trusting Mark when he said CLDR has no problem (but never addressed my 
questions). My interest is in a multilingual framework, which can be 
adapted to particular needs, as per the Charter.

2. I now see that that quoted particular problem is not related to the 
langtags librairies, but to the limitations of the charsets librairies. And 
that the idea is to use the langtag to carry a payload which does not 
belong to it, as specified by a previous RFC.

This does not change much in terms of architectural framework, since the 
langtag can be used as a data base for everything missing elsewhere. But it 
changes the way we are to study and address the Charter request. This is an 
RFC 2130 violation and an absurd request. Full stop. But it is necessary to 
address if to an absurd need.

This must be made clear to all, if to reach a consensus, and why it is not 
possible to do in the normal way. Otherwise no one will ever understand 
why, when the charset, the language, the region, the referent and the style 
are at least necessary to document the linguistic aspects of a document 
(together with a reference to the date of generation to know the used 
ersion of the standard), you want to have two possibly different or even 
conflicting charsets defined and no referent and no style.

Very interesting.
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 13 May 2005 19:05:46 -0700

Hi -

Could you *please* identify the *specific* text in the draft
you would like to add / remove / replace?

The IESG reviewed our charter before approving it.  You even
commented on the proposed charter while the IESG was reviewing
it, so if anything was unclear, you certainly had opportunity to make
your view heard at that time.

This working group's job is to produce two documents, as
spelled out in the charter.  You are the only participant who seems
to have any difficulty understanding the charter.  No one else on
this mailing list has expressed any confusion as to what our
deliverables are.  Given the depth and breadth of expertise
of the participants, I'm willing to take their lack of confusion as
a sign that we know what we need to do.

Randy

> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Cc: <[email-masked]>; "Martin Duerst" <[email-masked]>
> Sent: Monday, May 09, 2005 6:27 PM

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 10 May 2005 16:02:51 +0200

Dear Randy,
it is always a pleasure to repeat the same thing to you. So I will do it again.

At 04:05 14/05/2005, Randy Presuhn wrote:
>Given the depth and breadth of expertise of the participants, I'm willing 
>to take their lack of confusion as a sign that we know what we need to do.

Never thought a WG was a resume contest, but I suppose I have no problem 
with that.

Now, it would be surprising that people who came for a purpose (which will 
never be globally consensual, two negative Last Calls), would be confused 
on what they want to achieve. Those who disagreed but me gave up.

>Could you *please* identify the *specific* text in the draft you would 
>like to add / remove / replace?

I thought it was clear to you, since end of December.

Remove: the whole draft.

Add: the XML oriented parts of the Draft in the second document where they 
belong, together with a consistent documentation of its filters and working 
tools (you oddily have no problem to add them to langtag libraries but you 
cannot add them to charset libraries?), a good explanation of the charset 
violation needs, a clear assessment/commitment of the resources required 
from IANA

Replace: make BCP 47 an Internet technology (RFC 1591, 1958, 2277, 2301, 
3066, etc., etc.) consistent framework for the support of language context 
identification as one of the Multilingual Internet building blocks, 
together with others works such: within IETF (OPES, IDN, LDAP, PPP, SNMP, 
etc.), outside (for the time being) the IETF (those I know of: classes, 
groups, externets, CRC, ISO 639-X, UNITAG). And let document a consistent 
IANA external tables and values management consistent or aggregating the 
current registries.

>The IESG reviewed our charter before approving it.

IESG will also review the deliverables of this WG before accepting them for 
a Last Call and then after the Last Call. And during an appeal if they 
approved it. So would IAB after that if they confirmed.

What is the interest to have something which pleases a small score of 
supporters and is defeated by lack of global consensus? If the problem is a 
IANA registry conflict please tell us. If the problem is to ascertain the 
Unicode table vs. ISO 10646 please tell us. If the problem is to make ISO 
15924 the center of the world please tell us. If the problem are W3C 
analysis difficulties please tell us. If the problem is rooted in the CLDR 
structures please tell us.

Your problem is neither to produce a Draft, nor to shut my mouth. Your 
target is to address a problem. Either it is the one written in the Charter 
and IMHO its is partly erroneously worded the way you seem to read it. Or 
it is another one, and I doubt you can solve it if you do not spell it. If 
it is part of both, let sort it out first.

>You even commented on the proposed charter while the IESG was reviewing 
>it, so if anything was unclear, you certainly had opportunity to make your 
>view heard at that time.

I commented positively on your proposition to have a WG. This is what I 
asked for early January. I had proposed the creation of a WG-TAGs because 
this is what I am working on in a much broader scope. I was not opposed on 
a WG on language and I detailed my conditions a minima. These conditions 
are not spelled out in the Charter, but since the Charter has been 
submitted/reviewed to/by the IESG it is mostly consistent with the whole 
Internet architecture (all the more that it MUST be read in its perspective).

>This working group's job is to produce two documents, as spelled out in 
>the charter.  You are the only participant who seems to have any 
>difficulty understanding the charter.

May be I am the only one with a very low IQ? Did you forget one thing, I am 
also the only one who does not to speak English. That alone should be an 
alarm for you when addressing a multilingual issue. I am also the only one 
in various areas of importance to this topic (a ccTLD registry, the founder 
of the oldest user/operator structure, a former @large panelist, an active 
contributor to the WSIS process where multilingualism is a priority, etc.).

I only think there is a qui pro quo you should have resolved first. You 
proposed a text with a W3C/Unicode culture, it was read by the IESG with an 
Internet culture. I read it with another more global network culture. All 
this makes the Internet, but one has to accept to have a limited 
methodology. This starts with reviewing what all the participants have read 
and accept in your text, not  to end with it when everyone is gone.

You said there were thorny points in the charter. There are. I am not sure 
you saw them all. I just waited for the list to be calm enough to rise the 
charset issue.

Please understand, as I mentioned it in my response to the Chairs and ADs, 
I am as everyone else entitled to a Charter review by the WG to make sure I 
am not wrong, before producing my own Draft. Having a fragmented review of 
the Charter while most of the people disappointed with the Draft are gone, 
only delays the whole process and does not help. Neither me, nor the 
current Draft.

>No one else on this mailing list has expressed any confusion as to what 
>our deliverables are.

This is precisely the problem. On such a matter, there should have been 
much more. This only means they are not here.

Language tags, the way authors see them, are a deep change in the Internet 
architecture. This has lead to the opposition met during the first two last 
calls. This WG should have started in assessing that change. Its reasons, 
its implications. debreifing the opposition, not just jumping at an 11th 
and 12th version of the same proposition with the same text.

- They want a change which affects/opposes a consistent corpus RFC.
- I see one of the seeds of the response to an urgent market and political 
demand not addressed until now.

Both have to be discussed. Better here than on the general list during the 
third Last Call, all the more if it is opposed by a short Draft of mine.

You just start listing some of the points of my last month review (delay is 
not on my side) on the management system you chose. Thank you: this will 
save me the time of listing during the Last Calls all the points I rose 
which have not been discussed - what would have been poor (I am not sure 
however you will list them all?). Now they have to be addressed. But not 
all them are listed and most are listed in a way no one can understand what 
it refers to without accessing the whole review each time and to figure out 
where it is. I gave each point a "#" number (there are 55 of them). Why not 
just to paste them into your system before commenting them? Also, in the 
follow-up, why to assume people agree with you (and not me) because they 
did not comment?

Think that my draft would use the Charter framework and quotes the 
concerned RFCs, documenting how to support the XML, DNS, IDNA, OPES, LDAP, 
PPP, etc. etc. needs (even the non documented ones of CLDR) in the scalable 
way the Internet has always supported them with success up to 
now.  Discussing the reducing ways others may have proposed over time which 
have been opposed with that success. Scalable, simple, robust, stable, 
secure will be the keywords. I could also propose a F2F meeting before the 
Paris meeting. I would propose people from the MINC, UNESCO, WSIS, 
Francophonie, etc. to attend.

I accept there will be lacks in such a document of mine as I lack inputs 
from the WG debate on the charter, and I have not the time, the expertise 
and the interest to became a specialist of all the IETF oddities it should 
aggregate and consolidate, such as the RFC of Ira McDonnald, and all the 
times the internationalisation of the ASCII Internet is considered in RFCs. 
IMHO what you miss is that what you made at stake is the transition from 
internationalisation to multilingualisation (actually to vernacularisation) 
- user to user relations, over brain to brain, over end to end. I accept 
this is beyond what this WG is able to discuss, but this This is _your_ 
decision in wanting to replace BCP 47.

I frankly prefer focusing on the Multilingual Global Network (MGN) - as it 
should progressively result from our current work, the WSIS, the dialog 
between ITU, WSIS and the operators efforts (currently engaged). Let be 
candid: if this WG does not produce a Draft along that lines, the Draft (or 
eventually an RFC) and the IANA registry will only be a problem to forget. 
Is that what you really want?

Here is what I propose for a serious review of the topic:

1. what I had not time to do it yet: a dump of the whole IETF corpus and a 
grep on "international" and "lingual" to know which RFC can be affected and 
which experience has been gathered in there. There are more than you 
thought in preparing the Charter.

2. to seriously review the problems, starting with those quoted by the 
charter. What they really mean. What are the architectural implications 
they may have in an MGN framework. They are not perfect, but they will lead 
to most of them.

3. what architectural responses they may call for and what this implies on 
the structures of the contents' containers.

4. _IF_ there are architectural changes (I doubt there are much, as the MGN 
IMHO concerns higher layers than the end to end architecture) what are 
they? IMHO they concerns mainly the way to use IPv6, OPES and the DNS due 
to current implication of the DNS in the architecture of usage and hyperlinks.

5. what is the stable, simple, robust framework the IETF technology should 
provide to the applications designers.

6. to seriously review the way this can be made supported by IANA and CRCs. 
And let implement test applications.

7. let discuss how to address the evolutions/trasnsitions possibly implied 
at a network level.

This makes the first document.

Then a second document should use that stable foundations to write the 
specific solution called by the documentation of the charset in the W3C 
containers and the stabilisation of the XML langtag, its filtering, sorting 
etc. Another document could be proposed by Unicode (if free of IPRs) to 
document the CLDR approach, propositions and specific own usage (if any) of 
this framework.

I accept that the expertise of this WG is more oriented towards the second 
document and I am more interested in the first one. There are two possible 
responses to that:

1. either to follow my proposition above and make the general list aware of 
what we plan to discuss. I bet there will be new comers with depth and 
breadth of expertise in the concerned areas (even if IETF, IAB and IESG is 
not much aware/motivated in the lingual areas).

2. or to follow the recommendations received on the general list during the 
Last Call. Let us stop pretending changing BCP 47: let consolidate RFC 3066 
as it is today, with its relations to RFC 2277 and 2301, and publish a 
specific solution for XML. I do not think anyone will oppose this. Only 
some people will find it odd if you document IETF values violation they may 
want the IETF/W3C liaison committee to approve. This is the RFC 3066 
bis/ter option. The real work will be carried afterward. And your problem 
will be quickly fixed. This is what I proposed the day we started the WG 
and to work with the Authors on that. We could be done for a long. Actually 
the WG was even not necessary.

I fully understand this is does not make things simple for you. But you 
decided that the most complex issue Internet is to face since its 
inception, and delayed for 20 years, was something simple. It is not.
All the best.
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 14 May 2005 10:55:27 -0700

Hi -

Rather than addressing the numerous points and assertions
individually, I'd like to get a hum from the working group:

Should we adopt the general course of action outlined below by
Jefsey?  I'm not looking for point-by-point responses at this time,
just a succinct "yes, let's adopt the general approach Jefsey
proposed," "no, let's not go down that path," or  "I'd like to hear
more discussion of his proposal before deciding."

Randy, ltru co-chair

> Sent: Tuesday, May 10, 2005 7:02 AM

---

From: John Cowan <[email-masked]>
Date: Tue, 10 May 2005 14:04:25 -0400

> more discussion of his proposal before deciding."

Let's not go down that path.

-- 
What has four pairs of pants, lives             John Cowan
in Philadelphia, and it never rains             http://www.reutershealth.com
but it pours?                                   [email-masked]
        --Rufus T. Firefly                      http://www.ccil.org/~cowan

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 10 May 2005 11:16:00 -0700

> Jefsey?

Absolutely not.

‎Mark

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: "LTRU Working Group" <[email-masked]>
Sent: Saturday, May 14, 2005 10:55
Subject: Re: [Ltru] RFC 2277 - considerations

> > >it, so if anything was unclear, you certainly had opportunity to make
your

---

From: [email-masked]
Date: Tue, 10 May 2005 11:26:44 -0700 (PDT)

> is a stable and well accepted matter.

Your previous message quoted the definition of a charset. This isn't it.

> This means that one can build from here.

If by "build" you mean add script tags, the answer is no, you cannot.

> IDNs, to filter out the code points used for phishing. They will be used by

This is both unnecessary and unacceptable. It also far exceeds the charter of
this group and is therefore inapppropriate even as a topic of discussion here.

And since this list is noisy enough while dealing with relevant matters, this
will be my final posting on this topic.

				Ned

---

From: [email-masked]
Date: Tue, 10 May 2005 11:34:11 -0700 (PDT)

> Absolutely not.

In case it wasn't obvious from my earlier response, I also reject
this proposal.

				Ned

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 10 May 2005 22:10:04 +0200

>If by "build" you mean add script tags, the answer is no, you cannot.

Dear Fred,
I do not know you, so I can only try to guess what you mean by "no, you 
cannot".

- if you mean you technically cannot: the response is obviously yes I can, 
I did, I tested and it works well thank you.
- if you mean "I will not register them in the IANA", this is sad, I cannot 
do anything about it, except to forget about IANA in that part of generic 
CRCs development.
- if you mean that I miss some elements to do so. You are right (I 
documented that). But the advantages are so interesting that it is worth at 
this stage to go ahead. And I welcome every help.
- if you mean XML will not understand it. I agree, but it will not 
understand either (libraries) what the Draft or what the Draft after the 
Draft will chose to implement. We will do for XML what the XML people say, 
but for our applications we will do what is consistent with the Internet 
technology.

No worry here.

>This is both unnecessary and unacceptable.

I am interested in why this would be unnecessary because this is what we 
are supposed to address. Letting know the receiving party what the content 
layout is.

Also to know what you mean by unacceptable: is that technical or because 
you would so decide?

>It also far exceeds the charter of this group and is therefore 
>inapppropriate even as a topic of discussion here.

I fully documented that it does not exceed (and even then?) the charter of 
this group which has to document why it wants to document what I (many 
will) consider to be a charset violation.

>And since this list is noisy enough while dealing with relevant matters, 
>this will be my final posting on this topic.

OK. No problem. But you obviously realise that all the issues which will 
have not been sorted out within this WG, will have to be addressed during 
the general Last Call. I have  no problem with that: I just want the final 
result not to create me more problem.

There are many people and applications around more happy with RFC 
2277/2301/3066 as they are (how imperfect they may be) than in seing them 
challenged and confused.

jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 10 May 2005 23:13:02 +0200

>more discussion of his proposal before deciding."

Dear Randy,
I am not sure which of the three courses of action I list you allude to. 
Let me quote them so the ones who said they "oppose" may not look a fool of 
opposing again what they support:

1. to follow the charter, understanding what it means and studying 
seriously what it calls for, what will probably get more people involved 
for a better legitimacy of a resulting clean sheet draft, reviewing all the 
impacted RFCs.
2. to follow the Last Call advise: to fix the XML problem without wanting 
to fix the Internet (replacing BCP 47) against RFC 2301.
3. to continue as per today and to address, during the general Last Call, 
all what has not been sorted out within the WG. (you have currently entered 
only a very few of the 55 points of my Draft-11.txt review).

Obviously, if some oppose the three of them and have another one, I am more 
that interested.

I suppose the current mood being what it is, 3 will be favored, the last 
call will fail again on the grounds of 2, what will lead 1 to be the end 
result, next year or outside the IETF. This will be good for the Internet, 
but will represent a certain waste of efforts and time for all of 
us.  Obviously I will not complain to get a good result addressing the real 
world's needs, but could not some common sense and humility help us doing 
better and faster.

After all, this approach will have delayed the odd XML solution the W3C 
wants by two years (counting the last 2 failed Last Calls). What is too bad 
if they really want it (I do not use XML much) because 2 would have made an 
RFC of it by now.
jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 11 May 2005 15:01:32 +0200

Randy,
I do not know if you are testing Marks date validation system, but you are 
creating a problem: when the reference date is in the futur, what should we do?
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 11 May 2005 12:15:37 -0700

Hi -

> Sent: Wednesday, May 11, 2005 6:01 AM
> Subject: date problem
>

> creating a problem: when the reference date is in the futur, what should we do?

???

What text in the i-d concerns you?

Randy

---

From: Erkki Kolehmainen <[email-masked]>
Date: Thu, 12 May 2005 11:31:32 +0300

"no, let's not go down that path"

Sincerely, Erkki I. Kolehmainen