Re: [EAI] mailto: was RE: Rechartering

[John C Klensin <[e-mail]>]

--On Friday, July 24, 2009 04:48 +0000 Shawn Steele
<[e-mail]> wrote:

> 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.

And I don't know what you are suggesting.   If it is "use the
mailto: with the ASCII local part" then EAI is irrelevant.   If
it is "supply two separate mailto: URIs", then you are, in
effect, suggesting downgrading only at the sending MUA or
submission server.   I'm strongly in favor of doing as much
downgrading as is necessary and possible there, but it doesn't
require any protocol changes or new syntax.

> 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.

And that is precisely one of the arguments why downgrading on
the fly and mid-network is not likely to be useful enough to be
worth all the trouble, extra syntax, etc.

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

And, depending on how your address book is designed --a topic
_far_ outside the scope of the WG-- a better way might be
something isomorphic with
   <email>Unicode</email>
   <alt-email>ASCII</alt-email>
or
   <email>Unicode <alt>ASCII</alt></email>
saving a lot of parsing aggravation when the addresses are
needed, _especially_ if the downgrade point is the originating
system.

>...
>> 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.

Mostly agreed, but, if we specify the two-address syntax,
mailto: ought to be able to access it somehow.   That is another
case of "providing for on-the-fly downgrading complicates a lot
of things without a lot of payoff".

> 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.

Complete, yes.   Reasonably guaranteed to work, no.  And it does
suggest another case that might be worth considering, which is
permitting downgrade syntax and logic only for backward-pointing
addresses (MAIL, "From:", "Sender:", "Reply-to:") but not
forward-pointing ones (RCPT, "To:", etc.)

> 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.

I think we agree although I'd like to push back mildly on even
the backward-pointing addresses just because of the costs of
dealing with the new syntax at all.

> 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

Well, maybe.   It'll work iff the downgraded info survives the
gateways, etc., some of which may be EAI-unaware to the point of
being hostile.

>     b) You probably won't
> get my Unicode address, but that's OK, because you don't know
> how to use it anyway.

right

>     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.

I could probably live with this, but want to see the outcome of
more testing.

     john