Subject: [EAI] Question about AUTH48 text for 5336bis/ proto-RFC 6531

From: John C Klensin <[email-masked]>
Date: Tue, 07 Feb 2012 00:39:56 -0500

Hi.

We have encountered a small problem at AUTH48 with some text in
5336bis (RFC-to-be 6531).  The text in Section 3.2 of
draft-ietf-eai-rfc5336bis-16 (just before the numbered list)
reads:

	"Instead, if a UTF8SMTPbis-aware SMTP client
	"(UTF8SMTPbis-aware SMTP sender) attempts to transfer an
	internationalized message and encounters an SMTP server
	that does not support the extension, it MUST make one of
	the following three choices and the priority order is 1, 2
	and 3." 

The last part of that sentence was added in response to a Last
Call comment.  If there is a moral here, it is that folks
should be really careful with changes in response to even
seemingly-editorial comments made during Last Call.  In any
event, "the priority order is 1, 2 and 3" is ambiguous as to
whether the WG thinks choice 1 or choice 3 should come first.

But it is a little worse than that because, in trying to fix
this, we discovered that the phrasing of those three choices
may not have been quite right.  In particular, the third case
seemed to contradict a very carefully-worded exception case in
RFC 5321.

To be clear what we are talking about before I outline what I
think are the options and ask for a decision, the current
AUTH48 working text reads (please don't worry about spacing):

   ...Instead, if an SMTPUTF8-aware SMTP client
   (sender) attempts to transfer an internationalized message
   and encounters an SMTP server that does not support the
   extension, it MUST make one of the following three choices.
   These are listed in decreasing order of preference.

   1.  It MAY either reject the message during the SMTP
       transaction or
       accept the message and then generate and transmit a
       notification of non-deliverability.  Such notification
       MUST be done as specified in RFC 5321 [RFC5321], RFC
       3464 [RFC3464], and RFC 6533 [RFC6533].

   2.  If and only if the SMTPUTF8-aware SMTP client (sender)
      is a
       Message Submission Agent (MSA) [RFC6409] [RFC5598], it
       MAY choose its own way to deal with this scenario
       according to the provisions of RFC 6409 [RFC6409] or its
       future versions.  However, the detailed specification of
       this process and its results are outside the scope of
       this document.

   3.  It MAY find an alternate route to the destination that
       permits
       SMTPUTF8.  That route MAY be discovered by trying
       alternate Mail eXchanger (MX) hosts (using preference
       rules as specified in RFC 5321) or using other means
       available to the SMTPUTF8-aware SMTP client.

There was an earlier stage in which the text was the same, but
"increasing" was substituted for "decreasing".

With an adjustment for what RFC 5321 actually allows, Pete
summarized these three cases as: 

	1. It MAY reject the message.
	2. If and only if it's a submission server, it MAY
	   something of its own choosing. 
	3. It MAY try another MX.

	If we take RFC 5321 Section 2.2.3 into account, 3 can be
	expanded to "It MAY try another MX if it decides to do so
	based on the particular circumstances."

It is absolutely clear to us (myself, Joseph, and Pete) that
the WG intended to encourage letting submission servers fix up
messages if they knew how (case 2 above) and rejecting/bouncing
messages back to those servers so that they could fix things
(case 1 above).  The third case is certainly reasonable as long
as it makes clear, somehow, that the circumstances are
important.  Indeed, although it is a useful clarification that
RFC 5321 Section 2.2.3 may apply to this particular extension,
it actually adds nothing to what RFC 5321 would permit if this
document said nothing at all.

So we probably need to fix the text (and to spend as little
time as possible making a decision).  I think the following are
a complete list of options although, if someone has a better
idea, he or she should raise it.  I hope that the WG can reach
consensus by mid-week (please make comments quickly so the WG
has a chance to discuss them if needed or, if you need more
time, say so).  If there is no consensus on choice of text,
Joseph, Jiankang, Pete, and I will make a decision.  If we have
to make a decision, we will consider both preferences for
particular approaches and remarks along the line of "do
whatever you like as long as you don't pick option 99".  Note
that I'm not asking whether the WG still believes in correction
by submission servers, etc.: those issues are closed unless
someone comes up with a _really_ strong argument, presumably
strong enough to put all of this back into WG and IETF LC.  We
are only trying to figure how to most clearly and accurately
reflect the WG's existing conclusions in the document.

Note that whatever is chosen may still be fine-tuned
editorially.

These options are deliberately in no particular order:

A.  Drop case 3 entirely to be consistent with the model of
putting nothing in these specs that is really part of the base
protocol (RFC 5321 in this case) and then clean up the text.
Note that this drops one piece of information that is not in
the base protocol, i.e., the WG's belief that SMTPUTF8 is an
extension to which Section 2.2.3 might reasonably be applied.

   ...Instead, if an SMTPUTF8-aware SMTP client
   (sender) attempts to transfer an internationalized message
   and encounters an SMTP server that does not support the
   extension, it SHOULD make one of the following two choices.
   These are listed in decreasing order of preference.

   1.  It MAY either reject the message during the SMTP
       transaction or
       accept the message and then generate and transmit a
       notification of non-deliverability.  Such notification
       MUST be done as specified in RFC 5321 [RFC5321], RFC
       3464 [RFC3464], and RFC 6533 [RFC6533].

   2.  If and only if the SMTPUTF8-aware SMTP client (sender)
       is a
       Message Submission Agent (MSA) [RFC6409] [RFC5598], it
       MAY choose its own way to deal with this scenario
       according to the provisions of RFC 6409 [RFC6409] or its
       future versions.  However, the detailed specification of
       this process and its results are outside the scope of
       this document.

Note the change from MUST to SHOULD because there is another
choice (the MX searching of RFC 5321 Section 2.2.3) out there.
It could just be left alone on the theory that whatever 5321
says overrides whatever is said here.   Or we could explain the
SHOULD, but that takes us back to three cases and...

B.  We leave all three cases as above and come up with revised
text as needed to clarify both the order and fact that case 3
isn't to be used unless the client has the information
(presumably out of band) that permits it to conform to the key
requirement in RFC 5321 Section 2.2.3.  That requirement
(second paragraph of 2.2.3) starts:

   In particular, if an extension implies that the delivery
   path normally supports special features of that extension,
   and an intermediate SMTP system finds a next hop that does
   not support the required extension, it MAY choose, based on
   the specific extension and circumstances, to requeue the
   message and try later and/or try an alternate MX host.

Note that 2.2.3 goes on to impose additional requirements on
timeouts in that case.

C.  We conclude that the "preference" order doesn't actually
mean much in this case.  From that point of view, option 2
applies only if the client is a submission server, option 3
applies only if the client has special additional information
or circumstances (information or circumstances that presumably
could override either of the other preference), and option 1
applies otherwise.  If we then turn the wording around a bit,
we would get something like (borrowing text from the above
where possibe)...

   ...Instead, if an SMTPUTF8-aware SMTP client
   (sender) attempts to transfer an internationalized message
   and encounters an SMTP server that does not support the
   extension, the best action for it to take depends on other
   conditions.  In particular:

    o If it is a Message Submission Agent (MSA) [RFC6409]
      [RFC5598], it MAY choose its own way to deal with this
	  scenario using the wide discretion for changing addresses
	  or otherwise fixing up and transforming messages allowed
	  by RFC 6409. As long as the resulting message conforms
	  to the requirements of RFC 5321 (i.e., without the
	  SMTPUTF8 extension), the details of that transformation
	  are outside the scope of this document.  

    o Otherwise, it SHOULD reject the message.  As usual, this
      can be done either by generating an appropriate reply
	  during the SMTP transaction or by accepting the message
	  and then generating and transmit a non-delivery
	  notification.  If the latter choice is made, the
	  notification process MUST conform to the requirements of
	  RFC 5321 [RFC5321], RFC 3464 [RFC3464], and RFC 6533
	  [RFC6533]. 

    o As specified in RFC 5321 Section 2.2.3, an SMTP client
	  with additional information and/or knowledge of special
	  circumstances MAY choose to requeue the message and try
	  later and/or try an alternate MX host as specified in
	  that section.

D.  Just about the same thing could be done, in somewhat more
terse form, by saying something like:

	"If the client is a submission agent [RFC6409], it SHOULD,
	if possible, fix the message to be consistent with SMTP
	requirements (in the absence of this extension) and resend
	the transformed message.   If it cannot or is not a
	submission agent, it SHOULD reject or bounce the message
	to give the user an opportunity to make her own
	corrections.  Alternately, if the client has sufficient
	additional information to know that special circumstances
	exist, it MAY examine hosts specified in DNS MX records
	with equal or lower preferences as specified in RFC 5321
	Section 2.2.3."

That approach assumes that the NDN requirements are covered in
other standards and need not be repeated here.  Of course, they
could be listed if the WG prefers.

     john

---

From: Yangwoo Ko <[email-masked]>
Date: Tue, 7 Feb 2012 17:03:46 +0900

Considering relations between 5321 and EAI documents, I like either choice
A or choice C. Among A and C, C looks better because it explicitly reminds
relations between 5321 and EAI documents.

On Tue, Feb 7, 2012 at 2:39 PM, John C Klensin <[email-masked]> wrote:

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

-- 
a human known as [email-masked] @ gtalk <[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 7 Feb 2012 16:46:29 -0000

I also have a mild preference for option C.  Here's the possibilities,
do what works for you.  I do think we should mention trying another
MX, if only via a pointer to 5321.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Feb 2012 17:35:54 +0000

Hi John,

C or D work for me. B is acceptable. I dislike A.

---

From: Chris Newman <[email-masked]>
Date: Tue, 07 Feb 2012 09:50:22 -0800

I really like the wording in the third bullet of option C, so that's my 
mild preference as a result. All four options are acceptable to me, but I 
think the proposed text in option C will result in minimal time expenditure 
on this issue.

		- Chris

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Feb 2012 06:24:42 -0500

Hi.

Ok, everyone who has spoken up has either identified option C as
their first preference or as one of a set of more-or-less equal
preferences.  Some were concerned about "Otherwise".  I had used
it to avoid having to use several more words and am not sure I
really see the preference implication, but have changed it.

The following text is going to the RFC Editor and, subject to
editorial revisions by them or changes made by the ADs, will
appear in the document.  Based on a note from the RFC Editor
yesterday, this is the last outstanding issue for 5336bis/
proto-RFC 6531.

   ------------

    o If is not an MSA or is an MSA and does not choose to
	  transform the message the message to one that does not
	  require the SMTPUTF8 extension, it SHOULD reject the
	  message.  As usual, this can be done either by
	  generating an appropriate reply during the SMTP
	  transaction or by accepting the message and then
	  generating and transmit a non-delivery notification.  If
	  the latter choice is made, the notification process MUST
	  conform to the requirements of RFC 5321 [RFC5321], RFC
	  3464 [RFC3464], and RFC 6533 [RFC6533]. 

   ------------

A quick check on the RFC Editor's status pages indicates that
our current status is:

RFC-to-be   (was)        status
 6530       4952bis     Complete
 6531       5336bis     See above.  Still needs formal AD
                        signoff, but I think that is routine at
                        this point.
 6532       5335bis     Complete
 6533       5337bis     RFC Editor processing comments from
                        Chris Newman, awaiting signoff from
                        Tony Hansen 

A separate note on next steps will follow soon.

    john