Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Lance Stout]

The reasoning behind creating a FT:4 was to leverage the core semantics of 
Jingle versus continuing to reinvent them inside of FT to solve some of the 
remaining open items in the FT:3 spec.

(The idea here being that a general Jingle session management implementation 
should have a well lit path for how to use its existing session management 
tools & data to support file transfer.)


Thus, instead of a bundle of files inside a single Jingle Content, there is a 
separate Content per file. That solves the unresolved issues in FT:3 about how 
to add (and remove!) additional files to the transfer session while it is in 
progress. In FT:4, we use the standard Jingle content-* actions. A nice side 
effect is that it means that the files do not need to wait for each other to 
download over a single connection, the data can be sent in parallel via 
multiple connections.

However, in the process of editing and creating FT:4, the  and 
 wrappers were removed, which appears to have removed the ability to 
request a file, but that case is still doable with FT:4. It now requires using 
core Jingle semantics instead of something inside FT itself. Namely, Jingle 
Contents may specify which side of the session is supposed to send data. This 
is an example of requesting files using FT:4



  

  

  65ea0164c91de2197956ed143099b90ff37d699e
  test.txt
  

  


  

  da39a3ee5e6b4b0d3255bfef95601890afd80709
  for-good-measure.txt
  

  

  



(Likewise for transfer offers, the Content should include `senders="initiator"` 
to indicate as such.)



I'm currently writing up patches to submit as a PR to add a section covering 
requesting files and the use of the content senders attribute, along with some 
additional examples and editorial fixes.


- Lance



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Dave Cridland]

While we're on the subject, is there any benefit to having a reestablish
mechanism in a more general sense? I'm thinking about the number of times I
tell colleagues that I'll call them right back - would we save much effort
in negotiation if we chose to repeat a previous session rather than create
a new one?

In this specific case, I don't see that jingle pub provides the same
semantic, without considerable effort and fiddling.
On 20 Jun 2015 13:09, "Yann Leboulanger"  wrote:

> Hi all,
>
> I just read the version 0.16 of Jingle File Transfer XEP, and saw that
> you removed the  flow.
> Just to mention that it is used in Gajim to re-request the file at the
> end of a tranfer when hash was wrong.
> I don't think it's a good thing to removed a feature without a
> replacement, that's not very nice for clients to remove a feature they
> implemented.
> Please note also that this  thing was used by XEP-0329 that is
> now no more implementable!
>
> Is there a way to have it back in the XEP or have a replacement XEP for
> that feature?
>
> --
> Yann
>
>

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On 7/13/15 5:12 PM, Emmanuel Gil Peyrot wrote:

On Mon, Jul 13, 2015 at 10:41:28PM +0200, Yann Leboulanger wrote:

But the way things are done is a bit strange. The feature was available and
working.
Removing a few lines in a XEP makes features no more available and another
depending XEP no more implementable and we now need to create another XEP to
workaround that.


XEP-0234 is an Experimental XEP, and as such was likely to get some
breaking changes before its promotion to the next state.  To quote
XEP-0001, §9.1, “Note: An Experimental specification is a work in
progress and may undergo significant modification before advancing to a
status of Draft.”

I do welcome that change, as it makes the XEP a lot simpler to
implement fully, and putting the removed features in some other XEP
doesn’t remove any usability from the clients which do implement it.


Actually I think the changes could have been handled much better in this 
instance, i.e., via more list discussion. That's my fault.


I agree about the ultimate goal of simplicity, but that doesn't excuse 
the lack of communication.


Peter

--
Peter Saint-Andre
https://andyet.com/

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Yann Leboulanger]

On 07/13/2015 09:37 PM, Tobias Markmann wrote:


On Mon, Jul 13, 2015 at 9:30 PM, Yann Leboulanger > wrote:


As there is no other answer, I guess nobody is interested in this
topic. Sad but I'll stay with :3 then.


Well.. there is http://xmpp.org/extensions/inbox/jingle-pub.html
Would this cover your use case and would there be interest seeing it 
becoming an Experimental and then Draft standard?


Trying to think to the scenario (I probably miss things):

for the re-send feature:
this mean that when we send a file to a contact, we also create a node 
that is accessible only by this contact (is that possible?) to which we 
push a jinglepub with this file. Then clients checks this node, choose 
the file he wants (base on what? previous jingle FT and this jinglepub 
have no link)


For the file sharing feature:
we need to create a node for each contact we want to share files with 
(or a public one)


But the way things are done is a bit strange. The feature was available 
and working.
Removing a few lines in a XEP makes features no more available and 
another depending XEP no more implementable and we now need to create 
another XEP to workaround that.


--
Yann

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Tobias Markmann]

On Mon, Jul 13, 2015 at 9:30 PM, Yann Leboulanger 
wrote:

> As there is no other answer, I guess nobody is interested in this topic.
> Sad but I'll stay with :3 then.
>

Well.. there is http://xmpp.org/extensions/inbox/jingle-pub.html
Would this cover your use case and would there be interest seeing it
becoming an Experimental and then Draft standard?

Cheers,
Tobias

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Yann Leboulanger]

On 06/21/2015 03:56 PM, Tobias Markmann wrote:
On Sat, Jun 20, 2015 at 2:08 PM, Yann Leboulanger > wrote:


