Murray S. Kucherawy wrote:
Ditto. And I also see a lot of creative interpretation. There's little we
can do to thwart any of those problems; some people read what they want to
read and do so in a vacuum.
+1.
I couldn't agree with you more Murray!
When you consider that its not very hard to find mainstream software,
or even the one they are using to post mail in the list using well
established IETF protocols that follows RFC2119 to the letter, it
makes you wonder if there really a problem with RFC2119. I mean, I
don't see it myself. It reads pretty clear to me, especially section 6
with that precise non-ambiguous sentence.
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
That last sentence is so clear. Maybe the error is not using an
uppercase MUST NOT and NOT REQUIRED in that last sentence. Maybe
software people need logic statements like:
If X doesn't need Y, then MUST NOT use SHOULD to impose Y.
Honestly, this is like in the DKIM WG where DKIM tried to impose the
SMTP extension 8BITMIME on SMTP servers with a SHOULD keyword. DKIM
tried to make that a MUST but the DKIM WG rejected it, I guess because
too many SMTP servers did not support 8BITMIME and it wasn't really
required. I think one person had a problem or something like that and
because of them, DKIM wanted to force 8BITMIME on SMTP Servers. So
instead the DKIM WG was yelled at for being RFC2119 illiterates
because DKIM didn't need a MUST anyway a SHOULD was enough to mandate
8BITMIME and any SMTP server that didn't support 8BITMIME was broken
already. So the question here is:
Does DKIM need 8BITMIME in order to work correctly?
DKIM seems to be working fine without it.
I will say that I don't agree that there isn't much anyone can do to
thwart these problems. You really can by just sticking to engineering
conviction and point out which misinterpretations of RFC2119 can cause
some serious problems, like with SMTP!
STD10 (RFC821) has a SHOULD NOT drop connection before QUIT is
negotiated, and it was changed in RFC2821 to a MUST NOT. I guess
RFC2119, released during DRUMS, was misread to help provide the
rational that a SHOULD NOT is really not an option so why not make it
a MUST NOT? After all there is really no valid reason for not a client
not to seen a QUIT and all those clients that don't are broken!
But look at that Current Standard STD10 SHOULD to Proposed Standard
MUST did! Receivers now are forced to wait for the client to hangup
for upto 5 minutes and this allowed smart clients to leverage this
delay to hold the remote host connection to wait for more mail to
send. Is that a problem? Well, maybe not, but those smart clients
seem to think so warning client operators to:
- Use it Wisely,
- Seek Remote Host permission to consume computer resources
- Do no hold the server too long
- Its considered Anti-Social, and
- even foretold that is abuse remote hosts, they might begin
to drop you and block you!
Even with all those warnings from the smart clients leveraging the
delays, its ignored and increasingly happening and that server
defensive prediction is starting to come true - by selectively
ignoring the one RFC2821 MUST NOT drop connection mandate and
selective using STD10 SHOULD NOT which RFC2119 says is an option, you
don't need to follow it.
Its frustrating I must admit when people read RFC2119 with creative
interpretations to do things it doesn't what you to do!
--
HLS
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf