On 2/11/10 8:04 PM, Jiří Zárevúcky wrote: > Peter Saint-Andre píše v Čt 11. 02. 2010 v 19:42 -0700: >> On 2/11/10 5:29 PM, Jiří Zárevúcky wrote: >>> XMPP Extensions Editor píše v Čt 11. 02. 2010 v 18:06 -0600: >>>> Version 0.10 of XEP-0234 (Jingle File Transfer) has been released. >>>> >>>> Abstract: This specification defines a Jingle application type for >>>> transferring files between two entities. The protocol provides a >>>> modular framework that enables the exchange of information about >>>> the file to be transferred as well as the negotiation of parameters >>>> such as the transport to be used. >>>> >>>> Changelog: Described the file retrieval case; updated referenced >>>> namespaces. (psa) >>>> >>>> Diff: see http://xmpp.org/extensions/diff/ >>>> >>>> URL: http://xmpp.org/extensions/xep-0234.html >>>> >>> >>> The XEP has the same flaw as the original File Transfer. It sends >>> the file's hash before the transfer, >> >> Says who? The 'hash' is not mandatory in the schema from XEP-0096: >> >> <xs:attribute name='hash' type='xs:string' use='optional'/> >> > > Yes. What I mean is the case when I do want to send the hash. > >>> which means the sender needs to >>> hash the file first (potentially very time-consuming). If the >>> transfer is terminated, the receiver won't use it anyway. >>> >>> Allowing the hash to be sent after the transfer is finished would >>> allow the sender to hash it while sending, making it much more >>> convenient and usable feature. >> >> We could certainly define a jingle-info payload to communicate the hash >> after the fact, and add some text about leaving the hash out of the offer. >> > > That would be great.
Done in my working copy, will push out a new version soon. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
