Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Richard Dobson]

Or:

- company policy forbids p2p file transfer
- server-side virus checking desired/required before download

It is difficult to define consistent requirements for consumer-oriented
services on the open internet and employee-oriented services within
enterprise deployments.


Virus scanning could be done with a slightly modified XEP-65 proxy, the 
proxy could receive the entire stream before passing it on and virus 
scanning it before they do, there are also virus scanners that can 
detect viruses in the stream (without having to have received the whole 
stream) and terminate it before it finishes if it detects one, there are 
many different ways that we can slice this one.


But yes its difficult to create a one size fits all solution here, the 
best option we have is to produce a selection to standards (that 
hopefully don't have too much overlap and can inter operate) that 
address all the requirements and developers can then pick and choose 
which is best for them.


Richard

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Michal 'vorner' Vaner]

Hello

On Tue, Sep 18, 2007 at 11:41:43AM -0600, Peter Saint-Andre wrote:
> - company policy forbids p2p file transfer
> - server-side virus checking desired/required before download

Couldn't it be solved like this:

1) One of them has a public IP -> does an HTTP server, the onther one
gets/puts
2) HTTP proxy server somewhere in the middle (One puts, one gets, does
not get stored).

You can get antivirus checks by that, and it is http, so good firewalls
should let it trough as they recognize it.

However, if admins forbid file transfers, then they will do it anyway
somehow. I wouldn't fight them, if it makes the thing less usable in
the "normal" way.

-- 
The cost of living is going up, and the chance of living is going down.

Michal 'vorner' Vaner


pgpYzBW9asjFU.pgp
Description: PGP signature

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Peter Saint-Andre]

Olivier Goffart wrote:
> Le vendredi 14 septembre 2007, Michal 'vorner' Vaner a écrit :
>> Hello
>>
>> On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote:
>>> Title: Requirements for IM File Transfer
>> With some more thinking, I have few more things that would be good to
>> have:
>>
>> • Serverless mode (for link-local)
>> • Doesn't go to server and back on LAN (If you have bad internet
>> connection, but more computers on LAN).
>> • Way of checking the transfer went well - some kind of hash
>> • Sending whole directories (may be another XEP, that just advertises a
>> directory with all its files and will auto-accept an transfer for each
>> of the files)
>> • I often hear people asking, if encrypted transfers are possible
>>
>> Furthermore, it should be easy to implement. (if we just all had IPv6,
>> simple TCP connection would work)
> 
> I agree that P2P filetransfer should be used whenever possible.
> 
> A server should be used only if:
>  - restrictive firewall or NAT make P2P impossible or difficult.
>  - sending to a contact which is offline
>  - willing to send the same file to multiple senders

Or:

- company policy forbids p2p file transfer
- server-side virus checking desired/required before download

It is difficult to define consistent requirements for consumer-oriented
services on the open internet and employee-oriented services within
enterprise deployments.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Tobias Markmann]

For sending a file to multiple recipients something BitTorrent like could be
used too, which bases on Jingle and ICE if someone is willing to write down
a XEP. But maybe that's beyond the usual IM P2P features. ;)

Cheers
Tobias

On 9/14/07, Olivier Goffart <[EMAIL PROTECTED]> wrote:
>
> Le vendredi 14 septembre 2007, Michal 'vorner' Vaner a écrit:
> > Hello
> >
> > On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote:
> > > Title: Requirements for IM File Transfer
> >
> > With some more thinking, I have few more things that would be good to
> > have:
> >
> > • Serverless mode (for link-local)
> > • Doesn't go to server and back on LAN (If you have bad internet
> > connection, but more computers on LAN).
> > • Way of checking the transfer went well - some kind of hash
> > • Sending whole directories (may be another XEP, that just advertises a
> > directory with all its files and will auto-accept an transfer for each
> > of the files)
> > • I often hear people asking, if encrypted transfers are possible
> >
> > Furthermore, it should be easy to implement. (if we just all had IPv6,
> > simple TCP connection would work)
>
> I agree that P2P filetransfer should be used whenever possible.
>
> A server should be used only if:
> - restrictive firewall or NAT make P2P impossible or difficult.
> - sending to a contact which is offline
> - willing to send the same file to multiple senders
>
> One could imagine that each contact has a shared folder (in another XEP)
> where
> all contacts could pick files from.
>
>

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Unnikrishnan V]

 thinking loud, It may be better to increase the message types and making
