Subject: Re: [EAI] Should/may

From: Shawn Steele <[email-masked]>
Date: Thu, 3 Feb 2011 18:15:00 +0000

>>      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 more interesting in the future when more mail is UTF-8.  That increases the odds that the client is unaware, in which SHOULD NOT is sufficient.  IMO "MAY NOT" hints that this might be more common and so is unreliable.  SHOULD NOT also allows the "unaware" behavior, and so that works too, however it doesn't provide the hint to developers of servers that MAY NOT provides).

But I don't care nearly enough to rathole on this.  Either works for me.

-Shawn

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

"MAY NOT" if we wish the UTF-8 environment gradually become the legacy
situation. It is not a nit, it is a phylosophical assesment.

>>      This specification
>>      does not require that the client inspect the message or
>>      otherwise go to extraordinary lengths to assure itself
>>      whether these EAI capabilities are required for the
>>      particular message.  However, in mixed or transitional
>>      environments in which EAI is not completely deployed,
>>      more precision on the part of the client (sender) may
>>      prevent unnecessary message rejections.
>

mmmhhhh... it is an attempt to explain why, but... do we really to phrase
it like this? I share aother comments doubts here.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

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

Message: 2
Date: Thu, 03 Feb 2011 10:24:08 -0000
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL
To: IMA <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1

On Thu, 03 Feb 2011 03:08:32 -0000, Dave CROCKER <[email-masked]> wrote:

> On 2/2/2011 8:03 AM, John C Klensin 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.  This specification
>>      does not require that the client inspect the message or
>>      otherwise go to extraordinary lengths to assure itself
>>      whether these EAI capabilities are required for the
>>      particular message.  However, in mixed or transitional
>>      environments in which EAI is not completely deployed,
>>      more precision on the part of the client (sender) may
>>      prevent unnecessary message rejections.
>
>
> So, the goal is to guarantee that no environment can ever be certain of
> operating in a simplified, "pure" UTF-8 mode?
>
> As phrased, this language requires permanent support for legacy ASCII
> mode.

Then I suggest s/it SHOULD NOT supply .../
       it MAY omit the UTF8SMTPbis parameter with the MAIL command.
       Indeed it is advisable to do so for reasons yadda yadda yadda/

Where the "Indeed ..." sentence might be better as a NOTE, and the "yadda
yadda yadda" should cover the "extraordinary lengths" and "mixed or
transitional environments" stuff, suitably reworded.

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

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

Message: 3
Date: Thu, 3 Feb 2011 18:40:52 +0800
From: "Yao Jiankang" <[email-masked]>
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL
To: "John C Klensin" <[email-masked]>, <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
        reply-type=original

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 03, 2011 12:03 AM
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL

> Hi.
>
> Because I really don't have any strong feeling about this issue
> other than:
>
> (i) When 5336bis is revised to reflect the parameter, it
> must be absolutely clear and precise about what the
> parameter means.
>

+1

>
> (ii) We need to keep this as simple as possible (but, in
> Wirth's words, no simpler).
>

+1

I strongly support the two principles above.

Jiankang Yao

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

Message: 4
Date: Thu, 03 Feb 2011 08:31:33 -0500
From: John C Klensin <[email-masked]>
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL
To: John Levine <[email-masked]>, [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

--On Thursday, February 03, 2011 04:47 +0000 John Levine
<[email-masked]> wrote:

>> So, the goal is to guarantee that no environment can ever be
>> certain of  operating in a simplified, "pure" UTF-8 mode?
>>
>> As phrased, this language requires permanent support for
>> legacy ASCII mode.

> I'm having trouble understanding the objection here.  In the
> far off day when everyone does EAI, since ASCII messages are a
> subset of UTF-8 messages, a server that does not care about
> the distinction between them can ignore the flag and treat all
> messages as EAI, and a client that doesn't care can set the
> flag on everything.

Or, put differently, a server that does not care can ignore the
flag, making it completely irrelevant what the client does.  So,
if the client happens to know and care, it is careful about
sending the flag and, if it has been updated to know that no
server cares any more, it just sends it always.

That said, we've still got clients and servers who are operating
in pure 821 mode, i.e., sending only HELO and accepting only
HELO.  A few of the clients aren't even spammers or bots.
That has been 18 years and, while I think we are in the tail of
that curve, we aren't going to see the end of the asymptote any
time soon.  Remembering that clients have to support pure-ASCII
mode (and, for the older cases, pure-821 mode) to have any hope
or getting mail to such servers and that servers have to support
it (independent of whatever "only spammers are that retarded"
scores they assign) in order to have any hope of receiving mail
from such clients, I just can't visualize the point at which it
will be possible to remove all code for ASCII-only situations.

> Unless you're proposing a server "send EAI or else" flag, I
> don't see what you want to change.

Indeed.
    john

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

Message: 5
Date: Thu, 03 Feb 2011 08:54:19 -0500
From: John C Klensin <[email-masked]>
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL
To: Claudio Allocchio <[email-masked]>,      John Levine
        <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

--On Thursday, February 03, 2011 09:22 +0100 Claudio Allocchio
<[email-masked]> 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.
>
> +1 to keep alive an ASCII only legacy world forever.
>
> "MAY NOT" if we wish the UTF-8 environment gradually become
> the legacy situation. It is not a nit, it is a phylosophical
> assesment.

I don't think it is a nit, but I was trying to summarize what I
saw on the list (I may not have gotten that right).  I do see
this as an operational issue: especially in the short-term
environment in which there are going to be lots more
non-EAI-capable servers around than EAI-capable ones, being
careful about that parameter will make the difference between
whether ASCII-only (i.e., 5321/5322 conforming) messages are
delivered or rejected.   It seems to me to be clearly
advantageous to have more, rather than fewer messages delivered
and to avoid unnecessary rejections.

Remember that messages that are claimed to require EAI MUST NOT
be sent unless the server advertises the capability.  So, if a
relay receives a message that appears to require EAI (parameter
sent to it on the MAIL command) and the next hop doesn't
advertise the capability, that relay must either

        - reject the message as stated to require EAI
        functionality but having no host to which it can be
        delivered

        - scan the envelope and message to determine whether it
        can safely drop the flag

        - risk violating 5321/5322 by sending a message that
        potentially requires the EAI extensions without getting
        a server OK for using those extensions.

Whatever me might think of the third, we cannot specify it as an
acceptable option.  The choice between the first two seems to me
to be an implementation or operational choice, not one that we
should try to specify in a standard (but I can easily imagine a
"how sure do you want to be before sending the parameter" knob
for locally tuning an implementation).

In environments in which clients know that all, or substantially
all, servers support EAI, MAY may be more appropriate but, if
their users communicate outside that environment, they will
still probably want to do the checking and be careful about what
functions they claim they require.

My own personal sense is that we are better off with SHOULD NOT
now.  When these specs are revised or updated in the future, the
state of the network and EAI deployment should be assessed and
the language changed to MAY (and the explanation retuned) as
needed.  While I think it would confuse more than it would help,
one could also add an explanation of how the operational reading
of "SHOULD NOT" might evolve with increasing EIA deployment.

>>>      This specification
>>>     does not require that the client inspect the message or
>>>     otherwise go to extraordinary lengths to assure itself
>>>     whether these EAI capabilities are required for the
>>>     particular message.  However, in mixed or transitional
>>>     environments in which EAI is not completely deployed,
>>>     more precision on the part of the client (sender) may
>>>     prevent unnecessary message rejections.

> mmmhhhh... it is an attempt to explain why, but... do we
> really to phrase it like this? I share aother comments doubts
> here.

FWIW, it was intended less as an explanation of why than as an
relatively brief explanation of when one would want to ignore
the SHOULD.    I was remembering an earlier comment from Dave
asking why one would not want to send the parameter and
therefore why the statement would not be "EAI-capable clients
talking with EAI-capable servers MUST always send the
parameter".   He and I are in agreement that SHOULD statements
should (sic) almost always be accompanied of an explanation of
when it was reasonable to make an exception, so I was trying to
supply one.

    john

p.s. I did not intend my language to be inserted into the
document, so nit-picking it (again, I don't consider the
SHOULD/MAY distinction to be a nit) is probably not useful.  If
we can agree on the intent, let's see what the authors come up
with.

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

Message: 6
Date: Thu, 3 Feb 2011 15:12:35 +0100 (CET)
From: Claudio Allocchio <[email-masked]>
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL
To: John C Klensin <[email-masked]>
Cc: Claudio Allocchio <[email-masked]>, [email-masked]
Message-ID:
        <[email-masked]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 3 Feb 2011, John C Klensin wrote:

>
>
> --On Thursday, February 03, 2011 09:22 +0100 Claudio Allocchio
> <[email-masked]> 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.
>>
>> +1 to keep alive an ASCII only legacy world forever.
>>
>> "MAY NOT" if we wish the UTF-8 environment gradually become
>> the legacy situation. It is not a nit, it is a phylosophical
>> assesment.
>
> I don't think it is a nit, but I was trying to summarize what I
> saw on the list (I may not have gotten that right).  I do see
> this as an operational issue: especially in the short-term
> environment in which there are going to be lots more
> non-EAI-capable servers around than EAI-capable ones, being
> careful about that parameter will make the difference between
> whether ASCII-only (i.e., 5321/5322 conforming) messages are
> delivered or rejected.   It seems to me to be clearly
> advantageous to have more, rather than fewer messages delivered
> and to avoid unnecessary rejections.
>
> Remember that messages that are claimed to require EAI MUST NOT
> be sent unless the server advertises the capability.  So, if a
> relay receives a message that appears to require EAI (parameter
> sent to it on the MAIL command) and the next hop doesn't
> advertise the capability, that relay must either
>
>       - reject the message as stated to require EAI
>       functionality but having no host to which it can be
>       delivered
>
>       - scan the envelope and message to determine whether it
>       can safely drop the flag
>
>       - risk violating 5321/5322 by sending a message that
>       potentially requires the EAI extensions without getting
>       a server OK for using those extensions.
>
> Whatever me might think of the third, we cannot specify it as an
> acceptable option.  The choice between the first two seems to me
> to be an implementation or operational choice, not one that we
> should try to specify in a standard (but I can easily imagine a
> "how sure do you want to be before sending the parameter" knob
> for locally tuning an implementation).
>
> In environments in which clients know that all, or substantially
> all, servers support EAI, MAY may be more appropriate but, if
> their users communicate outside that environment, they will
> still probably want to do the checking and be careful about what
> functions they claim they require.
>
> My own personal sense is that we are better off with SHOULD NOT
> now.  When these specs are revised or updated in the future, the
> state of the network and EAI deployment should be assessed and
> the language changed to MAY (and the explanation retuned) as
> needed.  While I think it would confuse more than it would help,
> one could also add an explanation of how the operational reading
> of "SHOULD NOT" might evolve with increasing EIA deployment.

yes, SHOULD NOT is better for current situation, and MAY NOT will become
more appropriate with time. And we can always change it during the
document updates.

>>>>      This specification
>>>>    does not require that the client inspect the message or
>>>>    otherwise go to extraordinary lengths to assure itself
>>>>    whether these EAI capabilities are required for the
>>>>    particular message.  However, in mixed or transitional
>>>>    environments in which EAI is not completely deployed,
>>>>    more precision on the part of the client (sender) may
>>>>    prevent unnecessary message rejections.
>
>> mmmhhhh... it is an attempt to explain why, but... do we
>> really to phrase it like this? I share aother comments doubts
>> here.
>
> FWIW, it was intended less as an explanation of why than as an
> relatively brief explanation of when one would want to ignore
> the SHOULD.    I was remembering an earlier comment from Dave
> asking why one would not want to send the parameter and
> therefore why the statement would not be "EAI-capable clients
> talking with EAI-capable servers MUST always send the
> parameter".   He and I are in agreement that SHOULD statements
> should (sic) almost always be accompanied of an explanation of
> when it was reasonable to make an exception, so I was trying to
> supply one.

ok. But the language at first read did not seem to convey that (at least
to me...). that was my objection.

>
>    john
>
> p.s. I did not intend my language to be inserted into the
> document, so nit-picking it (again, I don't consider the
> SHOULD/MAY distinction to be a nit) is probably not useful.  If
> we can agree on the intent, let's see what the authors come up
> with.
>
>
>
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

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

Message: 7
Date: Thu, 03 Feb 2011 11:07:14 -0500
From: John C Klensin <[email-masked]>
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL
To: Claudio Allocchio <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

--On Thursday, February 03, 2011 15:12 +0100 Claudio Allocchio
<[email-masked]> wrote:

>...
>> My own personal sense is that we are better off with SHOULD
>> NOT now.  When these specs are revised or updated in the
>> future, the state of the network and EAI deployment should be
>> assessed and the language changed to MAY (and the explanation
>> retuned) as needed.  While I think it would confuse more than
>> it would help, one could also add an explanation of how the
>> operational reading of "SHOULD NOT" might evolve with
>> increasing EIA deployment.
>
> yes, SHOULD NOT is better for current situation, and MAY NOT
> will become more appropriate with time. And we can always
> change it during the document updates.

I don't know how others in the WG --especially those who are
likely to have to do the work-- feel about this but my
preference is that we try to get a complete and competent
protocol spec out as quickly as we can now, focusing on what
people should do in the short term/ early transition phrase as
appropriate.  We should then move to revise as soon as we have
implementations and deployment experience.  In other words, I
think we will need to revise in a few years or less anyway and
should not spend energy now trying to make sure we have all the
language exactly correct.

Again, that is mostly personal opinion, but it is more
consistent with the objective to get things done quickly than a
lot of fine-tuning.

>>>>>      This specification
>>>>>   does not require that the client inspect the message or
>>>>>   otherwise go to extraordinary lengths to assure itself
>...
>> FWIW, it was intended less as an explanation of why than as an
>> relatively brief explanation of when one would want to ignore
>> the SHOULD.    I was remembering an earlier comment from Dave
>> asking why one would not want to send the parameter and
>> therefore why the statement would not be "EAI-capable clients
>> talking with EAI-capable servers MUST always send the
>> parameter".   He and I are in agreement that SHOULD statements
>> should (sic) almost always be accompanied of an explanation of
>> when it was reasonable to make an exception, so I was trying
>> to supply one.
>
> ok. But the language at first read did not seem to convey that
> (at least to me...). that was my objection.

On second reading, I agree that might not be clear enough.

Let's see if we can reach agreement on intent (so far, Dave's
objection is the only one I remember seeing and both John L and
I have wondered about its implications) and then have the
authors/editors propose specific language... which we can then
tune to the extent needed.

best,
   john

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

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

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Feb 2011 13:46:11 -0500

> 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]