Question about AUTH48 text for 5336bis/ proto-RFC 6531
John C Klensin <klensin <at> jck.com>
2012-02-07 05:39:56 GMT
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
RSS Feed