[Standards] XEP-0115 1.4pre1

Peter Saint-Andre stpeter at jabber.org
Wed Jul 11 14:37:16 UTC 2007

Ian Paterson wrote:
> 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.

No objections here. How about also formatting the category and type
information as "category" "/" "type" since that is how we usually show
them (e.g., "client/pc")?

> 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"?

It shouldn't. Leftover text from the previous version. Removed.

> 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)?

More leftover text. Removed.

> 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).



Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070711/cca3fe73/attachment.bin>

More information about the Standards mailing list