Peter Saint-Andre wrote:
I've made a first pass at updating XEP-0115 (Entity Capabilities) in
line with recent list discussion:
This looks like a good first pass.
- In section 1.2 "How it Works":
1. If Benvolio is publishing caps with a different 'node' but the same
'ver' then I don't need to perform another disco#info. So can you make
that clear from the outset by giving Benvolio a different node attribute
to Romeo in the example?
- When generating the ver attribute (section 5):
1. It would be more secure to include a delimiter character between the
various parts of the string E. The delimiter should be a '<' character
since it may not appear in an XML attribute value.
2. The big-endian array of bytes output by the hash function should be
converted directly to a base64 string, since converting it to a
hexadecimal string first only serves to double the length of the ver
attribute.
- Discovering Capabilities (Section 6.2)
Why should the client "pick a random JID from that list"?
Why is the disco#info query sent to a node of "node#ver" (see section
1.2 too). Why should "the capabilities supported by the base
installation of the application without plugins or other add-ons" be
returned, and not the capabilities that the client currently offers
(i.e. those that correspond to the hash value)?
Insert a point saying that clients SHOULD (MUST?) calculate the hash of
the returned identity and features to confirm that they correspond to
value of the 'ver' attribute (to prevent caps cache poisoning).
- Ian
