Re: [Standards] XEP-0115 1.4pre1
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
Re: [Standards] XEP-0115 1.4pre1
Le mercredi 11 juillet 2007, Ian Paterson a écrit : Why is the disco#info query sent to a node of node#ver (see section 1.2 too). I had the same interrogation : Why are we still using a node attribute at all ? Both in the presence and in the disco element it is useless. But it is probably for backward compatibility with the old XEP-0115. Also, i think the meaning of the deprecated ext attribute should be more documented in order to produce client compatible with the old XEP signature.asc Description: This is a digitally signed message part.
Re: [Standards] XEP-0115 1.4pre1
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. Done. - 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). Done. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115 1.4pre1
Peter Saint-Andre wrote:
Ian Paterson wrote:
- 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 very outset by giving Benvolio a different node
attribute to Romeo in the example?
Any objections to changing 'http://exodus.jabberstudio.org/caps' to
'http://psi-im.org/caps' in the second presence stanza in section 1.2
(i.e. the one from '[EMAIL PROTECTED]/230193')?
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.
OK, thanks. In that case, in Section 1.2 the text: '(note that the
disco#info query is sent to a node of node#ver)' and #{ver} in the two
disco#info examples also need to be removed.
Finally, a small typo, there's a double '' character in the line below
from section 5:
5. E =
'client/pchttp://jabber.org/protocol/disco#infohttp://jabber.org/protocol/disco#itemshttp://jabber.org/protocol/muc'
- Ian
Re: [Standards] XEP-0115 1.4pre1
Ian Paterson wrote:
Peter Saint-Andre wrote:
Ian Paterson wrote:
- 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 very outset by giving Benvolio a different node
attribute to Romeo in the example?
Any objections to changing 'http://exodus.jabberstudio.org/caps' to
'http://psi-im.org/caps' in the second presence stanza in section 1.2
(i.e. the one from '[EMAIL PROTECTED]/230193')?
That's what I had intended to do. :)
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.
OK, thanks. In that case, in Section 1.2 the text: '(note that the
disco#info query is sent to a node of node#ver)' and #{ver} in the two
disco#info examples also need to be removed.
Fixed.
Finally, a small typo, there's a double '' character in the line below
from section 5:
5. E =
'client/pchttp://jabber.org/protocol/disco#infohttp://jabber.org/protocol/disco#itemshttp://jabber.org/protocol/muc'
Fixed.
http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html has been updated
accordingly and changes have been checked into Subversion.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
[Standards] XEP-0115 1.4pre1
I've made a first pass at updating XEP-0115 (Entity Capabilities) in line with recent list discussion: http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=742r2=1035 Feedback is welcome as always. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
