Subject: Re: [EAI] silly states and header label

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 22 Mar 2006 10:12:46 -0000

On Mon, 20 Mar 2006 07:15:41 -0000, Chris Newman <[email-masked]>
wrote:

> If we must use a labeling mechanism, I suggest using a zero-width
> non-joiner UTF-8 character at the beginning of the message.  UTF-8 aware
> SMTP servers are required to insert Received and Return-Path after the
> zero-width non-joiner character.  That has some other nice features --
> it permits instant detection of the encoding for certain out-of-band
> mechanisms (e.g. UTF-8 editors), it has no impact on display, and if the
> message gets to a non-8-bit system the failure is likely to be immediate
> and more obvious rather than later and more obscure (indeed it's so
> obvious that legacy systems can be patched to check for it easily).  I'm
> still not sure those benefits outweigh the cost of silly states, but
> it's closer to making the cut.

Please! Can we establish a basic principle that any feature in a message
that can cause some "technical effect" MUST be visible and understandable
by a human reader (I grant that the feature may be written in UTF-8, but
it must still exhibit a readable text to a human equipped with means to
display that UTF-8).

So no "zero-width non-joiner UTF-8 characters" in critical parts of the
protocol.

But it goes further than that. I think everyone agrees that the present
ASCII local-part is far too permissive - essentially it seems to allow any
combination of ASCII characacters that could not be interpreted as
anything else according to RFC (2)822. Hence people devise all sorts of
obscure ways of encoding secret information in them, and hence the rule
that only the agent at the very end is allowed to interpret what is inside
them.

If that was a mistake (too late to fix now), then let us not make the same
mistake again. It is entirely within our remit to determine what is to be
allowed/forbidden within "UTF-8-extended-local-parts", and the first rule
there should be "WYSIWYG". That means no invisible characters in there,
and no possibility to assign different meanings to different Unicode
characters that may be rendered as the same. IOW, the local-parts should
be normalized in the Unicode sense at least to level NFC, and maybe to
NFKC. Or, equivalently, by using 'stringprep' or some other '*prep'.

Only when that basic decision has been made can we begin to consider
whether an ATOMIC parameter is needed as well. And we can't really answer
that until we have some plausible examples of what hacks end-user-agents
might actually want  to perform.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Mar 2006 10:46:55 -0600

> it must still exhibit a readable text to a human equipped with means to
No, I think establishing this as a basic principle would be inappropriate.

For instance, there are many contexts in which the difference between LF 
and CR/LF is not visible to humans; neither is the difference between 
unnormalized and normalized Unicode text - yet both are going to be 
important features of IMA messages.

                  Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Mar 2006 10:48:49 -0600

Administrativia: If people change the subject, PLEASE change the subject 
line!

And if you have multiple issues to raise, PLEASE create more than one 
thread!

> that only the agent at the very end is allowed to interpret what is 
I have detected no such consensus.

---

From: Chris Newman <[email-masked]>
Date: Thu, 23 Mar 2006 14:21:14 -0600

It would be a good idea to exclude obs-local-part and obs-domain syntax when 
defining the ABNF for UTF-8-addr-spec in a message header given we have IETF 
consensus to deprecate that syntax.  But I'd oppose more extensive deprecation 
of syntax as it would distract from more important issues.

                - Chris

Harald Alvestrand wrote on 3/23/06 10:48 -0600:

> Administrativia: If people change the subject, PLEASE change the subject line!
>
> And if you have multiple issues to raise, PLEASE create more than one thread!
>

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Mar 2006 18:57:35 -0000

> important features of IMA messages.

I grant you that you can mostly ingnore the difference between CRLf and a  
naked LF (which is not supposed to happen on the wire anyway), but the  
matter of unnormalized Unicode text is a good illustration of my point.

If some unnormalized text appears in a header, and normalizing that text  
would lead to a different outcome somewhere in the protocol, then that  
would be a Bad Thing. So it hardly matters if some unnormlized text  
appears in a Subject header (though I would regard it as bad practice),  
but unnormalized text in a local-part could make quite a difference.  
Recall that the IDNA people took greate care to ensure (through the use of  
nameprep) that only the normalized form of a domain name was to be  
meaningful. We should learn from that when designing the local-part.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 24 Mar 2006 08:00:20 -0600

