On Thu, Jun 2, 2011 at 3:26 AM, Peter Saint-Andre <stpe...@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, etc. 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> or <sha1 xmlns="new XEP-0096 namespace, or even the existing namespace, since the updated protocol is fully backwards compatible">...</sha1> -- Waqas Hussain
