On Wed Jun 25 08:30:14 2008, Iljitsch van Beijnum wrote:
Also note the difference between the two sides in a client-server
protocol. I recently used SHOULD where I would have liked to use
MUST but existing clients don't conform to the MUST so I used
SHOULD to indicate that servers must support clients that don't
have the feature.
Yes, the problem being that older client implementations otherwise
become cast into non-conformancy.
I think we should be biting the bullet and doing so, however -
otherwise we risk having the old behaviour used in new
implementations more than it would be otherwise. The primary reason
for doing the behaviour you describe is a kind of political
correctness, and introduces a political-SHOULD I'm not sure I care
for.
A phrasing like:
Clients MUST send bar; however implementations based on an earlier
revision of this specification are known to send foo, and therefore
servers MUST accept foo without error.
both casts these old clients into the oblivion of non-conformancy,
but also firmly establishes who to blame - ie, the specification and
not the implementation.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf