Sounds like an never ending loop. 2119 is an RFC too and thus written in
"RFCish" as well.
To me, it only matters in terms of implementation - should we waste time
and money on implementing a SHOULD/RECOMMENDED feature? Is it required
to be coded? Can it be delayed, for version 2.0? Is it really needed,
competitively? Will something break if we don't add it?
A good example was the DKIM and BIT8MIME issue.
BIT8MIME is an SMTP extension, therefore NOT REQUIRED by SMTP servers to
support it.
It was determined the conversion and translation recommendations in
BIT8MIME helps DKIM function better with less integrity errors,
therefore there was an argument that all SMTP servers MUST support
BIT8MIME if they claim to support DKIM. There was an attempt to mandate
this in DKIM-BIS:
SMTP Servers MUST support BIT8MIME.
This created an immediate, resounding uproar and negative response
simply because not every SMTP server supported BIT8 MIME conversions.
So it was changed back to:
SMTP Servers SHOULD support BIT8MIME.
This shows the growing integration design and requirements pressure we
are in, especially with newer protocols that depend on other OPTIONAL
protocols in order to function correctly. The same is true with other
things like international conversions and translations, all currently
optional for the most part.
--
On 6/25/2013 10:08 AM, Scott Brim wrote:
On Tue, Jun 25, 2013 at 8:52 AM, Phillip Hallam-Baker
<hallam(_at_)gmail(_dot_)com> wrote:
I DO NOT agree that 2119 is the only source of consequence here.
Sorry. RFCs are not written in English, they are written in RFCish, a
language based in English but with modifications (specified in RFCs).
2119 overrides anything you might think you know about what words
mean.