[EAI] AD review of draft-ietf-eai-mailinglist-04.txt

[Alexey Melnikov <[e-mail]>]

I think the document is very close to being ready for publication as an 
Experimental RFC.

Below are some comments:

2.  Introduction
   
    In most cases, the mailing list agent redistributes a received
    message to its subscribers as a new message, that is, conceptually
    it uses message submission [submit]

This is not listed as a reference. I assume it should be Informative.

    (as did the sender of the
    original message).  The exception, where the mailing list is not a
    separate agent that receives and redistributes messages in separate
    transactions, but is instead an expansion step within an SMTP
    transaction where one local address expands to multiple local or
    non-local addresses, is out of scope for this document.

 [...]

    There are considerations for internationalized email addresses in
    the envelope as well as

"in" missing here?

    header fields of redistributed messages.  In
    particular, an internationalized message cannot be downgraded unless
    envelope addresses are in ASCII (which includes use of ALT-ADDRESS).

I would suggest rewording this to make it clear that either envelope
addresses are in ASCII, or ALT-ADDRESSes for them are available.

3.  Scenarios Involving Mailing Lists
   
    The submission server then decides
    which recipients to include in whi ch transaction.)

nit: which


4.  Capabilities and Requirements
   
    1.  If the list uses a UTF8 submission or return-path address, it
    SHOULD specify an alt-address for it.  Clearly, it needs to sit
    behind a UTF8SMTP-enabled final-delivery SMTP server and delivery
    agent.

I think this needs an Informative reference to RFC 5336.

    Likewise, if a list uses a UTF8 return-path address, then
    its MSA needs

I recommend an Informative reference to RFC 5598 here.

    to support UTF8SMTP.

5.  List Header Fields

    Even without these header fields being extended to support UTF8,
    some special provisions may be helpful when downgrading.  In
    particular, when a List-* header contains a UTF8 mailto (even
    encoded in ASCII) followed by an ASCII mailto, it may be advisable
    to not only copy and preserve the original header as usual, but also
    to edit the header to remove the UTF8 address.  Otherwise, a
    non-UTF8-aware client might run into trouble if the decoded mailto
    results in a non-ASCII address. [[[EDITOR'S NOTE:  This needs to be
    vetted by the eai list.]]]

I think this is sensible.

But note that currently mailto-bis doesn't directly allow UTF-8 in LHS
of addresses. This will be dealt with when the WG recharters (hopefully).

    The List-ID header filed uniquely identifies a list.  The intent is
    that the value of this header remain constant, even if the machine
    or system used to operate and host the list changes.  This header
    field is often used in various filters and tests, such as
    client-side filters, Sieve filters, and so forth.  Because of this,
    great care should be taken, as a non-ASCII value might not match
    when encoded into ASCII.  It is generally desirable that this header
    field contain something meaningful that users can type in.  However,
    non-ASCII characters encoded into ASCII are unlikely to be
    meaningful to users or easy for them to accurately type.

I think that we should make it simple and just say that any List-ID is 
all-ASCII (for the reasons
you specified) the same way as we did for the Message-ID header field.
And informational suggestion to use punycode version of domain names
can be added, if needed.

6.  Further Discussion

    1.  Obtaining Downgrade Information -- for a mailing list, or mail
    relay server for that matter, that is UTF8SMTP-aware, receiving mail
    from an internationalized email address, the alt-address is not
    required from the sending MTA for the transport to be complete.
    Thereupon when the mailing list retransmits the message to its
    subscribers, it may encounter paths where a downgrade is called for.
    In order to mitigate this situation, the mailing list might perhaps
    decide to reject all incoming mail from an internationalized email
    address that lacks an alt-address.

An alternative would be to require that all subscribers be UTF8SMTP-aware.
I think this would become the more common alternative over time, if EAI 
takes off.

    However, note that in general,
    downgrades are not expected to be the normal case.

11.  Informative References
   
    [mailto-bis] M. Duerst and L. Masinter, "The mailto URI scheme",
    draft-duerst-mailto-bis-xx (work in progress).
   
    [List-*] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for
    Core Mail List Commands and their Transport through Message Header
    Fields", July 1998
   
    [List-ID] R. Chandhok and G. Wenger, "List-Id:  A Structured Field
    and Namespace for the Identification of Mailing Lists", March 2001
   
    [IRI] M. Duerst and M. Suignard,"Internationalized Resource
    Identifiers (IRIs)", January 2005

The last 3 documents are lacking RFC numbers.