From: Shawn Steele <Shawn.Steele@microsoft.com>
To: John C Klensin <klensin@jck.com>, Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: mailto: was RE: [EAI] Rechartering
Thread-Index: AQHKDBoA8N2XUvpvWEmPEljKeHTUeA==
Date: Fri, 24 Jul 2009 04:48:35 +0000
Message-ID: <CAD7705D4A93814F97D3EF00790AF0B315FDF9CC@tk5ex14mbxc105.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ima@ietf.org" <ima@ietf.org>
Subject: [EAI] mailto: was RE:  Rechartering
Precedence: list

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 john@bogus.domain.name should still work :)0

> Sure.  But unless it can be parsed out of the above, that isn't
> interesting.

I disagree.  Assuming that =C9=D7=C1=CE@bogus.domain.name is your Unicode a=
lias and john@bogus.domain.name is your ASCII alias, you can always use mai=
lto:john@bogus.domain.name and it should get to you regardless of any <> or=
 whatnot.

I actually find the < > downgrade syntax fairly unlikely to be helpful.  Pr=
esumably your mail server understands the complete EAI syntax since you're =
providing both addresses.  Likewise my client knows about EAI if it underst=
ands <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 m=
y 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 sce=
narios would be when some in-between relay wasn't EAI aware, yet any such s=
ender or receiver side relay would necessarily be EAI aware.  Relays that a=
ren'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 popu=
late 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,
>    =C9=D7=C1=CE@bogus.domain.name
> would parse as the address the user would expect while
>    <=C9=D7=C1=CE@bogus.domain.name <john@bogus.domain.name>>
> 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 h=
ave 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 m=
ailto: 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 awa=
re client to an EAI unaware client.  In that case the mail is downgraded an=
d 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 addres=
s that works.  I think the downgrade behavior in this scenario is fairly co=
mplete.

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 do=
wngrade 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 sys=
tem 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 down=
grade 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 yo=
u 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, pro=
bably)
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 Uni=
code.
    c) If it doesn't work with Unicode and is EAI unaware, then downgrade w=
on't work anyway since it won't understand whatever has to happen to the pr=
otocol (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 down=
grade completeness stuff like mailto:, I agree that there're interesting is=
sues and I don't think they're helpful for that 5%.  So I'd go ahead and st=
andardize the non-downgrade stuff, the downgraded headers stuff, and I woul=
dn't worry about the other downgrade scenarios right now.

-Shawn