Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Feb 2009 21:07:04 +0000

The IESG wrote:

>The IESG has received a request from an individual submitter to consider 
>the following document:
>
>- 'Internet Mail Architecture '
>   <draft-crocker-email-arch-11.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[email-masked] mailing lists by 2009-03-26. Exceptionally, 
>comments may be sent to [email-masked] instead. In either case, please 
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt
>  
>
I've reviewed the latest version and it addresses my earlier comments 
I've sent to Dave Crocker privately.

I think it is an important document and it is long overdue for 
publication. While I can see people asking for improvements forever, I 
think it is important to publish a snapshot ASAP.

---

From: [email-masked]
Date: Thu, 26 Feb 2009 13:33:31 -0800 (PST)

> think it is important to publish a snapshot ASAP.

+1

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Fri, 27 Feb 2009 00:28:57 -0500

The IESG wrote:
> The IESG has received a request from an individual submitter to
> consider the following document:
>

+1 for publication.

Should it be using RFC5321/RFC5322 instead of RFC2821/RFC2822, such as
RFC5322.From instead of RFC2822.From?

A couple nits for AUTH48:

<   service.  Examples are voicemail over email "[RFC3801], EDI over
>   service.  Examples are voicemail over email [RFC3801], EDI over

<   Receiver role (Section 2.2.4)correlates with the Recipient role.
>   Receiver role (Section 2.2.4) correlates with the Recipient role.

