On Sat Oct 4 01:18:45 2008, Matthew Wild wrote:
I thought I recalled some discussion on the lists already regarding
this, but I haven't been able to find it. On resource binding, the
RFC
says the server MAY modify the client's chosen resource. Is there a
reason that it doesn't say "If the client provides a resource, the
server SHOULD use this" instead?
To take this argument is a rather different direction, it's important
to understand that MAY, SHOULD, and MUST as defined in RFC 2119 are
not concerned with "good ideas" and community preferences, but
interoperability requirements.
So server implementors ought to be aware that "MAY" provides no
information at all, positive or negative, about whether client
implementors and users alike will track them down and beat them over
the head with an iron bar. But then, nor does "SHOULD".
"SHOULD" here would imply that if servers do not use a
client-supplied resource where available, then sometimes things might
break, and other Bad Things will more than likely occur.
So "Oh, it's terribly annoying when my resource is changed" is not a
good argument. Nor, indeed, is "I rely on a fixed resource", because
servers have always been capable of changing the supplied resource,
so from an interop standpoint, "Clients MUST NOT rely on a server
accepting their supplied resource".
Reading through this, there are obviously some definite cases (like
reconnection), where there is poorer service due to servers changing
the resource, so I'd support a SHOULD here. There have been arguments
on the IETF mailing list that any SHOULD ought to have information
about why not, and when might be an acceptable reason for ignoring
the SHOULD.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
