Re: [EAI] [IETF] Content Issues [

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

--On Sunday, October 16, 2016 6:48 AM -0700 [e-mail]
wrote:

>... 
> You're missing the point. If I send to an IETF list from an
> EAI address, the message I send is going to be an EAI message.
> Given the way EAI works, that message is only going to reach
> the (currently small) subset of list participants for whom the
> path to their eyeballs is EAI-capable at every step along the
> way.
> 
> The effect of this is to essentially to create a EAI-capable
> subset of any discussion. That breaks accontability, as John
> notes. But perhaps more important is the fact that it also
> breaks the entire open model.
> 
>> I'd vote for "eat our own dogfood"
> 
> Like it or not, that's not possible at this point. Perhaps
> that will change at some point in the future when the
> penetration of EAI has increased, but until it does the best
> we could offer is to allow EAI addresses to receive the list
> but not post to the list. And I don't think that's of
> sufficient utility  to bother implementing.
> 
> 				Ned


Ned,

Yes, exactly.  Even for the "receive but don't post" case, it is
worth remembering that just including a cc to a non-ASCII
address on a message, even if the sender and list addresses are
all-ASCII, or having non-ASCII in the headers when all addresses
are in ASCII, is sufficient to prevent many members of the
community from receiving the message.  I haven't thought through
the implications of IMAP-accessible archives of messages that
require SMTPUTF8 capabilities, but I don't think that would be
pleasant either.

FWIW, in the IETF context, those who are concerned about not
being able to use non-ASCII addresses because the local parts
cannot properly represent their personal names should probably
be pushing much harder on more substantive issues like why the
IETF does not allow list postings in their preferred languages
and provide (and insist on) real-time parallel translation at
meetings for all of the languages  whose users might be present.
Those are important, substantive, issues and not resolving them
prevents the community to be as diverse and open as it might
otherwise be.  Mailbox names are just identifiers.  I'd probably
feel differently if we had no provision for what were
historically often called "personal name phrases".  But those
arrangements have existed ever since we discovered that being
able to associate personal names with serially-assigned account
identifiers was useful (e.g., knowing me as "M3418" was never
helpful and was hard on transparency).  The required
functionality goes back to at least RFC 822 (and IIR earlier)
and has been possible with encoded words (which are widely
supported) since MIME was introduced 24 years ago.

   john