Subject: Re: Last Call: <draft-ietf-yam-rfc4409bis-02.txt> (Message Submission for Mail) to Full Standard

From: Tony Hansen <[email-masked]>
Date: Fri, 12 Aug 2011 00:02:06 -0400

I support publication of this RFC.

     Tony Hansen
     [email-masked]

On 8/11/2011 9:37 AM, The IESG wrote:
> The IESG has received a request from the Yet Another Mail WG (yam) to
> consider the following document:
> - 'Message Submission for Mail'
>    <draft-ietf-yam-rfc4409bis-02.txt>  as a Full 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 2011-08-25. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Aug 2011 21:39:28 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Hansen
> Sent: Thursday, August 11, 2011 9:02 PM
> To: [email-masked]
> Subject: Re: Last Call: <draft-ietf-yam-rfc4409bis-02.txt> (Message Submission for Mail) to Full Standard
> 

+1, which is to say:

- I've read it
- I agree with what it says
- I can't find any reason not to move it to Full Standard
- Nice job all around

-MSK

---

From: SM <[email-masked]>
Date: Thu, 11 Aug 2011 23:29:59 -0700

>[email-masked] mailing lists by 2011-08-25. Exceptionally, comments may be

Please note that RFC 4956, RFC 5321 and RFC 5322 are documented as 
downward references. The protocols that they describe are 
widely-deployed, interoperable, stable, and successful, so the 
references are justified based on RFC 4897.

Although the downward references have not been explicitly called out 
in the Last Call announcement, the editors mentioned that in Appendix 
B of draft-ietf-yam-rfc4409bis-02.

Regards,
-sm

P.S. RFC 5322 is not a downward reference given that it is listed 
under Informational References.

---

From: Joseph Yee <[email-masked]>
Date: Fri, 12 Aug 2011 11:41:38 -0400

> - I can't find any reason not to move it to Full Standard

+1 here too, followed with details:

+ I read the latest revision
+ I agree with the content too, especially about converting character encoding (for EAI)
+ Nothing to against from the RFC
+ Support to move it to standard

Thanks
Joseph

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Fri, 12 Aug 2011 19:07:04 -0700 (PDT)

> I support publication of this RFC.

+1

				Ned

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 17 Aug 2011 19:21:11 +0300

My 2 pence:

I did finally manage to read the document and I support its 
publication.  The only minor comment:

>     The table in Table 1 has been corrected (reference for NO-SOLICITING)
>     and extended (ATRN, DELIVERBY, CONPEM, and CONNEG).  The registry
>     should be updated to reflect the changed and new entries.  Entries in
>     the registry that do not appear in the table above are correct and
>     should not be altered.

IANA commented that it should be clear that "the registry" refers to 
SMTP Service Extensions 
(http://www.iana.org/assignments/mail-parameters); but the registry 
there seems to have other format compared to Table 1:

>     +------------------+------------------+-----------+-----------------+
>     | Keyword          | Name             | Submissio | Reference       |
>     |                  |                  | n         |                 |

please compare with

> Keywords             Description                         Reference    Note

So how is this table going to be incorporated in the aforementioned 
registry?

<thinking off-topic="yes">There is the equivalence of English 
collocation "two pence" in Russian and Ukrainian, that are "pjat' 
kopeek" and "pjat' kopijok", respectively, and are translated as "five 
kopecks".  One kopeck is 1/100 of ruble or hryvnia; one penny is 1/100 
of pound; respectively one penny is nearly 13 Ukrainian kopecks and 
nearly 50 Russian kopecks.  So, when saying this in Ukrainian or 
Russian, I actually make a contribution which less that one said in 
English :-).</thinking>

Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 18 Aug 2011 18:14:38 +0300

