Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM?

From: Shawn Steele <[email-masked]>
Date: Tue, 18 Jan 2011 07:03:31 +0000

Character encodings are, in short, evil, and should be avoided.  Most of the other encodings have variants, ambiguities and other inconsistencies that make them inappropriate for reliable use.  So we really shouldn't have this be extensible in that direction.  It's unclear to me how other extensions might interact with, or extend EAI, but it seems that a general extensibility is outside of the purview of this WG.

-Shawn

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

Message: 10
Date: Mon, 17 Jan 2011 22:39:10 -0800
From: Troy Starr <[email-masked]>
Subject: Re: [EAI] Consensus Issue #1:  parameter on MAIL FROM?
To: 'EAI WG' <[email-masked]>
Message-ID:
        <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Yes, it should.

I would prefer it to be a parameter that takes a value, and that the value indicates legacy behavior or EAI behavior, because I believe that makes any potential future extensions to this standard easier to integrate.  I would prefer that the value be descriptive of the type of character encoding (ASCII/UTF-8, or whatever terminology is deemed appropriate) rather than a simple binary value, again because I believe that makes any potential future extensions to this standard easier to integrate.  If it had such a value, then a parameter name such as HEADERENCODING might be a good name.

But if there was a consensus for this parameter to have a binary value, or no value at all, I would not object.

- Troy Starr

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 18 Jan 2011 01:29:03 -0800

If there is to be a parameter on the MAIL FROM: command, it seems that it
may have overloaded meanings:

  1 - The message immediately following has non-ASCII

  2 - The client is able to accept non-ASCII in responses to any commands
      related to the immediately following message

This might entail a syntax like:

  UTF8=WITHIN  or  UTF8=ACCEPTED

Where WITHIN implies ACCEPTED.

-- 
Bill McQuillan <[email-masked]>

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 18 Jan 2011 07:13:24 -0800

>    1 - The message immediately following has non-ASCII

A message can be in UTF-8 and have only ASCII.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John Levine <[email-masked]>
Date: 18 Jan 2011 16:02:14 -0000

>      related to the immediately following message

I suppose that's hypothetically true, but I do not ever want to meet a
mail client that sends a UTF-8 message but can't accept UTF-8 in the
responses.  For EAI, you're either on the bus or you aren't.

Add my +1 to having one parameter with no options.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jan 2011 12:49:05 -0500

--On Tuesday, 18 January, 2011 16:02 +0000 John Levine
<[email-masked]> wrote:

>...
> I suppose that's hypothetically true, but I do not ever want
> to meet a mail client that sends a UTF-8 message but can't
> accept UTF-8 in the responses.  For EAI, you're either on the
> bus or you aren't.
>...

And that should be a conformance issue elsewhere in the text.
More generally, the WG has so far consistently taken the
position that one is either EAI-conforming (i.e., fully
i18n-email-capable) or not.  I think that is consistent with the
view John expresses above.

    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jan 2011 13:03:38 -0500

--On Tuesday, 18 January, 2011 07:13 -0800 Dave CROCKER
<[email-masked]> wrote:

>> If there is to be a parameter on the MAIL FROM: command, it
>> seems that it may have overloaded meanings:
>> 

So?  Assuming you are not just being pedantic for its own sake,
what does that suggest to you?   It was part of the WG's
original reasoning for _not_ needing this parameter -- the
server had asserted that it was UTF-8 capable (or whatever one
wants to call it), so the client could send UTF-8 (including
just the ASCII subset) without additional fussing.  If the
server actually needs to know whether the extended features are
being used, without having to parse the message, then it seems
to me that the client should tell the server what it actually
knows about addresses and main and MIME headers, not assert that
maybe it is sending characters outside the ASCII,
5321/5322-conforming, range and maybe it isn't.   

