[Standards] XEP-0115 1.4pre1

Ian Paterson ian.paterson at clientside.co.uk
Wed Jul 11 10:55:10 UTC 2007


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




More information about the Standards mailing list