I just read the version 0.16 of Jingle File Transfer XEP, and saw that
you removed the  flow.
Just to mention that it is used in Gajim to re-request the file at the
end of a tranfer when hash was wrong.


Does that happen without user interaction? Why should a retransfer not 
lead to the same errors when both implementations didn't change?


No, the user is notified that transfert went wrong and can choose to 
re-download file.



I don't think it's a good thing to removed a feature without a
replacement, that's not very nice for clients to remove a feature they
implemented.


Indeed. I think features should be removed if there are no known 
implementations of it or there

is at least a replacement XEP available.

Please note also that this  thing was used by XEP-0329
that is
now no more implementable!

Is there a way to have it back in the XEP or have a replacement
XEP for
that feature?


A new XEP would be nice implementing similar functionality. This would 
lower the barrier of implementation for basic Jingle file-transfer (so 
no requests and no multi-files) but allow more advanced clients to 
provide the functions if needed.


As there is no other answer, I guess nobody is interested in this topic. 
Sad but I'll stay with :3 then.


--
Yann

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Jefry Lagrange]

I vote for not moving towards supporting :4. There isn't a compelling 
reason to do it. So it is better to wait until (or if) there features 
are supported in the next version or in some other XEP.



On 20/06/15 16:13, Daniel Gultsch wrote:
2015-06-20 21:59 GMT+02:00 Yann Leboulanger >:


That will also break compatibility with clients that supports only :3
namespace, but currently we don't work with clients that have :4
namespace implemented. implementing several version of a protocol is
quite complexe.


Thats basically the reason I'm asking. My client Conversations 
currently only supports :3 and I'm not going to support both however I 
would upgrade to :4 if gajim were to do so as well and thus making 
Conversations compatible with Swift.


(Gajim, Conversations and Swift - to my knowledge - are the only 
clients supporting Jingle FT)


cheers
Daniel

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Tobias Markmann]

On Sat, Jun 20, 2015 at 2:08 PM, Yann Leboulanger 
wrote:

> I just read the version 0.16 of Jingle File Transfer XEP, and saw that
> you removed the  flow.
> Just to mention that it is used in Gajim to re-request the file at the
> end of a tranfer when hash was wrong.
>

Does that happen without user interaction? Why should a retransfer not lead
to the same errors when both implementations didn't change?


> I don't think it's a good thing to removed a feature without a
> replacement, that's not very nice for clients to remove a feature they
> implemented.
>

Indeed. I think features should be removed if there are no known
implementations of it or there
is at least a replacement XEP available.


> Please note also that this  thing was used by XEP-0329 that is
> now no more implementable!
>
> Is there a way to have it back in the XEP or have a replacement XEP for
> that feature?
>

A new XEP would be nice implementing similar functionality. This would
lower the barrier of implementation for basic Jingle file-transfer (so no
requests and no multi-files) but allow more advanced clients to provide the
functions if needed.

Cheers,
Tobias

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Daniel Gultsch]

2015-06-20 21:59 GMT+02:00 Yann Leboulanger :

> That will also break compatibility with clients that supports only :3
> namespace, but currently we don't work with clients that have :4
> namespace implemented. implementing several version of a protocol is
> quite complexe.
>

Thats basically the reason I'm asking. My client Conversations currently
only supports :3 and I'm not going to support both however I would upgrade
to :4 if gajim were to do so as well and thus making Conversations
compatible with Swift.

(Gajim, Conversations and Swift - to my knowledge - are the only clients
supporting Jingle FT)

cheers
Daniel

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Yann Leboulanger]

On 06/20/2015 09:41 PM, Daniel Gultsch wrote:
> out of curiosity does this mean you are working on implementing jingle
> file transfer 0.16 in gajim?
>

I was looking at it, but this would cause a regression in 2 of our
features: ability to re-request a file in hash is wrong and our file
sharing plugin (that is a work in progress for the moment)

That will also break compatibility with clients that supports only :3
namespace, but currently we don't work with clients that have :4
namespace implemented. implementing several version of a protocol is
quite complexe.

-- 
Yann

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Daniel Gultsch]

out of curiosity does this mean you are working on implementing jingle file
transfer 0.16 in gajim?

2015-06-20 14:08 GMT+02:00 Yann Leboulanger :

> Hi all,
>
> I just read the version 0.16 of Jingle File Transfer XEP, and saw that
> you removed the  flow.
> Just to mention that it is used in Gajim to re-request the file at the
> end of a tranfer when hash was wrong.
> I don't think it's a good thing to removed a feature without a
> replacement, that's not very nice for clients to remove a feature they
> implemented.
> Please note also that this  thing was used by XEP-0329 that is
> now no more implementable!
>
> Is there a way to have it back in the XEP or have a replacement XEP for
> that feature?
>
> --
> Yann
>
>

[Standards] XEP-0234 Jingle File Transfer 0.16

[Yann Leboulanger]

Hi all,

I just read the version 0.16 of Jingle File Transfer XEP, and saw that
you removed the  flow.
Just to mention that it is used in Gajim to re-request the file at the
end of a tranfer when hash was wrong.
I don't think it's a good thing to removed a feature without a
replacement, that's not very nice for clients to remove a feature they
implemented.
Please note also that this  thing was used by XEP-0329 that is
now no more implementable!

Is there a way to have it back in the XEP or have a replacement XEP for
that feature?

-- 
Yann