If all that parameter means is that the client is sending UTF-8
that might happen to be nothing but ASCII, then, if the server
cares whether what it is getting requires extended capabilities,
it needs to parse the message and its headers.  And that is
exactly what those who took the strongest positions in favor of
this parameter seemed to me to want to avoid.

     john

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 18 Jan 2011 10:15:23 -0800

On 1/18/2011 10:03 AM, John C Klensin wrote:
> what does that suggest to you?

(Thanks for that assumption and, of course, for expressing it.)

As I have been repeatedly noting, this group has fallen into the pattern of 
using "non-ascii" as a synonym for UTF-8.

It's not a synonym.

An example of the error this inaccurate usage causes is to assume that someone 
sending an ASCII message is not working within a UTF-8 environment.

>  It was part of the WG's
> just the ASCII subset) without additional fussing.

The problem was the step after that:  The committee felt that the server could 
determine whether an incoming message was in UTF-8 by whether it contained only 
ASCII characters.  Hence it did not require an explicit label.

This was an erroneous assumption and I believe it flowed directly from this 
mis-use of "non-ascii".

 >                If the

If the message is in UTF-8, it does not matter whether it happens to have 
characters only inside, only outside, or inside and outside the ASCII range.

What matters is that the message and the participants have declared that they 
are working within the set of specifications defined for UTF-8 messages.

d/
-- 

   Dave Crocker

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 18 Jan 2011 10:25:50 -0800

> view John expresses above.

That's certainly right. But NOT what I was concerned with.

How does an EAI compliant client express that fact when sending a message
that is ASCII only? If it marks the message as UTF8, it may limit it's
propagation unnecessarily, and if the client *doesn't* mark it as UTF8, it
may miss out on some useful responses from the server.

Case 0 - Non-EAI client; Message Header MUST be ASCII only

Case 1 - EAI client; Message Header is ASCII only

Case 2 - EAI client; Message Header is *not* ASCII only

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jan 2011 13:49:00 -0500

--On Tuesday, 18 January, 2011 10:15 -0800 Dave CROCKER
<[email-masked]> wrote:

> The problem was the step after that:  The committee felt that
> the server could determine whether an incoming message was in
> UTF-8 by whether it contained only ASCII characters.  Hence it
> did not require an explicit label.
> 
> This was an erroneous assumption and I believe it flowed
> directly from this mis-use of "non-ascii".
> 
> 
>  >                If the
>> server actually needs to know whether the extended features
>> are being used, without having to parse the message, then it
>> seems to me that the client should tell the server what it
>> actually knows about addresses and main and MIME headers, not
>> assert that maybe it is sending characters outside the ASCII,
> If the message is in UTF-8, it does not matter whether it
> happens to have characters only inside, only outside, or
> inside and outside the ASCII range.

Aha.  I finally think I understand what you are talking about.
I still think you are wrong, but starting to understand where we
disagree is progress.

First, nothing in the EAI work, with  or without parameters,
requires that the _message_, and its various body parts, be in
UTF-8.  That is why we have content-types and, for some text/
types, charset parameters (which deliberately and explicitly
specify both a CCS and a particular encoding rather than a cell
in a matrix).  While some of us believe that gradually retiring
everything on the wire other than Unicode-in-UTF-8 (even its
ASCII subset) would be a good idea, making that a requirement
would be well outside EAI's scope as well as implausible for the
near future.

So we are talking only about addresses and [other] header
information, both the main set of header fields and any MIME
body part headers, not "messages" or "message content".

Now prior to the EAI work, the technical term for any message
containing non-ASCII (and I do mean "non-ASCII", not just UTF-8
Unicode outside that range) characters was "seriously
non-conforming" (or perhaps "invalid" or "broken").   If there
are instances of that particular bad behavior around, addressing
them is outside EAI's scope (at best).

So a server that advertises availability of the EAI extension is
asserting that it can accept headers and addresses in UTF-8
(yes, including nothing-but-ASCII).  It is not asserting that it
can handle, e.g., ISO 8859-5 or BIG5 in headers or addresses.

