Re: Normalisation and matching

"J-F C. (Jefsey) Morfin" <[email protected]>
Newsgroups gmane.ietf.imaa
Message-ID <[email protected]>
On 11:11 11/08/03, Adam M. Costello said:
>Yes, we want that, but there are other things we want too, and sometimes
>we have to make choices.

Sorry, but the only reason why would be that you do not know how to make 
it. It is true there is a problem, but the reason of this effort is to work 
out a solution. And if this demonstrates not possible priorities in choice 
may be other prirorities than yours.

> > Matching is case-insensitive - everybody do not know what case you
> > prefer on your e-mail address (and case is not spoken over a phone
> > when you give your address).

No. Matching is the matching system the application is set-up for. Do not 
think in old terms. We are discussing future not only support of the past.

> > If we cannot handle ACE->UCS with case preservation we could as well
> > use a one way hash for the ASCII world.
>
>Do you see what you're saying?  Given:
>
>  1) José
>  2) josé
>  3) kmcsi5csxy
>
>you're saying that if you can't show (1), then it doesn't matter whether
>you show (2) or (3), because neither is any better than the other.  Are
>you serious?
>
>We already went through all this for IDNA.  Traditionally domain names
>are case-insensitive and case-preserving, but the case-preserving
>part was relaxed for IDNs because it wasn't deemed worth the
>additional required complexity.  We can add an optional mechanism for
>case-preservation later.
>
>We could repeat the same arguments for IMAA, but I see no reason why it
>would play out any differently than it did for IDNA.

Adam, this is not because _you_ do not understand a need that this need 
does not exist. This is not because you made something limited for years 
that this must go for ever. This is not because you chose one way for 
something that it must be followed for everything else.

We all agreed that IDNA was a try. This is why it was eventually accepted. 
Don't try to make it a rule. The only result would be a network split.

> > IMAA should define how non-ASCII e-mail addresses are used in
> > protocols, not how a user interface should handle them.
>
>Just the opposite.  Initially, non-ASCII mail addresses will not appear
>in protocols at all (only ASCII address will), but they will appear in
>user interfaces.

This is a demand of the DNS for RHS. There is no DNS on LHS.

>And again, I see no reason why IMAA and IDNA should take different
>courses on this issue.  IDNA did not prescribe any particular form for
>IDN-aware slots.

ditto.

I see no reason why future IDNA and IMAA should take different
courses on this issue. IMAA is not to prescribe any particular form
for LHS.

> > Slots with other encodings are something else and should not be
> > recommended.
>
>They are neither recommended nor discouraged.

Let then have an IMAA and a RichIMAA

Let have a new RR as "RM" for RichMail supported instead
of MX. MX will mean that RichMail will have to be degraded
to Standard IMAA. It is likely that non "MR" supporting Bind
versions will not give access to RichMail applications.



On 14:25 11/08/03, Adam M. Costello said:
>The local part is no more a name than the domain part.  Both are 
>identifiers designed to be memorable in association with a 
>person/organization, not equal to the name of that 
>person/organization.  No one expects to exchange email with <John Q. 
>Public at Yahoo! Inc.>, they are accustomed to exchanging email with "John 
>Q. Public" <[email protected]>.

Will repeating that, change that YES there ARE people demanding it?

That for 6.000 years men use Upper Cases when they could have used lower 
cases only. That there are people crazy enough to set up language 
organizations like Eurolinc to demand it. Even States like 25 european 
States putting into their Constitution that such things have priority over 
international agreements and local laws.

1. our role is not to impose technical limitations but to work out the way 
we will address their expectations. Or just say "I do not know how to do it".

2. this is not because some techies had not the budget, the skills or only 
the cultural interest and accepted to degrade language, courtesy, user 
services that this should extend to the workd for ever.

This world of us is made of names, trade marks, IP rights, information, 
knowledge, suscriptions, .. which not only come Upper and Lower cases we 
obviuosly have to support but also with many new signs like emotocons and 
dingbats we need to support. Unless we do not want e-mail to stay 
compatible with SMS?

Internationalizing is ASCII patch. Multiliguism is a necessity. Vernacular 
e-names is the demand (on the network the names the way they are used be 
everyone everywhere else). If Real Names was closed it was by Bill Gates 
political decision we all know why, not by lack of user demand.

jfc

PS. may I recall you that "@" is an old French character for "ad" in Latin 
(as & for "et") - also spelled "à" (same key on the keyboard) which is used 
exactly in the way you say we do not.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.