Subject: [yam] I-D Action: draft-ietf-yam-rfc4409bis-01.txt

From: [email-masked]
Date: Mon, 25 Jul 2011 14:52:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Yet Another Mail Working Group of the IETF.

	Title           : Message Submission for Mail
	Author(s)       : Randall Gellens
                          John C Klensin
	Filename        : draft-ietf-yam-rfc4409bis-01.txt
	Pages           : 21
	Date            : 2011-07-25

   This memo splits message submission from message relay, allowing each
   service to operate according to its own rules (for security, policy,
   etc.), and specifies what actions are to be taken by a submission
   server.

   Message relay is unaffected, and continues to use SMTP [SMTP-MTA]
   over port 25.

   When conforming to this document, message submission uses the
   protocol specified here, normally over port 587.

   This separation of function offers a number of benefits, including
   the ability to apply specific security or policy requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-yam-rfc4409bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-yam-rfc4409bis-01.txt

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 26 Jul 2011 16:24:49 +0300

Should this document ask IANA to update registration of 587 port with 
reference to it?  There currently is nothing related to this in the IANA 
considerations section.  Mykyta

---

From: Chris Newman <[email-masked]>
Date: Tue, 26 Jul 2011 16:28:10 -0400

> 	Filename        : draft-ietf-yam-rfc4409bis-01.txt

I have reviewed this version of this document. My comments:

Section 1:

>   o  Provide a basis for adding enhanced submission services in the
>      future

Remove "in the future" as we have now added advanced submission services 
such as BURL and FUTURERELEASE. Informational references to those 
specifications would be helpful to implementers to show examples of 
enhanced submission services.

Section 5.3:

Great improvement, but...
I want to confirm implementers are OK with 2 minutes here -- it's rather 
slow from a user interface viewpoint. This may result in _increasing_ 
timeouts in SMTP client software. One web client I looked at has a 30 
second read timeout and a 10 second write timeout (applies to each 
send/receive).

Section 7, Table 1:

The wrapping of this table looks really bad. Please investigate ways to fix 
it. One ugly option would be to make it ASCII-ART and remove unnecessary 
spaces next to dividers. Changing the column name for the "Submission" 
column to a shorter word might also help.

Section 7, before last paragraph:

I suggest adding:

   [Start-TLS] is the most widely used mechanism at the time this is written
   that allows the MUA and MSA to protect message submission integrity and
   privacy.

Section 10:

Need to update port 587 registration as noted by others.

Otherwise, this looks great and I think is ready for advancement.

		- Chris

---

From: S Moonesamy <[email-masked]>
Date: Tue, 26 Jul 2011 21:49:49 -0700

Hi Chris,

Thanks for the review.

At 01:28 PM 7/26/2011, Chris Newman wrote:
>I want to confirm implementers are OK with 2 minutes here -- it's 
>rather slow from a user interface viewpoint. This may result in 
>_increasing_ timeouts in SMTP client software. One web client I 
>looked at has a 30 second read timeout and a 10 second write timeout 
>(applies to each send/receive).

There was some discussion about this during the IETF 81 YAM 
session.  John and Randy will propose some text for the above.

>Section 7, Table 1:
>
>The wrapping of this table looks really bad. Please investigate ways 
>to fix it. One ugly option would be to make it ASCII-ART and remove 
>unnecessary spaces next to dividers. Changing the column name for 
>the "Submission" column to a shorter word might also help.

This editorial change has been raised before.  Given that you are YAM 
guest co-chair, John Klensin and you can sort it out. :-)

Regards,
S. Moonesamy
YAM WG co-chair

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Jul 2011 12:09:16 -0400

Chris,

All changes made in -02 except as noted below...

--On Tuesday, 26 July, 2011 16:28 -0400 Chris Newman
<[email-masked]> wrote:

>...
> The wrapping of this table looks really bad. Please
> investigate ways to fix it. One ugly option would be to make
> it ASCII-ART and remove unnecessary spaces next to dividers.
> Changing the column name for the "Submission" column to a
> shorter word might also help.

Actually, it could probably be improved significantly by using
explicit column widths in the xml2rfc <texttable> element.  I
think I mentioned this in a earlier discussion of the draft, but
I've been reluctant to spend the time to do that, partially
because the RFC Editor is likely to reformat the thing to their
taste and to do so with a formatting tool rather than a generic
markup tool.  What I've now done is to insert an explicit and
visible request to the highly professional and expert RFC Editor
staff to work  on the table, replacing a comment that was in the
XML earlier.  I'm happy to work with them on formatting; I just
don't want to do the work twice and prefer that the experts do
it.

    john