Re: [EAI] Discussion of draft-ietf-eai-mailinglist-01.txt

[Randall Gellens <randy at qualcomm.com>]

At 7:56 PM +0000 3/13/07, Charles Lindsey wrote:

>  The mailing-list draft has been short of discussion. Time to rectify that.

I agree.  Thank you for doing so.

>  3 Scenarios Involving Mailing Lists
>
>  Whilst this section covers many interesting cases, it is not clear 
> that all the possible scenarios have been addressed.
>
>  I therefore suggest classifying systems against three orthogonal axes:
>
>  1. Does it have a UTF8 submission address?
>  2. Does it accept subscriptions to UTF8 addresses?
>  3. Does it accept UTF8SMTP messages?
>
>  In principle, that gives 8 different kinds of mailing lists, though 
> not all of them are sensible. But the requirements can be discussed 
> separately for each of those axes.

Sounds reasonable.

>  1. If it has a UTF8 submission address, it SHOULD publish an ASCII 
> alt-address as well. Clearly, it needs to sit behind a 
> UTF8SMTP-enabled MDA. If it also intends to use a UTF8 Return-Path, 
> that too should have an ASCII alt-address, and it will need a 
> UTF8SMTP-enabled MSA with at least the capability to accept that 
> address in a MAIL FROM. There are also implications for the List-* 
> headers (see below).

I'm inclined to think that even lists which use a UTF8 submission 
address should use an ASCII return-path.  Seems much safer.  I'd like 
to know what others think of this, though.

>  2. If it accepts UTF8 subscriptions, it SHOULD require an ASCII 
> alt-address as well for each subscriber. It also requires a 
> mechanism to accept requests to add those subscription addresses 
> (preferably specified in the form <utf8 at utf8<ascii at ascii>>). And 
> presumably it needs a UTF8SMTP-enabled MSA with at least the 
> capability to downgrade the envelope and any From/Reply-To header 
> field in a message.

Seems reasonable (I think some of this is already said).

>  3. If it accepts UTF8SMTP messages, it needs a UTF8SMTP-enabled MSA 
> with at least the capability to downgrade messages. It it is really 
> smart, it might prepare both UTF8SMTP and downgraded versions of 
> each message, and choose which to send based on the capability of 
> the MTA identified by each recipient's MX record.

That would require a very close coordination between the list agent 
and the MTA/MSA that is beyond what is normally expected.

>  Many of those points are made in the present draft, but not 
> necessarily broken down according to the particular kind of mailing 
> list. It may indeed be quite sensible to open existing mailing 
> lists to UTF8 subscribers even though message content is still to 
> be in ASCii-English. And also to admit UT8FSMTP messages to lists 
> which still require ASCII-only subscriptions.

I'm not sure about this last point.  Why accept UTF8SMTP messages to 
a list which has only ASCII-address subscribers?

>  4 Mailing List Header Fields
>
>  Please can someone who understands the subtle difference tell us 
> whether we should now be referring to "URI"s rather than "URL"s.
>
>      By and large, the data contained in these mailing list header fields
>      are URLs which often contain email addresses.  The same mechanism
>      should be used for these fields as with other fields specifically
>      discussed in the UTF8-Headers document [EAI-UTF8Headers].  Generally
>      therefore, for fields that contain an internationalized email
>      address, it could be expressed as a UTF8 string.
>
>  Leaving alt-addresses aside for the moment, how does this differ 
> from just using IRIs instead of URIs in these fields? In any case, 
> it is an extension to the syntax of these fields as defined in RFCs 
> 2369 and 2919, with a downgrade provision either here or in our 
> downgrade draft, so it would be as easy to extend by allowing IRIs 
> as by making special allowances for UTF8 addresses in mailtos. 
> Moreover, IRIs come with a nice downgrade to URIs already provided 
> by RFC 3987.
>
>      These fields might contain other URLs, such as HTTP.  In these
>      cases, there are no EAI-specific considerations, since these
>      non-mail-related URLs are out of scope for internationalized email
>      documents, and have been addressed elsewhere, such as RFC3987
>      "Internationalized Resource Identifier (IRI)" [RFC3987].
>
>  But it would be bizarre to provide different extension mechanisms 
> for mailto: URIs than for http: URIs. Much simpler to use IRIs for 
> both cases.
>
>      Because the email addresses are expressed as "mailto" URLs, further
>      specifications for presentation and inclusion of alt-addresses as
>      well as other considerations may be necessary, other than simply
>      following RFC3987 "Internationalized Resource Identifier (IRI)"
>      [RFC3987] specifications.  This will be further discussed in Section
>      6.
>
>  But this is the _real_ problem, and Section 6 does not really add 
> anything beyond what is said here. Essentially, what we need is an 
> extension to the mailto: for alt-addresses (whether it appears in a 
> URI or an IRI). And such an extension could well use our 
> "<utf8 at utf8<ascii at ascii>>" syntax.
>
>  The question is how to bring this about? Martin has declared 
> willingness to bring it into his new mailto draft at some stage 
> (and now we at least have an agreed notation for him to use). But I 
> don't think it would be a good idea to invent our own mechanism, 
> with its own downgrade, for use in the interim. Better to forego 
> the possibility of alt-addresses for the moment, with a NOTE to 
> explain that an extended mailto syntax is expected to be defined in 
> the near future. But, in fact, there is another way:
>
>  The alternative is to use two URIs or IRIs in those headers which 
> need it. RFC 2369 is not particularly well written, but if you 
> examine it closely you will see that comma-separated lists of URLs 
> are allowed. So one could have, for example:
>
>     List-Post: <utf8-submission at utf8>, <ascii-submission at ascii>
>
>  and RFC 2369 already tells you to examine them from left-to-right 
> and to use the first which you have the capability to use.

I'm concerned that many existing implementations of List-* headers 
wouldn't work in this case.  (Either they wouldn't handle multiple 
addresses, or if they did, they wouldn't handle UTF8 addresses.)

It might be safer to have new List-* header fields for EAI addresses.

So, an EAI list might include two sets of each List-* header, one for 
ASCII address using the existing List-* header names, and one for EAI 
addresses, using the new List8-* names.


>  6 Further Discussion
>
>  Much of this section seems to repeat what has been (or should be) 
> said in the earlier sections.
>
>      ...  Alternatively, it may be useful
>      to consider having a mechanism, such as an additional SMTP command,
>      for the receiving MTA (in this case the mailing list) to request the
>      alt- address.  This may be useful in other scenarios as well,
>      especially those concerning multiple recipients.
>
>  But if you want to invent new SMTP commands, then our smtp draft is 
> the place to do it.

Yes, this should be deleted.

>  7 IANA Considerations
>
>      None.
>
>  If you are going to extend the various List-* headers (whether by 
> allowing IRIs or any other way of admitting UTF8 into them), then 
> the IANA registry of header fields needs to be updated (RFC 3864).

Yes, thank you.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is no human problem which could not be solved if people would
simply do as I advise.                                -- Gore Vidal

_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima