Re: what is the real problem?

Hello Keith,

Very good start. Some comments.

At 15:14 03/11/11 -0500, Keith Moore wrote:

>Here I attempt to define the problems that IMAA needs to solve from a 
>user's perspective:
>
>1. Users need to have email addresses that are easy to remember and can be 
>reliably transcribed from memory.  That's the reason we like to use 
>people's names in email addresses - because it makes them easy to remember.

Yes. Add to that:
- easy to recognize (who's email was that? passive memory rather than
   active memory as above)
- easy to guess (works less for email addresses than for domain names,
   but is still sometimes useful)
- easy to create (when somebody gets a new address)
- easy to identify with

[these things are listed in the IRI draft]

>ASCII addresses are not adequate because the ASCII repertoire is not 
>sufficient to express people's names in most of the world's languages.
>
>2. Users need to have email addresses that can easily be transcribed from 
>written or printed form, so they can be copied from business cards, 
>handwriting on paper, etc.
>ASCII addresses do not always suffice because these characters may be 
>difficult to generate on the keyboards that are commonly in use in some 
>parts of the world,

I do not really know any examples of keyboards that would make generating
ASCII characters actually difficult. The difficulties lie much more
at the following points:
- People may rarely use ASCII characters, and therefore may not be familiar
   with how to input them (even if it's actually very easy).
- People are not (very) familiar with the characters themselves, which
   makes all operations much more difficult and error-prone. The best
   example for this is to imagine that you would have to use Greek
   characters. Although many scientists and engineers,... basically
   know the Greek alphabet, and inputing Greek on most modern computers
   isn't really difficult (assuming correct setup), it would still be
   a big pain for you/us.

>and because people unused to generating Latin characters on their 
>keyboards can easily confuse Latin characters with similar characters in 
>Greek, Cyrillic, or other alphabets.

I'm not exactly sure how this plays in here. It seems to me it could
be used as an argument both ways.


>3. Users need to have email addresses that can be transcribed from sounds 
>- e.g. read over a telephone.  This is harder in some languages than in 
>others, but even in most languages where this works, ASCII is not adequate 
>because people may not know or recognize the names of Latin or special 
>characters (even if they could type them).
>
>So, given a suitable input device, a user who is skilled in a language and 
>a writing system for that language should be able to:
>
>a. With a high probability of success, correctly transcribe an email 
>address that uses a person's name and a well-known domain string from that 
>language and writing system,
>
>b. With a high probability of success, correctly transcribe an email 
>address from that language and writing system that is written or printed 
>on paper,
>
>c. With a high probability of success, correctly transcribe an email 
>address from sounds spoken over the telephone by another user with 
>adequate skills in that language, approximately to the extent that those 
>users could successfully transcribe the same address over the telephone 
>onto paper

- a. seems to include both b. and c. Is it needed?
- I like your wording for c. It works very well even for not at all
   phonetic writing systems (e.g. Japanese)


>Other constraints:
>
>4. IMAs must have a low probability of causing operational failures with 
>existing mail software - MTAs, MUAs, mailing lists, automatic responders, 
>etc. - and other software which uses email addresses (directories, address 
>books, security protocols, etc.).
>
>5. All ordinary mail functions - replies, forwarding, resending, mailing 
>lists, must continue to work in the presence of any mixture of IMA-capable 
>software and legacy software.
>
>6. Users need to be able to transcribe addresses that they receive in 
>email, whether in message headers or in a message body, and whether or not 
>their software supports the extensions that enable IMAs, and whether or 
>not the recipient knows the language and script in which the sender 
>normally writes his name and email address.  This is separate from the 
>need to reply to messages or store received addresses in an address book.
>
>(Note: #6 directly implies the need to support multiple versions of a 
>sender address, in order to provide a recipient with an address that he 
>can transcribe.)

I think it implies multiple versions of a sender address, or multiple
sender addresses.

At this point, this may be a detail, but I think that MUAs will develop
ways to handle the problem of 'which address to use for which recipient(s)'.
This will be based on:
- User settings (use this address for this counterpart, or this domain,...)
- Detection on incoming mail (replies to mails with new addresses can use
   new addresses)
- Detection of mail content (e.g. at some point, a mail containing
   Japanese may be sent with a Japanese address, but a mail containing
   only ASCII would be sent with as ASCII address).
- ...
I think there is enough potential here that we can leave the implementations
to each MUA.


Regards,    Martin.


>Keith