Subject: Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 28 Jun 2010 16:32:10 +0800

----- Original Message ----- 
From: "SM" <[email-masked]>
To: <[email-masked]>
Cc: "Jiankang YAO" <[email-masked]>; "Wei MAO" <[email-masked]>
Sent: Sunday, June 27, 2010 6:38 AM
Subject: Comments on draft-ietf-eai-rfc5336bis-00

> Hello,
> 
> I have a few comments about draft-ietf-eai-rfc5336bis-00.  I'm 
> posting them to EAI to get the discussion started.
> 
> Please change the Updates and references to RFC 5321 and RFC 5322.
> 
> In Section 3.1:
> 
>    'The EHLO keyword value associated with this extension is
>    "UTF8SMTPbis".'
> 
> I suggest dropping the "bis" and choosing something like "UTF8".
> 
>   "Servers offering this extension MUST provide support for, and
>    announce, the 8BITMIME extension [RFC1652]"
> 
> Please update the reference for RFC1652 to draft-ietf-yam-rfc1652bis-03.
> 

if we change it to draft-ietf-yam-rfc1652bis-03, we must wait for that document.

> In Section 3.2:
> 
>   "If the original client submits a message to a Message Submission
>    Server ("MSA") [RFC4409], it is the responsibility of the MSA
>    that all domain labels are valid; otherwise, it is the original
>    client's responsibility."
> 
> Is the "original client" a SMTP Client or a MUA?

I propose to  change it to "MUA"

> 
>   "It may find an alternate route to the destination that permits
>    UTF8SMTPbis.  That route may be discovered by trying alternate
>    Mail eXchanger (MX) hosts (using preference rules as specified in
>    RFC 2821) or using other means available to the SMTP-sender."
> 
> What is the SMTP-sender?

I propose to  change it to "SMTP-client or MSA"

> 
> In Section 3.4:
> 
>   'When messages are rejected for other reasons, such as
>    the MAIL command requiring an ASCII address, the response code 550 is
>    used with the meaning "mailbox unavailable".'
> 
> Is this a policy decision?

yes

> 
> RFC 5336 registered the UTF8SMTP keyword.  There should be a note in 
> the IANA Considerations Section to deprecate it.
> 

+1

> Regards,
> -sm

---

From: SM <[email-masked]>
Date: Wed, 30 Jun 2010 13:42:58 -0700

Hi Jiankang,
>I propose to  change it to "MUA"

We may see the UTF8SMTP extension in two places, the MTA and the 
MSA.  The MSA can apply several fixes or checks to ensure that the 
message going through MTAs are well-formed.  I'll rewrite that 
sentence in Section 3.2 with the word "MUA":

   "If the MUA submits a message to a Message Submission Server
    ("MSA") [RFC4409], it is the responsibility of the MSA that
    all domain labels are valid; otherwise, it is the MUA's
    responsibility."

Do we assume that all messages are submitted through a MSA?  If so, 
we can push all responsibility to the MSA.  We then specify what 
changes or verification should be done at the MSA.

>I propose to  change it to "SMTP-client or MSA"

If I recall correctly, the discussion was about the case where we 
have two more MX hosts and not all of them supported the UTF8SMTP 
extension.  It should be SMTP Client instead of "SMTP-server".

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Wed, 30 Jun 2010 17:05:21 -0400

--On Wednesday, June 30, 2010 13:42 -0700 SM <[email-masked]>
wrote:

> We may see the UTF8SMTP extension in two places, the MTA and
> the MSA.  The MSA can apply several fixes or checks to ensure
> that the message going through MTAs are well-formed.  I'll
> rewrite that sentence in Section 3.2 with the word "MUA":
> 
> Do we assume that all messages are submitted through a MSA?
> If so, we can push all responsibility to the MSA.  We then
> specify what changes or verification should be done at the MSA.

We don't quite, but that can be worked around with a bit of hand
waving.  For example, putting a sentence indicating that we are
treating the first entity that supports an SMTP interface to a
full-service SMTP server as an MSA, and describing it in those
terms, even if it is fully integrated with the sending MUA,
would probably get us past that problem (that wording is almost
certainly not exactly right, but some variation on it would
probably work).

>...

    john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 01 Jul 2010 09:58:38 +0900

On 2010/07/01 5:42, SM wrote:
> I'll rewrite that sentence in
> Section 3.2 with the word "MUA":
>

Why: Message Submission Server ("MSA")
It would be easier to understand if it were
Message Submission Agent ("MSA") or
Message Submission Server ("MSS")

Regards,     Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Jiankang YAO" <[email-masked]>
Date: Thu, 1 Jul 2010 11:02:05 +0800

----- Original Message ----- 
From: ""Martin J. Dürst"" <[email-masked]>
To: "SM" <[email-masked]>
Cc: "Jiankang YAO" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 01, 2010 8:58 AM
Subject: Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00

> Message Submission Agent ("MSA") or

section 1 in RFC 4409 seems to support  Message Submission Agent

---

From: Yangwoo Ko <[email-masked]>
Date: Thu, 1 Jul 2010 14:06:09 +0900

> certainly not exactly right, but some variation on it would

Provided that MSA is defined as John suggested, do we still
need to mention MUA? I think that it is enough to say that

"MSA is responsible for the validity of all domain label."

MSA fulfills the responsibility by itself or by enforcing MUA
to do so on behalf of MSA. In either case, MSA is responsible.

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

-- 
a human / twitter as yangwooko / msn as [email-masked] / nate
as [email-masked]