Re: [EAI] Last Call: <draft-ietf-eai-frmwrk-4952bis-07.txt> (Overview and Framework for Internationalized Email) to Proposed Standard

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

Hi.

I'm going to reply to parts of this note in different roles, and
have tried to identify them clearly...

--On Wednesday, September 01, 2010 21:15 +0200 Julien ÉLIE
<[e-mail]> wrote:

> Hi all,
> 
>> The IESG has received a request from the Email Address
>> Internationalization WG (eai) to consider the following
>> document: - 'Overview and Framework for Internationalized
>> Email' <draft-ietf-eai-frmwrk-4952bis-07.txt> as a Proposed
>>  Standard
> 
> Thanks for the document, which I find to be very interesting.

<editor>
First, we've pleaded with the WG and those following this work
to get comments in early and there have been repeated messages
about the schedule.  Comments of this They are much more easily
accommodated if they arrive in a timely fashion, before IETF
Last Call begins.   I mention this, less because of this
document but because the WG Charter claims that three more
documents will be entering this last phase within the month --
please review them and get comments in early.

> Here are a few editorial remarks, as I read it:
> 
> * I read in the Abstract, in Section 1 and in Section 15 that
> "This document is an update of RFC 4952".  Shouldn't it be
> better
> to say that this document obsoletes RFC 4952?  (especially in
> the Abstract)

Certainly that change would not be harmful although I'd content
that the current text is correct -- conceptually, it does update
4952.  But note that the first page header indicates "obsoletes
4952", so there is no ambiguity.


> * I do not fint it easy to read lists of RFC references.  For
> instance:
> 
>    A prior
>    version of this specification, RFC 4952 [RFC4952], also
> provided an
>    introduction to a series of experimental protocols [RFC5335]
>    [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825].
> 
> Shouldn't commas be added between these references?

