[Standards] UPDATED: XEP-0234 (Jingle File Transfer)

Jiří Zárevúcky zarevucky.jiri at gmail.com
Fri Feb 12 03:04:42 UTC 2010


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.

> Peter
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Toto je digit?ln? podepsan? ??st zpr?vy
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100212/e0edca1d/attachment.sig>


More information about the Standards mailing list