[Standards] hash agility in file transfer

Peter Saint-Andre stpeter at stpeter.im
Thu Jun 9 16:59:40 UTC 2011

On 6/1/11 4:55 PM, Waqas Hussain wrote:
> 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,
> 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, I think you're right that we want separate elements, not
attributes. However, I think that's a breaking change to XEP-0096. Given
that we're moving away from XEP-0096 anyway, I think the best path
forward is to define a new format for XEP-0234, and make that new format
more extensible (or at least explicitly extensible).


Peter Saint-Andre

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

More information about the Standards mailing list