[EAI] mailto: was RE: Rechartering

[Shawn Steele <[e-mail]>]

I think we're digressing from rechartering to mailto :)

> Then it seems to me that you are in big trouble because
> deploying EAI with Downgrade --even in the syntax-only form
> Charles suggests-- means that users will encounter it working
> one way in some places (e.g., accepting non-ASCII addresses but
> not alternate address syntax) and in other ways (e.g., accepting
> non-ASCII and alternate addresses) in others, even within the
> same system.   That is, IMO, much worse even that having
> extended (non-ASCII) addresses work in some places but not in
> others.

>> I'd agree, but [e-mail] should still work :)0

> Sure.  But unless it can be parsed out of the above, that isn't
> interesting.

I disagree.  Assuming that иван@bogus.domain.name is your Unicode alias and [e-mail] is your ASCII alias, you can always use mailto:[e-mail] and it should get to you regardless of any <> or whatnot.

I actually find the < > downgrade syntax fairly unlikely to be helpful.  Presumably your mail server understands the complete EAI syntax since you're providing both addresses.  Likewise my client knows about EAI if it understands <unicode <ASCII>>.  So pretty much the only place that <unicode <ASCII>> is going to gain anything is when my mail server is not EAI aware, but my client and your server are EAI aware.  It seems more likely to me that my server and client would both be EAI aware.  So, to me, the most likely scenarios would be when some in-between relay wasn't EAI aware, yet any such sender or receiver side relay would necessarily be EAI aware.  Relays that aren't tightly coupled with the sender/receiver side tend to be blacklisted anyway.

So to me, the <Unicode <ASCII>> syntax is mostly interesting merely to populate my address book with both addresses.

FWIW: mailto:Unicode@Unicode on Windows+Safari/IE will invoke Outlook with the address as expected.  I seriously doubt we'll block that behavior, and I think it should be permitted in the mailto draft.

>  Note that, if one had a Unicode-native system and
> simply removed the "ASCII address" restriction,
>    иван@bogus.domain.name
> would parse as the address the user would expect while
>    <иван@bogus.domain.name <[e-mail]>>
> would almost certainly get some sort of "invalid end of address"
> or "invalid unquoted space in the middle of the address" error.
> And, if it tried to "fix" that error, as many MUAs and some
> other systems would, life would get interesting.

Pretty much my feeling.

> Again, if you are in a hurry, the key question is whether we
> need downgrading.  If we don't, a large fraction of the issues
> I'm raising just disappear and I have no trouble working through
> a schedule (in your model) or a requirements plan (in Harald's).

In mailto: I don't find downgrade very helpful.  As I said, you'd have to have an updated client anyway to handle the new syntax, while mailto:unicode & mailto:ASCII are likely to work already.  I don't really object to the mailto: updates because I don't really see them having any practical impact :) and they provide some completeness.

I think downgrade is primarily interesting when I send mail from an EAI aware client to an EAI unaware client.  In that case the mail is downgraded and the recipient is able to reply to me.  In nearly every other case either the user has a Unicode address that may or may not work, or an ASCII address that works.  I think the downgrade behavior in this scenario is fairly complete.

So I think we pretty much sort of agree.  You think that without downgrade the experimental RFCs are somewhat stable.  I agree.  You ask if I think downgrade is required.  I'd split that out into downgrade when I send a mail, and "the rest of downgrade."  Downgrade when mailing from an EAI aware system to an EAI unaware system is useful and also somewhat reasonably defined, and I'd include that in my stable behavior.  mailto and most of the rest of downgrade I think is less helpful.

The scenarios I see are:
1) EAI to EAI, in which downgrade is unhelpful
2) Me giving you a Unicode address on a post-it, in which case downgrade is unhelpful (because I didn't give you the ASCII form)
3) Me giving you my ASCII address on a post-it, in which case downgrade is irrelevent because it's gonna work anyway.
4) Me mailing you from EAI aware to EAI unaware systems, in which case downgrade is helpful
    a) My mail gets to you, and if you reply to me, it'll work
    b) You probably won't get my Unicode address, but that's OK, because you don't know how to use it anyway.
    c) If you happen to have a client that can upgrade my address, then you'll have the info to send mail to me (that'll be downgraded on the way, probably)
5) Something like mailto:
    a) It'll continue to work with a downgraded ASCII address.
    b) If it happened to work with Unicode, it'll continue to work with Unicode.
    c) If it doesn't work with Unicode and is EAI unaware, then downgrade won't work anyway since it won't understand whatever has to happen to the protocol (like mailto)

So I think we're pretty close for the non-downgrade stuff.  For downgrade I think we're pretty close for the 95% useful cases.  For the remaining downgrade completeness stuff like mailto:, I agree that there're interesting issues and I don't think they're helpful for that 5%.  So I'd go ahead and standardize the non-downgrade stuff, the downgraded headers stuff, and I wouldn't worry about the other downgrade scenarios right now.

-Shawn