Pete Resnick wrote:
On 5/19/11 6:52 PM, Hector Santos wrote:
SHOULD is an optional requirement - Its a recommendation for the
better, but things will not break things for your peers if you don't
follow it. You may be shamed but the person shaming you is the one
wrong if they depended on a SHOULD operation as a MUST and his
software broke.
This is 100% incorrect, and if a WG were to produce a document where it
assumed the above definition of SHOULD, the chair should immediately put
the brakes on, because it should get bounced by the IETF Last Call and
the IESG Review. SHOULD has a singular meaning in IETF Standards Track
documents which cite RFC 2119, and it is stated quite clearly in section
3 and section 6 of that document. If anyone is using it differently,
they need to go back and re-read RFC 2119 *very* carefully. This is not
a matter of opinion. Implementations very much depend on the RFC 2119
definitions of these terms and this document had better as well.
pr
I was curious about how 100% incorrect I was:
From 2119:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
hmmm, I don't think my understanding is off base at all:
RECOMMENDED
reasons to ignore
Of course, any good protocol implementator is not normally going to go
against recommendations without good reason and there shouldn't be any
shock its common place especially for things that are controversial.
That 80% of the reason things of this nature are made SHOULD or MAY.
In this case, if this is enforced with a MUST, for a system that is
not 8BITMIME ready but is adding DKIM signing support, to remain
compliant it is far more feasible to add a rule to a DKIM signing
component:
If mail is 8bit then SKIP signing.
So unless this document is now going to revamp the mail industry by
stating all mail MUST be signed, this 8bit downgrading can not be
enforced.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html