On 6/1/11 4:55 PM, Waqas Hussain wrote:
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=md5552da749930852c69ae5d2141d3766b1/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
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