Charles Lindsey wrote:
>> For instance, there are many contexts in which the difference between 
>> LF and CR/LF is not visible to humans; neither is the difference 
>> between unnormalized and normalized Unicode text - yet both are going 
>> to be important features of IMA messages.
>
> I grant you that you can mostly ingnore the difference between CRLf 
> and a naked LF (which is not supposed to happen on the wire anyway), 
> but the matter of unnormalized Unicode text is a good illustration of 
> my point.
I thought it was a refutation of your point. But no matter; we seem to 
agree that being precise about the requirements on normalization of 
Unicode text is important.
>
> If some unnormalized text appears in a header, and normalizing that 
> text would lead to a different outcome somewhere in the protocol, then 
> that would be a Bad Thing. So it hardly matters if some unnormlized 
> text appears in a Subject header (though I would regard it as bad 
> practice), but unnormalized text in a local-part could make quite a 
> difference. Recall that the IDNA people took greate care to ensure 
> (through the use of nameprep) that only the normalized form of a 
> domain name was to be meaningful. We should learn from that when 
> designing the local-part.
>
> --Charles H. Lindsey ---------At Home, doing my own thing------------------------ 
>

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Mar 2006 14:28:31 -0500

--On Friday, 24 March, 2006 08:00 -0600 Harald Alvestrand
<[email-masked]> wrote:

>>>> it must still exhibit a readable text to a human equipped
>>>> with means to display that UTF-8).
>>> For instance, there are many contexts in which the
>>> difference between  LF and CR/LF is not visible to humans;
>>> neither is the difference  between unnormalized and
>>> normalized Unicode text - yet both are going  to be
>> I grant you that you can mostly ingnore the difference
>> between CRLf  and a naked LF (which is not supposed to happen
>> on the wire anyway),  but the matter of unnormalized Unicode
>> text is a good illustration of  my point.
> I thought it was a refutation of your point. But no matter; we
> seem to agree that being precise about the requirements on
> normalization of Unicode text is important.

Ok so far.  As Harald and some others who were in Dallas know,
but Charles probably does not yet, a discussion in the
applications area meeting on Monday has resulted in my starting
work on a "net-UTF8" specification to supplement the traditional
"net-ASCII" one.  My preference, partially for the reasons
below, is to have any discussions we need to have about
normalization in that context, then to incorporate those rules
in the mail spec.  If we end up with more mail-specific (or
mail, news, and one or two other things-specific) rules we will,
I think, regret it.

If others agree, let's look together at the Net-UTF8 draft and
see if it meets our needs.  If it doesn't, we can revisit this
theme again.  I hope to have a first draft Net-UTF8 I-D up
toward the end of this coming week but, since I need to travel
to New Zealand for ICANN, no promises... it could be sometime
the week after.

>> If some unnormalized text appears in a header, and
>> normalizing that  text would lead to a different outcome
>> somewhere in the protocol, then  that would be a Bad Thing.
>> So it hardly matters if some unnormlized  text appears in a
>> Subject header (though I would regard it as bad  practice),

Well, let's be careful here.  If the "no one looks at the
address other than the receiving system", it is safe to have the
local-part text be the local-part text.   Problems would arise
only if someone started applying normalization rules to text
that wasn't expected to be normalized.  I don't know if we
should prohibit that, or require some sort of normalization
(comments welcome), but it is not obvious that there are
problems with either course of action.

>> Recall that the IDNA people took greate care to
>> ensure  (through the use of nameprep) that only the
>> normalized form of a  domain name was to be meaningful. We
>> should learn from that when  designing the local-part.

There are many things we can learn from that, including learning
from the perception by some people after a couple of years of
experience in some parts of the community that nameprep, in RFC
3491 form, was a mistake.  That particular dissenter community
believes that nameprep should have mapped the upper-case
characters in scripts that have clear "case" into lower-case
ones, should _perhaps_ have mapped pre-composed characters and
composition sequences together, but otherwise should have
avoided doing anything and that, in particular, other character
mappings should have been avoided in favor of simply prohibiting
characters that would be mapped to others.

For us, traditional rules about the local-part avoid the
requirement (or even the desirability) of trying to simulate
case-mapping.   There is no equivalent in local-parts to the
hostname/LDH convention for domain names -- basically, all of
NVT-ASCII is permitted.  The Unicode consortium essentially
claims that, if a character is assigned a code point, it is
different from characters assigned other code points.  

So, there is a case to be made that, if we are to normalize at
all, the only things that need normalizing involve making
sequences of combining characters that should equal each other
or a single precomposed character match.  I'd like advice from
UTC (and others) as to whether that would be wise or worth
doing.  Martin, I'm pretty sure you are following this list...
comments?   Others?

Anyone see any strong justification for doing anything else
along the lines or normalization?    

Rathole warning: if we can avoid stepping very far into this
topic, it would probably be a really good idea.

regards,
   john

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Mar 2006 11:56:20 +0100

> mail, news, and one or two other things-specific) rules we will,

OK, if some general principles and conventions can be established at a  
higher level and we can buy into them, then that is well and good.

We are concerned primarily with email addresses here, and I believe these  
have several concerns that do not apply to other headers that might use  
UTF-8 for assorted purposes. Essentially, any email address scheme needs  
to pas two tests, which I shall call the "telephone test" and the "fax  
test".

Suppose Ålice wants to communicate with Bøb. We will presume they are both  
fluent in whichever Scandinavian language uses those characters, but that  
they are unaware of how Unicode works or of possible pitfalls within it.

Harald can correct me, but I think Ålice (who probably pronounces it as  
"Arlice") is Norwegian and Bøb (who probably pronounces is as "Berb") is  
Danish. They use non-ASCII characters in both their local-parts and domain  
names ([email-masked] and [email-masked]).

The telephone test.

It must be possible for Ålice to tell Bøb her email address over the  
telephone, spelling out the names of the characters if necessary, in such  
a manner that Bøb will be able to send email that will reach her.

The fax test.

It must be possible for Ålice to hand write her email address on a piece  
of paper and fax it to Bøb, in such a manner that Bøb will be able to send  
email that will reach her.

Now those examples were rather simple. But the tests must also succeed  
when the local-part contains routeing information for intepretation by the  
destination host and expressed using the conventions of the target  
language, and they must also work with more complex scripts such as Arabic  
where (AIUI) the same character may be written differently depending on  
its position within a word, and even on whether it forms part of a  
quotation from the Koran.

Consider how present-day email addresses would pass those tests. Domain  
names expressed in ASCII should have no problems at all, and even  
local-parts should work reliably unless they contain quoted-strings with  
NO-WS-CTLs inside them.

Also, internationalized domain names that have passed through nameprep  
should work pretty well, unless they have been deliberately obfuscated by  
using characters of similar appearance taken from different alphabets.

Which leave internationalized local-parts ...

> problems with either course of action.

