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/pc
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/pc
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
Olivier Goffart wrote: > 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. Right. > Also, i think the meaning of the deprecated ext attribute should be more > documented in order to produce client compatible with the old XEP Yes, I think we need historical documentation of the legacy, non-hash approach in an appendix. Didn't get to that last night. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
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
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
[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=742&r2=1035 Feedback is welcome as always. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
