Subject: FYI: BOF on Internationalized Email Addresses (IEA)

From: Patrik Fältström <[email-masked]>
Date: Sun, 26 Oct 2003 20:55:08 +0100

At the IETF in Minneapolis, there will be a BOF on Internationalized 
Email Addresses (IEA).

It is *preliminary* on the agenda on Monday, November 10, 2003 at 
1530-1730.

Chairs:  Pete Resnick, Patrik Fältström
Mailing list:[email-masked] (other salient lists include [email-masked])
Agenda:

Agenda Bashing (Chairs)                5 min.
Topic Introduction (Chairs)           10 min.
Proposals
   IDNA-Based (Paul Hoffman)           15 min.
   Infrastructure-Based (John Klensin) 15 min.
   IRI-Based (Michel Suignard)         15 min.

Discussion                            60 min.

Topics for discussion:

   Are there other solutions which have been specified?

   The solutions present the problem at different scopes;

      Where should the IETF tackle it?

      Are some short-term, and other long-term?

      Can the solutions be staged or co-exist?

      If staged, how to migrate from one to another?

   What are the next steps for the IETF?

NB:  This BoF is exploratory in nature, and it is not intended that the 
IETF will finalize a decision in this venue.  It was proposed to foster 
a community discussion, not charter a working group or pick a winner. 
If further work is required, step one would be identifying individuals 
willing to carry that work forward.

Reading material:
   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

Pete and myself hope people will come with a lot of constructive 
comments and ideas.

         Patrik, co-chair of the bof

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2003 07:41:11 -0800

Patrik,

Thanks for putting this BOF together.

PF>       Where should the IETF tackle it?

I am not sure I understand this question.  Please clarify.

PF>    What are the next steps for the IETF?

Would it help to have a draft charter for the meeting?  (I realize that the
presence of such different specifications makes a charter at least a bit
challenging, but it seems to help to have a draft, to make things concrete.)

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Oct 2003 10:52:22 -0500

> Would it help to have a draft charter for the meeting?  

let's back up a step further.

what problem are we trying to solve here?

Keith

---

From: Pete Resnick <[email-masked]>
Date: Mon, 27 Oct 2003 10:37:21 -0600

On 10/27/03 at 10:52 AM -0500, Keith Moore wrote:

>>DC: Would it help to have a draft charter for the meeting?

As was mentioned in the draft agenda at 
<http://www.ietf.org/ietf/03nov/iea.txt>, we want to simply start the 
discussion, not immediately attempt to charter a working group.

>what problem are we trying to solve here?

Please have a look at draft-hoffman-imaa, 
draft-klensin-emailaddr-i18n, and draft-duerst-iri. Certainly the 
first two have very explicit descriptions of the problem.

pr
-- 
Pete Resnick <http://wwww.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 27 Oct 2003 12:00:01 -0500

> what problem are we trying to solve here?

to me, that (problem we are trying to solve) would be part of the
introduction in the charter...

so I guess some initial proposal for:
- what are we trying to solve
- what would be the way to solve it

would be a good starting point together with the "state-of-the-art"
presentations.

Marc.

> Keith

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Oct 2003 13:44:03 -0500

Mark,

Thanks for taking a stab at a problem statement.  I'd like to drill down
on this just a bit.

What is the source of the "growing need"?  Is it:

a. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to remember
b. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to transcribe or type
c. users want to use their names in email addresses
d. users are confused by apparently arbitrary restrictions on use of 
   characters in email addresses, and this leads to mistakes
e. on computer systems employing non-ASCII names for other purposes (e.g.
   login or account names) these do not map well to ASCII email addresses

or something else that I don't see?

> As presently constituted, email addresses are limited to the 26 Latin
> alphabetics, 10 digits, and a limited number of special characters in
> the ASCII character set.  There is a growing need to use additional
> characters, specifically Latin characters with diacriticals and
> non-Latin characters, in email addresses to better serve the needs of
> the multi-national Internet community.  However, the restrictions of
> ASCII email addresses have served as a "lingua franca" since everybody
> can enter ASCII email addresses, and there is an ongoing need for this
> as well.  The problem to be solved is the resolution of these two
> needs.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 27 Oct 2003 09:13:29 -0800 (PST)

