Melinda Shore wrote:
On 09/01/2011 11:25 AM, Hector wrote:
In my view, and honestly its hard to imagine how anyone can really
survive writing or implementing protocols especially as the complexity
increases, take any RFC, if you can't make the protocol work by
removing all the SHOULD|MAY [NOT] and just leaving behind the MUST
[NOT], then it really a bad specification and will drive people nuts
trying to get it right.
Can anybody point to an incident in which lack of clarity around
2119 language caused problems, and it was determined that 2119
itself was the problem and not authors or editors being careless?
Melinda, the closest incident apropo this is what happen in the DKIM
WG where a SHOULD for the optional SMTP extension 8BITMIME was argued
that based on RFC2119, a SHOULD is enough to mandate SMTP servers to
implement it, despite the fact that many didn't and it wasn't required
for DKIM to work. I personally took exception that a group of people
were called out as RFC2119 illiterates and that any SMTP server that
did not support 8BITMIME was non-compliant and broken already.
So personally don't see a problem with RFC2119, but a new perception
by overzealous authors using RFC2119 to impose methods on others.
I can only assume its due to the growth of new proposals with a high
dependency on a suite of optional protocols. Efforts to consolidate
and integrate well established but optional protocols to make thinks
work better as a whole. ESMTP, DKIM, IDN, IPv6, IPSEC etc, etc, etc,
all work better if "everyone" following a "All or nothing" methodology
- one way to encourage change is to change the rules of "conformance."
--
HLS
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf