----- Original Message ----- From: "Michael F Lin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 06, 2002 4:10 PM Subject: Re: [JDEV] File transfers
> Richard, by your logic, every ISP and backbone provider over which > copyrighted materials are transferred are liable, since "they were helping > users transfer files between each other". Clearly, there is a major > distinction between something like the Internet or Jabber that have many > totally legitimate uses, but unfortunately may be put to nefarious > purposes; and something like Napster where it is at least a challenge to > convincingly argue that it has viable, legal applications. Yes but there is a significant difference, ISP's and backbone providers are providing simply providing data paths, Jabber is an application on top of that backbone facilitating the data sharing, the ISP's network on its own without applications transferring data over it is not facilitating the data sharing, applications such as Jabber and Kazza are which is why Jabber is at risk from legal proceedings. > Moving transfers out of band is fine, however, it would be highly > advantageous for whatever band you move them into to fully adopt JID > routing rules. This is the trouble with using PASS - you are still on your > own to configure it around firewalls and such. The idea I'm pushing is that > we are setting up Jabber servers so that they can straddle firewalls; it > should not be necessary for clients to figure this out too in order to > transfer larger amounts of data. I should be able to tell PASS a *JID* that > I want to communicate with, and *PASS* should do all the remaining work, > negotiating with other PASS components if necessary, and return back to me > an IP and port to which to connect. Good at least you have dropped the horrible idea of transfering the data in-band. I dont mind if another solution is found, my main point was that the data should not be sent in-band and should be sent in between the end points. I used PASS as an example because that is a defined method of transfer which was firewall friendly. > The most important argument I can propose is that we are not solving new > problems. We are sitting on top of 30 years of research and trial and error > in network architecture, and we are really doing the exact same things, > just on a higher level. These problems we are talking about, have all been > solved before. > > When you send a packet to some IP address, it is not up to your client > machine to figure out which routers it needs to hop along the way. You just > send it into the cloud, and the network does the rest. Fine then why not have a process like this: S = Sender R = Receiver S (file send request)-> R R (request result, e.g. accept deny)-> S If accepted: S (sets up port, or gets one via PASS, or SOCKS, sends connect command)-> R R (connects to sender, transfers file over socket)-> S This is a little different from your premise that the receiver should be the one opening the socket, I think it should be the sender, which is how it works in most IM and file transfer systems, it means it is thes sender that possibly exposes himself and not the receiver. Although in this way if the receiver wants the sender to connect to him the protocol can allow this because the receiver could send a connect command instead of an accept to the sender. Richard _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
