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

From: SM <[email-masked]>
Date: Sat, 26 Jun 2010 15:38:01 -0700

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.

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?

   "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?

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?

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

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Jun 2010 19:17:29 -0400

--On Saturday, June 26, 2010 15:38 -0700 SM <[email-masked]>
wrote:

>...

I have asked that we defer the discussion of what keyword to
choose until near the end of our process.  If we need to review
the reasons why a change is needed, that is open for discussion
now.  But, if we are to change it, I believe we should do a late
binding on that decision (which affects Framework as well as
SMTP).  There are two reasons:

(1) We could waste a lot of time on this now, only to almost
certainly have to revisit it later as someone shows up with a
better idea.

(2) Doing a late binding on the keyword will considerably lower
the odds that someone will implement to what they think we are
going to do, develop something that doesn't interoperate, but
still use the same keyword because they knew (at least) what
that was going to be.

>...

For these and others, let's make sure we remember (the Nits
checker will presumably do that for us, but not actually make
changes until it is absolutely, 100%, clear that 1652bis will be
published.  In particular note that, while it is in the RFC
Editor queue, it is stuck in MISSREF waiting on 5321bis and
5322bis, for neither of which there is even an active I-D yet (I
expect that will be cured for one or both before IETF 78, but
one should not count on that until it happens).  Also note that
if the IESG, in its wisdom, approves
draft-housley-two-maturity-levels in the next month or two, the
YAM WG enters the "overtaken by events" stage and 5321bis and
5322bis (and probably even the supposedly-approved 1652bis)
become more effort than they are worth to finish.  Having the
distinction of being the last full standards approved by the
IETF under a set of rules that are being phased out does not
seem to me to be likely to be treated by the responsible editors
as worth the trouble.  That is, of course, just my opinion.
 
>...
> RFC 5336 registered the UTF8SMTP keyword.  There should be a
> note in the IANA Considerations Section to deprecate it.

Yes.

best,
    john

---

From: SM <[email-masked]>
Date: Sat, 26 Jun 2010 17:54:01 -0700

Hi John,
>choose until near the end of our process.  If we need to review

Sorry about that. I read your message and forgot about that when I 
wrote the comments.

>still use the same keyword because they knew (at least) what

Agreed.

>as worth the trouble.  That is, of course, just my opinion.

I don't know what will happen to the maturity levels.  The MISSREF 
could be cleared.  The safe bet is to go with your approach.

I read draft-ietf-eai-frmwrk-4952bis-00.  Section 11 is a good piece of work.

Regards,
-sm