[Standards] XEP-0115 redux

Wed Jan 9 17:14:42 CST 2008

OK folks, it seems that we're not quite there on XEP-0115 (Entity 
Capabilities), or at least that some people (especially important people 
with votes on the XMPP Council ;-) don't quite understand the logic 
behind certain aspects of what we agreed to on the list.

Three issues were raised during the Council meeting earlier today (see 
[0] for the relevant discussion). In this email message I present the 
issues in order of gravity. For each issue I provide a description, some 
discussion points (mostly based on previous list consensus), and my 
personal conclusion. I do not provide pointers to the list archives for 
each point, but they are publicly accessible. [1]

ISSUE #1: Do we need a new namespace?

Description: We have changed things around so radically since version 
1.3 [2] of the spec that maybe we need a new namespace (as we did for 
the Entity Time protocol).

Discussion: Yes we could do this, but then we'd have two separate entity 
capabilities notations in every presence notification that every user 
sent over the network, thus violating one of the requirements of 
XEP-0115 ("minimize network impact"). Therefore we have bent over 
backwards to not define a new namespace. The result is not the prettiest 
protocol in the world, but it doesn't break anything.

My conclusion: I am opposed to defining a new namespace.

ISSUE #2: Should the 'v' attribute be REQUIRED?

Description: The 'ver' attribute was REQUIRED in version 1.3 [2] of the 
spec. In a late change made to version 1.4 [3] of the spec during the 
Council meeting at which version 1.4 was approved, we suggested that the 
value of the 'node' should be "ProductURL#ProductVersion" (e.g., 
"http://psi-im.org/#0.11") but we agreed that this would *not* be 
REQUIRED or even officially RECOMMENDED. In the proposed version 1.5 [4] 
of the spec, we added a new attribute 'v' to encapsulate the software 
version, but it is only RECOMMENDED, *not* REQUIRED.

Discussion: Some people on the list objected strenuously to the late 
change made to version 1.4 [3] which suggested that the 'node' attribute 
should encapsulate the ProductVersion. Therefore the list consensus was 
that the 'node' attribute should be the ProductURL not including the 
ProductVersion, and that we would define a new attribute 'v' to 
communicate the ProductVersion; however, the list consensus was that 
this attribute would *not* be REQUIRED but instead only RECOMMENDED 
(some people argued for making it OPTIONAL or removing it altogether, 
but we settled on RECOMMENDED).

My conclusion: Leave version 1.5 [4] as it is now, with 'v' RECOMMENDED 
but *not* REQUIRED. (In fact I would not object to making it OPTIONAL, 
but RECOMMENDED seems closest to the prior list consensus.)

ISSUE #3: Which hashing algorithms?

Description: The Council discussion seemed to assume that version 1.5 
[4] says SHA-1 is mandatory-to-implement ("MTI"). In fact, version 1.5 
does not mandate implementation of any specific algorithm. Be that as it 
may, some Council members suggested that we recommend MD5 instead of 
SHA-1 (the only concrete reason I heard in the meeting is that MD5 
output is smaller).

Discussion: As far as I can see, we had consensus not to mandate any 
particular hashing algorithm, but instead to allow any algorithm that is 
registered with the IANA [5]. Currently the registered algorithms are 
md2, md5, sha-1, sha-224, sha-256, sha-384, and sha-512. However, we 
seemed to have list consensus that most people would use SHA-1 at the 
beginning (SHA-1 is the default value of the 'hash' algorithm in the 
currently-approved version 1.4 [3] of the spec), and perhaps switch to 
SHA-256 in the future if it is shown that pre-image attacks (see RFC 
4270) are likely against SHA-1. That said, people *could* implement MD5 
if they want to because it is registered with the IANA.

So I see several questions:

3a. Do we specify an MTI algorithm or let the market decide?

3b. If we specify an MTI algorithm, do we specify MD5 or SHA-1 or 
something else?

Right now (version 1.4), SHA-1 is the default value of the 'hash' 
attribute so it is essentially MTI. However, version 1.4 does not 
explicitly say that SHA-1 is MTI because it doesn't specify *anything* 
as MTI. However it seems like good idea to explicitly specify an MTI 
algorithm because that usually helps to ensure interoperability. If we 
decide to specify an MTI algorithm, I think we would specify SHA-1, 
because that is what list consensus seems to indicate as the preferred 
algorithm to start -- especially because version 1.4 (which specifies 
SHA-1 as the default) is approved and is the currently operative version 
of the spec.

My conclusion: Specify an MTI algorithm and say it is SHA-1, but allow 
other algorithms as registered with the IANA. If the market leans 
heavily toward MD5 or SHA-256, consider (in the future!) a change to the 
MTI algorithm by issuing an updated version of the spec (after proper 
list discussion etc.).

On a more general note, I think we have had list consensus on Issue #3 
for at least a few weeks now, on Issue #2 for about 2 months, and on 
Issue #1 for 6+ months. Not everyone was happy with the consensus, but 
everyone who participated in the list discussion agreed to give a little 
bit in order to reach consensus.

My final conclusion is that we need to accept the list consensus and 
move on. We have ensured backwards-compatibility, minimized network 
impact, improved security, and met the other requirements of the 
specification. You may not be in love with the final product, but 
sometimes consensus is rougher than others. Let's get this done, and 
soon, because people need to code against these specs (e.g., for 
compliance with the "XMPP Basic Client 2008" level specified in XEP-0211).

/psa

[0] 
http://logs.jabber.org/council@conference.jabber.org/2008-01-09.html#13:33:52

[1] See 
http://mail.jabber.org/pipermail/standards/2007-November/017085.html and 
http://mail.jabber.org/pipermail/standards/2007-December/017323.html

[2] http://www.xmpp.org/extensions/attic/xep-0115-1.3.html

[3] http://www.xmpp.org/extensions/attic/xep-0115-1.4.html

[4] http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html

[5] http://www.iana.org/assignments/hash-function-text-names
-------------- 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/20080109/fd07b5bf/attachment-0001.bin 