On August 29 I posted to this list about some provisional changes that Joe Hildebrand and I made to XEP-0115:
http://mail.jabber.org/pipermail/standards/2007-August/016619.html Some discussion ensued here: http://mail.jabber.org/pipermail/standards/2007-August/016655.html http://mail.jabber.org/pipermail/standards/2007-August/016657.html http://mail.jabber.org/pipermail/standards/2007-August/016664.html http://mail.jabber.org/pipermail/standards/2007-August/016670.html http://mail.jabber.org/pipermail/standards/2007-August/016680.html http://mail.jabber.org/pipermail/standards/2007-August/016681.html As far as I can see the consensus was as follows (following the numbering from my email of August 29): 1. No objections to making the 'hash' attribute mandatory so that it flags whether you are using the legacy approach (version 1.3) or the modern approach (version 1.4 and higher). 2. No objections to changing the name of the 'hash' attribute to 'algo'. HOWEVER I think this is probably not a good idea at this point because I'm sure we have implementations of 1.4 now, so I propose that we leave it as 'hash'. 3. No objections to removing the default value for the 'hash' attribute, since not including the 'hash' attribute does not mean that you used the SHA-1 algorithm -- it means that you generated the 'ver' value according to the legacy approach. 4. Objections to specifying that the disco#info request should be sent to a specific node, not to the JID without a node. Specifically Sergei Golovan said: *** I think that it's not a good idea to send disco#info query to a specific node (concatenated node and ver attributes). Instead, queries should be sent to peer's JID without any node (as it is specified in version 1.4 of the XEP). If I understand correctly, this change was made for two reasons: 1) to make disco#info query the same as in version 1.3 of the XEP; 2) to prevent race condition when disco#info query is sent after the peer has changed features list (so, the new features list generates a different hash value). The first problem I see is that a client which indeed able to change its features must remember hashes for all possible combinations of features (at least those combinations which appeared in the current session). Otherwise, it simply can't answer disco#info query correctly. The second problem is that the answer to a disco#info query doesn't reflect a current client capabilities. So, the XEP introduces another race condition (which is worse in my opinion). Moreover, since the hash can be calculated in my client, I can hash the peer's capabilities without any info from his presence. And it's likely that the next capabilities hash in the presence packet will be this new one and not old one (which should reduce a network traffic little bit). *** Oliver Goffart agreed: http://mail.jabber.org/pipermail/standards/2007-August/016657.html Sergei's reasoning seems accurate to me, but I will look at it further. 5. Objections to the Council change in version 1.4 specifying that the value of the 'node' attribute should be "ProductURL#SoftwareVersion". Specifically Olivier Goffart said: *** And why should we put the version number in the node? If it is to substitute the XEP-0092, I think it's the wrong way. *** I don't think the intent was for the 'node' to provide the same information as is provided in XEP-0092. Kevin Smith's reasoning from (http://mail.jabber.org/pipermail/council/2007-August/002183.html) was as follows: *** <node> / <ver> I'd suggest we change node to be some amalgamation of the old node and ver tags. It could, in the future, be useful to be able to identify which implementation of a featureset you're being told about. With the old node and ver you could and with the new one you can't; making node node-ver would allow this. *** So it is not for use by the requesting application, it is for use by the responding application. Kevin's proposal seems fine to me and was approved by the Council. Is there a strong desire to remove "ProductURL#SoftwareVersion" as the recommended (not required) form of the 'node' attribute? 6. No objections to updating the security considerations slightly to mention that the service discovery 'name' attribute is ignored when generating the hash. 7. No objections to more fully specifying how the processing entity should handle caps data generated according to the legacy format. Sergei Golovan suggested the following: *** As for compatibility with clients supporting version 1.3 I would say that it should be optional and separately described. (If you don't see algo attribute then send disco#info to a node#ver. If you receive query to node#ver then reply to it or whatever.) Probably the 'node' attribute should be made optional too and should be used only if a client wants to be compatible with 1.3. But if it's desirable then some degree of compatibility may be required. *** That model for querying and processing caps information seems appropriate if we say that the query for version 1.4+ is to send to the JID without a node. Joe and I have argued that the 'node' attribute may be desirable even in 1.4+ implementations and the Council agreed. I still don't see a good reason to make it optional or deprecated, and Kevin's suggested format (see above) seems reasonable. 8. No objections to explicitly specifying that the 'ext' attribute is deprecated. So unless there are further objections, I will post version 1.5pre6 soon to incorporate the foregoing consensus. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
