Subject: Negotiated noncompliance

From: John Gardiner Myers <[email-masked]>
Date: Wed, 16 Aug 2000 16:28:51 -0700

I propose the following additional wording for resolving the "naked LF"
issue:

Section 2.3.7, in "Conforming implementations MUST NOT recognize or
generate any other..." remove "recognize or".

Add:

6.4 Negotiated Noncompliance

A general protocol implementation principle may be useful to
implementations which wish to interoperate with particular types of
noncompliant peers: If an implementation receives protocol which is not
permitted by the specification and the specification does not mandate
the response to such illegal protocol, the implementation MAY consider
the peer to have negotiated a nonstandard protocol.  At that point, the
implementation is not constrained by the protocol specification in its
handling of that particular connection.

For example, if an SMTP server receives commands terminated by the ASCII
character "LF" but not containing the ASCII character "CR", it MAY
consider the SMTP client as having negotiated a nonstandard variant of
the SMTP protocol wherein the <CRLF> sequence is encoded as a single
"LF" character.  The prohibition against recognizing the sequence
"<LF>.<LF>" as the end of mail data indication would then not apply to
that particular connection.

Note that this negotiation does not release the implementation from the
conformance requirements in any other protocol session, including any
session that relays mail received from a negotiated nonstandard protocol
variant.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Aug 2000 16:41:38 -0700

>  If an implementation receives protocol which is not
>the peer to have negotiated a nonstandard protocol.

In other words, a receiver is free to handle errors in any way it deems 
appropriate, unless the specification explicitly defines the handling of 
this particular effort.

Besides being on the wrong side of a slippery slope, this sort of language 
will only serve to make the distinction between "in spec" and "out of spec" 
more confused than it already is.

Any two consenting protocol engines may do anything they wish, in the 
privacy of their own interactions.  They do not need text to give them 
permission, especially when the text is of the form "if the sender goes 
outside the spec, you can choose whether top accept it."

The goal of a specification should be to remove choice, not add to it.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Aug 2000 20:28:09 -0400

I would like to register negative support for this suggestion.
More details if we actually open the discussion.

Keith

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 16 Aug 2000 19:01:32 -0700

>More details if we actually open the discussion.

I would like to see the discussion open. John's text comes from a 
discussion that he and Chris and I had in Pittsburgh. Basically, 
there is a great deal of dissent on this list for some of the 
prohibitions for servers in 821bis. It is clear that some server 
writers intend to ignore some of them, given that they are doing so 
now and do not want to break current functionality in their servers. 
However, without the prohibitions, the servers can say "anything 
goes" as soon as the client does something out of spec, including 
dropping the mail on the floor. The intent is to narrow the "anything 
goes" so that server implementors have guidance about where they 
really must prohibit and where they can make their own choices.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Aug 2000 22:45:27 -0400

> I would like to see the discussion open.

I'd like to see the discussion open also, even though I disagree with
the text as proposed.  This is a subtle enough issue that I doubt
we'll get good text without some discussion.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Aug 2000 01:32:37 -0700

I would like to see discussion open as well.  And since I'm number 4 on
the list as far as I can tell (John, Keith, Paul, me), I'm gonna open it
right here.

I agree with the sentiment behind the wording.  May I propose an
alternative, to be inserted in or around section 6.3, as the editor sees
fit?

--
This standard takes a stricter tone than its predecessor.  It does so
with the experience of nearly twenty years of odd interoperability
failures, and with the realization that where-as thousands of people
used SMTP at the time of RFC 821, now millions of people rely on the
standard.  Non-conformance, therefore, can be far more costly.

If one implementation in an SMTP conversation demonstrates its failure
to comply with this standard, the other implementation MAY vary from
this standard if its developer believes it has sufficient knowledge as
to the intent of the other side.  However, it does risk misinterpreting
the intent of the other implementation, which may lead to altered or
lost messages, protocol deadlocks, or other failures.  Thus great care
must be taken in such circumstances.
--

This is not a matter of "negotiated noncompliance" but more a matter of
dealing with an implementation's failure to comply with the words in the
document.

--
Eliot Lear
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Aug 2000 01:47:50 -0700

At 01:32 AM 8/17/00 -0700, Eliot Lear wrote:
>to the intent of the other side.

Implementors do not need language in a standard to tell them that they can 
do things differently if they know what they are doing.

>However, it does risk misinterpreting

Absent the details of what constitutes "great care", what does a reader 
learn that they did not already know?

d/

=-=-=-=-=

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Aug 2000 02:15:15 -0700

Dave,

If we had stuck with the original tone of 821, I would agree with you.
However, because the standard is fairly strict (and rightly so), I want
to make it clear that if you didn't kick dirt first, you MAY use your
brain to deal with the other guy and still be considered compliant with
the document.

My text may need refining.  In particular, I'm not talking about dumb
mail submitting clients, since we already cover those guys in 6.3.  I'm
far more concerned about relays.  This is why I'd propose that the
editor stitch it in.
-- 
Eliot Lear
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Aug 2000 09:19:20 -0400

Eliot's text is a lot closer to what I think.  

However, using MAY may be too strong - it implies that behavior which 
an SMTP engages in to accomodate a broken peer is within the scope of
the standard.    It might be better to say that if an implementation 
deviates from the SMTP spec in an attempt to accomodate another 
implementation which deviates from the SMTP spec, such behavior is 
outside of the scope of the standard.  So an implementation which
does this is not immediately nonconforming, but neither is such 
behavior blessed.

still, this whole idea makes me nervous.  I'll say more if I
can articulate my concerns.

Keith

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Aug 2000 13:54:33 -0400

> do things differently if they know what they are doing.

