Re: [EAI] Shepherd report review of mailinglist-02

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

WG participants,

I've responded to some of John L's points below -- read or not
as you like.  Either way, consider this a heads-up that we will
ask Pete to start the process of initiating an IETF Last Call in
circa 24 hours.  So, if there is anything here you don't like,
this is your last chance to speak up inside the WG.

John,

Inline.

    john



--On Thursday, July 12, 2012 17:45 -0400 John R Levine
<[e-mail]> wrote:

> OK, I've posted an -03 that I think takes into consideration
> everyone's comments.  The comment that lists are inanimate
> messages while list agents are software was a good one, that
> let me go through and make the document (I think) considerably
clearer.
> 
> Just so you don't think I ignored you:
> 
>> FWIW, I've never seen a large list handled by putting hundreds
>> of messages into a single SMTP envelope and handing off to a
>> conventional submission server.
> 
> It's quite common now, e.g., one of Mailman's normal config
options.

Ack.  Thanks for clarifying.

>> In a world in which we encourage explicit confirmation as part
>> of an email subscription process for other reasons (ones with
>> which you are thoroughly familiar), putting something that
>> requires SMTPUTF8 handling into the automated confirmation
>> message would not be burdensome.
> 
> I didn't do that for two reasons.  One is that while requiring
> signup confirmation usually a good idea, there are real
> situations where it's not needed, and this is the wrong place
> to argue about list policies. 

Absolutely.

> Also, this could apply to lists
> where the manager is upgrading an existing list to EAI, and
> getting all of a list's subscribers to reconfirm is, ah,
> challenging.  So it mentions it as an option, not as advice.

Wfm.  I just wanted to be sure that, if anyone asked, Joseph and
I could say "yes, we considered doing that and decided no to".
 
>> We've essentially said that in-transit message downgrading is
>> impossible unless the message contains no non-ASCII addresses
>> and has non-ASCII material only in header fields in which
>> encoded words can be used.  Absent a whole series of
>> provisions that you haven't discussed, a mailing list
>> exploder is in no better shape to downgrade messages for
>> ASCII-only recipients than a relay.
> 
> Already discussed later on, added references.

Again, thanks.