I don't find these easy to read either.  Unlike many documents,
this one (following the model of the IDNA2008 RFCs) makes those
referenced RFCs real references when possible without making the
sentences too convoluted.  But the real problem is that almost
every style manual that permits this type of reference at all
recommends that multiple references be in the
much-easier-to-read form "[RFC5335,RFC5336,RFC5337,RFC5504,...]"
(with or without spaces after the commas).  The xml2rfc tool
does not permit that layout and I've had mixed success trying to
sort it out with the RFC Editor.   Commas between the
references, e.g., "[RFC5335], [RFC5336], [RFC5337],..." would
simply be wrong because, especially given the RFC Series history
of treating references as objects, it would turn the sentence
into  a list of references that aren't attached to anything
rather than a list of references for "experimental protocols".
So I don't think I can do anything else about this right now
(unless you and others believe that citations like "[1] [2]
[3]..." would be preferable -- a change that is easily made),
although I promise to try again to get the RFC Editor to convert
it to a more acceptable form on final editing.

>    This document, and others that comprise the collection
> described
>    above, assume a reasonable familiarity with the basic
> Internet
>    electronic mail specifications and terminology
> [RFC5321][RFC5322] and
>    the MIME [RFC2045] and 8BITMIME [RFC1652] ones as well.
> While not
>    strictly required to implement this specification, a general
>    familiarity with the terminology and functions of IDNA
>    [RFC5890][RFC5891] [RFC5892][RFC5893] [RFC5894] are also
> assumed.
> 
> Aren't a few spaces missing between the references?  (+ commas)

Well, this is another version of the same problem.  There is a
case to be made that 
   [RFC5890][RFC5891][RFC5892]...
is easier to read, closer to the 
   [RFC5890,RFC5891,RFC5892]...
format, etc., than the form with the spaces, but this is hard to
do with the tool and something I prefer to leave to the RFC
Editor to sort out.

> * Section 6
>    that turned out to not be the case
> 
> Isn't "that turned out not to be the case" better?

The meaning is slightly different.  Opinions from others would
be welcome.

> * Section 7.2
>    For
>    transition purposes and compatibility with legacy systems,
> this can
>    done by extending the traditional MIME encoding models for
> non-ASCII
>    characters in headers [RFC2045] [RFC2231].
> 
> I think "be" is missing at the end of the second line.

Yes.  Will be fixed.

> * I read in Section 8 "Submission server" with an uppercase
> letter, but
> "submission server" in Sections 8.1 and 9 with a lowercase
> letter.
> Shouldn't it be homogenized?

yes, probably.


> * Section 11.3
>    While extensions to both
>    POP3 [RFC1939] and IMAP [RFC3501] have been defined that
> include
>    automatic upgrading of messages that carry non-ASCII
> information in
>    encoded form -- including RFC 2047 decoding -- of messages
> by the
>    POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server,
 
> I think "have defined" is the right wording at the second
> line, isn't it?

I don't think so.  "Have defined" would imply that the POP3 and
IMAP specified those extensions and would make the sentence very
confused.  The extensions have been defined by the subsequent
documents and that is exactly what is said.  The sentence could
certainly be improved but rewriting it, but this is one of the
examples I was specifically referring to above: rewriting the
sentence involves the risk of inadvertent changes and other side
effects.  It would be a lot safer if the suggestion had been
made prior to the careful and in-depth reviews by members of the
WG.

At this stage, while we will clearly do whatever the WG and ADs
tell us to do, I'm reluctant to substitute new sentences for
existing ones that are actually correct.

> * Section 14
>    Expecting and most or all
>    such transformations prior to final delivery be done by
> systems that
>    are presumed to be under the administrative control of the
> sending
>    user ameliorates the potential problem somewhat as compared
> to what
>    it would be if the relationships were changed in transit.
> 
> Isn't it "Expecting that most or all [...]"?

Yes.

</editor>
>...

> * In section 11 about additional issues, would it be
> worthwhile adding
> a paragraph about Netnews gatewaying?
> With a reference to Section 3.10.2 of RFC 5537, where it is
> for instance written:
> 
>    News articles prepared by gateways MUST be valid news
> proto-articles
>    (see Section 3.4.1).  This often requires the gateway to
> synthesize a
>    conforming article from non-conforming input.  The gateway
> MUST then
>    pass the article to an injecting agent, not directly to a
> relaying
>    agent.
>...

<WG-Co-chair>
Sorry.  The time to put "deal with netnews issues" on the WG's
agenda was when the charter was being redone.  That wasn't done
and it is now, IMO, too late.  If you don't like that procedural
answer, you have the right of appeal to the AD (and, if
necessary, beyond) as outlined in RFC 2026 but I note that any
such appeal would considerably delay the WG's getting its work
out.  I recommend you also read the comments below before
deciding whether to pursue this.

I also note that the WG barely has enough people with in-depth
experience with email to properly review the changes it is
making from an Internet email standpoint.  There is far less
depth in the netnews area, so, if we were to move down this
path, we would have an issue as  to whether there was adequate
informed consensus about any topics that might have bearing on
netnews, or even whether a specific topic might have such
bearing.
</WG-Co-Chair>

<Personal-observation>
This observation is based on a very long and painful history,
both personally and for the IETF.

Efforts to make comments about netnews in email documents have a
long history in which we end up spending a lot of time trying to
be sure that the comments are correct, that we don't end up with
references that send readers and/or specifications around in
loops, etc.  They also lead, directly or indirectly, to disputes
about which of the two sets of protocols is primary with the
other needing adjustment to match.  Those discussions almost
always reach the conclusion that netnews specifications should
reference email ones but not vice versa.  And we have often
gotten things wrong when we've made exceptions.

The observation that your comments in the paragraphs below go
much more deeply into the netnews situation than the WG
permitted us to go for email (e.g., about the nature of signed
messages and its relationship to still other protocols) strongly
reinforces the view that we should not discuss the netnews
environment at all, much less do so with the expectation that we
could quickly reach agreement about acceptable text.

>       NOTE: Message identifiers play a central role in the
> prevention of
>       duplicates, and their correct use by gateways will do
> much to
>       prevent loops.  Netnews does, however, require that
> message
>       identifiers be unique, and therefore message identifiers
> from
>       other media may not be suitable for use without
> modification.  A
>       balance must be struck by the gateway between preserving
>       information used to prevent loops and generating unique
> message
>       identifiers.
> 
>    An incoming gateway MUST add a Sender header field to the
> news
>    article it forms by containing the <mailbox> of the
> administrator of
>    the gateway.  Problems with the gateway may be reported to
> this
>    <mailbox>.  The <display-name> portion of this <mailbox>
> SHOULD
>    indicate that the entity responsible for injection of the
> message is
>    a gateway.  If the original message already had a Sender
> header
>    field, it SHOULD be renamed to Original-Sender so that its
> contents
>    can be preserved.

Then we get to...

> Addresses in Netnews are still derived from RFC 5322
> (according to
> Section 3.1.2 of RFC 5536) and only allow ASCII characters.
> And other header fields are expected to be MIME-encoded.  No
> direct UTF-8.

To the extent to which this is the case, the EAI effort has
absolutely nothing to say about netnews except as an extended
aside... one about which I believe we would have trouble getting
and demonstrating informed consensus.  We've needed to be very
careful to not make statements about what legacy systems that do
not explicitly support EAI are supposed to do.  That comment,
and some of your others, seem to bring netnews quite explicitly
under that umbrella.
 
> News articles can also be PGP-signed (for control articles,
> moderated
> newsgroups, de-spamming bots, etc.) so it is still not
> advisable to
> use an i18n mail address in a From:, Sender: or Approved:
> header field
> for instance...
 
> (I hope that one day we will have UTF-8 newsgroup names and
> that
> we will be able to send mails to an i18n email address that
> will be
> posted (by gatewing) to an i18n newsgroup.)

I actually do too.  But the way to get there from here, IMO, is
to let the EAI WG finish its work on email and then to spin up a
Netnews I18n effort that addresses the above issues including
UTF-8 newsgroup names.  In the interim, I'd personally favor an
effort to get an informational document together that tried to
explain the implications to netnews of lots if i18n email
floating around.  But I don't think it should be a work item for
this WG, especially if we retain the goal of getting the core
specs out quickly, at least in the near term.

</Personal-observation>

best,
   john