I suspect that normalization enroute is going to happen whether we like it  
or not - from some unerlying operating system even if not explicitly coded  
into the mail software :-( .

> or a single precomposed character match.

That is essentially normalization level NFC, which is usually good enough  
for text intended for human consumption. For words that are of the nature  
of "identifiers" you usually need NFKC.

>  I'd like advice from

Yes, we really need Martin to guide us through all of this.

---

From: Chris Newman <[email-masked]>
Date: Tue, 28 Mar 2006 11:35:40 -0800

While the tests you describe can not be discounted, there is one much more 
important test: the gateway test.

When a local part passes through an 8-to-7 (or 7-to-8) gateway, I believe any 
transformation to the local-part must be 99.99% reversible and our 
specifications have to make this very clear.  Things in the middle are 
permitted to alter the syntax used to represent the local part (for this 
down-conversion scenario), but are not permitted to alter the contents or 
semantics in any way.  I consider this critical to minimize the risk of 
partitioning the network.

The recipient domain is permitted to perform any normalization on the recipient 
local part that it chooses, just as many sites today choose a case-insensitive 
normalization of US-ASCII local parts.  Recipients who wish to pass the 
telephone and fax test to the degree you describe will choose to perform more 
normalization.  But our specifications do not need to mandate anything in that 
area for interoperability.  The correct normalization to use is probably a 
research problem (and varies by language and community) and in this case it's 
thankfully a problem we need not solve to have a valid specification.

What's different from domains names it that we treated the 7-bit 
down-conversion as the canonical form (and had to due to DNS restrictions). 
Because the e-mail infrastructure is more agile than DNS (because it's higher 
level and more extensible), we can view the 7-bit local-part encoding as merely 
a tunneling mechanism.  And the best tunneling mechanism is one which does not 
damage what it tunnels.

We could recommend normalization at the email-address input system.  But I'd 
say anything beyond a limited Unicode pre-composed canonicalization as simple 
advice is a bad idea.  While some email-address input systems are influenced by 
our standards, many are not (including word processors, text editors, terminal 
windows, etc).  So true interoperability rests with the canonicalization done 
by the recipient system.

                - Chris

Charles Lindsey wrote on 3/27/06 11:56 +0100:

> UTF-8 for assorted purposes. Essentially, any email address scheme needs  to
> pas two tests, which I shall call the "telephone test" and the "fax  test".
>
> telephone, spelling out the names of the characters if necessary, in such  a
> manner that Bøb will be able to send email that will reach her.
>
> The fax test.
>
> It must be possible for Ålice to hand write her email address on a piece  of
> paper and fax it to Bøb, in such a manner that Bøb will be able to send
> Now those examples were rather simple. But the tests must also succeed  when
> the local-part contains routeing information for intepretation by the
> destination host and expressed using the conventions of the target  language,
> and they must also work with more complex scripts such as Arabic  where
> (AIUI) the same character may be written differently depending on  its
> position within a word, and even on whether it forms part of a  quotation
> from the Koran.
>
> for text intended for human consumption. For words that are of the nature  of
> "identifiers" you usually need NFKC.
>
>>  I'd like advice from

---

From: Martin Duerst <[email-masked]>
Date: Wed, 29 Mar 2006 15:28:42 +0900

>language,

I don't see any fundamental difference between routing information
and the rest of the address LHS (is there a specific name for that
rest?). If there is a difference, it may be between names for
people and just plain words from the language. Differences that
are significant in people's names may not be significant in
plain words. As an example, Johann Wolfgang von Goethe is always
written Goethe, not Go"the (with the dots on the 'o', sorry for
the limited German capabilities of my Japanese mailer), but
in most German words, substituting oe for o" doesn't alter
meaning at all.

 >and they must also work with more complex scripts such as Arabic
 >its position within a word,

That's duely handled by Unicode. There are some issues if you want
a Persian user input an Arabic address or vice versa. There are
also some issues regarding orthography, but these may appear in
any language, and we can assume that they

 >and even on whether it forms part of a quotation from the Koran.
 >
 >names expressed in ASCII should have no problems at all,

Sorry, wrong. 0/O or l/I/1 may pass the telephone test, but they
may easily fail the fax test.

 >and even

Yes, and if they do, we would all blame the person who came up with the
idea of using NO-WS-CTLs, rather than the system, wouldn't we.

 >using characters of similar appearance taken from different alphabets.

