[Standards] XEP-0115: version 1.5 revisited

Peter Saint-Andre stpeter at stpeter.im
Thu Nov 8 17:32:19 UTC 2007

On August 29 I posted to this list about some provisional changes that
Joe Hildebrand and I made to XEP-0115:


Some discussion ensued here:


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

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:


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

So unless there are further objections, I will post version 1.5pre6 soon
to incorporate the foregoing consensus.


Peter Saint-Andre

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

More information about the Standards mailing list