> what problem are we trying to solve here?

I agree with Keith.  This isn't to say that I dispute that there is a
problem to be solved -- indeed, I think that the problem is apparent to
all -- but we must have a problem statement that we all agree upon before
we even think about solutions.

I don't think that references to drafts of proposed solutions suffice as a
problem statement.  Leaving aside questions of possible bias (= present a
problem in such a way that this is the obvious best solution), having the
problem statement in a draft (which by its nature is an ephemeral
document) muddies the issues.

The problem statement should consist of a single paragraph (and preferably
in one or two sentences), separate from any proposed solution, and stated
in a charter which is approved by everyone.

Here's a start at such a statement:

As presently constituted, email addresses are limited to the 26 Latin
alphabetics, 10 digits, and a limited number of special characters in the
ASCII character set.  There is a growing need to use additional
characters, specifically Latin characters with diacriticals and non-Latin
characters, in email addresses to better serve the needs of the
multi-national Internet community.  However, the restrictions of ASCII
email addresses have served as a "lingua franca" since everybody can enter
ASCII email addresses, and there is an ongoing need for this as well.  The
problem to be solved is the resolution of these two needs.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: [email-masked] (WJCarpenter)
Date: Mon, 27 Oct 2003 09:30:46 -0800

mc> As presently constituted, email addresses are limited to the 26
mc> Latin alphabetics, 10 digits, and a limited number of special
mc> characters in the ASCII character set.  There is a growing need to