18.08.2011 10:06, S Moonesamy wrote:
> Hi Mykyta,
> At 09:21 17-08-2011, Mykyta Yevstifeyev wrote:
>> SMTP Service
>> Extensions (http://www.iana.org/assignments/mail-parameters); but the 
>> registry there
>
> From the write-up:
>
> The entry in the SMTP Service Extensions registry for RFC 4409 should 
> be updated to reference this document. The reference for Submit (RFC 
> 2476) should be updated to point to this document. The registry should 
> be updated to reflect the changed and new entries in Section 7.
>
> "the registry" in the above should be read as "the SMTP Service 
> Extensions registry".
>
>> seems to have other format compared to Table 1:
>>
>>>     
>>>     |                  |                  | n         
>>> |                 |
> The following extract is from Section 7.1 of RFC 2476:
>
>    RFC   Name             Submission  Reference
>    ----  ---------------  ----------  ------------------
>    2197  Pipelining         SHOULD    [PIPELINING]
>    2034  Error Codes        SHOULD    [CODES-EXTENSION]
>    1985  ETRN              MUST NOT   [ETRN]
>
> This is from Section 7.1 of RFC 4409:
>
> Keyword        Name                        Submission  Reference
> ----------     --------------------------  ----------  ----------------
> PIPELINING     Pipelining                    SHOULD    [PIPELINING]
> ENHANCEDSTATUSCODES  Enhanced Status Codes   SHOULD    [CODES-EXTENSION]
> ETRN           Extended Turn                 MUST NOT  [ETRN]
>
> And finally from Section 7.1 of draft-ietf-yam-rfc4409bis-02:
>
>
>    | PIPELINING       | Pipelining       |   SHOULD  | [PIPELINING]    |
>    | ENHANCEDSTATUSCO | Enhanced Status  |   SHOULD  | [CODES-EXTENSIO |
>    | DES              | Codes            |           | N]              |
>    | ETRN             | Extended Turn    |  MUST NOT | [ETRN]          |
>
> The table has been in two previous RFCs.  It was not a problem then.

Neither RFC 2476 nor RFC 4409 asked IANA to make changes according to 
the contents of these tables; but this draft does.  4409 and its 
predecessor just mentioned which are eligible for use with submission.

Mykyta

> It should not be a problem now.  Section 10 of the draft mentions how 
> the table is going to be incorporated.  The document editors will 
> follow up on this editorial matter.
>
> Regards,
> S. Moonesamy
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 18 Aug 2011 00:06:21 -0700

Hi Mykyta,
At 09:21 17-08-2011, Mykyta Yevstifeyev wrote:
>Extensions (http://www.iana.org/assignments/mail-parameters); but 
>the registry there

 From the write-up:

The entry in the SMTP Service Extensions registry for RFC 4409 should 
be updated to reference this document. The reference for Submit (RFC 
2476) should be updated to point to this document. The registry 
should be updated to reflect the changed and new entries in Section 7.

>So how is this table going to be incorporated in the aforementioned registry?

The table has been in two previous RFCs.  It was not a problem 
then.  It should not be a problem now.  Section 10 of the draft 
mentions how the table is going to be incorporated.  The document 
editors will follow up on this editorial matter.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 18 Aug 2011 12:30:12 -0700

Hi Mykyta,
At 08:14 18-08-2011, Mykyta Yevstifeyev wrote:
>Neither RFC 2476 nor RFC 4409 asked IANA to make changes according 
>to the contents of these tables; but this draft does.  4409 and its 

I'll discuss this matter with the document editors at the end of the 
Last Call.  The working group will obviously be consulted about the 
matter.  I'll copy the message to you.

As a personal comment, it would be a bad idea for me to raise this as 
a serious concern.  The document editors would yell at me; the 
working group would petition the Area Director to fire me. :-)  In 
the IETF, everyone will tell that you have the right to view this as 
a serious concern.  What they won't tell you is that it is also a way 
to squander your goodwill.

Regards,
S. Moonesamy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Aug 2011 18:49:35 +0100

>- I can't find any reason not to move it to Full Standard
Well said, so +1 for all of the above.

One pedantic nit:

8.4.  Transfer Encode

   The MSA MAY apply transfer encoding to the message according to MIME
   conventions, if needed and not harmful to the MIME type.

Shouldn't this be "media type"?

---

From: Chris Newman <[email-masked]>
Date: Wed, 24 Aug 2011 15:20:49 -0700

>   <draft-ietf-yam-rfc4409bis-02.txt> as a Full Standard

I have read this draft and support advancing it to Full Standard as written 
or with modifications suggested by others.

My comment on issues raised:

Russ Housley's discuss:

The document is more helpful to implementers if it has an informational 
downward reference to deployed signing technologies such as DKIM and 
multipart/signed (RFC 2480, RFC 1847) so that implementers know to consider 
the impact of message modification on those technologies. Normative 
language on that topic is best avoided so the document would be improved by 
removing the "SHOULD" related to those technologies.

I believe the alternative text that was proposed is fine, but I would also 
be fine with the current text and also with dropping the offending 
paragraph if necessary to advance the specification.

Informative reference to RFC 6186:

As much as I like 6186 and hope it deploys, there is not sufficient 
deployment today to justify a reference from a full standard.

Informative reference to RFC 5068 / BCP 134:

I think an informative reference would be helpful to readers, but if adding 
that reference would cause an approval delay then expedience is more 
important.

SMTP AUTH / STARTTLS:

I have seen SMTP AUTH and STARTTLS work well operationally between multiple 
independent implementations of submission. Problems with those technologies 
related to MTA relay are unrelated to this submission draft and thus need 
no additional text in this draft.

		- Chris