Re: quick & dirty alternate addresses

Pete Resnick <[email protected]> writes:

>> It can just use the real angle-addr (as it always has), and treat
>> the display-name as an opaque string to display to the user (as it
>> always has).
>
> Nope, my MUA has never treated the display-name as an opaque
> string. It decodes it and, upon reply, copies the whole address
> (display name and angle-addr) directly into the "To:" field where it
> expects to be able to be able to re-encode it for sending. But when
> the MUA tries to re-encode the address, it finds these angle-bracketed
> things that it thinks are illegal addresses and chokes.

How is this anything but a software bug?  It may be illustrating as a
point in discussion, but if we are going to reject all solutions that
exploit legal constructs in existing specifications, but may trigger a
problem in some piece of software, I don't think we'll be likely to
end up with anything.  Introducing capability negotiation, and new
capabilities, including falling back to a compatibility mapping, will
undoubtedly uncover many bugs as well, but that shouldn't prevent us
from choosing that approach [if the gains are worth the prize].

I find the angle-addr-in-quoted-string idea worth exploring.  The
arguments against it, so far, hasn't been convincing, to me at least.

Thanks,
Simon