changes between imaa-01 and -02

[Adam M. Costello]

This might be helpful for reviewing the new draft.

AMC

Issues that were open and are now fully closed (not mentioned):

Should IMAA support case-sensitive mail exchangers? No.

Should IMAA keep the requirement about recognizing fullwidth
at-signs? Yes.

Should ideographic full stop be converted to ASCII full stop in
local parts, as is done for domain name separators? No.

Should IMAA require that fullwidth quotation marks and backslashes
be recognized? No.

Issues that were closed-but-could-be-reopened and are now fully closed
(not mentioned):

Should local parts be processed in segments? Yes.

Issues that were open and are now closed-but-could-be-reopened:

Should the 59-character limit on the Punycode encoder output
be relaxed? No.

Should hyphens be protected? Yes.

Should the IDNA ACE prefix be resused for IMAA (which is an option
only if hyphens are not protected)? No.

Issues that remain open:

Should we remove the recommendation that applications avoid altering
the quoting of a local part when applying ToASCII/ToUnicode would
have no other effect?

Does IMAA say the right things about stored strings versus query
strings?

Inserted section 6 as a first attempt at addressing the stored/query
issue.

Changed "mail address" to "mail address (or part of a mail address)" in
the definition of mail address slot and in section 3.1 requirement 2.
(Motivation: /etc/aliases contains slots for just the local parts, while
the associated domain parts are likely to be in separate slots in some
sort of local_domains parameter of the MTA config file.)

In order to protect hyphens, changed "ACE prefix" to "ACE infix" and
tweaked ToASCII steps 5b,e and ToUnicode steps 5a,b and section 5.

Added section 3.2.2 to discuss the issue of local parts and domain names
getting transplanted from one side of the at-sign to the other.

In section 4, split step 5 into 5 & 6 (they had previously been combined
and presented out of order).

In ToUnicode tweaked steps 3 and 8. There was no need to save a copy in
step 3, because step 8 can use the original input instead.

Made all the citations descriptive. Previously some had been
descriptive, like [STRINGPREP], while others had been numeric, like
[RFC2822]. No change to the references themselves, except to add the
informative reference for [DNS], which had been missing (it is cited in
the introduction in the explanation of the differences between IDNA and
IMAA).

Some inconsequential rewording.

[J-F C. (Jefsey) Morfin]

Post by Adam M. Costello
Should IMAA support case-sensitive mail exchangers? No.

I thought we made clear that yes. And that you made clear that punnycode
had no problem with it .

Or am I wrong on the meaning. We need ***@wanadoo.fr to land as
***@wanadoo.fr. Up to Wanadoo to reduce it if it wants to
***@wanadoo.fr or to ***@wanadoo.fr or not.

jfc

[Arnt Gulbrandsen]

Post by J-F C. (Jefsey) Morfin

Post by Adam M. Costello
Should IMAA support case-sensitive mail exchangers? No.

I thought we made clear that yes. And that you made clear that
punnycode had no problem with it .

Today, some software needs to treat localparts as case sensitive and
some as insensitive (e.g. an address book lookup). That's painful. To
me, it makes very little sense to carry that forward into IMAA.
Why do we need that? And even if we do, a simple 'preserve case during
handling' rule will do.

--Arnt

[Paul Hoffman / IMC]

Post by J-F C. (Jefsey) Morfin

Post by Adam M. Costello
Should IMAA support case-sensitive mail exchangers? No.

I thought we made clear that yes.

I don't see that in the mailing list archives. Could you point to the
messages that said we should?

--Paul Hoffman, Director
--Internet Mail Consortium

[J-F C. (Jefsey) Morfin]

Post by Paul Hoffman / IMC

Post by J-F C. (Jefsey) Morfin

Post by Adam M. Costello
Should IMAA support case-sensitive mail exchangers? No.

I thought we made clear that yes.

I don't see that in the mailing list archives. Could you point to the
messages that said we should?

Last mail on the matter was a mail of mine responding Adam Costello on
20:13 23/04/2003. It repeated my request and rose questions that were never
addressed further on, but which basically make the support mandatory (by
this system or the real final one). I understand this at least as leaving
the question open. I did not press it because of other obligation and the
understanding of Adam silence as an OK.


Let's take back the cons and pros as I understand them.

Cons. No RFC requires it. Not konwn software support them. No technical
reasons risen in here seem to demand them. "Keyboards are in upper cases" -
that one would be good if there was no upper-case key. John Klensin: people
tend in computing (and elsewhere) to understand "john" as "John" or "JOHN",
but John did not really investigated it. Supporting case sentivity would be
"absurd".


