[Standards] UPDATED: XEP-0234 (Jingle File Transfer)
stpeter at stpeter.im
Fri Feb 19 21:37:05 UTC 2010
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards