[Standards] hash agility in file transfer

Waqas Hussain waqas20 at gmail.com
Wed Jun 1 22:55:47 UTC 2011

On Thu, Jun 2, 2011 at 3:26 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Last year we had some discussions about hash agility in file transfer,
> as a result of which I made an interim version of XEP-0096:
> http://xmpp.org/extensions/diff/api/xep/0096/diff/1.1/vs/1.2rc1
> However, it seems that the XMPP Council never considered publication of
> that version. Do folks on the list think we need to do anything more
> than what's at that diff?
> (And yes, we might need to look at hash agility in other extensions,
> too, but we started with file transfer...)
> Peter

This way of going about hash agility has the same issue as the entity
caps hash's agility. You can only serve one hash, and you have no idea
what hashes the recipient supports. Senders would forever be stuck
with sending MD5, because doing otherwise will not be interoperable
with existing recipients, unless all clients were updated. The interop
failure case is quite severe, with the user possibly getting a prompt
that the transferred file is corrupted, data getting auto-discarded,

A simple solution is to use tags instead of attributes:
<hash algo="md5">552da749930852c69ae5d2141d3766b1</hash>

This lets clients which wish to use a stronger hash interop nicely
with clients which only support MD5. Tags also allow specifying
additional meta-data via attributes, and complex structured data which
is more than just a hex string.

But if we go with tags, do we even need to specify that? We can always
add tags later in new namespaces, even defined in new XEPs, e.g.
<hash xmlns="new sha1 xmlns">...<hash>
<sha1 xmlns="new XEP-0096 namespace, or even the existing namespace,
since the updated protocol is fully backwards compatible">...</sha1>

Waqas Hussain

More information about the Standards mailing list