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

["Charles Lindsey" <chl at clerew.man.ac.uk>]

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

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.

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

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.

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.

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.


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.


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.


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

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 ;                      
   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

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