upper and lower case alphabetics
-- 
[email-masked] (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

---

From: Dave Aronson <[email-masked]>
Date: Mon, 27 Oct 2003 14:43:09 -0500

> upper and lower case alphabetics

Yes, but with either of those two sets (generally) considered equivalent 
to the other, boiling down to effectively 26 choices.

-- 
Dave Aronson, Senior Software Engineer, Secure Software Inc.
Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org
Web: http://destined.to/program http://listen.to/davearonson

---

From: James Seng <[email-masked]>
Date: Mon, 27 Oct 2003 19:07:09 +0800

I seen John and Paul proposal but I have not seen Michel. Is there a 
draft that I can read up?

ps: I wont be able to join the meeting but I am interested in the subject.

-James Seng

Patrik Fältström wrote:

> a community discussion, not charter a working group or pick a winner. If 
> further work is required, step one would be identifying individuals

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 27 Oct 2003 20:08:25 -0500

- good start!
- timeline seems pretty agressive... will see.
- would probably good to have a requirement document upfront. Might not the
same way that idn requirement ends up, but a narrow-implementable
requirement would help to have a concensus (hopefully) on what needs to be
done. 
- while the idn req went not that good, now that we have experience, I
think we should try to be better and have one.

I know I might start some debate with this, but still think it is the best
way to go...

- would be useful to have some reference to idn (idna) in the charter, as
background work. the developers and users will have to take care of "both"
(ie. idn and imail) in the email infrastructure.

Marc.

-- Monday, October 27, 2003 16:19:25 -0800 Dave Crocker <[email-masked]>
wrote/a ecrit:

> Folks,
> 
> On the theory that discussions go better when they have a concrete
> deliverable, here is a proposed charter for a proposed working group.
> 
> The following started with Mark Crispin's text, although it might not
> look it. Besides the usual goals for a charter, the following text
> attempts to specify the problem domain in the narrowest feasible form
> that is valid. If anyone thinks the scope is too narrow, they need to
> explain why.
> 
> 
> 
> DRAFT CHARTER
> 
> Mail Internationalised Local-Part (MILP)
> ---------------------------------
> 
> The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821
> mail addresses are restricted to a subset of ASCII. This poses a
> fundamental barrier for users needing mail addresses to be expressed in a
> richer set of characters, such as Latin characters with diacriticals and
> the many Asian characters. The goal of the current work is to add
> local-part support for these additional characters, while preserving the
> large, installed base of ASCII usage.
> 
> The group will take:
> 
> as input to discussions.
> The group will pay particular attention to barriers to adoption and
> utility, as well as any impact the new scheme might have on the existing
> base of Internet mail usage.
> 
> 
> Milestones
> ----------
> 
> Nov, 03:  BOF
> 
> Dec, 03:  WG chartered
> 
> Feb, 03:  Initial draft of working group specifications.
> 
> Jun, 03:  Specifications submitted for IETF approval
> 
> 
> d/
> --

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2003 18:42:26 -0800

Roy,

 >> Mail Internationalised Local-Part (MILP)

RB> Even though, given IDNA now exists as a proposed standard, the main
RB> issues relate to the local part, the issue under discussion is that of
RB> internationalized mail addresses, not just internationalized
RB> local-parts.

Really?  What work needs to be done, except for local part?  IDNA takes care
of the right-hand side.

So what is there to do about "internationalized mail addresses" other than the
local part?

RB> Restricting the disucssion to local-parts runs the risk of excluding
RB> other potentially relevent issues.  For instance, one of the issues
RB> that has been discussed on the IMAA list is whether full-width at
RB> should be recognized in an internationalized mail address.

full-width _where_?  somewhere other than local part?

if yes, then how can that be practical?  if no, then the charter does not
preclude their use.  (if you think otherwise, please explain.)

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2003 16:19:25 -0800

Folks,

The following started with Mark Crispin's text, although it might not look it.
Besides the usual goals for a charter, the following text attempts to specify
the problem domain in the narrowest feasible form that is valid. If anyone
thinks the scope is too narrow, they need to explain why.

DRAFT CHARTER

The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821 mail
addresses are restricted to a subset of ASCII. This poses a fundamental
barrier for users needing mail addresses to be expressed in a richer set of
characters, such as Latin characters with diacriticals and the many Asian
characters. The goal of the current work is to add local-part support for
these additional characters, while preserving the large, installed base of
ASCII usage.

The group will take:

as input to discussions.

The group will pay particular attention to barriers to adoption and utility,
as well as any impact the new scheme might have on the existing base of
Internet mail usage.

Milestones
----------

Nov, 03:  BOF

Dec, 03:  WG chartered

d/

---

From: Pete Resnick <[email-masked]>
Date: Tue, 28 Oct 2003 01:20:58 -0600

>Really?  What work needs to be done, except for local part?  IDNA takes care

Please review John Klensin's draft before making these kinds of assumptions.

>RB> other potentially relevent issues.

I agree. Limiting discussion at this point to local-part does not 
take into account some of the possibilities.

pr

---

From: Zefram <[email-masked]>
Date: Tue, 28 Oct 2003 09:31:15 +0000

Dave Crocker wrote:
>                                               This poses a fundamental
>characters,

I have yet to see this "need" established.  Everyone who has supported
internationalised mail addresses has axiomatically assumed such a need,
and has conspicuously failed to provide any more detail, such as any of
Keith Moore's suggestions.

I think the first task in this area should be to investigate the nature
and degree of desire for non-ASCII local parts.  This desire needs to
be weighed against the benefits we derive from writing all local parts
in a small, fixed alphabet (ASCII printables).

-zefram

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Oct 2003 01:13:50 -0800

Pete,

>>RB> other potentially relevent issues.
PR> I agree. Limiting discussion at this point to local-part does not
PR> take into account some of the possibilities.

That was exactly the intent of the text.

We have already seen how nicely the text served to bring into pretty stark
relief one bit of expectation from one of the proposals. It is only fitting to
have it serve the same purpose for another one.

IETF BOF time is pretty lousy for an open-ended chat.  Having specifications
to chat about is only marginally better than not having them.

What makes the real difference is having serious focus to the meeting. If we
go into this meeting without even having a clear sense of the scope of the
problem to be tackled, then the chance of having a productive meeting is
pretty small.

At the moment, it appears that the focus of the meeting is likely to be:
Shall we break existing Internet mail or shall we lay an enhancement on top of
it that preserves the installed base.  (I'm sure that everyone else who was
present at the pre-MIME/ESMTP discussions is really looking forward to
repeating the experience.)

d/

---

From: Roy Badami <[email-masked]>
Date: Tue, 28 Oct 2003 00:50:53 +0000

> Mail Internationalised Local-Part (MILP)

Even though, given IDNA now exists as a proposed standard, the main
issues relate to the local part, the issue under discussion is that of
internationalized mail addresses, not just internationalized
local-parts.

Restricting the disucssion to local-parts runs the risk of excluding
other potentially relevent issues.  For instance, one of the issues
that has been discussed on the IMAA list is whether full-width at
should be recognized in an internationalized mail address.  IMHO, the
charter shouldn't be framed in a way that is sufficiently narrow as to
render such questions out of scope.

	-roy

---

From: Mark Crispin <[email-masked]>
Date: Mon, 27 Oct 2003 11:10:55 -0800 (PST)

On Mon, 27 Oct 2003, Keith Moore wrote:
> [snip]

I agree that this needs to be stated, but someone other than me will have
to do it.

I believe that the primary push for this functionality comes from regions
which use Latin alphabetics with diacriticals; and that most individuals
in regions which do not use Latin script are accept the use of Latin
script for multinational interchange.  In many regions where Latin
diacriticals are used, there is no acceptable transform of a surname to a
form that does not use diacriticals.  Simply omitting the diacritical
causes (at least to the inhabitants of those regions) a misspelling.

This set of beliefs naturally biases how I approach the problem.  The
problem statement must be free of bias, including mine.

-- Mark --

---

From: Zefram <[email-masked]>
Date: Tue, 28 Oct 2003 15:13:06 +0000

Mark Crispin wrote:
>                                       In many regions where Latin

Ah, this one's easy.  Local parts aren't limited to Latin letters,
they can use all the ASCII printables.  Diacriticals are available
there, albeit in characters that are shared with other uses.
<[email-masked]> is a perfectly valid email address already.
It doesn't start to get tricky until we get into the eastern European
languages -- ASCII only intentionally provides western European
diacriticals.

Cue the debate about whether the diacritic should go before or after
the base letter.

-zefram

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Oct 2003 18:03:15 -0500

Dave,

(distro trimmed to IMAA and IETF lists; I hope we can soon get
rid of the latter too).

One large problem with the charter draft (I'm too tired to know
if there are small ones)...

If one is going to consider internationalization of email
addresses in a way that permits them to move through the mail
protocol in some traditional Unicode encoding  (e.g., UTF-8),
then I believe that we at least need to entertain the notion
that what we are going after is "mailbox", rather than "local
part".  Yes, the hard work lies in the local part.  But, to me,
the goal is to have an I18N presentation form that is also
carried over the protocol.   

That implies that one should be able to have
      local-part-i18n@FQDN-i18n
(UTF-8 on both sides or, if you prefer, throughout the string
(since the coding of "@" in UTF-8 is the same as it is in ASCII) 

rather than, e.g.,
      local-part-i18n@FQDN-IDNA
(UTF-8 on the LHS, but punycode for any domain labels that use
non-ASCII).

Again, the goal is that this should be natural for the user,
using the user's script (or the script of the recipient), both
in protocol transactions and in the case of "My email address is
xx@yy." in the body of a message... where the only parts of that
sentence (appropriately translated) which are a ASCII characters
are the @-sign and _maybe_ the TLD (whether the TLD can be
non-ASCII is presumably an ICANN problem unless the user
interface does something akin to draft-klensin-idn-tld-01.txt). 

If the email address the user sees _looks_ like local script in
the local part, but is forced into ASCII/punycode in the domain
part, I think the users will assume that we have been smoking
something.  And, arguably, they will be right --punycode is a
way of transporting internationalized data so it doesn't foul up
other systems or cause DNS damage.  But, from the user
standpoint, however much users hate, e.g., a string representing
a name transliterated into Roman characters, they will hate
looking at punycode-- which has no mnemonic value at all for
non-Roman scripts-- even more.

So please don't prejudge the question of what happens to the
domain part (right hand side) of an email address in the
charter: this set of issues should at lease be considered very
carefully.

      john

--On Monday, October 27, 2003 16:19 -0800 Dave Crocker
<[email-masked]> wrote:

> Folks,
> 
> On the theory that discussions go better when they have a
> concrete deliverable, here is a proposed charter for a
> proposed working group.
> 
> The following started with Mark Crispin's text, although it
> might not look it. Besides the usual goals for a charter, the
> following text attempts to specify the problem domain in the
> narrowest feasible form that is valid. If anyone thinks the
> scope is too narrow, they need to explain why.
> 
> 
> 
> DRAFT CHARTER
> 
> The <local-part> portion of RFC2822 and <Local-part> portion
> of RFC2821 mail addresses are restricted to a subset of ASCII.
> This poses a fundamental barrier for users needing mail
> addresses to be expressed in a richer set of characters, such
> as Latin characters with diacriticals and the many Asian
> characters. The goal of the current work is to add local-part
> support for these additional characters, while preserving the
> The group will pay particular attention to barriers to
> adoption and utility, as well as any impact the new scheme
> might have on the existing base of Internet mail usage.
> 
> 
> Milestones
> ----------
> 
> Nov, 03:  BOF
> 
> Dec, 03:  WG chartered
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Oct 2003 18:16:46 -0800

John,

JCK> If one is going to consider internationalization of email
JCK> addresses in a way that permits them to move through the mail
JCK> protocol in some traditional Unicode encoding  (e.g., UTF-8),
JCK> then

...then we get to repeat the mime/esmtp debates all over again.  After all,
why should we even try to learn anything from 10 years of experience.  (And
no, John, I'm not directing my comment at you.)

To be specific: I am not suggesting that pure utf-8 is a bad goal -- although
the fact that utf-8 is, itself, a condensed representation of unicode should
strike folks as a just a tad ironic, with respect to these discussions.

Rather, I suggest that it be a _separate_ goal from near-term support of an
edge-only enhancement for Unicode support, the same as we did for mime and
IDN.

We already have that support for domain names. That only leaves local-part.

It's fine to pursue a separate path for long-term 8-bit purity.  I'm sure we
will achieve it much sooner for addresses than we have for content.

JCK> Again, the goal is that this should be natural for the user,
JCK> using the user's script (or the script of the recipient), both
JCK> in protocol transactions and in the case of "My email address is
JCK> xx@yy."

The business card representation of an email address is the classic example of
IETF work that very much _does_ directly involve the user interface.  However
we already dealt with this issue for non-ascii domain names.  We do not need
to rehash this issue yet again.

As for the protocol, I could have sworn that users do not type protocol data
units directly, or at least that they haven't for roughly 25 years.  (Another
jibe, citing the fact that utf-8 is, itself, a modification to "raw" unicode
is probably worth repeating, here.)

JCK> in the body of a message... where the only parts of that
JCK> sentence (appropriately translated) which are a ASCII characters
JCK> are the @-sign and _maybe_ the TLD (whether the TLD can be
JCK> non-ASCII is presumably an ICANN problem unless the user
JCK> interface does something akin to draft-klensin-idn-tld-01.txt).

Indeed, representation of non-ascii addressing information within a text
segment is an interesting problem.  I'd guess it's identical to the business
card requirement.

And the current issue is no different than we have for IDN.

So perhaps the right thing to do is forget about IDN.  Pretend it never
happen.  Let's start all over.

Or, perhaps we could complete the design approach started by IDN, while
_separately_ pursuing the purist approach of end-to-end 8-bit.

JCK> So please don't prejudge the question of what happens to the
JCK> domain part (right hand side) of an email address in the
JCK> charter: this set of issues should at lease be considered very
JCK> carefully.

Indeed it should, including tidbits like adoption barriers, and the last
several years of IDN work.

d/

---

From: [email-masked]
Date: Wed, 29 Oct 2003 02:51:55 -0500

> languages -- ASCII only intentionally provides western European

"Macrons and carons and cedillas, oh my..." :)

Actually, ASCII doesn't intentionally provide any diacriticals. Western
European diacriticals are in the Unicode Latin-1 Supplement, and (as you
correctly note) some of us of the eastern European persuasion need characters
from Latin-A and/or Latin-B to actually do things...
  
> Cue the debate about whether the diacritic should go before or after

So tell me, does the dot on an 'i' go before or after the base letter?

(OK, so I'm just touchy because nobody on this side of the big puddle
wants to deal with the fact that the 3rd letter of the preferred spelling of
my last name is Unicode codepoint 0113 (Latin small e with macron)).

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Oct 2003 07:11:30 -0800

Mark,

>>   (Another
MD> When Unicode is expressed as a series of bytes, there are a number of equally
MD> valid sncoding schemes (aka serializations). UTF-8 is one of those schemes, and
MD> is no more or less a "modification", and no more or less "Unicode" than any
MD> other of these schemes.

That's right.  It is an "encoding".  Raw Unicode takes more than 8-bits.  Lots
more.  UTF-8 is a method of encoding those raw bits into a non-raw form.

So is the ACE approach.

My point was that folks tend to talk about UTF-8 as if it were the raw
representation, rather than a derivative encoding.  In fact, UTF-8 is exactly
parallel to the ACE approach.

It might be a more efficient encoding, but it is no more "native" or "direct"
or "raw" than ACE.

d/

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Wed, 29 Oct 2003 16:50:39 +0100

On 10:31 28/10/03, Zefram said:
>and degree of desire for non-ASCII local parts.  This desire needs to be 
>weighed against the benefits we derive from writing all local parts in a 
>small, fixed alphabet (ASCII printables).

May I ask which part of the world you come from?

This being said only Americans want/are satisfied with "internationalized" 
(sic) names (the artificial extension of the American character set with 
most of the American foreign scripting, within an ascii frame). No one 
really wants multilingual names (a totally internationalized (sic) frame 
supporting languages and therefore some language oriented rules - at least 
ni management and user support). The users need vernacular support, that is 
to be able to freely do in the mail what they use to do elsewhere.

I note that for non-American writers "international names" means names that 
everyone from every nation will understand. It happens to be the ascii 
character set limited to the DNS used names (they were selected for that 
reason).
jfc

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Oct 2003 09:14:04 -0800

John,

JC> That's only true if you take the position that there are no native/direct/raw
JC> encodings of Unicode.

Oh?  You mean that Unicode does not fit directly -- ie, with no special
encoding rules -- into 32 bits, or 24 bits, or somesuch.

You mean that Unicode does not need special rules to stuff it into 8 bits, and
another set of rules to stuff it into 16 bits?

Because if the answer is that yes it does -- and the answer _is_ yes it does
-- then my point stands.

That's the difference between native representation, versus "encoding".

d/

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 29 Oct 2003 07:02:22 -0800

> is probably worth repeating, here.)

While it doesn't really have a bearing on the rest of your message, this is a
common misperception that I'd like to take a moment to correct.

When Unicode is expressed as a series of bytes, there are a number of equally
valid sncoding schemes (aka serializations). UTF-8 is one of those schemes, and
is no more or less a "modification", and no more or less "Unicode" than any
other of these schemes. Different encoding schemes may be better for different
domains, but the conversion between any of those schemes is fast and lossless.
See http://www.unicode.org/versions/Unicode4.0.0/ch02.pdf, Sections 2.4-2.6.

(When Unicode started out 15 years ago, the architecture was different; but it
has long been structured this way.)

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

---

From: John Cowan <[email-masked]>
Date: Wed, 29 Oct 2003 11:27:39 -0500

[snip]

> It might be a more efficient encoding, but it is no more "native" or "direct"

That's only true if you take the position that there are no native/direct/raw
encodings of Unicode.

-- 
In politics, obedience and support      John Cowan <[email-masked]>
are the same thing.  --Hannah Arendt    http://www.ccil.org/~cowan

---

From: John Cowan <[email-masked]>
Date: Wed, 29 Oct 2003 14:01:33 -0500

> encoding rules -- into 32 bits, or 24 bits, or somesuch.

Nope.  The Unicode character set maps characters to integers.  How the
integers are mapped to bytes is defined by the encoding rules, of which
there are seven standard ones:  UTF-8, UTF-16, UTF-16BE, UTF-16LE,
UTF-32, UTF-32BE, UTF-32LE.  All have equal status.

> That's the difference between native representation, versus "encoding".

There is no native representation in the sense you mean.  All
representations are equal.

-- 
De plichten van een docent zijn divers,         John Cowan
die van het gehoor ook.                         [email-masked]
      --Edsger Dijkstra                         http://www.ccil.org/~cowan