Pros. Adam says that punnycode support them but he did not documented it,
so the problem is not technical impossibilty/. Several people explained
that in their language the same word with or not with leading or in text
upper-case had different meanings. DOS/WIN does not make difference, but
Unix does, so will Netix. Passwords make differences and can be used in
LHS. TMs make difference: being forced to accept a third party lower case
name can lead to consider that one does not deffend the TM using the same
string wih upper cases. The first juridprudence would be be a killer. Is
"ford" the same as "John Ford" or "FORD Cars" when "Ford/FORD" are
possible? I will not bet on it - is there a lawyer in the plane?

Laws require that addresses conform with Title for validity (a bad
orthograpy in the addressing of a document can be a procedural error: in a
country deciding this applies to LHS [there are 190 countries] e-mail would
be ruled out from Justice/e-govement procedures with an international impact).

The French cultural exception is now in the European Constitution and this
exception now applies to the 25 European countries, plus our regional
cultures (laws must respect cultural priorities). I reported that I
questionned people during WSIS meeting and I engaged all of you to do it
with friends and families: everyone will basically respond that if one
decided to use upper and lower cases, there were many reasons and that they
want these reasons respected.

I just read yestderday a very interesting compartive analysis by scolars
from many horizons on the US culture (indivually centric) being far less
concerned by the respect of the language than European and other (community
centric) cultures, where touching to the language is touching to the
community and felt as a real agression. We all have examples in mind, don't
we? Most people in the world will not care about former RFCs and
non-existing yet programs. Once they know this is possible they will only
demand to be personnally respected by the standard and by the programs.

IDNA is not accepted well because it is only an internationlization of the
legacy namespace. The ML.ML demand is an operators demand (James Seng
documented that Variants accomodated ccTLD needs, not the users needs far
too complex to consider). Users want "vernacular names and addresses"
(these they use all the day long in life, streets, geography, books, laws,
school learning and teaching. Their current relative disinterest in
Internet and DNS is partly comming from that: the brainware layer is not
happy with the limitations imposed by the software layer).

I fully accept this is difficult to consider as priority in an American
oriented technical group. As one of the BoD Members of Eurolinc (a language
organization accepted in the ccTLD WG-IDN or by the MINC, Europe and active
at WSIS, dialoging with ITU) I call testify that it is not the same with
language and cultural group from every culture.

Our problem today, in order to specify correctly is that no many people are
interested in participating to a standardization process. So we have to ask
around, not only to our one selves.

I fully accept that "phoffman" or "jefsey" are technical short-cuts and
nice nicknames. But will you ask you mother or your daughter to coin such a
nickname for her driving license, hospital care, etc. May be as an American
will you? I will certainly not. But I am afraid 90+% of the mankind would
not accept either.

