ietf
[Top] [All Lists]

Re: 2119bis

2011-09-01 01:58:37
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>