Well, yes, and I think we wouldn't want to change anything in
internationalized domain names. (Or each of us might want to change
something, but we agree it's not our job as a group.)

 >into the mail software :-( .

My guess is that this will not happen. First, people working on
OSes have rather little interest in I18N. Second, it would create
a mess, because the layers above definitely don't all have the
same requirements. Third, while normalization could be existing
e.g. in a file system for file names (Apple uses, or at least
used, decomposition (mostly NFD) for their file system), I can't
see it for TCP/IP pipes. As long as the recepient's address isn't
in some way included in a file name, it would be weird for
the OS to mess with the data. For the OS, in particular on an
intermediary MTA, mail addresses are just data. Or am I getting
something wrong here?

 >That is essentially normalization level NFC,

Yes. NFC also includes some 'singletons', i.e. it removes
what most people think are simple duplicates of characters.
The easiest example is A-ring and the Angstro"m sign, which
look exactly the same but somehow got coded twice.

 >which is usually good enough

Could be correct, but depends on what exactly you mean by 'need'.
More about that in another mail.

Regards,    Martin.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 29 Mar 2006 10:05:26 -0800

>may easily fail the fax test. 

C and Z are often confused on the telephone when using
American English (especially with non-native speakers, 
something my wife can attest to :-).  2 (zwei)
and 3 (drei) can be confused when speaking German
(so much so that some German speakers will instead say
zwo instead of 2 to avoid the zwei/drei confusion).

Kurt

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Mar 2006 09:32:23 +0200

I think the discussion so far has proved just about conclusively that 
the standards cannot possibly require recipient systems to have email 
addresses that pass either the telephone number test or the fax test.

It may be a recommendation (good practice for those who pick mailbox 
names), but a sending system cannot assume that recipient systems' email 
addresses are different enough to pass those tests.

So I think that for the purposes of the EAI WG, this is irrelevant.

                 Harald

---

From: Martin Duerst <[email-masked]>
Date: Thu, 30 Mar 2006 16:07:14 +0900

At 03:05 06/03/30, Kurt D. Zeilenga wrote:
 >something my wife can attest to :-).

I have problems with J and G, and sometimes with V and Y.

 >2 (zwei)

Yes indeed. In Swiss military service, I was in an artillery-
like unit where we had to shout elevation and direction numbers
over distances. We were drilled from day one to always
use 'zwo' rather than 'zwei'.

Regards,    Martin.

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Mar 2006 10:07:10 -0500

--On Thursday, March 30, 2006 09:32 +0200 Harald Alvestrand 
<[email-masked]> wrote:

> I think the discussion so far has proved just about
> conclusively that the standards cannot possibly require
> recipient systems to have email addresses that pass either the
> telephone number test or the fax test.
>
> It may be a recommendation (good practice for those who pick
> mailbox names), but a sending system cannot assume that
> recipient systems' email addresses are different enough to
> pass those tests.

There is a document that people have talked about writing for 
many years.  It would be called "how to choose email addresses 
for maximum interoperability and minimum confusion" or something 
like that.  There have been versions for other networks, but 
never, as far as I know, for the Internet, although two of the 
rules that would go into it are well known:

	* Don't take advantage of the fact that local-parts are
	case-sensitive; it just causes trouble.
	
	* Don't put anything into an address that requires
	quoting or escaping -- something, somewhere, will trash
	the address beyond recognition.

Perhaps, after this WG completes its work (under some other 
name, I hope) someone can write a fully internationalized 
version of that document.

> So I think that for the purposes of the EAI WG, this is

Yep
     john

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Mar 2006 18:05:03 +0100

> addresses that pass either the telephone number test or the fax test.

Sure we cannot write rules telling people to say "zwo" rather than "zwei",  
but we can avoid the grosser failures of the telephone and fax tests (and  
especially the ones which will still confuse people even if they take the  
greatest care over their pronunciation and handwriting) by requiring some  
reaonable level of normalization of email addresses (and of the local-part  
in particular). John's "Net-utf-8" document may or may not be sufficient  
for the purpose, so I suggest we wait and see what that covers before  
returning to this subject again.

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Mar 2006 22:43:25 -0500

--On Thursday, March 30, 2006 18:05 +0100 Charles Lindsey 
<[email-masked]> wrote:

>> recipient systems to have email   addresses that pass either
>> the telephone number test or the fax test.
>
> Sure we cannot write rules telling people to say "zwo" rather
> than "zwei",  but we can avoid the grosser failures of the
> telephone and fax tests (and  especially the ones which will
> still confuse people even if they take the  greatest care over
> their pronunciation and handwriting) by requiring some
> reaonable level of normalization of email addresses (and of
> the local-part  in particular). John's "Net-utf-8" document
> may or may not be sufficient  for the purpose, so I suggest we
> wait and see what that covers before  returning to this
> subject again.

That document will certainly not be sufficient for what you 
intend, since it will "match" characters only to the extent 
needed to avoid technical problems induced by the nature if 
Unicode (e.g., resolving differences between composed characters 
(ones built up from a base character and one or more combining 
characters) and precomposed characters.

What I think you are asking for gets into the area that the 
Unicode Technical Committee describes as the "identifier" 
problem, i.e., the characters that are appropriate for use in 
identifiers.   They have a somewhat different view of what 
constitutes appropriate criteria for identifiers than you do and 
a debate on those points might be interesting.

But, for email, the principle that we impose as few limits of 
what can be put in a local part should, IMO, still prevail. 
Limiting characters or character sequences that have 
operationally proven to cause problems --such as the 
difficulties  with quoting and control characters-- makes sense. 
Beyond that, as earlier notes have pointed out, it is probably 
better to rely on advice to mail server operators about the 
strings they should permit rather than trying to write rules 
into the protocol.

If one doesn't like the theoretical reason for doing things that 
way, let me suggest a pragmatic one -- making decisions about 
what characters should and should not be permitted is a huge 
rathole.  Worse, the only way to avoid confusion, even within a 
single script, involves banning characters within a script (as 
some examples have pointed out) and we just are not going to get 
away with that.

    john

     john

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 31 Mar 2006 14:26:19 +0100

On Fri, 31 Mar 2006 04:43:25 +0100, John C Klensin <[email-masked]> wrote:

> That document will certainly not be sufficient for what you intend,  
> since it will "match" characters only to the extent needed to avoid  
> technical problems induced by the nature if Unicode (e.g., resolving  
> differences between composed characters (ones built up from a base  
> character and one or more combining characters) and precomposed  
> characters.

That is NFC normalization, and is a good starting point.
>
> What I think you are asking for gets into the area that the Unicode  
> Technical Committee describes as the "identifier" problem, i.e., the  
> characters that are appropriate for use in identifiers.

And that is essentially NFKC normalization which, since it is defined by  
the Unicode people, is easy to incorporate if we so decide. I think  
Nameprep includes at least NFKC for example.

If you want to go beyond that, then you can look at the classifications  
into which Unicode divides things. I would think, at least, that you would  
want to forbid characters that are not visible, and probably also any  
characters that are just new forms of whitespace (because those would all  
fail both the telephone and fax tests). That would probably be far enough.  
I would not want to disallow punctuation or mathematical symbols, not  
upper- or title-case letters (since, with due diligence, thay need not  
fail my two tests).

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 Mar 2006 12:46:15 -0500

--On Friday, March 31, 2006 14:26 +0100 Charles Lindsey 
<[email-masked]> wrote:

>...
>> problem, i.e., the   characters that are appropriate for use
>> in identifiers.
>
> And that is essentially NFKC normalization which, since it is
> defined by  the Unicode people, is easy to incorporate if we
> so decide. I think  Nameprep includes at least NFKC for
> example.
>
> If you want to go beyond that, then you can look at the
> classifications  into which Unicode divides things. I would
> think, at least, that you would  want to forbid characters
> that are not visible, and probably also any  characters that
> are just new forms of whitespace (because those would all
> fail both the telephone and fax tests). That would probably be
> far enough.  I would not want to disallow punctuation or
> mathematical symbols, not  upper- or title-case letters
> (since, with due diligence, thay need not  fail my two tests).

Charles,

First, nameprep is essentially NFKC with some additional 
restrictions.   The current UTC thinking on identifiers is more 
restrictive, see UTR 31 
(<http://www.unicode.org/reports/tr31/)>) for more information. 
Second, please read the rest of my note, where I explained why 
we probably don't want to go down that path (and Chris Newman's 
note of several days ago that reached essentially the same 
conclusion after reasoning from a different perspective.  If you 
want to argue for a more restrictive character model, please 
respond in terms of my comments, Chris's comments, and the 
explanations of the "no one looks or interprets before the 
delivery MTA in RFCs 1123 and 2821.

      john