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

From: Randall Gellens <[email-masked]>
Date: Mon, 11 Jan 2010 17:10:04 -0800

Hi Alexey,

Thanks very much for your review.  Please see in-line:

At 5:04 PM +0000 11/28/09, Alexey Melnikov wrote:

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

Yes, thank you.

>
>     (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?

It's correct with or without it, but I think it is easier for 
non-native English speakers to read it if the second "in" is added, 
so I did.  Thanks.

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

Thanks, I reworded it to:

     In particular, an internationalized message cannot be downgraded
     unless all envelope addresses are available in ASCII (that is,
     each address either is ASCII or has an ALT-ADDRESS).

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

Thanks.

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

Yes, I agree.

>
>     Likewise, if a list uses a UTF8 return-path address, then
>     its MSA needs
>
>  I recommend an Informative reference to RFC 5598 here.

I figured it was easier to add a reference to [submission] since that 
was already there.

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

It's going to be all-ASCII either way, the question is if the ASCII 
is an encoding of something else.  I reworded it to be more clear 
that it is warning against using an encoding:

     This header
     field is often used in various filters and tests, such as
     client-side filters, Sieve filters, and so forth.  Such filters and
     tests may not properly compare a non-ASCII value which has been
     encoded into ASCII.  In addition to these comparison considerations,
     it is generally desirable that this header field contain something
     meaningful that users can type in.  However, ASCII encodings of
     non-ASCII characters are unlikely to be meaningful to users or easy
     for them to accurately type.

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

That's not sufficient, because if even one MTA between the mailing 
list and each subscriber doesn't support UTF8SMTP at the time the 
message is sent, it may be downgraded.  Further, even users with 
all-ASCII addresses might be on servers that do support UTF8SMTP.  I 
added this clarification to the text:

     it may encounter paths where a downgrade is needed (if
     a relay or final MSA does not supports UTF8SMTP)

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

Fixed, thanks.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Accident: A condition in which presence of mind is good, but absence of
body is better.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Jan 2010 21:37:50 +0000

> Hi Alexey,

Hi Randy,

 [...]

>>  I think this is sensible.
You haven't removed the Editor's note from the latest version.

> It's going to be all-ASCII either way, the question is if the ASCII is 
> an encoding of something else.  I reworded it to be more clear that it 
> is warning against using an encoding:
>
>     This header

This text is weaker than I would personally like, but I can live with it.

>     a relay or final MSA does not supports UTF8SMTP)

I think you meant "final MDA".