I usually find myself in agreement with Dave, but not this time: I agree 
with Eliot that because of the situation that exists now, in deployed 
servers, it's a good idea for us to say *something* about it.  Absent that, 
what happens (you know it; you've seen it) is that implementors see 
noncompliant stuff coming in and they simply change their implementations 
to accept it -- often without realizing that this might have undesirable 
effects.  Wouldn't it be a good idea for us to give them some guidance, 
based on, as Eliot says, "the experience of nearly twenty years of odd 
interoperability failures".  I think so.  We can massage the wording, but I 
think it's not the best answer to say what Dave says above.  The fact is 
that many, many implementors *do*, in fact, need wording to help them out 
here, because they often *don't* know what they're doing -- not to the 
extent that those of us with many years of experience do.

> learn that they did not already know?

Right... If we're going to say something like this, it's probably a good 
idea to say why -- perhaps in a separate document (though I'm not sure how 
DRUMS would do that).

Barry Leiba, Internet Messaging Technology   ([email-masked])
http://www.research.ibm.com/people/l/leiba

---

From: Chris Newman <[email-masked]>
Date: Thu, 17 Aug 2000 12:39:44 -0700

Personally, I'd like to see some text in this area.  I'm very fond of the 
precision of John's text, but agree with some of the concerns expressed 
about scope.  I like Eliot's first paragraph, but the second is far too 
vague.

Here's an attempt to take the best of both and address concerns expressed:

-----
6.4 Interoperability with Noncompliant Implementations

This standard takes a stricter tone than its predecessor in order to 
discourage deployment of non-complaint software and to prevent harm caused 
by poorly designed attempts to interoperate with deployed non-compliant 
software.  It does so with the experience of nearly twenty years of odd 
interoperability failures, and with the realization that where-as thousands 
of people used SMTP at the time of RFC 821, now millions of people rely on 
the standard.  Non-conformance, therefore, can be far more costly.

If an implementation receives protocol which is not permitted by the 
specification and the specification does not mandate the response to such 
illegal protocol, the implementation can treat this as a negotiated a 
non-standard protocol.  At that point, the implementation is not 
constrained by the protocol specification in its handling of that 
particular connection.  Implmentations which choose to do this SHOULD 
narrowly tailor the accepted non-compliant protocol to that strictly 
necessary to interoperate with known deployed non-compliant software.

For example, if an SMTP server receives commands terminated by the ASCII
character "LF" but not containing the ASCII character "CR", it can decide
the SMTP client has negotiated a nonstandard variant of
the SMTP protocol wherein the <CRLF> sequence is encoded as a single
"LF" character.  The prohibition against recognizing the sequence
"<LF>.<LF>" as the end of mail data indication would then not apply to
that particular connection.

-----

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 17 Aug 2000 13:14:41 -0700

> more confused than it already is.

How does this make the distinction more confused?  The wording lists a
specific set of preconditions which must be satisfied in order for an
implementation to legitimately claim the specification does not apply.
 
> privacy of their own interactions.

This is absolutely incorrect.  It is this kind of wording, berefit of
necessary preconditions, that adds the kind of confusion complained
about.  A protocol engine must have reasonable proof that it is talking
to a peer that does not expect conformance before varying from the
specification.  Otherwise, it might "do anything they wish" with a peer
which is expecting conformance.

> to the intent of the other side.

is similarly too lax.  It is not sufficient that the peer demonstrate
failure to comply with the standard, it is also necessary that the
standard not require the implementation to react to that demonstration
in a particular way.

Part of the issue is that section 2.3.7 currently prohibits
implementations from recognizing a naked LF as a command line
terminator.  Unless the two words "recognize or" are removed, conforming
implementations have no freedom to handle this particular type of error.

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 17 Aug 2000 14:00:13 -0700

Chris Newman wrote:
> non-standard protocol.

This is grammatically incorrect.  It should be something like "...this
as a negotiation of a non-standard protocol."

Other than that the wording is acceptable, assuming that we also remove
"recognize or" from section 2.3.7.

---

From: Philip Hazel <[email-masked]>
Date: Fri, 18 Aug 2000 09:16:58 +0100 (BST)

> interoperability failures, and with the realization that where-as thousands 
                                                           ^^^^^^^^
                                                           whereas
                                       (at least, on this side of the pond)

> particular connection.  Implmentations which choose to do this SHOULD 
                          ^^^^^^^^^^^^^^

I am broadly in favour of some wording of this kind. There is a lot of 
"background culture" that has to be learned by implementors, not all of 
whom have been around for very long, and this will help them pick some 
of it up.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: DRUMS WG Chair <[email-masked]>
Date: Tue, 22 Aug 2000 14:43:20 -0700

The chair's observations about this thread:

* There is more support than opposition for wording along these lines, but 
not yet a rough concensus.

* There is a distinct lack of concensus on specific wording.

This thread is open for debate, please speak up if you believe you have 
something to say that has not yet been said.

If someone believes they can distill the concerns expressed on this thread 
into precise wording, please start a new thread where rough concensus on 
that specific wording can be determined based on the "Procedures for Moving 
Forward".

		- DRUMS WG Chair

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Aug 2000 04:28:26 -0700

I would like to separate two issues: wording of section 6.4 and whether
we strike "recognize" in section 2.3.7.

In reverse order, I believe we are at or near consensus on Chris'
wording, taking into account John's and Philip's changes.  Do others
disagree?

This standard takes a stricter tone than its predecessor in order to 
discourage deployment of non-complaint software and to prevent harm
caused 
by poorly designed attempts to interoperate with deployed non-compliant 
software.  It does so with the experience of nearly twenty years of odd 
interoperability failures, and with the realization that whereas
thousands 
of people used SMTP at the time of RFC 821, now millions of people rely
on 
the standard.  Non-conformance, therefore, can be far more costly.

If an implementation receives protocol which is not permitted by the 
specification and the specification does not mandate the response to
such 
illegal protocol, the implementation can treat this as a negotiated a 
non-standard protocol.  At that point, the implementation is not 
constrained by the protocol specification in its handling of that 
particular connection.  Implementations which choose to do this SHOULD 
narrowly tailor the accepted non-compliant protocol to that strictly 
necessary to interoperate with known deployed non-compliant software.

character "LF" but not containing the ASCII character "CR", it can
decide

-------

We are NOT in complete agreement on what to do about section 2.3.7, but
I believe we are arguing between a MUST/SHOULD and striking the word
"recognize".  As I wrote earlier, I could survive with SHOULD, but would
still prefer MUST, and I would not wish to hold up the draft in any
event.  My argument is that 6.4 should be taken into consideration wrt
2.3.7 as it would be with other parts of the document.  The document
doesn't mandate a RESPONSE to naked LFs.  It merely states they should
not be "recognized" as <CRLF>s.

Comments?
--
Eliot Lear
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Aug 2000 10:09:36 -0400

> wording, taking into account John's and Philip's changes.  Do others

The more I think about it, the less comfortable I am with the idea that 
a noncompliant SMTP "negotiates a nonstandard protocol".  There is a
significant difference between a bug and a protocol negotiation.
Protocol negotiations are explicit things; the meaning of a negotiation
and the means for negotiating the feature are (hopefully well-) defined 
in advance.  In the case of an implementation bug, the meaning of the
bug is not well-defined, and the other implementation (the one that
detects the bug) is guessing at what is meant.  This is inherently risky,
and while it may be operationally necessary in some cases, calling this 
a protocol negotiation makes it seem far safer and more legitimate than
it deserves. 

Arguably the standard already defines appropriate behavior of the server 
in the presence of a client that sends noncompliant commands; several error 
codes are defined for the very purpose of rejecting commands that exhibit 
such bugs.  Appropriate behavior of a client in the presence of a buggy 
server is less clear, and perhaps we should remedy that.

so here's another attempt at concrete wording

This standard takes a stricter tone than its predecessor in order to 
discourage deployment of non-complaint software and to prevent harm
caused by poorly designed attempts to interoperate with deployed 
non-compliant software.  It does so with the experience of nearly 
twenty years of odd interoperability failures, and with the realization 
that whereas thousands of people used SMTP at the time of RFC 821, 
now millions of people rely on the standard.  Non-conformance, 
therefore, can be far more costly.

An implementation which receives protocol which is not permitted
by the specification SHOULD (if it is a client) abort the attempt
to send the message and (if it is a server) reject the command
with an appropriate status code (rather than assume that the
non-complaint server will deliver the message).  However, it is 
recognized that non-complaint implementations are sometimes 
widely deployed, and that there is occasionally a compelling 
operational need for a client or a server to cope with 
non-complaint peers until such time as the peers can be fixed.  

An SMTP implementation MAY be configurable to deviate from the 
standard in order to meet operational requirements to cope with
specific non-compliant behavior that is believed to be 
well-understood, subject to the following constraints:

- The SMTP MUST continue to behave according to the standard when
communicating with peers that also appear to behave according to 
the standard, unless it has specific knowledge that the peer is
non-complaint,

- To the extent that an SMTP client or server is purposely ignoring
a protocol error or making assumptions about the nature of the bug 
which causes a protocol error, it SHOULD be possible to configure
the SMTP to reject that command (if it is a server) or abort sending
the message (if it is a client) in the presence of such errors.  Note 
this does not require an SMTP to check for every possible protocol 
error, it merely requires that workarounds for such bugs be optional 
for the operator.

- Options which enable bug workarounds SHOULD be disabled by default.
 
- Implementations which choose to do this SHOULD narrowly tailor 
the workaround to what is strictly necessary to interoperate with 
known deployed non-compliant software.

---

From: Robert Elz <[email-masked]>
Date: Wed, 23 Aug 2000 23:36:07 +1000

Almost everything in this thread has been about what can/should be
done with clients that send LF where they should be sending CR LF.

I'd like to leave that one aside for a minute and ask whether there
are any other areas of the protocol where "negotiated noncompliance"
(by pseudo-negotiation, rather than anything explicit, which is
what we're talking abut here) is considered to be likely to be useful,
or even necessary?

Would it be reasonable for a server that receives a RCPT TO without
having received a MAIL FROM to simply assume that the sender meant to
send "MAIL FROM:<>" (no information has been lost) and go on and
deliver the mail anyway?

How about if the client doesn't dot stuff its input (perhaps common
if the "client" in this case is a user telnet'd to port 25). Might
the server then not un-stuff any leading '.' lines (even if they start ..)
and not treat a '.' on a line alone as the end of message unless what
follows is something that looks like an SMTP command?

How far do we let servers go along this "I know what he was really trying
to do, though he stuffed it" response to broken clients, before the
server is declared broken as well?

Personally, I would prefer not at all.  Allowing this just entrenches
broken clients, which helps no-one long term.

On the LF issue specifically, do we have any evidence at all that any
large number of clients are still doing this?   I know that sendmail
used to default to send LF alone, but that was changed ages ago, anyone
with a sendmail that old should really be persuaded to upgrade, it is
for their own good, those ancient versions had bugs of other kinds...
(and it isn't as though a fix to the CR LF problem takes more than a
second to implement - it is in the .cf file after all - if the site can't
upgrade for some reason).

I heard rumours of some other clients that sent bare LF, though I don't
recall any of them ever being considered in any way major, or very
important - and if someone is stuck with such a mailer, they can always
just relay their mail through a non-conformant mailer which adds the
missing CRs before passing the mail to the rest of the world, so it isn't
as if anyone would be shut out of e-mail if most servers started enforcing
the CR LF rule --- and this assumes that there is anything left out there
in the world (other than perhaps an old sendmail which is trivially fixed)
which has this bug.

Let's speed the draft along, just leave the text unchanged - if someone
feels that their SMTP server just has to violate the rules for some reason
(and that is actually detected somehow) then let them explain why they have
to be non-conformant, and let the market decide.

kre

---

From: Philip Hazel <[email-masked]>
Date: Wed, 23 Aug 2000 16:36:04 +0100 (BST)

> what we're talking abut here) is considered to be likely to be useful,

Off the top of my head, some I have come across:

. Space character(s) after MAIL FROM: or RCPT TO:

. Local parts containing null components or having dots at either end.

. Multiple pairs of <>  e.g.   MAIL FROM:<<user@domain>>

> broken clients, which helps no-one long term.

I entirely agree. Unfortunately, the commercial world does not, and it's 
too late to put certain genies back into their bottles. Managers don't
want to be bothered with techical details. "Our clients worked with the
old MTA - go make the new MTA work with them too." is something that has
been passed on to me more than once. (The old MTA was "forgiving", you
see.)

> with a sendmail that old should really be persuaded to upgrade, 

So they upgrade to a new MTA, the clients that were broken now won't 
work any more, the managers start screaming at the techs who "broke" 
their email world... A lot of people run a lot of old software.

> it is

Of course I agree with you all the way, but I fear that the Real World 
(tm) doesn't work like that. At least, that's how it has been presented 
to me (in my ivory tower :-).

> to be non-conformant, and let the market decide.

That will of course be what happens anyway. I agree with you about 
speeding the draft along. Let's get it standardised. THEN we can start 
discussing where to go next.

---

From: Robert Elz <[email-masked]>
Date: Thu, 24 Aug 2000 02:30:46 +1000

Date:        Wed, 23 Aug 2000 16:36:04 +0100 (BST)
    From:        Philip Hazel <[email-masked]>
    Message-ID:  <[email-masked]>

  | . Space character(s) after MAIL FROM: or RCPT TO:
  | . Local parts containing null components or having dots at either end.

Those ones I'd be willing to simply include as legal in the first place.
I never really understood the dot rule (why they had to be treated so
magically, rather than just being another legal character, in local parts,
I suspect it just made the grammar easier, rather than being expressly
designed, but I am guessing).   But I believe that some others believe that
this is actually important for some reason (maybe some MTA actually enforces 
that rule?)   The spaces I think are totally harmless.

  | . Multiple pairs of <>  e.g.   MAIL FROM:<<user@domain>>

That one I'm less sure about - also no <> at all I think occurrs as well.
I'd be tempted to just ban that noise, and have people fix the broken stuff.

  | I entirely agree. Unfortunately, the commercial world does not, and it's 
  | too late to put certain genies back into their bottles. Managers don't
  | want to be bothered with techical details. "Our clients worked with the
  | old MTA - go make the new MTA work with them too." is something that has
  | been passed on to me more than once. (The old MTA was "forgiving", you
  | see.)

Oh - that isn't the kind of client/server interaction I was imagining.
For that there doesn't need to be this strange "negotiated noncompliance"
where the server just guesses for itself what the client is trying to do.

This is a "known situation" - the server can be expressly configured to
allow the violations committed by known broken clients that have to be
dealt with (that's the kind of thing I meant where I said broken clients
that can't be fixed can just relay through a MTA that will fix things).

I had assumed that this "negotiated non-compliance" stuff was intended for
your average MTA receiving messages from the big wide world of unknown
who knows whats, rather than from the local installed client base (the people
that have to be answered to).

I have no problems at all with MTAs being able to be configured to be
lenient, when their operator finds that is necessary for the environment.
The problem I have is when the MTA simply decides that it should be, without
anyone telling it to relax the restrictions.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Aug 2000 04:34:51 -0000

> SHOULD narrowly tailor

Are you using the definition of ``SHOULD'' from RFC 1123, or the
radically different definition from smtpupd, or some other definition?

I don't know whether the next version of smtpupd is going to be aligned
with the RFC 1123 definition. I haven't seen a clear statement from the
editor on this topic.

I don't see how we can reasonably discuss text using the word ``SHOULD''
when the definition is up in the air.

---Dan

---

From: Russ Allbery <[email-masked]>
Date: 23 Aug 2000 22:00:19 -0700

> with the RFC 1123 definition. I haven't seen a clear statement from the

I believe that the last summary I saw from the chair said that the
standard definitions were being imported into the document and then the
usage of SHOULD, MUST, and MAY will be reviewed to make sure they still
make sense.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: [email-masked] (Claus Färber)
Date: 25 Aug 2000 14:14:00 +0200

Robert Elz <[email-masked]> schrieb/wrote:
> large number of clients are still doing this?

Sending bare LF is not the only problem.

There is also an interoperability problem regarding the handling of bare  
LF on the receiving side. According to the current standard, bare LFs  
are allowed within mail data. However, I don't think that _any_  
implementation will actually handle it correctly.

The whole CRLF/LF problem is due to a implementation technique mandated  
by C/C++ libraries: They detect line endings based on the LF only. As a  
result this is what also most MTA implementations do. They then strip  
the CR and treat the result as a line.

So if they receive a bare LF, they either give an error because the CR  
is missing /or/ treat it as equivalent to CRLF. Both is illegal  
according to the standard (within message bodies).

Further, implementations on Unix-like systems tend to write the message  
to their queue or to user's mailboxes with their local line-ending  
conventions. So even if the smtpd part would handle bare LFs correctly,  
they would be converted to CRLF when the message is relayed to the next  
host via SMTP (or made available to a client via protocols such as IMAP,  
POP3 or even local file access).

So while sending bare LFs within mail bodies is allowed by the standard,  
it just won't work with most MTAs and MUAs running on the Internet.

It's too late to change the installed base of MTAs and MUAs. Better  
change the standard to explicitly disallow (or at least discourage) bare  
LFs within message texts.

Although I know it's very late, I thus propose the following change in  
section 4.1.1.4 DATA (DATA):

< codes, although experience has indicated that use of control characters
< other than SP, HT, CR, and LF (especially the ASCII "Null" character)
< may cause problems and SHOULD be avoided when possible.

> codes, although experience has indicated that use of control characters
> other than SP, CR and HT (especially the ASCII "Null" and bare LF
> characters) may cause problems and SHOULD be avoided when possible.

Claus

-- 
http://www.faerber.muc.de

---

From: Graham Klyne <[email-masked]>
Date: Wed, 30 Aug 2000 11:54:18 +0100

At 09:19 AM 8/17/00 -0400, Keith Moore wrote:
>outside of the scope of the standard.  ...

Yes!  While I appreciate the motivation for the texts offered, I think we 
want to try and avoid expending too many words on describing what the 
standard is not.  So, slightly re-working Keith's text might yield the 
following:

An implementation may deviate from this specification in an attempt to 
interwork with another non-conformant implementation, but any such behavior 
is outside of the scope of the standard.

[Note: lower case "may".]

#g