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.