If your reasoning is correct, the client really doesn't need to
assert anything as long as what it sends is UTF-8 (which might
be nothing but ASCII) in its address and header material.  I.e., 

	5321/5322-conforming: headers and addresses are
	ASCII-only
	EAI-conforming: headers and addresses are UTF-8 only
	(and might be all-ASCII because that is a proper
	subset).  

But then we don't need this parameter except for one case that
the WG has explicitly tried to exclude.  That case arises if the
server gets to advertise both UTF8SMTP and LowerSlobbovianSMTP.
If that is permitted -- if we are going to accept and tolerate a
whole collection of CCSs and encodings from which a client might
choose, then the client would properly have to assert that its
headers and addresses are Unicode-in-UTF-8, and not "something
else".  A better solution is to avoid specifying and
standardizing such extensions.

Even if that were the concern, it would be far better to simply
have a provision that a given server can advertise at most one
address and/or header CCS or encoding extension at a time.
Anything else leads to more interesting edge cases and
complexities than could possibly be wise.

The much stronger argument for a parameter, IMO, is for a client
to assert that it is actually using some EAI facilities and
hence that any subsequent relay must make sure that those
facilities are available (and can make the determination that it
needs to require them without parsing all headers in the message
to determine if non-ASCII (sic, but think "octets with the high
bit on") characters are present.

     john

---

From: [email-masked]
Date: Tue, 18 Jan 2011 10:44:39 -0800 (PST)

>   1 - The message immediately following has non-ASCII

THat's not what the proposed parameter means. The proposed parameter is an
indicator that the following *transaction* may contain utf-8 in several new
places. The new places include not only header fields but also envelope
parameters.

And since it is pretty common - and in some cases essential - to be able  to
return some of that now-potentially-utf-8 material in error responses, this
needs to extend to server responses as well.

>       related to the immediately following message

You're making this sound like it is an independent thing. It's not. It's  a
direct consequence of sending utf-8 material (and addresses in particular).

Indeed, it is easy to envision a different sort of extension that lets the
language of SMTP responses be negotiated. This would almost certainly also
require suport for utf-8 in SMTP server responses. But it isn't what we're
considering here.

> Where WITHIN implies ACCEPTED.

Unless you can come up with an argument for why it would be useful to allow one
of these but not the other - and without getting into capabilities that go
beyond what this WG is chartered to do, I see no point in having such a split.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jan 2011 13:57:06 -0500

--On Tuesday, 18 January, 2011 10:25 -0800 Bill McQuillan
<[email-masked]> wrote:

> How does an EAI compliant client express that fact when
> sending a message that is ASCII only? If it marks the message
> as UTF8, it may limit it's propagation unnecessarily, and if
> the client *doesn't* mark it as UTF8, it may miss out on some
> useful responses from the server.
> 

This may be at the core of the discussion Dave and I are having,
except that it really isn't about UTF-8 except as a consequence.
If one has a parameter, the desired behavior is:

* No EAI facilities used or required: no parameter associated
with the extensions on MAIL.  That corresponds to your cases 0
and 1 and is the same whether the server advertises UTF8SMTPbis
or not.

* EAI facilities used or required: appropriate parameter is sent
with MAIL, VRFY, or EXPN as needed.  Server actually doesn't
know much more about the handling of the commands or message
(other than that it can return replies that would have have
conformed to 5321) but it knows that, if it relays the message,
it has to require those facilities downstream without having to
parse anything.

      john

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2011 14:02:45 -0500

> that is ASCII only?

It doesn't.  I believe that the consensus is that all the efforts at 
selective downgrading turned out to be more trouble than they were worth.

If you think that there will be enough pure ASCII mail sent to non-ASCII 
addresses that then forward to ASCII addresses to merit special case code 
to recognize and downgrade and do some kludge to fix any non-ASCII stuff 
in Received: headers, you still have the option of Deep Message 
Inspection.

Personally, I think that's not sufficiently likely to be worry about.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Troy Starr <[email-masked]>
Date: Tue, 18 Jan 2011 12:01:19 -0800

Hi Shawn -

While I don't think I have the same zeal about character encodings, I appreciate your concern.  I don't think the working group should spend a significant amount of time trying to think about how the standard might be extended, but I still think it's valuable to acknowledge that it might happen for reasons that aren't obvious to us today.  And if we can design our parameters to be more friendly to potential future extensions with minimal cost and no negative impact on implementing this standard, then I think it would be wise for us to do so.  We don't need to concern ourselves with whether those future extensions are good ideas - that can be safely left to future working groups who wish to propose those extensions.

And as I said, while I would prefer the type of design I've described, the other proposals that have been given also meet the goal of this working group and I would have no objection to them.

- Troy Starr

-----Original Message-----
From: Shawn Steele [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 11:04 PM
To: [email-masked]
Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM?

-Shawn

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 18 Jan 2011 15:23:56 -0800

> and 1 and is the same whether the server advertises UTF8SMTPbis

I am concerned about the case where the client does NOT know that there is
an EAI facility needed, but THERE IS a need!

For example, a client (which is EAI compliant) is handed a message (say, by
SUBMISSION) which has no non-ASCII recipients or non-ASCII in its header.
The client contacts the MX server for one or more of the recipients and
begins a transaction with MAIL FROM: using *no* UTF8 parameter.

It then sends RCPT TO: commands until one of the recipients has a
forwarding address and the MX server would like to return a 551 reply
suggesting a <forward-path>. However, the <forward-path> is a non-ASCII
address and the MX server has no way to return this to the client since the
client must be presumed to be NON-EAI compliant due to the lack of a UTF8
parameter on the MAIL FROM: command.

This all presumes we are using the UTF8 parameter to both relieve the MX server
from Deep-Analysis as well as informing it of the capabilities of the
client.

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

---

From: [email-masked]
Date: Tue, 18 Jan 2011 16:06:35 -0800 (PST)

> an EAI facility needed, but THERE IS a need!

OK, now I see what you're getting at. My problem with this is that in my
experience the use of the address correction facilities in RFC 5321 is quite
rare, bordering on nonexistent. I'd like to see some evidence that such
facilities are not just in some code somewhere, but in such active use that the
costs of complicating this proposal are worth the added benefit of supporting
this capability for non-ASCII responses.

The tradeoff here may seem to be similar to when we decide whether or not to
retain some obscure feature in some specification (like, say, all the obsolete
syntax in RFC 5322), but it really isn't. The difference is in fact rather
stark: Support costs versus deployment costs.

Most of the support costs for obscure existing are, in one way or another, sunk
costs, e.g., if you have code that supports source routes, you've already paid
the price of developing that code.

Deployment costs are another matter. These are mostly future costs and hence
have a direct impact on deployability - the more complex and costly this stuff
is to implement and operate, the less people are going to be willing to be
early adopters. Raise the cost too high, and this dog is not going to hunt. And
that more than anything is my goal here - I want this specification to  be as
simole and as easy to implement as possible, because otherwise I think this
group is going to be very surprised at just how little large parts of the world
care about having the ability to put utf-8 in addresses.

> from Deep-Analysis as well as informing it of the capabilities of the

I think the avoidance of message inspection is vitally important, but let's not
forget this also facilities early rejection of messages on a per-recipient
basis as well.

				Ned

---

From: Bill McQuillan <[email-masked]>
Date: Wed, 19 Jan 2011 00:06:55 -0800

> care about having the ability to put utf-8 in addresses.

My main concern was to raise this issue for completeness sake.

I defer to others with more recent operational and development experience
as to the importance of this special case.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 20 Jan 2011 13:40:14 -0000

> places. The new places include not only header fields but also envelope

+1

However, it needs a NOTE to the efect that including this parameter in a  
message where it is not strictly necessary (that message is pure ASCII)  
MAY result in a more circuitous propagation path, or even in falure to  
deliver the message at all (e.g if the ultimate recipient does not  
advertise UTF8SMTPbis).

> direct consequence of sending utf-8 material (and addresses in  

+1

I don't think this meaning is perticularly important (and certainly not  
worth a second version of the parameter).

-- 
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: [email-masked]
Date: Thu, 20 Jan 2011 09:12:02 -0800 (PST)

> deliver the message at all (e.g if the ultimate recipient does not

Yes, it would be a very good idea to include a statement like this.

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 21 Jan 2011 10:24:00 +0100 (CET)

> this capability for non-ASCII responses.

I stepped into such (or nearly such) implementation only once (an old 
version of Communigate), which however was always resulting in a non 
delivery message ("no such user") to sender because all the clients in 
common use did not understand the answer (forwarding suggestion) 
correctly, even if the message was pure ASCII anyhow. In subsequest 
versions it seems this "feature" was replaced by a plain "accept, store, 
then re-deliver" approach when forwarding was in actions, and no more 
problems were reported (at least to my knowledge).

Thus, +1 to Ned's comment. The complication is not worth the benefits.

> Most of the support costs for obscure existing are, in one way or 
> another, sunk costs, e.g., if you have code that supports source routes, 
> you've already paid the price of developing that code.

correct. it's already there *and working*, let it live.

> Deployment costs are another matter. These are mostly future costs and 
> hence have a direct impact on deployability - the more complex and 
> costly this stuff is to implement and operate, the less people are going 
> to be willing to be early adopters. Raise the cost too high, and this 
> dog is not going to hunt. And that more than anything is my goal here - 
> I want this specification to be as simole and as easy to implement as 
> possible, because otherwise I think this group is going to be very 
> surprised at just how little large parts of the world care about having 
> the ability to put utf-8 in addresses.
>
> I think the avoidance of message inspection is vitally important, but 
> let's not forget this also facilities early rejection of messages on a 
> per-recipient basis as well.

another +1

> 				Ned

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

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 21 Jan 2011 11:04:02 +0100 (CET)

> Yes, it would be a very good idea to include a statement like this.

True: requesting by default optional services when you do not need them 
either results in unecessary "costs", or potential risks. Thus we need to 
warn implementors (or users configuring things).

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jan 2011 07:50:35 -0500

--On Thursday, January 20, 2011 09:12 -0800 [email-masked]
wrote:

>> However, it needs a NOTE to the efect that including this
>> parameter in a message where it is not strictly necessary
>> (that message is pure ASCII) MAY result in a more circuitous
>> propagation path, or even in falure to deliver the message at
>> all (e.g if the ultimate recipient does not advertise
>> UTF8SMTPbis).
> 

Sorry, folks, but I'm seeing a contradiction here, not just
notes, and, if I were Jiankang, I'd have trouble knowing what to
write.

Option 1: Any EAI-capable client that is talking with a server
that supports EAI extensions SHOULD send the parameter with
MAIL, indicating that it is modern and that message envelope or
headers might contain UTF-8 (restricted however we might
restrict it, but not necessarily restricted to ASCII).  That
SHOULD might be accompanied by a note about exceptions. but the
intent is "almost always".   As I understand it, this is what
Shawn is proposing.

Option 2: In order to avoid requiring a subsequent analysis of
headers before dealing with a server that cannot handle EAI
extensions, an EAI-capable client talking with an EAI-capable
server SHOULD send the parameter only if it has reason to
believe that the message requires EAI support.  "Reason to
believe" allows exceptions and might be further noted, but the
intent is that the parameter not be sent with ASCII-only (aka
strictly 5321/5322-conforming) messages.  As I understand it,
this is what Charles and Ned are proposing.

In practice, option 2 probably gradually becomes equivalent to
option 1 as the EAI extensions are broadly deployed (just as
support for 8BITMIME (without requiring downgrading) is now
pretty general.  But, in the reasonably short term, it does make
a difference.  

So which is it?
     john

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jan 2011 08:03:02 -0500

--On Tuesday, January 18, 2011 10:44 -0800 [email-masked]
wrote:

>...
> Indeed, it is easy to envision a different sort of extension
> that lets the language of SMTP responses be negotiated. This
> would almost certainly also require suport for utf-8 in SMTP
> server responses. But it isn't what we're considering here.

Indeed, there have been several proposals to do this over the
years, none of which have assumed or required non-ASCII
materials in either the headers or the envelope.  With the
exception of the possible requirement to return addresses that
contain characters outside the ASCII in the responses to VRFY
and EXPN, the two sets of extensions are almost completely
orthogonal.

   john

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 21 Jan 2011 14:09:24 +0100 (CET)

> this is what Charles and Ned are proposing.

I believe option 2 is safer and more pragmatic.

> pretty general.  But, in the reasonably short term, it does make

no. 2

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 24 Jan 2011 11:33:15 -0000

> this is what Charles and Ned are proposing.

Most definitely #2. For sure that is what I have been assuming in all the  
comments I have posted.

Now there may be reasons for toning down the wording a bit. I take Shawn's  
point that when everybody is using EAI there is little point in striving  
to maintain that SHOULD. And it may be just too much trouble for some MUAs  
or submission agents to make the necessary checks.

So replacing "an EAI-capable client ... SHOULD send ..." by "an  
EAI-capable client ... would be well advised to send ...". Followed, of  
course, by that NOTE explaining the difficulties that might ensue of the  
advice is not taken. It is then up to each implementor to evaluate the  
warnings in the NOTE in the light of his own circumstances, and the then  
prevailing practice in the great big world outside.

---

From: John Levine <[email-masked]>
Date: 24 Jan 2011 15:50:18 -0000

>MAIL, indicating that it is modern ...

>Option 2: ... an EAI-capable client talking with an EAI-capable
>believe that the message requires EAI support.

I think that King Canute may have some useful advice for us here.

It is obviously the case that for a while, perhaps quite a while, #2
will make it more likely that your mail will get delivered to the many
non-EAI destinations, and it's probably worth putting a note and a
SHOULD about that.  But particularly in areas where English is not the
major language, people will do #1 and EAI mail hosts better be
prepared to deal with it, for some definition of deal with it yet to
be finalized.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 24 Jan 2011 13:23:53 -0500

--On Monday, January 24, 2011 15:50 +0000 John Levine
<[email-masked]> wrote:

>> Option 2: ... an EAI-capable client talking with an
>> EAI-capable server SHOULD send the parameter only if it has
>> reason to believe that the message requires EAI support.
> 
> It is obviously the case that for a while, perhaps quite a
> while, #2 will make it more likely that your mail will get
> delivered to the many non-EAI destinations, and it's probably
> worth putting a note and a SHOULD about that.  But
> particularly in areas where English is not the major language,
> people will do #1 and EAI mail hosts better be prepared to
> deal with it, for some definition of deal with it yet to be
> finalized.

That would be accomplished by either: 

(i) "MUST supply the parameter if the envelope or message
requires EAI facilities and SHOULD NOT supply it if the client
is EAI-capable but not using EAI facilities"

or

(ii) "MUST supply the parameter if the envelope or message
requires EAI facilities and MAY supply it if the client is
EAI-capable but not using EAI facilities"

Either of those would be consistent with Option 2, the second is
a lot weaker.

   john

---

From: "John R Levine" <[email-masked]>
Date: 24 Jan 2011 13:28:13 -0500

> EAI-capable but not using EAI facilities"

I'd go with (ii) since that's likely to match what people really do.

Regards,