I'm not sure what is meant by the <<>> portion here:
   Originator<<initial def>> .  This Return handling address (also known

	Tony Hansen
	[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 26 Feb 2009 21:56:41 -0800

> RFC5322.From instead of RFC2822.From?

yes.

current draft came out just before the latest RFCs were published.

final publication will be revised (and nits fixed -- thanks for the close read.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Eric Burger <[email-masked]>
Date: Thu, 26 Feb 2009 20:20:54 -0500

More than a +1: it is about time we got this out. For example, we  
would like to reference a document like this in the LEMONADE series of  
documents.

That said, this particular document is well written, gets the point  
across, and does the job nicely.

Of course, we could hold up publication for another three months, just  
so it can be an even five years since Dave submitted -00 :-(((((

On Feb 26, 2009, at 4:06 PM, Eliot Lear wrote:

> Lisa,
>
> I think this document is fairly well written, and I would support  
> its publication.
>
> Eliot
>
> On 2/26/09 9:59 PM, Lisa Dusseault wrote:
>> FYI
>>
>> ---------- Forwarded message ----------
>> From: The IESG<[email-masked]>
>> Date: Thu, Feb 26, 2009 at 10:10 AM
>> Subject: Last Call: draft-crocker-email-arch (Internet Mail
>> Architecture)  to Proposed Standard
>> To: IETF-Announce<[email-masked]>
>>
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11811&rfc_flag=0
>>
>> The following IPR Declarations may be related to this I-D:
>>
>>
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> _______________________________________________
>> Apps-Discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>>
>
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Feb 2009 19:36:03 -0500

Since this is a substantive comment on a document that is in
Last Call for Standards Track, I'm posting the note to the IETF
list.  Since I use different addresses for the SMTP list and the
IETF one, I don't know when or if this will appear on the latter.

With the exception of the last point, this note addresses
Section 6.3 of this document (on Internationalization)
exclusively.  I will post another note before the cutoff to
address other issues.

--On Friday, February 27, 2009 15:49 -0700 "J.D. Falk"
<[email-masked]> wrote:

> Dave CROCKER wrote:
> 
>> Just to make this explicit, SM's note is to the rest of you,
>> not to me. I asked him to solicit comments from the group,
>> since I have only tried to make the document parrot what I8N
>> folk say. My own comprehension of the topic remains muddled.
> 
> Mine is similarly muddled, but I wonder...is it appropriate to
> reference a recent (and presumably temporary) experiment
> alongside documenting the current state of the art?
> Particularly when email-arch is unlikely to be updated for
> another five years?

Well, while my comprehension may be equally muddled, it isn't
for lack of trying and involvement.

A few observations:

(1) The use of international (non-ASCII) characters in message
bodies and content has been a done deal since MIME came in.
That should probably be said explicitly.  If we were redoing
that work today, we would probably strongly recommend the use of
UTF-8, rather than alternate encodings, and might require a
charset parameter on all instances of text/plain.   But no WG
has ever been willing to move on either of those two points.

(2) Given the requirement for an Internationalization
Considerations section, which this document honors with Section
6.3, handing the substance of that section off to an
non-consensus document (IMC's Mail-I18N) in what is clearly a
normative reference despite being listed as an informative one
(the previous sentence has essentially no content other than to
indicate that i18n is an "ongoing challenge") seems dubious and
probably inappropriate.

(3) There are some useful things that can be said that are, at
this point, settled parts of the architecture or at of least the
relevant protocols.  As suggested above, one is that the content
matter is settled and that UTF-8 is the winner in the character
set wars (although other things are certainly around).  Another
is that work on i18n of email headers and addresses is
progressing, but that, until that work completes, IDNs can be
expressed in ACE form (with appropriate references).  I would
personally avoid making anything resembling a normative
reference to the experimental documents, largely because they
introduce more new syntax and terminology that would then need
to be discussed.

(4) It is a nit, but "Because its origins date back to the use
of ASCII" leaves an impression that is not strictly correct.  It
would be accurate to say that its origins date back to the time
when even the use of ASCII was controversial.  However, the
origins have nothing to do with anything: the email architecture
of today is defined in ASCII terms.  RFCs 5321, 5322, and 2045ff
are written in ASCII terms and require ASCII (except in
body-part content) as are most of the other protocols
referenced.  It would be far more accurate to simply say that we
have an ASCII-based protocol suite that is gradually being
adapted to accommodate non-ASCII elements where those are
appropriate, with the current thread and model starting with the
introduction of text/ content-types in MIME.
 
(5) The document needs to be updated to reflect current
references.  In particular, RFCs 5321 and 5322 were published
almost six months ago.  They also contain some slight
adjustments to terminology and this document should be carefully
checked to be sure its terminology is still consistent with them.

regards,
     john

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 27 Feb 2009 16:50:33 -0800

John,

With respect to character set, internationalization, and the like, I cannot tell 
what text changes you propose for the document.  The current text was developed 
through community discussion.  What specific changes are you proposing?

s/old/new/ form, or a multiline equivalent, would be most helpful.

I suggest that the bulk of any changes really does need to refer to community 
consensus documents, rather than trying to summarize the topic.

d/

> A few observations:
...

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Feb 2009 20:30:03 -0500

--On Friday, February 27, 2009 16:50 -0800 Dave CROCKER
<[email-masked]> wrote:

> John,
> 
> With respect to character set, internationalization, and the
> like, I cannot tell what text changes you propose for the
> document.  The current text was developed through community
> discussion.

>  What specific changes are you proposing?
> 
> I suggest that the bulk of any changes really does need to
> refer to community consensus documents, rather than trying to
> summarize the topic.

Actually, Dave, I can remember no community discussion of the
Internationalization section of this document.   And while I
tend to agree with you about reference to community consensus
documents, that section does not reference one.  Instead, it
references (given how little text is in the Internationalization
section, "incorporates by reference" might be more accurate) a
somewhat-outdated private consortium document that has never had
anything resembling formal IETF review.

While this document has been kicking around the community for
quite a while and gotten comments and input from far more people
than are listed in the Acknowledgements, it is an individual
submission for the standards track, not a WG product subsequent
to a IETF-approved charter.   If the IESG is consistent with the
criteria it has applied to a large number of other individual
submission documents in the last year or so, the question is "is
it ready" rather than "can the author insist that IETF
participants put other work aside to do a sufficiently close
review of a 49 page document to suggest alternate text that is
consistent with other text in the document".  

I've demonstrated (and will demonstrate further below) that at
least this one section is not ready and have suggested what is
needed to fix it -- describe the current internationalization
status in sufficient detail to either eliminate the need to
reference "[MAIL-I18N]" or to reduce it to a clearly
informative, "additional reading" reference.   

An alternative, if you could get the IESG to agree to it, would
be to say, somehow, "the Internet's email system is mostly ASCII
although various changes have been made and are being made to
accommodate non-ASCII strings in appropriate contexts;
internationalization is not further discussed in this document".
Personally, I would object less to your saying nothing (or to
saying the above, which is equivalent) than to your hand waving
and then pointing off to a decade old non-consensus document
that is outdated in several areas.   But, while it is a pity to
hold the architecture document up because of [MAIL-I18N], if
that document represents what you have to say architecturally
about i18n issues, then it is normative and your document isn't
ready to go until it is... or until the reference to it can be
eliminated.  

For example, [MAIL-I18N] points to RFC 2279, which has been
obsolete for more than five years due to a definitional change,
for an authoritative definition of UTF-8.  It also points to and
recommends Unicode TR 7 for inline language tagging.  That
document was withdrawn years ago, the link given in [MAIL-I18N]
no longer works, and the material that supercedes it (Section
16.9 of TUS 5.0 for an accessible reference) has, as its second
sentence, "The use of these characters is strongly discouraged".
That rather clear statement is followed by a discussion of
alternatives (e.g., XML or HTML) and conditions under which the
tags might be appropriate, none of which obviously apply to
Internet mail.

Several of its other references, to both IETF and non-IETF
documents, are obsolete as well.

    john

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Feb 2009 18:37:24 -0800

At 8:30 PM -0500 2/27/09, John C Klensin wrote:
>Instead, it

+1. I am slowly going through draft-crocker-email-arch, but when I saw John bring this up, I thought it had to be a mistake.

I haven't touched the reference in question in over a decade. (There is no URL for the document in the draft, but it can be found at <http://www.imc.org/mail-i18n.html>.) For those of you checking your chronometers, that means it predates IDNs, much less EAI.

It should not be referenced in a modern architecture document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 27 Feb 2009 18:52:11 -0800

>>  What specific changes are you proposing?

Really, John, whatever folks agree on is more than fine with me.  However, I 
also note that some other experienced IETFers have indicated that they consider 
it acceptable to leave the text as-is.

Please note that besides the terse Section 6.3, the document does duly cite RFC 
2045 and RFC 2047, for body and "header extensions", in Section 4.1.

My own sense of why the current I8N section is so sparse is because the 
additional capabilities have yet to be all that well established into the 
service, except for very narrow (albeit useful) exceptions.  Since the document 
seeks to describe what is standardized as accepted practice, that leaves a bit 
of a hole for I8N details.

The incorporation-by-reference done in the draft is an attempt to limit the 
document's being drawn into a topic that seems to be email's third rail.  Since 
you feel strongly about the document's failings in this regard and since you 
happen to be a tad more knowledgeable about the topic than I (or most others), 
what do you want included, *specifically*?

> Internationalization section of this document.  

   <http://www.imc.org/ietf-smtp/mail-archive/msg04377.html>

> than are listed in the Acknowledgements, it is an individual

I've variously done two or three detailed audits, to find and list the name of 
every person who made posted a substantive note about any of the email-arch 
drafts.  This of course does not mean that I found everyone who should be 
listed. I know there are many others who have looked at the document, but if you 
know of any contributors who are missing from the section, please let me know.

>    the question is "is

First, "is it ready" sounds like exactly the question that folks responding to 
the Last Call have been answering.

Second, in your own case this document is not exactly being sprung on you 
without notice.  It's been circulated in the ietf-smtp mailing list with 11 
revisions over 5 years, including 2 or 3 (or maybe even) four postings that 
characterized themselves as "pseudo Last Call".  And as cited above, there was 
an explicit request for discussion about internationalization last March on that 
list.  And many of those people cited in the Acknowledgments section performed 
detailed reviews.

Since shyness is not one of my failings, you know that anyone with an interest 
in email technology and standards has had this document intrude on their screen 
more than once over the last five years -- and I don't mean just folk within the 
IETF sphere.  So it doesn't make sense that you would suggest that there is 
somehow some sudden demand for review by folks within the email community.

> least this one section is not ready and have suggested what is

Now all you have to do is to convince those other folk who feel that the current 
text in the section is sufficient.

Personally, I suspect you'll have an easier time of it if you suggest specific 
text.  (As for making the text "consistent with other text in the document" I'd 
be glad to perform that task, given any rough approximation that folks like.)

> internationalization is not further discussed in this document".

Well that is, indeed, specific text.

Are you suggesting it replace the existing Section 6.3 text?

Are you seeking support for that replacement from others on the list?

> obsolete for more than five years due to a definitional change,

What is the superior reference you suggest be used?

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Sat, 28 Feb 2009 00:51:22 -0500

Dave,

I don't think much can be accomplished by an extended debate
about our respective points.   I've injected my comments into
the Last Call bin, you have injected yours.  As both of us have
pointed out on many other occasions, this is not about seeing
how many endorsers one can get.

You will probably like some of my more general comments on the
document even less.   Please at least acknowledge that I am
entitled to have those opinions.

--On Friday, February 27, 2009 18:52 -0800 Dave CROCKER
<[email-masked]> wrote:

>...
> Personally, I suspect you'll have an easier time of it if you
> suggest specific text.  (As for making the text "consistent
> with other text in the document" I'd be glad to perform that
> task, given any rough approximation that folks like.)

That is a reasonable proposed compromise.  I am still concerned
that elements of this may be controversial enough that a WG
process is really required.   Most of those issues have been
aired before, especially vis-a-vis terminology that carries
highly loaded semantics with it, semantics are are particularly
sensitive given various efforts to establish mechanisms for
email sender authentication or authorization.  I will explain
that further in another note, but they are issues that have been
raised before.

>> An alternative, if you could get the IESG to agree to it,
>> would be to say, somehow, "the Internet's email system is
>> mostly ASCII although various changes have been made and are
>> being made to accommodate non-ASCII strings in appropriate
>> contexts; internationalization is not further discussed in
>> this document".
> 

What I'm suggesting is that you need to do one of two things:

(i) Get community consensus and IESG agreement to explicitly
blow off the internationalization issues.  I can personally live
with that as long as it is done explicitly, either with a "just
not discussed here" statement like the one above or with a
forward pointer to a document that may never be written.   I
note that either one would violate a BCP and some explicit
policy statements but that procedural issue is a separate
problem.

(ii) Write something real for Section 6.3 and put it there.
That might start with a trimming and reworking of the IMC
document (see Paul's "should not be referenced in a modern
architecture document" comment -- one of the few I18N-related
areas in which the two of us are in agreement).  Much of the
material there is good.  Some can just be left out.  The
references need to be updated and some of the text needs
reconsideration in the light of things that have happened in the
last decade.  I would volunteer to work with you and/or Paul on
the rewrite, but I really have to devote all of my
internationalization cycles right now to the IDNABIS WG.
However, if a revised version of that text were folded into the
architecture document and included in a Last Call, that would
obviously satisfy my concern about a normative reference to a
non-consensus document.

> Are you seeking support for that replacement from others on

No.  I am asserting my belief that, without one of the choices
above, the document is incomplete and not ready for prime time.
I am completely agnostic about which choice is made although I
believe that the requirements for a meaningful
internationalization session are more comfortably waived for an
informational document than for a standards track one.

> What is the superior reference you suggest be used?

A quick glance at the rfc-index, or faking an I-D format for
[MAIL-I18N] and pushing it through the reference checker, will
quickly point you to RFC 3629, a full Internet Standard.
Depending on what else is being said, an additional reference to
RFC 5198 might also be relevant.   But note that these are
references out of [MAIL-I18N] and not the architecture document
itself.  They are irrelevant if you adopt the first option above
and would probably fall out fairly automatically in any
extraction of text from, and revision of [MAIL-I18N] for
incorporation into the architecture document as suggested in
(ii).

      john