Subject: Re: [EAI] Should/may

From: Shawn Steele <[email-masked]>
Date: Fri, 4 Feb 2011 04:11:56 +0000

I'd intended "MAY", however that sounded funny in the sentence the way John had it.  (it was backwards).

So this is more along the lines of my intent:

> >>      If the client is aware that the envelope or message
> >>      being sent does not require any of the EAI extension
> >>      capabilities, it MAY choose to not supply the UTF8SMTPbis
> >>      parameter with the MAIL command.

Although that doesn't make it any easier to read :)

As mentioned, I'm happy with either MAY or SHOULD, however MUST NOT is not acceptable.

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

Message: 3
Date: Thu, 3 Feb 2011 13:46:11 -0500
From: Andrew Sullivan <[email-masked]>
Subject: Re: [EAI] Should/may
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

On Thu, Feb 03, 2011 at 06:15:00PM +0000, Shawn Steele wrote:
> >>      If the client is aware that the envelope or message
> >>      being sent does not require any of the EAI extension
> >>      capabilities, it SHOULD NOT supply the UTF8SMTPbis
> >>      parameter with the MAIL command.
> 
> I'd also lean toward MAY NOT, however I'm not that concerned about it.  I believe the practical implication is low.  
> 

MAY NOT is not an RFC 2119 term.  In English, it has almost the same meaning as MUST NOT.  Is that what you intended?

A

--
Andrew Sullivan
[email-masked]

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

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

End of IMA Digest, Vol 67, Issue 6
**********************************

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Feb 2011 08:16:42 -0500

> Although that doesn't make it any easier to read :)

Does this make it easier?

    If the client is aware that the envelope or message being sent
    does not require any of the EAI extension capabilities, it MAY
    choose to leave out the UTF8SMTPbis parameter to the MAIL command.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 04 Feb 2011 13:57:25 -0000

> Although that doesn't make it any easier to read :)

s/not supply/omit/

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Feb 2011 10:08:35 -0500

Shawn (and Charles),

--On Friday, February 04, 2011 04:11 +0000 Shawn Steele
<[email-masked]> wrote:

>> >>      capabilities, it MAY choose to not supply the
>> >>      UTF8SMTPbis parameter with the MAIL command.
> 

To the best of my knowledge, no one has proposed MUST NOT,
although even that wouldn't be very strong in the presence of
the deliberate weasel-wording about what the client is or is not
"aware" of.  The reasoning that caused me to select "SHOULD NOT
supply the parameter" was...

(1) If the client knows that the message doesn't require EAI
capabilities, it can safely omit the parameter and, given the
motivation of getting as many messages delivered as possible,
probably should omit it.

(2) If the client treats everything as EAI (i.e., as containing
UTF-8, whether that UTF-8 is ASCII or not) then, almost by
definition, it won't know (won't "be aware").   Such clients are
likely to be common in Unicode-native environments but may exist
in other ones.  As we have discussed many times before, the
logical upgrade to EAI for such clients (and the corresponding
servers) is to support the EHLO reply and recognize any
parameters the WG decides to require, disable any checks that
exist today to enforce ASCII-only restrictions, and otherwise
just go about their business.  The analogy to support for
8BITMIME in clients and servers that are 8bit-clean is pretty
obvious and we have a lot of experience with that case and how
well it works.   

But the important thing is that such clients can reasonably
claim to be unaware of whether the message is restricted to
ASCII or not.  If they are not aware of whether the message and
envelope are ASCII-only, then the provision is simply irrelevant
-- whether it says MAY, SHOULD, or MUST makes no difference at
all (now or in the future).

(3) I agree with Ned's comment that what we say about this sort
of thing is likely to have a lot less effect than perhaps we
would like to think.

That combination is one of the situations about which I was
trying to comment in my exchange with Dave about trying to be
sure that the protocol spec is "complete and competent" but that
we should not waste a lot of time fine-tuning language.  If a
client is designed to act as much as possible as if each message
is EAI-compliant, then it won't be aware of anything else and
whether the text that applies only when the client is aware says
MAY or SHOULD NOT is completely irrelevant.  

If a server is designed to act as much as possible as if each
message is EAI-compliant, it must still be able to handle
ASCII-only messages -- not only because those are EAI-compliant
anyway (except that the MAIL command parameter may not appear)
but because it is still required to be 5321-compliant and behave
well for 5321 (only)-compliant messages.  And, if it tries to
relay and encounters a server (or other system) that doesn't
handle messages that require EAI capability, then it has three
choices:

	(i) If the envelope it received does not contain the
	UTF8SMTPbis parameter on the MAIL command, then it
	proceeds to handle the situation as a 5321-compliant
	situation... EAI is irrelevant.
	
	(ii) If the envelope it received contains the
	UTF8SMTPbis parameter to the MAIL command, it can simply
	reject (or bounce) the message.
	
	(iii) If the envelope it received contains the
	UTF8SMTPbis parameter, it can do whatever it needs to do
	to determine whether it can safely forward the message
	to the next, presumably not-EAI-capable, system.  Of
	course, if it does that, it must not include the MAIL
	command parameter because the next-hop system will have
	not advertised the availability of the extension.

And, again, that is pretty much true regardless of what we say
(we could eliminate the third case by saying "MUST REJECT", but
we would be ignored).

So, again consistent with my earlier note, can we possibly
minimize the time we spend debating particular wording
differences that are unlikely to have any effect on
implementations?

    john

---

From: Shawn Steele <[email-masked]>
Date: Fri, 4 Feb 2011 18:53:55 +0000

Yes, sorry that I contributed anything that might be causing more delay :)  (I was trying to cause less delay :(

-Shawn

 
http://blogs.msdn.com/shawnste

________________________________________
From: John C Klensin [[email-masked]]
Sent: Friday, February 04, 2011 7:08 AM
To: Shawn Steele; [email-masked]
Subject: Re: [EAI] Should/may

Shawn (and Charles),

    john