Most of the countries are heading towards national eletronic IDs: they will
not accept jokes and nicknames and orthographic errors as names (they will
not accept also what may create confusion or reduce the number of names).
They will not change all their legal body to respect internet oddities (I
am sure that a good case about forcing someone to accept lowercases only
may lead to jail in France: let consider the cases where dropping the upper
cases will make someone's name a racist joke).

For example I will certainly not accept as legally binding documents sent
to me to any other address than Jean-Franç***@Morfin.78000.fr or what ever
the French Parliament will vote for a national naming service French
semantic. I am sure it will be the same the world over, in Arabic, Chinese
or Australian.


I do not know what may convince you people in here but let take a simple
example. ***@alcatel.com will be tought by most as a certain Doug's e-mail.
But ***@alcatel.com will be obvious to everyone of French language: this is
the CEO's Office e-mail address.

You may obviously chose not to support case-sensitivity because Americain
makes low use of it. It will only be an additional and presing reason for
us to call and obtain European funding to R&D a new, modern nd no spam mail
system. You will be remembered as those who made it a legal and technical
necessity. Thank you.

jfc

[Roy Badami]

Post by J-F C. (Jefsey) Morfin

Post by Adam M. Costello
Should IMAA support case-sensitive mail exchangers? No.

I thought we made clear that yes. And that you made clear that punnycode
had no problem with it .

Assuming that the localpart may be internationalized (eg contains
accented characters), we would need to use mixed case annotation in
punycode. But, as well as adding complexity, it isn't really enough
to solve the problem.

German users will probably be unhappy that their name Strau<es-zet>
gets mapped to strauss which is, essentially, a mis-spelling of their
name. Mixed-case anotation, as I understand it, can't capture the
distinction between ss, SS and es-zet.

So, I would like to propose an alternative solution: don't attempt to
tackle mixed case anotation at all within IMAA, but create a companion
document to handle e-mail address presentation forms.

Here's how it would work. An MUA that chooses to implement this
protocol would add a series of headers of the following form:

IMA-Presentation-Form: <ASCII-email-address> <base64-encoded-UTF8-IMA>

one for each IMA in the From/To/Cc headers. A cooperating receiving
MUA would search each ASCII address (either ACE or traditional)
against the presentation form headers, and if it finds a match, would
select the appropriate IMA as the prefered presentation of that
address (after first performing ToASCII on it and verifying that it
maps to the address you started with).

This allows cooperating MUAs to solve the problem of case, es-zet, and
any other distinctions lost by NFKC or case folding -- if they think
it's important. It also allows MUAs that don't wish to do this not to
be burdened with any extra complexity.

-roy

[Adam M. Costello]

Post by Adam M. Costello
Should IMAA support case-sensitive mail exchangers? No.

I thought we made clear that yes. And that you made clear that
punnycode had no problem with it.

There are at least three separate issues here.

1. Do josé@example.net and JOSÉ@example.net refer to the same mailbox?

[The non-ASCII characters just before the at-signs are e-with-acute and
E-with-acute.]

This was an open issue in imaa-00, but it was already closed in imaa-01.
There has been no change between imaa-01 and imaa-02 on this issue. The
decision was that yes, they refer to the same mailbox, because that's
what most users expect, it is consistent with current practice, and is
consistent with the recommendation of current standards.

This issue is closed.

2. Will josé@example.net and JOSÉ@example.net be displayed that way, or
might they both be displayed the same way?

In other words, is case preserved? This was an open issue in imaa-00,
but it was already closed in imaa-01. There has been no change
between imaa-01 and imaa-02 on this issue. The decision was that
they might both be displayed the same way, because preserving case
is too technically tricky to require of all implementations, and for
consistency with IDNA (where the existing recommendation that case be
preserved in ASCII names was relaxed for non-ASCII names).

In both IDNA and IMAA, it is possible to add optional support for case
preservation later, but it will not be in the initial RFC. This issue
is closed.

3. Will it be possible to create a mailbox named josé@example.net or
JOSÉ@example.net if the mail exchanger for example.net is IMA-unaware
and case-sensitive?

This was an open issue in imaa-01, and has been closed in imaa-02. The
decision is no, it will not be possible, because making it possible
would complicate the spec for almost zero gain, because all known mail
exchangers are case-insensitive anyway (which is what existing standards
recommend).

Of the three issues, this is the only one that changed between imaa-01
and imaa-02, but I think all of JFC's concerns pertain to the other two
issues, not this one.

Mixed-case anotation, as I understand it, can't capture the
distinction between ss, SS and es-zet.

Right, because ASCII letters are literal, not annotated. An es-zet
becomes ss, which is regular ASCII. It can appear as ss or SS or Ss or
sS, but those are all literal ASCII.

I suppose a special convention could be adopted that if mixed-case
annotation is enabled (which could be signaled by an ACE prefix of
xN--), then sS should be displayed as es-zet. Of course that would make
it impossible to display sS itself.

There would still be other things that mixed-case annotation could not
handle, like titlecase (letter Dz versus letter dz or letter DZ).

IMA-Presentation-Form: <ASCII-email-address> <base64-encoded-UTF8-IMA>
one for each IMA in the From/To/Cc headers.

That's both simpler and more expressive than mixed-case annotation,
which is attractive. On the other hand, it would work only for mail
addresses in message headers, not for mail addresses and domain names in
other contexts.

AMC

[Roy Badami]

Post by Adam M. Costello
That's both simpler and more expressive than mixed-case annotation,
which is attractive. On the other hand, it would work only for mail
addresses in message headers, not for mail addresses and domain names in
other contexts.

That's true, but I maintain that this case is probably percieved to be
important enough to some sets of users that if the best way of
tackling it is to make it a special case, so be it.

I can't immediately think of any other cases where end users (as
opposed to mail administrators) would routinely be presented with the
output of ToUnicode.

-roy

[Roy Badami]

Post by Adam M. Costello
I suppose a special convention could be adopted that if mixed-case
annotation is enabled (which could be signaled by an ACE prefix of
xN--), then sS should be displayed as es-zet. Of course that would make
it impossible to display sS itself.

Wouldn't work for Strau<es-zet>, though, because after nameprep the
localpart would be ASCII, so it wouldn't be ACE-encoded, and wouldn't
have a prefix.

-roy

[Adam M. Costello]

Post by Roy Badami

Post by Adam M. Costello
I suppose a special convention could be adopted that if mixed-case
annotation is enabled (which could be signaled by an ACE prefix of
xN--), then sS should be displayed as es-zet. Of course that would
make it impossible to display sS itself.

Wouldn't work for Strau<es-zet>, though, because after nameprep the
localpart would be ASCII, so it wouldn't be ACE-encoded, and wouldn't
have a prefix.

Indeed, so it's even less useful than I thought. Never mind. :)

AMC