use cases and rules around it for rest all needs.

ex: is i can call somebody and the other person can respond with a text
message or add voice to a shared whiteboard session or share my notes  in a
voice session

thanx
unni



On 9/14/07, Kevin Smith <[EMAIL PROTECTED]> wrote:
>
> On 14 Sep 2007, at 21:59, Unnikrishnan V wrote:
> > The shared white board and file transfer thread looks to me like
> > we need a more generic  session protocol which is capable of doing
> >
> > 1) Whiteboard
> > 2) File transfer
> > 3) Voice/ Video
> > 4) chat and MUC
> >
> >
> > mostly based on the  than  ( it looks the core
> > requirement is to  "work with with the message session"  )  and
> > able to accommodate new services comes up.
>
> Isn't that XMPP?
>
> /K
>
>

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Kevin Smith]

On 14 Sep 2007, at 21:59, Unnikrishnan V wrote:
The shared white board and file transfer thread looks to me like   
we need a more generic  session protocol which is capable of doing


1) Whiteboard
2) File transfer
3) Voice/ Video
4) chat and MUC


mostly based on the  than  ( it looks the core  
requirement is to  "work with with the message session"  )  and  
able to accommodate new services comes up.


Isn't that XMPP?

/K

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Unnikrishnan V]

The shared white board and file transfer thread looks to me like  we need a
more generic  session protocol which is capable of doing

1) Whiteboard
2) File transfer
3) Voice/ Video
4) chat and MUC


mostly based on the  than  ( it looks the core requirement
is to  "work with with the message session"  )  and able to accommodate new
services comes up.

It should be able to add /remove participants and able to do push at
required stages.

reason why i think so: we need new extensions for managing session and we
are brainstorming for that. Final out put can be one xep for generic
framework protocol and contents and transports or one xep for every service
( means white board, file transfer etc etc ) . The later makes really
complicated and tough to implement.

thanx
unni


On 9/14/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>
> Matthew Wild wrote:
> > On 9/13/07, *Tobias Markmann* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Exactly. You can't expect an IM client to handle transfers of CD or
> > DVD image sized files. For these large files protocols like
> > BitTorrent have been developed and work really nice on doing that.
> >
> >
> > I found myself receiving a file over 200MB only yesterday, simply
> > because it was the easiest way to do it. Protocols like BitTorrent are
> > more for publishing files, than direct file transfer.
> >
> > I don't see why it is *necessary* for the protocol to place a limit on
> > file size at all, barring technical (implementation?) restrictions.
>
> I'm not saying that "the" protocol needs to limit the file size. I'm
> saying that we need to think about how to handle different file sizes,
> since the size of the file may have an impact on the choice of file
> transfer method (e.g., you may want to send really small files via IBB
> but not really big files).
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Peter Saint-Andre]

Matthew Wild wrote:
> On 9/13/07, *Tobias Markmann* <[EMAIL PROTECTED]
> > wrote:
> 
> Exactly. You can't expect an IM client to handle transfers of CD or
> DVD image sized files. For these large files protocols like
> BitTorrent have been developed and work really nice on doing that. 
> 
> 
> I found myself receiving a file over 200MB only yesterday, simply
> because it was the easiest way to do it. Protocols like BitTorrent are
> more for publishing files, than direct file transfer.
> 
> I don't see why it is *necessary* for the protocol to place a limit on
> file size at all, barring technical (implementation?) restrictions.

I'm not saying that "the" protocol needs to limit the file size. I'm
saying that we need to think about how to handle different file sizes,
since the size of the file may have an impact on the choice of file
transfer method (e.g., you may want to send really small files via IBB
but not really big files).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Richard Dobson]

Tobias Markmann wrote:
I use if for direct file transfers of big files too because the 
BitTorrent clients are able to continue abort transfers and validate 
the transferred data via hashs. As far as I know none of the protocols 
listed in the proposed XEP support continue abort/paused transfers but 
in SOCKS5 there is an option to pass a hash of the file to validate it.


