stpeter at jabber.org
Fri Jun 13 12:46:42 CDT 2003
On Fri, Jun 13, 2003 at 11:08:07AM -0600, Joe Hildebrand wrote:
> Sorry. A couple more quick nits.
No apologies necessary, we need to get this right.
> "note that any non-ASCII characters MUST be encoded as UTF-8" but should
> also probabl say, "with all appropriate XML escaping" or something. And
> perhaps an "obviously" on the front. :)
I've changed it so say this:
(obviously, characters that map to predefined XML entities MUST be
escaped according to the rules defined in section 4.6 of the XML
specification, and any non-ASCII characters MUST be encoded according
to the encoding of the XML stream, i.e., either UTF-8 or UTF-16)
> In Example 6, it should be easier to tell that this is a digest of 3EE948B0
> + Calli0pe (which I assume it is without doing the math).
That was left as an exercise to the reader, but I've made it explicit
> SHOULD the server return the bad query on error? MAY it? I think it SHOULD
> NOT, since the client already knows what it sent. (Example 8,9,10)
That's a SHOULD in XMPP Core, but we can override that and say SHOULD
NOT here. It's not good to send this information more than necessesary.
> In security considerations:
> "Client implementations SHOULD NOT implement the plaintext mechanism, MUST
> NOT make it the default mechanism, and MUST warn the user that the plaintext
> mechanism is insecure."
> Unless the channel is encrypted (using SSL or TLS) and the server is
> authenticated with a certificate that is signed by a trusted CA.
Um, did you mean that clients SHOULD NOT implement it, or that it SHOULD
NOT be used? Those are different things. :) I agree it should not be
used unless the channel is encrypted blah blah blah, but I can't even
use it if the client does not implement it.
More information about the Council