Hi, From my understanding of the descriptions of the two iq tags, they are used only to send the URL to the client. The client then goes to the URL to retrieve the file. Am I right? Is there anyway to do a direct client-to-client file transfer? Any help would be appreciated. Thanks, Julie [EMAIL PROTECTED] wrote: > Send jdev mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.jabber.org/listinfo/jdev > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of jdev digest..." > > Today's Topics: > > 1. Re: OOB filetransfer negotiation (Jens Alfke) > 2. Re: OOB filetransfer negotiation (Sebastiaan 'CBAS' Deckers) > 3. Re: OOB filetransfer negotiation (Thomas Charron) > 4. Re: Security Jig Meeting (Robert Norris) > > --__--__-- > > Message: 1 > Date: Sat, 11 Aug 2001 09:57:46 -0700 > Subject: Re: [JDEV] OOB filetransfer negotiation > From: Jens Alfke <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > > On Saturday, August 11, 2001, at 01:06 AM, Sebastiaan 'CBAS' Deckers > wrote: > > > I'm trying to figure out how exactly file-transfers get negotiated. > > WinJab seems to use an <iq> with namespace "jabber:iq:oob" containing > > the > > URL of the file. > > Oh boy, that's a new one to me! I keep finding more and more of these > secret protocol extensions. The "standard" way to transfer files, which > I've implemented, is to send a <message> containing a jabber:x:oob > extension element -- this is documented in the JPO and JPG. > > I just took at look at the jabber:iq:oob "spec". I don't really see why > someone decided to re-invent this in a different form. Surely the > accept/refuse feedback could have been implemented just as well using > reply <message>s? > > One drawback to using an <iq> to send files is that you can't send it > through a conference/chatroom, which I've implemented in my client. > (BTW, sending to a chatroom is a case that breaks the 'relay server' > thing that has recently been implemented to bypass firewalls, because > it's not one-to-one.) > > I've actually implemented a significant number of extensions to the > defined jabber:x:oob in my client, mostly to help the receiver display > meaningful information about the file transfer before it begins. I've > added attributes to the <url> element that identify various metadata > about the transfer (is it a file vs. a directory? What is its size? What > POSIX or HFS metadata does it have?) Of course this isn't known to be > accurate, but it lets the receiver display various info to the user > (including an icon) and it can be re-verified after the actual file is > downloaded. > > --Jens > > --__--__-- > > Message: 2 > From: "Sebastiaan 'CBAS' Deckers" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Re: [JDEV] OOB filetransfer negotiation > Date: Sat, 11 Aug 2001 21:20:31 +0200 > Reply-To: [EMAIL PROTECTED] > > > Oh boy, that's a new one to me! I keep finding more and more of these > > secret protocol extensions. The "standard" way to transfer files, which > > I've implemented, is to send a <message> containing a jabber:x:oob > > extension element -- this is documented in the JPO and JPG. > > > > I just took at look at the jabber:iq:oob "spec". I don't really see why > > someone decided to re-invent this in a different form. Surely the > > accept/refuse feedback could have been implemented just as well using > > reply <message>s? > > As a longtime ICQ-user, I think the <message> element should be used for > (web) URL's and the <IQ> for P2P transfers. > Actually the link Cris Chen posted (http://docs.jabber.org/proto/) clearly > states this (well, as clear as Jabber docs can be ;-) ). > > > One drawback to using an <iq> to send files is that you can't send it > > through a conference/chatroom, which I've implemented in my client. > > (BTW, sending to a chatroom is a case that breaks the 'relay server' > > thing that has recently been implemented to bypass firewalls, because > > it's not one-to-one.) > > What relay-server thing? Any docs about this? > > > I've actually implemented a significant number of extensions to the > > defined jabber:x:oob in my client, mostly to help the receiver display > > meaningful information about the file transfer before it begins. I've > > added attributes to the <url> element that identify various metadata > > about the transfer (is it a file vs. a directory? What is its size? What > > POSIX or HFS metadata does it have?) Of course this isn't known to be > > accurate, but it lets the receiver display various info to the user > > (including an icon) and it can be re-verified after the actual file is > > downloaded. > > Woohoo, I'm glad to hear that, but what client are you talking about? Did > you document the extensions so my own, and other, client can support them? > It'd be great to have a little more info about the transfer than a url with > some vague filedescription. > The icon you speak of, is it also sent inside the IQ? (seems odd, but > possible) > > I haven't looked at many clients (only Jabber IM and WinJab) but are there > any that don't support P2P transfer over HTTP? > And those that support HTTP, do they also support resuming or other fancy > HTTP-stuff? (like security, cookies, directory listing, searching, ...) > > Thanks for the help so far, > Sebastiaan > > --__--__-- > > Message: 3 > To: [EMAIL PROTECTED], Jens Alfke <[EMAIL PROTECTED]> > Subject: Re: [JDEV] OOB filetransfer negotiation > Date: Sat, 11 Aug 2001 16:57:19 -0500 (CDT) > From: Thomas Charron <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > > Quoting Jens Alfke <[EMAIL PROTECTED]>: > > On Saturday, August 11, 2001, at 01:06 AM, Sebastiaan 'CBAS' Deckers > > wrote: > > > I'm trying to figure out how exactly file-transfers get negotiated. > > > WinJab seems to use an <iq> with namespace "jabber:iq:oob" containing > > > the > > > URL of the file. > > Oh boy, that's a new one to me! I keep finding more and more of these > > secret protocol extensions. The "standard" way to transfer files, which > > I've implemented, is to send a <message> containing a jabber:x:oob > > extension element -- this is documented in the JPO and JPG. > > Err, the mechansim is the same either way. IQ messages contain namespace, > message X tags contains messages. Client developers can ise either extention. > Hopefully, client developers will agree on a common way of 'doing it', but > either way is 'acceptable' via the protocol. > > > I just took at look at the jabber:iq:oob "spec". I don't really see why > > someone decided to re-invent this in a different form. Surely the > > accept/refuse feedback could have been implemented just as well using > > reply <message>s? > > Well, yes, but not enforced by the protocol. On the other hand, an IQ should > ALWAYS have a 'result'. > > > I've actually implemented a significant number of extensions to the > > defined jabber:x:oob in my client, mostly to help the receiver display > > meaningful information about the file transfer before it begins. I've > > added attributes to the <url> element that identify various metadata > > about the transfer (is it a file vs. a directory? What is its size? What > > POSIX or HFS metadata does it have?) Of course this isn't known to be > > accurate, but it lets the receiver display various info to the user > > (including an icon) and it can be re-verified after the actual file is > > downloaded. > > So long as your not just addhock adding things to the tags, you're all set. > If you DO, then you end 'exbracing and extending' the protocol, without working > with other client developers, then you end up with many clients having > imcompatible extentions, etc.. > > The reason why *BOTH* way of doing oob messages is listed under 'standards' > is to allow clients to choose either way to handle it. Using iq also allows > for server involvement, allows things such as PASS componenets to be used to > assist in file transfers.. > > --- > Thomas Charron > << Wanted: One decent sig >> > << Preferably litle used >> > > --__--__-- > > Message: 4 > Date: Sun, 12 Aug 2001 20:26:56 +1000 > From: Robert Norris <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [JDEV] Security Jig Meeting > Reply-To: [EMAIL PROTECTED] > > --tThc/1wpZn/ma/RB > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > > ideas we already have. If you wish to be a part of the security work=20 > > but can not make the meeting please email me. > > That'd be me. I'm on leave this week, but I suspect that that time will > always be bad for me (UTC+10). > > Rob. > > --=20 > Robert Norris <[EMAIL PROTECTED]> > 1024D/FC18E6C2 6FBF 098A A3F2 A728 490F 7743 59BD 7767 FC18 E6C2 > > --tThc/1wpZn/ma/RB > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE7dlnvWb13Z/wY5sIRAWAwAKCR9wIMYxgplSYBfVf/cq05wOlu7gCeK9d8 > 2g61v868u7djwudcJR5caiI= > =YeEO > -----END PGP SIGNATURE----- > > --tThc/1wpZn/ma/RB-- > > --__--__-- > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > > End of jdev Digest _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