XEP-0096 has support for continue transfers from where you left off... 
You probably just need to send a bug report to the authors of whatever 
client you are using where this doesn't work.


Richard

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Michal 'vorner' Vaner]

Hello

On Fri, Sep 14, 2007 at 09:39:13AM +0200, Tobias Markmann wrote:
> I use if for direct file transfers of big files too because the BitTorrent
> clients are able to continue abort transfers and validate the transferred
> data via hashs. As far as I know none of the protocols listed in the
> proposed XEP support continue abort/paused transfers but in SOCKS5 there is
> an option to pass a hash of the file to validate it.

I'm not sure if it is in the XEP, but Psi allows continue of aborted
transfer. It even has a "pause" button. I didn't study how exactly it
does.

-- 
The cost of living is going up, and the chance of living is going down.

Michal 'vorner' Vaner


pgp89uXRiMkHI.pgp
Description: PGP signature

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Olivier Goffart]

Le vendredi 14 septembre 2007, Michal 'vorner' Vaner a écrit :
> Hello
>
> On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote:
> > Title: Requirements for IM File Transfer
>
> With some more thinking, I have few more things that would be good to
> have:
>
> • Serverless mode (for link-local)
> • Doesn't go to server and back on LAN (If you have bad internet
> connection, but more computers on LAN).
> • Way of checking the transfer went well - some kind of hash
> • Sending whole directories (may be another XEP, that just advertises a
> directory with all its files and will auto-accept an transfer for each
> of the files)
> • I often hear people asking, if encrypted transfers are possible
>
> Furthermore, it should be easy to implement. (if we just all had IPv6,
> simple TCP connection would work)

I agree that P2P filetransfer should be used whenever possible.

A server should be used only if:
 - restrictive firewall or NAT make P2P impossible or difficult.
 - sending to a contact which is offline
 - willing to send the same file to multiple senders

One could imagine that each contact has a shared folder (in another XEP) where 
all contacts could pick files from.


signature.asc
Description: This is a digitally signed message part.

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Tobias Markmann]

I use if for direct file transfers of big files too because the BitTorrent
clients are able to continue abort transfers and validate the transferred
data via hashs. As far as I know none of the protocols listed in the
proposed XEP support continue abort/paused transfers but in SOCKS5 there is
an option to pass a hash of the file to validate it.

Cheers,
Tobias

On 9/14/07, Matthew Wild <[EMAIL PROTECTED]> wrote:
>
> On 9/13/07, Tobias Markmann <[EMAIL PROTECTED] > wrote:
> >
> > Exactly. You can't expect an IM client to handle transfers of CD or DVD
> > image sized files. For these large files protocols like BitTorrent have been
> > developed and work really nice on doing that.
> >
>
> I found myself receiving a file over 200MB only yesterday, simply because
> it was the easiest way to do it. Protocols like BitTorrent are more for
> publishing files, than direct file transfer.
>
> I don't see why it is *necessary* for the protocol to place a limit on
> file size at all, barring technical (implementation?) restrictions.
>
> Matthew.
>
> >
>

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Michal 'vorner' Vaner]

Hello

On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote:
> Title: Requirements for IM File Transfer

With some more thinking, I have few more things that would be good to
have:

• Serverless mode (for link-local)
• Doesn't go to server and back on LAN (If you have bad internet
connection, but more computers on LAN).
• Way of checking the transfer went well - some kind of hash
• Sending whole directories (may be another XEP, that just advertises a
directory with all its files and will auto-accept an transfer for each
of the files)
• I often hear people asking, if encrypted transfers are possible

Furthermore, it should be easy to implement. (if we just all had IPv6,
simple TCP connection would work)

-- 
There's the light at the end of the the Windows.
   -- Havlik Denis

Michal 'vorner' Vaner


pgp7o65BfP5Rt.pgp
Description: PGP signature

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Michal 'vorner' Vaner]

Hello

