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.
[Standards] UPDATED: XEP-0165 (Best Practices to Discourage JID Mimicking)
Version 0.5 of XEP-0165 (Best Practices to Discourage JID Mimicking) has been released. Abstract: This document recommends best practices to discourage mimicking of Jabber IDs. Changelog: Updated to reflect changes to XEP-0189 syntax; completed editorial review. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0165.xml?r1=320r2=1036 URL: http://www.xmpp.org/extensions/xep-0165.html
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
[Standards] XEP-0115 1.4pre2
http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html Diff from 1.4pre1: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1035r2=1037 Diff from 1.3: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1037r2=742 Version 1.3 is archived here: http://www.xmpp.org/extensions/attic/xep-0115-1.3.html /psa 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] [Fwd: [Council] meeting minutes, 2007-07-11]
FYI Original Message Date: Wed, 11 Jul 2007 12:16:30 -0600 From: Peter Saint-Andre [EMAIL PROTECTED] To: [EMAIL PROTECTED] Jabber-ID: [EMAIL PROTECTED] Subject: [Council] meeting minutes, 2007-07-11 Results of the XMPP Council meeting held 2007-07-11... Agenda: http://www.jabber.org/council/meetings/agendas/2007-07-11.html Log: http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-07-11.html 0. Roll Call Chris Mullins, Ian Paterson, Peter Saint-Andre, and Kevin Smith in attendance. Ralph Meijer absent. Quorum achieved. 1. Next meeting July 25. Kevin will not be available then. 2. XEP-0211: XMPP Basic Client 2008 Advance version 0.5 to Draft? Consensus on changing XEP-0115 to recommended given recent changes to that spec. Peter to publish version 0.6. Ralph to vote on list. 3. XEP-0212: XMPP Basic Server 2008 Advance version 0.5 to Draft? Ralph to vote on list. 4. XEP-0213: XMPP Intermediate IM Client 2008 Advance version 0.4 to Draft? Consensus on adding XEP-0155 (Stanza Session Negotiation) as recommended. Peter to publish version 0.5. Ralph to vote on list. 5. XEP-0216: XMPP Intermediate IM Server 2008 Advance version 0.2 to Draft? Ralph to vote on list. 6. XEP-0080: User Geolocation Approve version 1.4pre3? Chris and Ralph to vote on list. 7. XEP-0060: Publish-Subscribe Approve version 1.10pre1? Peter to update with preconditions protocol before Council approves changes. 8. XEP-0163: PEP Approve version 1.1pre4? Depends on changes to XEP-0060. Also, Ian and Peter to work on persistent data publishing profile of pubsub (name to be determined). 9. XEP-0108: User Activity Approve version 1.2pre1? No objections to publishing updated version. 10. XEP-0004: Data Forms Approve version 2.9pre2? Peter to update with text about submitter not modifying hidden fields and inclusion of new fields in the submission. Will push out version 2.9pre3 before Council approves changes (next meeting). 11. XEP-0077: In-Band Registration Approve version 2.3pre1? Ian objected that we need to fix a security issue before publishing any updated versions. Peter agreed. Ian and Peter to work on this. 12. XEP-0084: User Avatar Issue Last Call? Consensus to wait until pubsub/pep modifications are finished. 13. Proto-XEP: Server Dialback Accept as a XEP? Peter explained reasons for moving this text from rfc3921bis to a XEP. No objections. 14. Other Business Discussion of methods for encouraging implementation of ESessions, e.g., two in-person meetings for developers to complete interop testing and protocol clarification (one in N. America, one in Europe). /psa -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0108 (User Activity)
Version 1.2 of XEP-0108 (User Activity) has been released. Abstract: This document defines an XMPP protocol extension for communicating information about user activities. Changelog: Added on_video_phone activity. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0108.xml?r1=1041r2=912 URL: http://www.xmpp.org/extensions/xep-0108.html
[Standards] UPDATED: XEP-0211 (XMPP Basic Client 2008)
Version 0.6 of XEP-0211 (XMPP Basic Client 2008) has been released. Abstract: This document defines the XMPP Basic Client 2008 compliance level. Changelog: Changed XEP-0115 to recommended. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0211.xml?r1=964r2=1042 URL: http://www.xmpp.org/extensions/xep-0211.html
[Standards] UPDATED: XEP-0213 (XMPP Intermediate IM Client 2008)
Version 0.5 of XEP-0213 (XMPP Intermediate IM Client 2008) has been released. Abstract: This document defines the XMPP Intermediate IM Client 2008 compliance level. Changelog: Added XEP-0155 as recommended. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0213.xml?r1=928r2=1043 URL: http://www.xmpp.org/extensions/xep-0213.html
[Standards] NEW: XEP-0220 (Server Dialback)
Version 0.1 of XEP-0220 (Server Dialback) has been released. Abstract: This document provides documentation of the server dialback protocol. Changelog: Initial published version. (psa) Diff: N/A URL: http://www.xmpp.org/extensions/xep-0220.html
[Standards] NEW: XEP-0221 (Data Forms Media Element)
Version 0.1 of XEP-0221 (Data Forms Media Element) has been released. Abstract: This document specifies an XMPP protocol extension for including media data in XEP-0004 data forms. Changelog: [See revision history] (psa/ip) Diff: N/A URL: http://www.xmpp.org/extensions/xep-0221.html
[Standards] UPDATED: XEP-0158 (Robot Challenges)
Version 0.6 of XEP-0158 (Robot Challenges) has been released. Abstract: This document specifies an XMPP protocol extension that entities may use to discover whether the sender of an XML stanza is a human user or a robot. Changelog: Moved media element definition to XEP-0221; consistently used the terms sender and challenger rather than client and entity; modified provisional namespaces to adhere to XMPP Registrar policies; completed editorial review. (psa/ip) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0158.xml?r1=615r2=1047 URL: http://www.xmpp.org/extensions/xep-0158.html
[Standards] UPDATED: XEP-0159 (Spim-Blocking Control)
Version 0.3 of XEP-0159 (Spim-Blocking Control) has been released. Abstract: This document defines an XMPP protocol extension that enables clients to control how their servers may block spim that is addressed to them. It specifies a default privacy list fall-through action. Changelog: Updated to reflect move of privacy rules to XEP-0016; modified provisional namespaces to adhere to XMPP Registrar policies; completed editorial review. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0159.xml?r1=590r2=1048 URL: http://www.xmpp.org/extensions/xep-0159.html
[Standards] DRAFT: XEP-0211 (XMPP Basic Client 2008)
Version 1.0 of XEP-0211 (XMPP Basic Client 2008) has been released. Abstract: This document defines the XMPP Basic Client 2008 compliance level. Changelog: Per a vote of the XMPP Council, advanced to Draft. (psa) Diff: N/A URL: http://www.xmpp.org/extensions/xep-0211.html
[Standards] DRAFT: XEP-0212 (XMPP Basic Server 2008)
Version 1.0 of XEP-0212 (XMPP Basic Server 2008) has been released. Abstract: This document defines the XMPP Basic Server 2008 compliance level. Changelog: Per a vote of the XMPP Council, advanced to Draft. (psa) Diff: N/A URL: http://www.xmpp.org/extensions/xep-0212.html
[Standards] DRAFT: XEP-0216 (XMPP Intermediate IM Server 2008)
Version 1.0 of XEP-0216 (XMPP Intermediate IM Server 2008) has been released. Abstract: This document defines the XMPP Intermedate IM Server 2008 compliance level. Changelog: Per a vote of the XMPP Council, advanced to Draft. (psa) Diff: N/A URL: http://www.xmpp.org/extensions/xep-0216.html