On Thu, Sep 13, 2007 at 04:50:15PM -0600, Peter Saint-Andre wrote:
> Michal 'vorner' Vaner wrote:
> > Hello
> > 
> > On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote:
> >> The XMPP Extensions Editor has received a proposal for a new XEP.
> >>
> >> Title: Requirements for IM File Transfer
> > 
> > May I add that it is sometime desirable to transfer large files, 
> 
> How large is "large"? Just curious!
> 
> I didn't address file size at all in the requirements yet, but I think
> it may help to think about what we mean by "large" and "small". I have
> heard of some companies where it is not rare for an email attachment to
> be 2G!

I was already sending a CD image to someone, I may want to send a DVD. I
do not want any restriction on the size, actually, only my internet
connection - not of my server/whoever else.

Actually, the current file transfer works for them without problems
(some clients has problems with larger than 2G files and they show the
size wrong, causing the progressbar unusable, but transfered them well).

> > so they
> > must go "trough" and not get saved as whole somewhere.
> 
> I'm not sure what you mean by "go through and not get saved as a whole
> somewhere". Does that mean the file never even exists on the sender's
> device, that it doesn't get stored in the middle somewhere?

It doesn't get stored in the middle, noone will not let me store it, if
it is so large and it will take a long time to upload, then long time to
download.

If it is not stored, then it is only one long time to transfer.

> And part of what we need to consider is how many potential recipients
> there might be. If there are lots of recipients, a technology like
> torrent is probably more appropriate.

-- 
Fragile. Do not turn umop ap1sdn!

Michal 'vorner' Vaner


pgpgAfqsKJ5Ge.pgp
Description: PGP signature

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Matthew Wild]

On 9/13/07, Tobias Markmann <[EMAIL PROTECTED]> wrote:
>
> Exactly. You can't expect an IM client to handle transfers of CD or DVD
> image sized files. For these large files protocols like BitTorrent have been
> developed and work really nice on doing that.
>

I found myself receiving a file over 200MB only yesterday, simply because it
was the easiest way to do it. Protocols like BitTorrent are more for
publishing files, than direct file transfer.

I don't see why it is *necessary* for the protocol to place a limit on file
size at all, barring technical (implementation?) restrictions.

Matthew.

>

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Tobias Markmann]

Exactly. You can't expect an IM client to handle transfers of CD or DVD
image sized files. For these large files protocols like BitTorrent have been
developed and work really nice on doing that.

On 9/14/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>
> Michal 'vorner' Vaner wrote:
> > Hello
> >
> > On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote:
> >> The XMPP Extensions Editor has received a proposal for a new XEP.
> >>
> >> Title: Requirements for IM File Transfer
> >
> > May I add that it is sometime desirable to transfer large files,
>
> How large is "large"? Just curious!
>
> I didn't address file size at all in the requirements yet, but I think
> it may help to think about what we mean by "large" and "small". I have
> heard of some companies where it is not rare for an email attachment to
> be 2G!
>
> > so they
> > must go "trough" and not get saved as whole somewhere.
>
> I'm not sure what you mean by "go through and not get saved as a whole
> somewhere". Does that mean the file never even exists on the sender's
> device, that it doesn't get stored in the middle somewhere?
>
> And part of what we need to consider is how many potential recipients
> there might be. If there are lots of recipients, a technology like
> torrent is probably more appropriate.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Peter Saint-Andre]

Michal 'vorner' Vaner wrote:
> Hello
> 
> On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Requirements for IM File Transfer
> 
> May I add that it is sometime desirable to transfer large files, 

How large is "large"? Just curious!

I didn't address file size at all in the requirements yet, but I think
it may help to think about what we mean by "large" and "small". I have
heard of some companies where it is not rare for an email attachment to
be 2G!

> so they
> must go "trough" and not get saved as whole somewhere.

I'm not sure what you mean by "go through and not get saved as a whole
somewhere". Does that mean the file never even exists on the sender's
device, that it doesn't get stored in the middle somewhere?

And part of what we need to consider is how many potential recipients
there might be. If there are lots of recipients, a technology like
torrent is probably more appropriate.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer

[Michal 'vorner' Vaner]

Hello

On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Requirements for IM File Transfer

May I add that it is sometime desirable to transfer large files, so they
must go "trough" and not get saved as whole somewhere.

-- 
Fragile. Do not turn umop ap1sdn!

Michal 'vorner' Vaner


pgpByVnUvruew.pgp
Description: PGP signature