RE: [JDEV] File transfers

[Andy Beetz]

Quote "I'm not sure I'd want to do anything to encourage this just so some
client developer can be lazy about implementing things the right way."

There is no right way. At least not yet. Client to client 'data' transfers
are fine, no problem as long as a single or range of ports can be agreed
upon. As long as everyone uses the same protocol again everything should be
cool. Which I think it needs to be specced out.

Standardizing a client port or ports and protocol would be beneficial to
everyone.

Corporate network admins, if company policy is to block data transfers into
and out of the company, there is a nice and easy target for the firewall
rules, the clients should not be able to bypass the firewall. If they want
to do content filtering, there could be a component on the jabber server
which intercepts the oob packet (if this were the way it was done), waits to
see if the receiver wants to accept, if so download the file from the sender
scan, and action as appropriate.

Jabber Server Admins, there world obviously doesn't change much if at all.
Clients will go direct no more traffic than normal.

Client Developers, they would be happy (I'm sure) because their products
will work together (without crashing each other), if the 'standard' is not
ambiguous or open to interpretation.

End users, they would surely get a system that is reliable, the lack of
needing to worry what client their friend is using before sending or
receiving some data. For corporate users, they would not be allowed to step
outside the company policy (which could get them in trouble anyway). For
home users, especially those behind NAT routers, they also benefit from the
agreed ports, because it makes it very easy for them to have the
file-sharing.

How about this?


-Original Message-
From: Max Metral [mailto:[EMAIL PROTECTED]] 
Sent: 07 June 2002 03:23
To: '[EMAIL PROTECTED]'
Subject: RE: [JDEV] File transfers


I don't understand the arbitrary port comment... They are arbitrary.
Marshall and others picked em, and that was that.  When I hit the send
button in my email client (Outlook) it connects to exchange on some god
awful port with some god awful protocol that is most definitely not 110 and
is most definitely not SMTP (SMTP is 25 by the way, not 110).  Now there's a
connector that plugs into exchange and sends my message out to the
appropriate SMTP server via port 25, but that has nothing to do with POP
unless the other end HAPPENS to be using POP as the mailbox access
mechanism.  That POP server on the other end in some ways acts as a client
to the SMTP server, although not via networked protocols but via file system
semantics or whatever the particular package has decided the right way to
communicate between components is (e.g. on Win2k simple SMTP server, I would
just look in the mailroot\Mailbox directory, or use the CDO "client" objects
to access the mail store from a POP server I could write).

POP, HTTP, SMTP and most modern protocols are really nothing special.  I
could implement a POP "server" on my "client machine" pretty damn easily,
and could pretty much reuse the same code for an HTTP "server" on my client.
This would blur the lines in the case where, for example, I wrote a local
POP proxy.  From the point of view of Outlook Express, my POP proxy is the
server, but from the distant POP server it is the client. The fact that all
of these protocols are text based, fixed command set protocols blurs the
importance of clients and servers because of exactly what you say, that a
client asks and a server answers.  This is not a component-wide or "process"
wide distinction necessarily, it is a REQUEST wide decision, and any or all
components can make requests of each other.  This is why it is generally a
good idea to implement file transfer by having the client act like an HTTP
"server".  #1, it's easy, and #2, if it really IS a full blown web server
(i.e. for a firewall workaround) everything still works just the same.

This is all turning into a conceptual argument, and clearly you're not going
for the analogy/metaphor, which is fine.  I can't speak for Mike, but I
certainly don't need any lessons in Internet protocols, I've been here since
there weren't any.  In one paragraph I think you're saying you want to make
client-server into peer-to-peer/client-client.  If I'm understanding you
right, I totally agree.  And what I understand that to mean is that these
labels of distinction really aren't relevant.  So the question comes down to
what components are well suited to doing what tasks.  The Jabber server is
not well suited architecturally to act as a byte repeater for client
non-messaging data transfer.  I'm not sure I'd want to do anything to
encourage this just so some client developer can be lazy about implementing
things the right way.  (Not to mention that this is actually complex to
implement in ADDITION to a proper file transfer mechanism, and in the end
costs our poor client developers more time, not less)

Re: [JDEV] File transfers

[Jacek Konieczny]

On Thu, Jun 06, 2002 at 12:28:00PM -0700, Mike Oliver wrote:
>  I completely concur the Jabber clients can open a second 
> session for the file transfer, 
I agree

> and the handshaking of "do you want it" "ok" 
> "send it" 
I don't agree. The handshaking should be done via jabber protocol.

> but the question is what protocol to use for that file transfer 
> session.  I vote for FTP because the FTP libraries and tools are universal 
> and every language that a Jabber client or server has been built on will 
> have them and can easily be added.
But FTP is a very broken protocol. It requires two connections, some
undetermined ports open on firewall, and in active mode connections 
are initiated by the both sides. I think many firewall adminitrators
hate FTP. Why should they hate jabber too?

> You could even use the Jabber protocol to ask the other Jabber client what 
> ip address/port to use and if they support FTP, HTTP or JTP (aka new TP) 
> for file transfers and leave the server out of it.
I think jabber shoudl be used for handshaking and choosing routes via
some proxies (it may be needed for firewall traversal). Of course
HTTP could be used for the actual transfer, but if the handshake is
already done, so we really need any higher level protocol? Just a simple
TCP stream should be enough.

Greets,
Jacek

PS. 
  Please, do cut the citations. We are talking about problems about
  sending large files and generating such files at the same time :-)
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

[JDEV] Re: jdev digest, Vol 1 #1470 - 4 msgs

[Brijesh]

Hi ,

Good morning,

We are actively working in jabber area in hp India. We are trying to port
the
jabber(server , client , jud, transport ) in win2k. We are thinking for two
approaches & we have done little bit of research.

1. porting of linux code into win2k using cygwin.
2. porting of linux code into win2k using Interix 3.0(POSIX 2.0 compliant).

But we are not sure about the performance , scalability of the system after
porting using cygwin/interix.
We have some query regarding the porting :

1.  Is it possible to port the code into win2k , if yes then which is the
better option in your opinion.
2.  What issues can come up during the porting?
3.  Is there any group is working on this , so that we can contact to get
more information.
4.  Is there any other option you can recommend.


We have downloaded the latest commercial jabber server in win2k i.e.
TIMP(Tipic Instant messenger platform) for
initial testing but we would like to know more about this :

1. Is the TIMP is full proof i.e. stress test is done.
2. How many concurrent user can access the server.
3. Any idea about pricing.
4. Customer base.


Thanks a lot for your time.
Best regards
Brijesh Singh

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 07, 2002 7:58 AM
Subject: jdev digest, Vol 1 #1470 - 4 msgs


> 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: [jadmin] visit to Prague (Denis Gueyffier)
>2. Re: File transfers (Jeremy Nickurak)
>3. Re: Implementation of JEP-0025 (Jabber HTTP Polling) (Ivan M.
Hendricks)
>4. RE: File transfers (Max Metral)
>
> --__--__--
>
> Message: 1
> Date: Thu, 6 Jun 2002 11:44:47 -0400 (EDT)
> From: Denis Gueyffier <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED]
> Subject: [JDEV] Re: [jadmin] visit to Prague
> Reply-To: [EMAIL PROTECTED]
>
> Anybody is going to Paris ?
>
> Denis Gueyffier
>
> On Sun, 2 Jun 2002, Peter Saint-Andre wrote:
>
> > This message is for Jabber people in the Czech Republic
> >
> > Ahoj!
> >
> > I will visit Praha June 15-17 after the JabberConf conference in Munich.
> > If possible I would like to meet with people in Praha who are interested
> > in Jabber. The best time for me would be the evening of Monday, June 17
> > (my train to Muenchen leaves at 22:00). If you are interested in an
> > informal meeting over knedlo, vepro, zelo (a pivo!), please let me know
by
> > emailing me offlist or contacting me on Jabber ([EMAIL PROTECTED]).
> >
> > Dekuji vam!
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > Jabber Software Foundation
> > http://www.jabber.org/people/stpeter.html
> >
> >
> > ___
> > jadmin mailing list
> > [EMAIL PROTECTED]
> > http://mailman.jabber.org/listinfo/jadmin
> >
>
>
> --__--__--
>
> Message: 2
> Date: Thu, 6 Jun 2002 13:44:23 -0600
> From: Jeremy Nickurak <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [JDEV] File transfers
> Reply-To: [EMAIL PROTECTED]
>
>
> --envbJBWh7q8WU6mo
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Jun 06, 2002 at 05:47:44PM +0100, Richard Dobson wrote:
> > 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.
>
> Kazaa, Gnutella, Napster (in it's time) don't even facilitate the data
transfer. They simply provide a handshaking service that introduces one node
to another node, at which point they transfer their data without
intervention of the authoritative servers. This is the fundamental property
of peer-to-oeer networks.
>
> Unfortunately, even these activities have already been deemed illegal.
It's not all that far fetched (from a legal perspective) that these
precedents could apply equally to web browsers, email clients, smtp servers,
ftp server, web servers, virtually anything in fact. The reason Napster was
singled out was not because it allowed copywritten information to be
illegally distributed, but because it's users overwhelmingly chose to use it
for that task.
>
> The single thing that binds all these products together is the use of a
global searching mechanism. As long as Jabber doesn't implement this, I
don't see how it could possibly be singled out for piracy complaints.
> -

Re: [JDEV] Please Help very urgent with jabber

[r-a-v-i-v-e-d-a-l-a]

hi
  i am in hyd and can u work with u for jabber !

Tx n Regds
V-E-D-A-L-A
Using the correct technology is not as important as 
  using the technology correctly. 
- Original Message - 
From: "Nehal Trivedi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 05, 2002 5:00 AM
Subject: Re: [JDEV] Please Help very urgent with jabber


> where r u located?
> 
> i am in lowell, MA and can work with you for Jabber.
> 
> tx,
> nehal
> --- Paresh Shah <[EMAIL PROTECTED]> wrote:
> > Hi Everyone
> > 
> > I m facing some problem with jabber
> > I have installed jabber
> > Now I want to embed JabberSMTP I have installed Apache
> > 1.3 with perl + Jakarta-tomcat + JAMES (Java Apache
> > Mail Enterprise Server) + Sendmail, now I want to
> > Embed JabberSMTP along with Sendmail + JAMES, can
> > anyone tell me proper steps how to configure,
> > 
> > Also I want to have some file system where a user can
> > save file on server through jabber client & another
> > user can download the files using jabber client. 
> > 
> > Also I need lot of help
> > Can you help in working with jabber
> > Where Can I find a right person who can really help
> > me.
> > 
> > Thanks in advance
> > regards
> > Paresh Shah
> > Credence Analytics
> > 
> > 
> > =
> > till then
> > take care
> > bye
> > luv
> > have a nice time,day,week,month,year & beautiful life
> > Paresh
> > 
> >
> 
> > Everything you always wanted to know about cars and
> > bikes,now
> >  at: http://in.autos.yahoo.com/cricket/tracker.html
> > ___
> > jdev mailing list
> > [EMAIL PROTECTED]
> > http://mailman.jabber.org/listinfo/jdev
> 
> 
> =
> Nehal Trivedi
> Graduate Student 
> Department of Electrical and Computer Engineering
> University of Massachusetts,
> Lowell, MA 01854
> (978)-764-3170
> [EMAIL PROTECTED]
> 
> __
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Ivan M. Hendricks]

I was just about to announce one, as well,  but now wondering if I should
hold
off until there is an agreed upon resolution.  It's a Windows paltform
implementation.

Although insecure, it was the only solution for me as our Co. blocks just
about
everything.  I'm using Exodus as it supports Polling.

By the way, I found out about Jabber about 1 month ago and think it's a
GREAT
solution in that it is an open solution and, of course, that there have been
several gateways developed.

I'll have to jump over to jig to see what the outcome will be.

Cheers,

Ivan

- Original Message -
From: "David Waite" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 12:35 PM
Subject: Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)


> An informational JEP documents an existing implementation. It will not
> be changed so it no longer maps the existing implementation. I agree
> with Peter Millard, we need a separate, standards-track version. If you
> feel that we need to make it clearer that this particular JEP is
> informational, that is different, and we can talk about that on the
> standards-jig mailing list.
>
> -David Waite
>
> Michael F Lin wrote:
>
> >I agree, unfortunately, we now have a new implementation based on this
> >"informational" JEP which is vulnerable to the same security problems. So
I
> >propose that the informational vs. standards track distinction is pretty
> >meaningless. Look at Matthias' comments - he used it for lack of anything
> >better.
> >
> >The authors of this JEP, in my opinion, have the responsibility of fixing
> >it. We have handed them several ways to do so. Jabber, Inc., in my
opinion,
> >has the responsibility of fixing its web client before its users using it
> >for "financial applications" get burned.
> >
> >-Mike
> >
> >
> >
> >|-+>
> >| |   "Peter Millard"  |
> >| |   <[EMAIL PROTECTED]|
> >| |   >|
> >| |   Sent by: |
> >| |   jdev-admin@jabber|
> >| |   .org |
> >| ||
> >| ||
> >| |   06/06/2002 01:05 |
> >| |   PM   |
> >| |   Please respond to|
> >| |   jdev |
> >| ||
> >|-+>
> >
>---
---|
> >  |
|
> >  |   To:   <[EMAIL PROTECTED]>
|
> >  |   cc:
|
> >  |   Subject:  Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP
Polling)  |
> >  |
|
> >  |
|
> >
>---
---|
> >
> >
> >
> >Mike -
> >
> >
> >
> >>I agree, and I strongly recommend against the use of JEP-0025 as-is
> >>for any remotely sensitive purposes.
> >>
> >>We have been aware of the security problems for two months and have
> >>proposed multiple viable solutions, but nothing has been fixed. This
> >>JEP either needs to be fixed or withdrawn.
> >>
> >>
> >
> >*disclaimer: I am employed by Jabber, Inc* :)
> >
> >JEP-25 is INFORMATIONAL! It won't be withdrawn as it's not standards
track.
> >The whole idea behind informational JEPS is that they allow companies
(like
> >Jabber, Inc.) to document the protocol extensions that they build, so
other
> >people in the jabber community can use and build other products to them
(if
> >they so desire). It's unlikely that this JEP will change since it
reflects
> >a
> >currently deployed product (good bad or ugly :).
> >
> >Someone needs to take JEP-25 as a base, and create a new STANDARDS track
> >JEP
> >that fixes the security holes in the current implementation and submit
it.
> >Then client authors (like myself) can choose to implement either JEP-25,
> >the
> >new standards JEP, or both.
> >
> >Hope this makes sense.
> >
> >Peter M.
> >
> >___
> >jdev mailing list
> >[EMAIL PROTECTED]
> >http://mailman.jabber.org/listinfo/jdev
> >
> >
> >
> >
> >
> >___
> >jdev mailing list
> >[EMAIL PROTECTED]
> >http://mailman.jabber.org/listinfo/jdev
> >
> >
>
>
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev
>
>


___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

RE: [JDEV] File transfers

[Max Metral]

I 
don't understand the arbitrary port comment... They are arbitrary.  
Marshall and others picked em, and that was that.  When I hit the send 
button in my email client (Outlook) it connects to exchange on some god awful 
port with some god awful protocol that is most definitely not 110 and is most 
definitely not SMTP (SMTP is 25 by the way, not 110).  Now there's a 
connector that plugs into exchange and sends my message out to the appropriate 
SMTP server via port 25, but that has nothing to do with POP unless the other 
end HAPPENS to be using POP as the mailbox access mechanism.  That POP 
server on the other end in some ways acts as a client to the SMTP server, 
although not via networked protocols but via file system semantics or whatever 
the particular package has decided the right way to communicate between 
components is (e.g. on Win2k simple SMTP server, I would just look in 
the mailroot\Mailbox directory, or use the CDO "client" objects to access 
the mail store from a POP server I could write).
 
POP, 
HTTP, SMTP and most modern protocols are really nothing special.  I could 
implement a POP "server" on my "client machine" pretty damn easily, and could 
pretty much reuse the same code for an HTTP "server" on my client.  This 
would blur the lines in the case where, for example, I wrote a local POP 
proxy.  From the point of view of Outlook Express, my POP proxy is the 
server, but from the distant POP server it is the client. The fact that all 
of these protocols are text based, fixed command set protocols blurs the 
importance of clients and servers because of exactly what you say, that a client 
asks and a server answers.  This is not a component-wide or "process" 
wide distinction necessarily, it is a REQUEST wide decision, and any or all 
components can make requests of each other.  This is why it is generally a 
good idea to implement file transfer by having the client act like an HTTP 
"server".  #1, it's easy, and #2, if it really IS a full blown web server 
(i.e. for a firewall workaround) everything still works just the 
same.
 
This 
is all turning into a conceptual argument, and clearly you're not going for the 
analogy/metaphor, which is fine.  I can't speak for Mike, but I certainly 
don't need any lessons in Internet protocols, I've been here since there weren't 
any.  In one paragraph I think you're saying you want to make client-server 
into peer-to-peer/client-client.  If I'm understanding you right, I totally 
agree.  And what I understand that to mean is that these labels of 
distinction really aren't relevant.  So the question comes down to what 
components are well suited to doing what tasks.  The Jabber server is not 
well suited architecturally to act as a byte repeater for client non-messaging 
data transfer.  I'm not sure I'd want to do anything to encourage this just 
so some client developer can be lazy about implementing things the right 
way.  (Not to mention that this is actually complex to implement in 
ADDITION to a proper file transfer mechanism, and in the end costs our poor 
client developers more time, not less)
 
I 
trust the maturity and experience of the members of this list to be able to 
understand conceptual discussions of this nature, this isn't developer 
school.  The original discussion was about whether the Jabber "server" 
should be used to shuttle packets on behalf of clients and whether that should 
be part of the protocol, at this point I'm confused reading your mail whether 
you advocate this or don't.  I'll be clear, I do not advocate creating 
protocol elements to allow the concept of a "file" to be routed, split, encoded, 
and reassembled by Jabber servers.  I advocate a mechanism for negotiating 
protocol based multi-party "connections" (i.e. clients providing endpoints) for 
things like file transfer, video conferencing, networked full-motion-video 
Parcheesi, and whatever the heck else the developer community thinks up.  
Whatever mechanism is used should not use the words "file transfer" in anything 
but string literals in my opinion.

  -Original Message-From: Mike Oliver 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, June 06, 2002 8:34 
  PMTo: [EMAIL PROTECTED]Subject: RE: [JDEV] File 
  transfersoh, right and ports 25, 143 and 110 are 
  arbitrary.At 04:50 PM 6/6/2002 -0700, you wrote:
  He knows what he's talking about, he's just assuming too much in his 
descriptions.  People who don't know what they're talking about don't 
use words like MTA and MUA, and if they do they act very proud of knowing 
it. :) Hard 
distinctions between client and server are SOOO last century. :)  
Geez and I thought last century was just a couple of 
  years ago.
  From a conceptual perspective, a *local* POP server (i.e. 
mycompany.com) is in some ways a client for the overall server "cloud" of 
Internet mail.  SMTP is essentially a non-realtime store and forward 
network, which is "batch" in many ways, for 

Re: [JDEV] File transfers

[Jeremy Nickurak]

On Thu, Jun 06, 2002 at 05:47:44PM +0100, Richard Dobson wrote:
> 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.

Kazaa, Gnutella, Napster (in it's time) don't even facilitate the data transfer. They 
simply provide a handshaking service that introduces one node to another node, at 
which point they transfer their data without intervention of the authoritative 
servers. This is the fundamental property of peer-to-oeer networks.

Unfortunately, even these activities have already been deemed illegal. It's not all 
that far fetched (from a legal perspective) that these precedents could apply equally 
to web browsers, email clients, smtp servers, ftp server, web servers, virtually 
anything in fact. The reason Napster was singled out was not because it allowed 
copywritten information to be illegally distributed, but because it's users 
overwhelmingly chose to use it for that task.

The single thing that binds all these products together is the use of a global 
searching mechanism. As long as Jabber doesn't implement this, I don't see how it 
could possibly be singled out for piracy complaints.


msg06134/pgp0.pgp
Description: PGP signature

[JDEV] Re: [jadmin] visit to Prague

[Denis Gueyffier]

Anybody is going to Paris ?

Denis Gueyffier

On Sun, 2 Jun 2002, Peter Saint-Andre wrote:

> This message is for Jabber people in the Czech Republic
>
> Ahoj!
>
> I will visit Praha June 15-17 after the JabberConf conference in Munich.
> If possible I would like to meet with people in Praha who are interested
> in Jabber. The best time for me would be the evening of Monday, June 17
> (my train to Muenchen leaves at 22:00). If you are interested in an
> informal meeting over knedlo, vepro, zelo (a pivo!), please let me know by
> emailing me offlist or contacting me on Jabber ([EMAIL PROTECTED]).
>
> Dekuji vam!
>
> Peter
>
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.html
>
>
> ___
> jadmin mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jadmin
>

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

RE: [JDEV] File transfers

[Mike Oliver]

oh, right and ports 25, 143 and 110 are arbitrary.
At 04:50 PM 6/6/2002 -0700, you wrote:
He
knows what he's talking about, he's just assuming too much in his
descriptions.  People who don't know what they're talking about
don't use words like MTA and MUA, and if they do they act very proud of
knowing it. :)
 
Hard distinctions between
client and server are SOOO last century. :) 

Geez and I thought last century was just a couple of years ago.

From
a conceptual perspective, a *local* POP server (i.e. mycompany.com) is in
some ways a client for the overall server "cloud" of Internet
mail.  SMTP is essentially a non-realtime store and forward network,
which is "batch" in many ways, for lots of good
reasons.

Are we in La La land?  You name me one email server that uses
something other than SMTP to transfer internet Mail between
servers?  When you hit that old send button you tell your email
client to open good old server port 110 and transfer the email message
and attachments via SMTP (the P stands for Protocol and there is no N for
Network in it) and your email server looks at the addresses and sends
copies of the message to all the addresses it can find or to another SMTP
server that might know more addresses, which in turn sends all the
messages off to other SMTP servers...POP is the protocol for email
clients to retrieve the email and attachments from a SERVER as is IMAP
with the key difference being the ability to have a persistent store of
folders/mailboxes.  POP is NOT used any other way.  So your
conceptual local POP server NEVER acts as a client and accesses some
other server in the "cloud", it sits there patiently until some
other 'server' sends it something.
So from the cloud of smoke you two must be smoking conceptually, you
can't make client-server, into client-client OR peer to peer.  Those
are words you know as well, but knowing their meaning is more
important.   A client makes requests and a server answers
them.  Yes indeed it gets cloudy when a server talks to a server and
the roles blur on a request by request basis, but not the protocols they
use.   
I am not advocating use of SMTP for Jabber File Transfers, however a mix
of Protocols that are accepted protocols for file transfers and messaging
is what I think we all want.  The Jabber protocol IS NOT a good idea
for large files, but some direct client to client or peer to peer
mechanism IS a good idea.
Maybe I am being to precise and too concise for you two.  But as an
Architect and developer it IS important and since this is a developer's
forum I choose not to mislead those that may be beginning to confuse them
with some "concepts" that are simply WRONG.
Knowing the words is only half the battle knowing what they mean takes a
little more effort.
 
And those points of view are
part of the reason we both think that putting this special "realtime
non-messaging packet forwarder" hat on the Jabber server is a
stretch, and has all the problems we've previously mentioned.

-Original Message-
From: Mike Oliver
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 7:38 PM
To: [EMAIL PROTECTED]
Subject: RE: [JDEV] File transfers

Ok adding value, you simply don't know what you are talking
about.

How's that?  POP AND IMAP are protocols for Clients to talk to
Servers to access stores of messages and attachments.  A Pop or IMAP
Client DOES NOT talk to another Pop or IMAP Client...EVER...SMTP is the
way you SEND messages to those stores and every single email message you
send is transferred using SMTP and BTW SendMail is just an SMTP Program
for sending mail, it has nothing to do with "bulk".  Have
you ever setup an email client?  If you did you had to setup the
email server for getting your email and choose POP3 or IMAP4 and then an
SMTP server for outgoing, or if you leave that blank it tries to use the
same server you setup for incoming.  But these are on different
ports even if on the same ip address/dns name.

If YOU want to add value, don't spout about things you obviously know
NOTHING about.  Read the specifications about POP3, IMAP4 AND SMTP
and you can find those at
http://www.ietf.org

I completely agree it depends on where you are standing and you are
standing in the dark. 


At 02:06 PM 6/6/2002 -0700, you wrote:

Mike cogently queries: 
> What planet are you from?  
There's a great way to add value to a thread. :) 

> POP, IMAP and MAPI (Exchange) ARE NOT
"client-to-client", PLEASE! 
Sure, why not?  user --> sendmail --> mail spool
accessible via POP, 
at which point the server stops being so much of a server and
starts 
acting a little more like a peer (POP, IMAP and MAPI being ad
hoc, 
connected, conversational programs, unlike SMTP, which is largely
a 
batch-oriented bulk drop).  It all depends where you're
standing. 
No need to question my mudball of origin. 

> sendmail is just an SMTP mail transfer agent program and no
different than 
> any other SMTP mail transfer agent program like those from
Netscape and 
> Microsoft

RE: [JDEV] File transfers

[Max Metral]

He 
knows what he's talking about, he's just assuming too much in his 
descriptions.  People who don't know what they're talking about don't use 
words like MTA and MUA, and if they do they act very proud of knowing it. 
:)
 
Hard 
distinctions between client and server are SOOO last century. :)  From a 
conceptual perspective, a *local* POP server (i.e. mycompany.com) is in some 
ways a client for the overall server "cloud" of Internet mail.  SMTP is 
essentially a non-realtime store and forward network, which is "batch" in many 
ways, for lots of good reasons.
 
And 
those points of view are part of the reason we both think that putting this 
special "realtime non-messaging packet forwarder" hat on the Jabber server is a 
stretch, and has all the problems we've previously 
mentioned.

  -Original Message-From: Mike Oliver 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, June 06, 2002 7:38 
  PMTo: [EMAIL PROTECTED]Subject: RE: [JDEV] File 
  transfersOk adding value, you simply don't know what you 
  are talking about.How's that?  POP AND IMAP are protocols for 
  Clients to talk to Servers to access stores of messages and attachments.  
  A Pop or IMAP Client DOES NOT talk to another Pop or IMAP Client...EVER...SMTP 
  is the way you SEND messages to those stores and every single email message 
  you send is transferred using SMTP and BTW SendMail is just an SMTP Program 
  for sending mail, it has nothing to do with "bulk".  Have you ever setup 
  an email client?  If you did you had to setup the email server for 
  getting your email and choose POP3 or IMAP4 and then an SMTP server for 
  outgoing, or if you leave that blank it tries to use the same server you setup 
  for incoming.  But these are on different ports even if on the same ip 
  address/dns name.If YOU want to add value, don't spout about things 
  you obviously know NOTHING about.  Read the specifications about POP3, 
  IMAP4 AND SMTP and you can find those at http://www.ietf.orgI completely agree it depends 
  on where you are standing and you are standing in the dark. At 
  02:06 PM 6/6/2002 -0700, you wrote:
  Mike cogently 
queries: > What planet are you from?  
There's a great way to add value to a thread. 
:) > POP, IMAP and MAPI (Exchange) ARE NOT 
"client-to-client", PLEASE! Sure, why not?  
user --> sendmail --> mail spool accessible via POP, at which point the server stops being so much of a server and 
starts acting a little more like a peer (POP, IMAP 
and MAPI being ad hoc, connected, conversational 
programs, unlike SMTP, which is largely a batch-oriented bulk drop).  It all depends where you're 
standing. No need to question my mudball of 
origin. > sendmail is just an SMTP mail 
transfer agent program and no different than > 
any other SMTP mail transfer agent program like those from Netscape and 
> Microsoft...ARG! Netscape makes an MTA?  What's it called?  I've seen their 
MUA, but I'm surprised to hear they have an 
MTA.  I bet it crashes a lot. :) F. 
**E-mail 
sent through the Internet is not secure. Western Asset 
thereforerecommends that you do not send any confidential or sensitive 
information tous via electronic mail, including social security numbers, 
account numbers,or personal identification numbers. Delivery, and or 
timely delivery ofInternet mail is not guaranteed. Western Asset 
therefore recommends thatyou do not send time sensitive or 
action-oriented messages to us viaelectronic 
mail.**
  Michael OliverChief Technology 
  OfficerAppsAsPeers.com7391 S. Bullrider Ave.Tucson, AZ 
  85747520.574.1150 

RE: [JDEV] File transfers

[Mike Oliver]

Ok adding value, you simply don't know what you are talking
about.
How's that?  POP AND IMAP are protocols for Clients to talk to
Servers to access stores of messages and attachments.  A Pop or IMAP
Client DOES NOT talk to another Pop or IMAP Client...EVER...SMTP is the
way you SEND messages to those stores and every single email message you
send is transferred using SMTP and BTW SendMail is just an SMTP Program
for sending mail, it has nothing to do with "bulk".  Have
you ever setup an email client?  If you did you had to setup the
email server for getting your email and choose POP3 or IMAP4 and then an
SMTP server for outgoing, or if you leave that blank it tries to use the
same server you setup for incoming.  But these are on different
ports even if on the same ip address/dns name.
If YOU want to add value, don't spout about things you obviously know
NOTHING about.  Read the specifications about POP3, IMAP4 AND SMTP
and you can find those at
http://www.ietf.org
I completely agree it depends on where you are standing and you are
standing in the dark. 

At 02:06 PM 6/6/2002 -0700, you wrote:
Mike cogently
queries: 
> What planet are you from?  

There's a great way to add value to a thread. :)

> POP, IMAP and MAPI (Exchange) ARE NOT "client-to-client", PLEASE! 

Sure, why not?  user --> sendmail --> mail spool accessible via POP, 
at which point the server stops being so much of a server and starts 
acting a little more like a peer (POP, IMAP and MAPI being ad hoc, 
connected, conversational programs, unlike SMTP, which is largely a 
batch-oriented bulk drop).  It all depends where you're standing. 
No need to question my mudball of origin. 
> sendmail is just an SMTP mail transfer agent program and no different than 
> any other SMTP mail transfer agent program like those from Netscape and 
> Microsoft...ARG! 
Netscape makes an MTA?  What's it called?  I've seen their MUA, but 
I'm surprised to hear they have an MTA.  I bet it crashes a lot. :) 
F. 

**
E-mail sent through the Internet is not secure. Western Asset therefore
recommends that you do not send any confidential or sensitive information to
us via electronic mail, including social security numbers, account numbers,
or personal identification numbers. Delivery, and or timely delivery of
Internet mail is not guaranteed. Western Asset therefore recommends that
you do not send time sensitive or action-oriented messages to us via
electronic mail.
**

Michael Oliver
Chief Technology Officer
AppsAsPeers.com
7391 S. Bullrider Ave.
Tucson, AZ 85747
520.574.1150

RE: [JDEV] File transfers

[Gallo, Felix S.]

Title: RE: [JDEV] File transfers





Mike cogently queries:
> What planet are you from?  


There's a great way to add value to a thread. :)


> POP, IMAP and MAPI (Exchange) ARE NOT "client-to-client", PLEASE! 


Sure, why not?  user --> sendmail --> mail spool accessible via POP,
at which point the server stops being so much of a server and starts
acting a little more like a peer (POP, IMAP and MAPI being ad hoc,
connected, conversational programs, unlike SMTP, which is largely a
batch-oriented bulk drop).  It all depends where you're standing.
No need to question my mudball of origin.


> sendmail is just an SMTP mail transfer agent program and no different than
> any other SMTP mail transfer agent program like those from Netscape and 
> Microsoft...ARG!


Netscape makes an MTA?  What's it called?  I've seen their MUA, but
I'm surprised to hear they have an MTA.  I bet it crashes a lot. :)


F.




**
E-mail sent through the Internet is not secure.  Western Asset therefore
recommends that you do not send any confidential or sensitive information to
us via electronic mail, including social security numbers, account numbers,
or personal identification numbers.  Delivery, and or timely delivery of
Internet mail is not guaranteed.  Western Asset therefore recommends that
you do not send time sensitive or action-oriented messages to us via
electronic mail.
**

RE: [JDEV] File transfers

[Mike Oliver]

What planet are you from?  
At 12:54 PM 6/6/2002 -0700, you wrote:
Mike writes:

> Firstly, there is no inherent problem with sending moderately 
> large files through a software server. Sendmail does it all 
> day, every day, on a massive scale, without relying on 
> client-to-client connections. 
However, most mail is accessed through POP, IMAP, or Exchange, 
which are definitely client-to-client connections -- for the 
simple reason that sendmail doesn't scale very well.  
POP, IMAP and MAPI (Exchange) ARE NOT "client-to-client", PLEASE! 
sendmail is just an SMTP mail transfer agent program and no different than
any other SMTP mail transfer agent program like those from Netscape and 
Microsoft...ARG!

For 
every byte send to a sendmail server, two bytes traverse the 
network.  Most unfortunately, those two bytes always involve 
just the one sendmail server and its attached network. 
What positives do you get for having the sendmail server involved 
in a large file transaction between two parties?  You get a 
guarantee of delivery and no need for continued storage on the 
sending party's side (since the file 'moves' to the sendmail server). 
If you're sending the file to multiple users at once, you get less 
traffic on your local network (the server takes the load). 
You also get an opportunity to mediate the file somehow (e.g., 
virus checking it as a service, converting it from aac into mp3, 
storing it for later delivery to other users..) 
What positives do you get for not having the sendmail server 
involved?  The network on the sendmail server sees 0X load 
rather than 2X load; the latency is lower; the sendmail server 
has no storage requirement; and you have arguably fewer points 
of failure. 
Pragmatically, taking the load off the server is more valuable 
in the normal case than replicating HTTP/FTP/SMTP/FXP yet again. 
The fact that 'SMTP does it' is not a great rationale for forcing 
all the jabber servers to pay 2X bandwidth costs for file transfers 
between their users. 
F. 

**
E-mail sent through the Internet is not secure. Western Asset therefore
recommends that you do not send any confidential or sensitive information to
us via electronic mail, including social security numbers, account numbers,
or personal identification numbers. Delivery, and or timely delivery of
Internet mail is not guaranteed. Western Asset therefore recommends that
you do not send time sensitive or action-oriented messages to us via
electronic mail.
**

Michael Oliver
Chief Technology Officer
AppsAsPeers.com
7391 S. Bullrider Ave.
Tucson, AZ 85747
520.574.1150

Re: [JDEV] File transfers

[Michael Rothwell]

Title: RE: [JDEV] File transfers



The jabber server could simply have a config option 
for "max transfer size," which ,when set to zero, disables all file transfers. 
Clients are notified of the file-transfer capabilities of the server by the 
server. You could even take it one step further and allow/disallow 
file-transfter use per account ID and/or groups. Other config options which 
would be useful are "cache time" and "max cache size" -- if cache time and/or 
size are zero, then if the server cannot stream the data directly to the 
recipient(s), it informs the client that the recipient isn't accepting 
transfers. You could even limit the number of transfers/person/day, 
etc.
 
Leave it up to the clients to B64 encode/decode the 
transfer. The server doesn't have to care, which will reduce processing load. 
The "max size" parameters will be for the encoded versions, which is what server 
operators care about, because it's what they pay for.
 
Server-supported transfers would be a nice config 
option, esp. for behind-the-firewall and small-number-of-users 
servers.
 

  - Original Message - 
  From: 
  Gallo, 
  Felix S. 
  To: '[EMAIL PROTECTED]' 
  Sent: Thursday, June 06, 2002 3:54 
  PM
  Subject: RE: [JDEV] File transfers
  
  Mike writes: > Firstly, there is no 
  inherent problem with sending moderately > large 
  files through a software server. Sendmail does it all > day, every day, on a massive scale, without relying on 
  > client-to-client connections. 
  However, most mail is accessed through POP, IMAP, or 
  Exchange, which are definitely client-to-client 
  connections -- for the simple reason that sendmail 
  doesn't scale very well.  For every byte send to 
  a sendmail server, two bytes traverse the network.  Most unfortunately, those two bytes always 
  involve just the one sendmail server and its attached 
  network. 
  What positives do you get for having the sendmail server 
  involved in a large file transaction between two 
  parties?  You get a guarantee of delivery and no 
  need for continued storage on the sending party's side 
  (since the file 'moves' to the sendmail server). If 
  you're sending the file to multiple users at once, you get less 
  traffic on your local network (the server takes the 
  load). You also get an opportunity to mediate the file 
  somehow (e.g., virus checking it as a service, 
  converting it from aac into mp3, storing it for later 
  delivery to other users..) 
  What positives do you get for not having the sendmail server 
  involved?  The network on the sendmail server 
  sees 0X load rather than 2X load; the latency is 
  lower; the sendmail server has no storage requirement; 
  and you have arguably fewer points of failure. 
  
  Pragmatically, taking the load off the server is more 
  valuable in the normal case than replicating 
  HTTP/FTP/SMTP/FXP yet again. The fact that 'SMTP does 
  it' is not a great rationale for forcing all the 
  jabber servers to pay 2X bandwidth costs for file transfers between their users. 
  F. **E-mail 
  sent through the Internet is not secure. Western Asset thereforerecommends 
  that you do not send any confidential or sensitive information tous via 
  electronic mail, including social security numbers, account numbers,or 
  personal identification numbers. Delivery, and or timely delivery 
  ofInternet mail is not guaranteed. Western Asset therefore recommends 
  thatyou do not send time sensitive or action-oriented messages to us 
  viaelectronic 
  mail.**

RE: [JDEV] File transfers

[Gallo, Felix S.]

Title: RE: [JDEV] File transfers





Mike writes:
> Firstly, there is no inherent problem with sending moderately 
> large files through a software server. Sendmail does it all 
> day, every day, on a massive scale, without relying on 
> client-to-client connections.


However, most mail is accessed through POP, IMAP, or Exchange,
which are definitely client-to-client connections -- for the
simple reason that sendmail doesn't scale very well.  For
every byte send to a sendmail server, two bytes traverse the
network.  Most unfortunately, those two bytes always involve
just the one sendmail server and its attached network.


What positives do you get for having the sendmail server involved
in a large file transaction between two parties?  You get a
guarantee of delivery and no need for continued storage on the
sending party's side (since the file 'moves' to the sendmail server).
If you're sending the file to multiple users at once, you get less
traffic on your local network (the server takes the load).
You also get an opportunity to mediate the file somehow (e.g.,
virus checking it as a service, converting it from aac into mp3,
storing it for later delivery to other users..)


What positives do you get for not having the sendmail server 
involved?  The network on the sendmail server sees 0X load
rather than 2X load; the latency is lower; the sendmail server
has no storage requirement; and you have arguably fewer points
of failure.


Pragmatically, taking the load off the server is more valuable
in the normal case than replicating HTTP/FTP/SMTP/FXP yet again.
The fact that 'SMTP does it' is not a great rationale for forcing
all the jabber servers to pay 2X bandwidth costs for file transfers
between their users.


F.




**
E-mail sent through the Internet is not secure.  Western Asset therefore
recommends that you do not send any confidential or sensitive information to
us via electronic mail, including social security numbers, account numbers,
or personal identification numbers.  Delivery, and or timely delivery of
Internet mail is not guaranteed.  Western Asset therefore recommends that
you do not send time sensitive or action-oriented messages to us via
electronic mail.
**

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[David Waite]

An informational JEP documents an existing implementation. It will not 
be changed so it no longer maps the existing implementation. I agree 
with Peter Millard, we need a separate, standards-track version. If you 
feel that we need to make it clearer that this particular JEP is 
informational, that is different, and we can talk about that on the 
standards-jig mailing list.

-David Waite

Michael F Lin wrote:

>I agree, unfortunately, we now have a new implementation based on this
>"informational" JEP which is vulnerable to the same security problems. So I
>propose that the informational vs. standards track distinction is pretty
>meaningless. Look at Matthias' comments - he used it for lack of anything
>better.
>
>The authors of this JEP, in my opinion, have the responsibility of fixing
>it. We have handed them several ways to do so. Jabber, Inc., in my opinion,
>has the responsibility of fixing its web client before its users using it
>for "financial applications" get burned.
>
>-Mike
>
>
>
>|-+>
>| |   "Peter Millard"  |
>| |   <[EMAIL PROTECTED]|
>| |   >|
>| |   Sent by: |
>| |   jdev-admin@jabber|
>| |   .org |
>| ||
>| ||
>| |   06/06/2002 01:05 |
>| |   PM   |
>| |   Please respond to|
>| |   jdev |
>| ||
>|-+>
>  
>>--|
>  |   
>   |
>  |   To:   <[EMAIL PROTECTED]> 
>   |
>  |   cc: 
>   |
>  |   Subject:  Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)   
>   |
>  |   
>   |
>  |   
>   |
>  
>>--|
>
>
>
>Mike -
>
>  
>
>>I agree, and I strongly recommend against the use of JEP-0025 as-is
>>for any remotely sensitive purposes.
>>
>>We have been aware of the security problems for two months and have
>>proposed multiple viable solutions, but nothing has been fixed. This
>>JEP either needs to be fixed or withdrawn.
>>
>>
>
>*disclaimer: I am employed by Jabber, Inc* :)
>
>JEP-25 is INFORMATIONAL! It won't be withdrawn as it's not standards track.
>The whole idea behind informational JEPS is that they allow companies (like
>Jabber, Inc.) to document the protocol extensions that they build, so other
>people in the jabber community can use and build other products to them (if
>they so desire). It's unlikely that this JEP will change since it reflects
>a
>currently deployed product (good bad or ugly :).
>
>Someone needs to take JEP-25 as a base, and create a new STANDARDS track
>JEP
>that fixes the security holes in the current implementation and submit it.
>Then client authors (like myself) can choose to implement either JEP-25,
>the
>new standards JEP, or both.
>
>Hope this makes sense.
>
>Peter M.
>
>___
>jdev mailing list
>[EMAIL PROTECTED]
>http://mailman.jabber.org/listinfo/jdev
>
>
>
>
>
>___
>jdev mailing list
>[EMAIL PROTECTED]
>http://mailman.jabber.org/listinfo/jdev
>  
>


___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

RE: [JDEV] File transfers

[Mike Oliver]

And you were doing so well...until...

At 02:49 PM 6/6/2002 -0400, you wrote:

>Firstly, there is no inherent problem with sending moderately large files
>through a software server. Sendmail does it all day, every day, on a
>massive scale, without relying on client-to-client connections.
>
>The trouble when we extend this to Jabber is that we expect Jabber to go
>faster than Sendmail, so it's not acceptable to block all other traffic
>while we send our file. Is this really a problem, though? I'm proposing -
>effectively, not literally - just open up a second Jabber session on both
>ends and do it that way. If the server is under heavy load, it can throttle
>the karma as necessary. If the recipient's queue is too large, it can
>reject the message. This is how e-mail works; just a bit smarter. This is a
>solution based on something that has been in place for years and is known
>to work reasonably well. E-mail has seen all the problems of mail bombing
>and spamming and denial of service attacks others have been warning of, but
>they have generally managed to keep themselves under control. I see no
>compelling reason to believe that the same will not be true for Jabber.
>
>Now, map what you and others are proposing we do back to e-mail. Every time
>you send an e-mail with an attachment, you first send a message to the
>recipient asking them for their IP address. Then your e-mail software opens
>up a connection with some custom protocol and transfers the file directly
>to the recpient. Firewalls are a problem, but you can set up some clever
>daemons and such to get around them most of the time. What if the recipient
>is not online at the time? What if it's a cell phone? What if, what if,
>what if...?
>
>Is that how e-mail should be done? If not, what's really so different about
>Jabber?
>
>Now, if you are transferring a gigabyte, you wouldn't send it via e-mail,
>so why would you send it via Jabber? If e-mail clients don't have
>facilities for client-to-client transfer of _extremely_ large files, why
>should Jabber clients?

If we followed this logic there wouldn't be IM of any 
kind...'cause  "e-mail clients don't have facilities for client-to-client 
transfer" of instant messages either.

The Reason it would be handy to do Jabber to Jabber direct transfers is 
because email doesn't do it well, plus it is more secure than intermediary 
email transfers and routing...Most workstations outperform most servers in 
a cpu cycle/user basis and that power can be used to transfer large files 
directly from Jabber to Jabber much easier and faster than any 
other  way...Napster anyone?

Doing large file transfers using XML and base64 encoding is not efficient 
and even SOAP has attachments capabilities because of it.  Email is equally 
inefficient.  I completely concur the Jabber clients can open a second 
session for the file transfer, and the handshaking of "do you want it" "ok" 
"send it" but the question is what protocol to use for that file transfer 
session.  I vote for FTP because the FTP libraries and tools are universal 
and every language that a Jabber client or server has been built on will 
have them and can easily be added.

You could even use the Jabber protocol to ask the other Jabber client what 
ip address/port to use and if they support FTP, HTTP or JTP (aka new TP) 
for file transfers and leave the server out of it.


>If you need to transfer huge files, use tools
>intended for that purpose. Maybe smart tools on the Jabber network could
>even help you figure out the right IP address for the recipient. But there
>is no reason to introduce this complexity to clients in order to transfer
>Word documents and Excel spreadsheets.
>
>-Mike
>
>
>
>|-+>
>| |   Max Metral   |
>| |   | |   epchq.com>   |
>| |   Sent by: |
>| |   jdev-admin@jabber|
>| |   .org |
>| ||
>| ||
>| |   06/06/2002 12:14 |
>| |   PM   |
>| |   Please respond to|
>| |   jdev |
>| ||
>|-+>
> 
>  
>>--|
>   | 
> |
>   |   To:   "'[EMAIL PROTECTED]'" 
> <[EMAIL PROTECTED]> 
> |
>   |   cc: 
> |
>   |   Subject:  RE: [JDEV] File 
> transfers 
> |
>   | 
> |
>   | 
> |
> 
>  
>>-

RE: [JDEV] File transfers

[Max Metral]

That's over generalizing my point... Sendmail sucks at it, but I agree it
does send files around.  I would submit that's more a failure of the clients
to do something smarter, or to make it easier not to send huge files inline
(I hate when people do that).  But the HUGE difference in this case is that
sendmail has evolved to be highly distributed.  I question whether Jabber
really plays out that way, and whether us forcing it that way now would
actually hamper its chances at success.  As a service provider, I control a
lot of users, and my choice of IM platform, in theory, is worth more than
somecompany.com.  As such, there is no way I'm going to choose a platform or
implement a feature that causes me to double pay (or infinitely more if you
weren't paying for client-server in the first place) for all bandwidth for
files exchanged among my users.  That free lunch ended with the millenium.
So then does that give MSN and AOL an unnatural advantage over us?  Not
sure, but if I put myself in other service providers' shoes, it sure does.

Furthermore, most all meaningful email providers cap the message size, and
at a number lower than the files we want to enable here... There's good
reason for that, obviously.  And even with that, the reality is most of us
are falling over under the load of spam and mail bombs.  In case peoples'
inboxes don't show it, the spammers are winning right now, Sendmail can't
handle them.  Part of the reason they're winning is mistakes at the protocol
level from 25 years ago... Unauthenticated senders, paths, headers, etc etc.
So in this case we either pick a message size cap, and then have to
implement something to allow files over that size (uh, how about client to
client) or we let Jabber do what it should, which is route and message, and
let someone else lug the heavy boxes.

Add to that, as another person mentioned, that files are not the only
instances of this issue.  Are you proposing that we put H.323 video
conferencing data in Jabber packets?  The semantics of usage and delivery
simply are not compatible between the two.  XML is not and never will be
about size or speed...

I really think this is a non-starter, and if people disagree, we should
probably take this conversation somewhere else, because this list has
probably had enough of it.

-Original Message-
From: Michael F Lin [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:49 PM
To: [EMAIL PROTECTED]
Subject: RE: [JDEV] File transfers



Firstly, there is no inherent problem with sending moderately large files
through a software server. Sendmail does it all day, every day, on a
massive scale, without relying on client-to-client connections.

The trouble when we extend this to Jabber is that we expect Jabber to go
faster than Sendmail, so it's not acceptable to block all other traffic
while we send our file. Is this really a problem, though? I'm proposing -
effectively, not literally - just open up a second Jabber session on both
ends and do it that way. If the server is under heavy load, it can throttle
the karma as necessary. If the recipient's queue is too large, it can
reject the message. This is how e-mail works; just a bit smarter. This is a
solution based on something that has been in place for years and is known
to work reasonably well. E-mail has seen all the problems of mail bombing
and spamming and denial of service attacks others have been warning of, but
they have generally managed to keep themselves under control. I see no
compelling reason to believe that the same will not be true for Jabber.

Now, map what you and others are proposing we do back to e-mail. Every time
you send an e-mail with an attachment, you first send a message to the
recipient asking them for their IP address. Then your e-mail software opens
up a connection with some custom protocol and transfers the file directly
to the recpient. Firewalls are a problem, but you can set up some clever
daemons and such to get around them most of the time. What if the recipient
is not online at the time? What if it's a cell phone? What if, what if,
what if...?

Is that how e-mail should be done? If not, what's really so different about
Jabber?

Now, if you are transferring a gigabyte, you wouldn't send it via e-mail,
so why would you send it via Jabber? If e-mail clients don't have
facilities for client-to-client transfer of _extremely_ large files, why
should Jabber clients? If you need to transfer huge files, use tools
intended for that purpose. Maybe smart tools on the Jabber network could
even help you figure out the right IP address for the recipient. But there
is no reason to introduce this complexity to clients in order to transfer
Word documents and Excel spreadsheets.

-Mike



|-+>
| |   Max Metral   |
| |  |
| |   Sent by: |
| |   jdev-admin@jabber|
| |   .org |
| |

RE: [JDEV] File transfers

[Michael F Lin]

Firstly, there is no inherent problem with sending moderately large files
through a software server. Sendmail does it all day, every day, on a
massive scale, without relying on client-to-client connections.

The trouble when we extend this to Jabber is that we expect Jabber to go
faster than Sendmail, so it's not acceptable to block all other traffic
while we send our file. Is this really a problem, though? I'm proposing -
effectively, not literally - just open up a second Jabber session on both
ends and do it that way. If the server is under heavy load, it can throttle
the karma as necessary. If the recipient's queue is too large, it can
reject the message. This is how e-mail works; just a bit smarter. This is a
solution based on something that has been in place for years and is known
to work reasonably well. E-mail has seen all the problems of mail bombing
and spamming and denial of service attacks others have been warning of, but
they have generally managed to keep themselves under control. I see no
compelling reason to believe that the same will not be true for Jabber.

Now, map what you and others are proposing we do back to e-mail. Every time
you send an e-mail with an attachment, you first send a message to the
recipient asking them for their IP address. Then your e-mail software opens
up a connection with some custom protocol and transfers the file directly
to the recpient. Firewalls are a problem, but you can set up some clever
daemons and such to get around them most of the time. What if the recipient
is not online at the time? What if it's a cell phone? What if, what if,
what if...?

Is that how e-mail should be done? If not, what's really so different about
Jabber?

Now, if you are transferring a gigabyte, you wouldn't send it via e-mail,
so why would you send it via Jabber? If e-mail clients don't have
facilities for client-to-client transfer of _extremely_ large files, why
should Jabber clients? If you need to transfer huge files, use tools
intended for that purpose. Maybe smart tools on the Jabber network could
even help you figure out the right IP address for the recipient. But there
is no reason to introduce this complexity to clients in order to transfer
Word documents and Excel spreadsheets.

-Mike



|-+>
| |   Max Metral   |
| |  |
| |   Sent by: |
| |   jdev-admin@jabber|
| |   .org |
| ||
| ||
| |   06/06/2002 12:14 |
| |   PM   |
| |   Please respond to|
| |   jdev |
| ||
|-+>
  
>--|
  |
  |
  |   To:   "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>  
  |
  |   cc:  
  |
  |   Subject:  RE: [JDEV] File transfers  
  |
  |
  |
  |
  |
  
>--|



There is no reasonable argument that client-to-client "open" file transfer
via the Jabber servers is a good idea.  You have to accept this to talk
about what specific VERSIONS of that idea might be useful.  The sub-10k
file
method isn't terrible, but it still has lots of abuse potential,and
complicates client design with having to support multiple mechanisms.  And
I'm not sure what problem it's really solving other than the firewall
situation.  We need to solve the firewall problem for big files, there's
nothing to say that solution can't handle small files too.  So all in all,
given that it's clear that client-server-client file transfer for normal
size files is a dead end, I would say the merits don't warrant new
techniques to get the server involved.

-Original Message-
From: Andy Beetz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 8:00 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JDEV] File transfers


I hear what you're saying, but there are ways you could easily stop large
transfers (or any for that matter) from occuring (limit by filesize, limit
bandwidth p/day or p/month

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Michael F Lin]

I agree, unfortunately, we now have a new implementation based on this
"informational" JEP which is vulnerable to the same security problems. So I
propose that the informational vs. standards track distinction is pretty
meaningless. Look at Matthias' comments - he used it for lack of anything
better.

The authors of this JEP, in my opinion, have the responsibility of fixing
it. We have handed them several ways to do so. Jabber, Inc., in my opinion,
has the responsibility of fixing its web client before its users using it
for "financial applications" get burned.

-Mike



|-+>
| |   "Peter Millard"  |
| |   <[EMAIL PROTECTED]|
| |   >|
| |   Sent by: |
| |   jdev-admin@jabber|
| |   .org |
| ||
| ||
| |   06/06/2002 01:05 |
| |   PM   |
| |   Please respond to|
| |   jdev |
| ||
|-+>
  
>--|
  |
  |
  |   To:   <[EMAIL PROTECTED]>  
  |
  |   cc:  
  |
  |   Subject:  Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)
  |
  |
  |
  |
  |
  
>--|



Mike -

> I agree, and I strongly recommend against the use of JEP-0025 as-is
> for any remotely sensitive purposes.
>
> We have been aware of the security problems for two months and have
> proposed multiple viable solutions, but nothing has been fixed. This
> JEP either needs to be fixed or withdrawn.

*disclaimer: I am employed by Jabber, Inc* :)

JEP-25 is INFORMATIONAL! It won't be withdrawn as it's not standards track.
The whole idea behind informational JEPS is that they allow companies (like
Jabber, Inc.) to document the protocol extensions that they build, so other
people in the jabber community can use and build other products to them (if
they so desire). It's unlikely that this JEP will change since it reflects
a
currently deployed product (good bad or ugly :).

Someone needs to take JEP-25 as a base, and create a new STANDARDS track
JEP
that fixes the security holes in the current implementation and submit it.
Then client authors (like myself) can choose to implement either JEP-25,
the
new standards JEP, or both.

Hope this makes sense.

Peter M.

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev





___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Re: [jadmin] [jadmin]Port access below 1024

[Justin Georgeson]

There is a big if clause to call setuid/setgid in the main function in 
jabberd.c. I've just been moving that around to see what happens. If I 
put it right before the while(1) loop at the end of the main function, 
then the process can bind priviledged ports, the pidfile is right, root 
owns the pidfile, and the extra jabberd thread (due to loading dnsrv) is 
still running as root. That's as close as I have come. The problem is 
that, as viewed from the main function, binding the ports and writing 
the pidfile all happen in one massive atomic step to process the config 
file. Perhaps the config file should be extended to have a tag for the 
username to run as. That way, you could arrange the order the steps are 
taken as the config file is processed.

Jonathan Augenstine wrote:
> Justin,
> 
> I have two questions.  The first is that have the changes you made to
> reorder the code been contributed back for inclusion with the
> distribution?  If not I would be interested in knowing what changes you
> made, as I have great need to implement this.  The second question is,
> can you change ownership or permisions on the pid file prior to the fork
> to make it writable to the designated user and rewrite the pid after the
> fork()??
> 
> Jonathan
> 
> 
>>-Original Message-
>>From: Justin Georgeson [mailto:[EMAIL PROTECTED]] 
>>Sent: Wednesday, June 05, 2002 6:45 PM
>>To: [EMAIL PROTECTED]
>>Cc: jdev
>>Subject: [JDEV] Re: [jadmin] [jadmin]Port access below 1024
>>
>>
>>It's not so much the ownership, it's that the pid in the pidfile is 
>>wrong. I couldn't get the pidfile to be written after the 
>>fork. Even on 
>>systems that have a tool to kill all processes with a given name 
>>(killall jabberd on RedHat for example), that's not always viable, as 
>>you might have multiple instances and only want to stop one.
>>
>>Jonathan Augenstine wrote:
>>
only answer I was given was to have my firewall forward the
priviledged 
port to the unpriviledged port jabber is running on.
>>>
>>>If I had that option available we would not be having this 
>>
>>exchange. 
>>
>>>Unfortunately.
>>>
>>>Can you clarify what the ramifications are of the problem 
>>
>>you describe 
>>
>>>below.  I understand that the pid file is created by root and as a 
>>>consequence the specified user account is unable to access the pid 
>>>file. How does this impact?
>>>
>>>
>>>
>>>
-Original Message-
From: Justin Georgeson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 11:55 AM
To: [EMAIL PROTECTED]
Subject: Re: [jadmin] [jadmin]


Using the -B command line options you can specify what user
to run as. I 
have successfully reordered the code to bind to the port 
before calling 
setuid/setgid and forking. The problem is I have been unsuccessful 
getting all this done before writing the pidfile, so I end up witha 
pidfile with the wrong pid and the process owner can't read. 
I've posted 
to several lists (this one, jdev, and 
[EMAIL PROTECTED]) and the 
only answer I was given was to have my firewall forward the 
priviledged 
port to the unpriviledged port jabber is running on.

Jonathan Augenstine wrote:


>I have a question on running Jabber on non-standard ports.  Does
>anyone have documentation or notes on how to run Jabber on 

ports below


>1024 but not run Jabber as root?
>
>Jonathan Augenstine ___
>jadmin mailing list
>[EMAIL PROTECTED]
>http://mailman.jabber.org/listinfo/jadmin


--
Justin Georgeson
UnBound Technologies, Inc.
http://www.unboundtech.com
Main   713.329.9330
Fax713.460.4051
Mobile 512.789.1962

5295 Hollister Road
Houston, TX 77040
Real Applications using Real Wireless Intelligence(tm)

___
jadmin mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jadmin

>>>
>>>___
>>>jadmin mailing list
>>>[EMAIL PROTECTED]
>>>http://mailman.jabber.org/listinfo/jadmin
>>
>>
>>-- 
>>Justin Georgeson
>>UnBound Technologies, Inc.
>>http://www.unboundtech.com
>>Main   713.329.9330
>>Fax713.460.4051
>>Mobile 512.789.1962
>>
>>5295 Hollister Road
>>Houston, TX 77040
>>Real Applications using Real Wireless Intelligence(tm)
>>
>>___
>>jdev mailing list
>>[EMAIL PROTECTED]
>>http://mailman.jabber.org/listinfo/jdev
>>
> 
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev


-- 
Justin Georgeson
UnBound Technologies, Inc.
http://www.unboundtech.com
Main   713.329.9330
Fax713.460.4051
Mobile 512.789.1962

5295 Hollister Road
Houston, TX 77040
Real Applications using Real Wireless Intelligence(tm)

__

Re: [JDEV] how to change the group name

[Dave]

I just wanted to make sure that all the client devs saw my suggestion
for a rather useful (and very easy to implement) feature; that's all ;-)

 - Dave


Peter Millard wrote:
> 
> Dave -
> 
> > Wouldn't it be nice if clients supported a "Rename Group" feature that
> > essentially just replaced all occurrences of "OldName" in the group
> > list for each roster item with "NewName?"  This isn't exactly asking
> > the client to do very much thinking, and it can save the user several
> > minutes of work if he's got loads of guys in a particular group that
> > he wants to rename.
> 
> The client should do exactly what you're proposing... What I was explaining
> is how to rename a group programatically using JabberCOM.
> 
> pgm
> 
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev
> 

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Info request

[Nicholas Perez]

It is very very little, but enough to get you started.

http://docs.jabber.org/general/html/component-intro.html


Andy Beetz wrote:
> Is there any documentation available for writing internal components?
> 
> Thanks in advance
> 
> |
> 
> 
>---
> Clearswift monitors, controls and protects all its messaging traffic in
> compliance with its corporate email policy using Clearswift products.
> Find out more about Clearswift, its solutions and services at
> www.clearswift.com.
> ***
> This communication is confidential and may contain privileged
> information intended solely for the named addressee(s). It may not
> be used or disclosed except for the purpose for which it has been
> sent. If you are not the intended recipient, you must not copy,
> distribute or take any action in reliance on it. Unless expressly stated,
> opinions in this message are those of the individual sender and not of
> Clearswift. If you have received this communication in error, please
> notify Clearswift by emailing [EMAIL PROTECTED] quoting the
> sender and delete the message and any attached documents. Clearswift
> accepts no liability or responsibility for any onward transmission or use of
> emails and attachments having left the Clearswift domain.
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for Content Security threats, including computer viruses.
> |


-- 
Nick

JabminRPC Developer
JabberSMTP Developer
ChatBot's B1tch


___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Peter Millard]

Mike -

> I agree, and I strongly recommend against the use of JEP-0025 as-is
> for any remotely sensitive purposes.
>
> We have been aware of the security problems for two months and have
> proposed multiple viable solutions, but nothing has been fixed. This
> JEP either needs to be fixed or withdrawn.

*disclaimer: I am employed by Jabber, Inc* :)

JEP-25 is INFORMATIONAL! It won't be withdrawn as it's not standards track.
The whole idea behind informational JEPS is that they allow companies (like
Jabber, Inc.) to document the protocol extensions that they build, so other
people in the jabber community can use and build other products to them (if
they so desire). It's unlikely that this JEP will change since it reflects a
currently deployed product (good bad or ugly :).

Someone needs to take JEP-25 as a base, and create a new STANDARDS track JEP
that fixes the security holes in the current implementation and submit it.
Then client authors (like myself) can choose to implement either JEP-25, the
new standards JEP, or both.

Hope this makes sense.

Peter M.

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] File transfers

[Richard Dobson]

- 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

Re: [JDEV] how to change the group name

[Peter Millard]

Dave -

> Wouldn't it be nice if clients supported a "Rename Group" feature that
> essentially just replaced all occurrences of "OldName" in the group
> list for each roster item with "NewName?"  This isn't exactly asking
> the client to do very much thinking, and it can save the user several
> minutes of work if he's got loads of guys in a particular group that
> he wants to rename.

The client should do exactly what you're proposing... What I was explaining
is how to rename a group programatically using JabberCOM.

pgm

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] File transfers

[Richard Dobson]

- 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

RE: [JDEV] File transfers

[Max Metral]

There is no reasonable argument that client-to-client "open" file transfer
via the Jabber servers is a good idea.  You have to accept this to talk
about what specific VERSIONS of that idea might be useful.  The sub-10k file
method isn't terrible, but it still has lots of abuse potential,and
complicates client design with having to support multiple mechanisms.  And
I'm not sure what problem it's really solving other than the firewall
situation.  We need to solve the firewall problem for big files, there's
nothing to say that solution can't handle small files too.  So all in all,
given that it's clear that client-server-client file transfer for normal
size files is a dead end, I would say the merits don't warrant new
techniques to get the server involved.

-Original Message-
From: Andy Beetz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 8:00 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JDEV] File transfers


I hear what you're saying, but there are ways you could easily stop large
transfers (or any for that matter) from occuring (limit by filesize, limit
bandwidth p/day or p/month, not allowing it at all full stop, content
filtering etc etc). 

I'm not hearing anything constructive from you. Your use of the oxymoron
"unofficial standard" (your other post) surprises me. For a technology that
wants to be a standard, I would have expected it to try and accommodate
usage of itself.

The jabber server has it's ports registered with IANA why not register one
for the clients? Then everyone is operating on the same level and not having
to re-invent the wheel every time someone writes a client. All I'm trying to
do is get something done which could prevent possible problems later on.


-Original Message-
From: Richard Dobson [mailto:[EMAIL PROTECTED]] 
Sent: 06 June 2002 12:11
To: [EMAIL PROTECTED]
Subject: Re: [JDEV] File transfers


Small level of abuse 
The problems I outlines are not small they are very significant, there may
be better ways to get copyrighted files but it does not stop people using
jabber for that purpose now does it, and any copyrighted files that get
transfered via the jabber server open the operators of that server to
serious legal problems because they helped transfer the actual file between
the two users, remember napster got shut down because they were helping
users transfer files between each other, they werent even transfering the
files in-band via the napster servers, which jabber already supports opening
it to possible legal problems already, but transfering files via the servers
just takes it up to a whole new level. Also transfering large files whether
they are split up or not is just not feasable at all because of the major
jump in bandwidth use for the server operators. Also there is nothing
stopping someone from pushing a file on someone wether they wanted it or
not, the only way files should be sent is that the sender sends a request to
the receiver and then the receiver downloads the file from the sender (HTTP
or otherwise), not the sender pushing the file to the receiver. Also if the
whole reason for this is because of wanting to get around a firewall then
you need to do it in the correct manor, using something like PASS, so if a
server provider is prepared to allow the transfering of files this way they
just setup a PASS server, you cant just force it on server providers like
this, that would end up making lots of the free servers either shut down or
start charging for using it. Bandwidth is not free.

Richard

- Original Message -
From: "Andy Beetz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 10:03 AM
Subject: RE: [JDEV] File transfers


> I can see a small level of abuse perhaps, but there are better ways to 
> distribute/get hold of copyrighted files (kazaa to name but one). The 
> fact that the communications are 1 to 1 would not make the sharing of 
> files on
a
> massive scale feasible. I can only speak for myself obviously, but 
> I've
only
> ever used file transfer in msn messenger for small files. If I wanted 
> to download say a movie, I would use something designed for that 
> purpose,
even
> if it was from someone I knew I would find a way around not using an 
> IM
app.
>
> I know in band data transfers present a problem, but I think splitting 
> the data would make it more server friendly. Plus the clients can 
> still send
and
> receive messages etc in between parts (given higher priority). 
> Firewalls present a major problem, but if you can get a connection to 
> the server,
then
> the problem dissipates.
>
> -Original Message-
> From: Richard Dobson [mailto:[EMAIL PROTECTED]]
> Sent: 06 June 2002 09:35
> To: [EMAIL PROTECTED]
> Subject: Re: [JDEV] File transfers
>
>
> I think that allowing file transfers of very small files in-band would 
> be cool, but anything over 10k or so should be sent out of band by 
> some other means, allowing it in band at all is also a big problem 
> because of

Re: [JDEV] File transfers

[Jacek Konieczny]

On Thu, Jun 06, 2002 at 11:10:10AM -0400, Michael F Lin wrote:
...
> 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. 
...
> 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.

I do also think this is the way it should be done. If jabber server know
how to route xml messages they should be able to find the best route for
the outband connections too. And this doesn't need to be the same. 
Several servers may be configured to direct clients to some globaly
accessible HUB, or may suggest direct link between the clients. This 
way jabber could be integrated with ISP's routing adn firewall
infrastructure and the clients would not have to guess any strange
configs of the network.

Greets,
Jacek
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Michael F Lin]

I agree, and I strongly recommend against the use of JEP-0025 as-is for any
remotely sensitive purposes.

We have been aware of the security problems for two months and have
proposed multiple viable solutions, but nothing has been fixed. This JEP
either needs to be fixed or withdrawn.

The relevant discussion appears here:
http://mailman.jabber.org/pipermail/council/2002-April/000245.html
http://mailman.jabber.org/pipermail/standards-jig/2002-April/000758.html

-Mike



|-+>
| |   [EMAIL PROTECTED]|
| |   f.de |
| |   Sent by: |
| |   jdev-admin@jabber|
| |   .org |
| ||
| ||
| |   06/06/2002 09:27 |
| |   AM   |
| |   Please respond to|
| |   jdev |
| ||
|-+>
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED]
  |
  |   cc:  
  |
  |   Subject:  Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)
  |
  |
  |
  |
  |
  
>--|



On Thu, 6 Jun 2002, Matthias Wimmer wrote:

> I have enhanced the JabberApplet to support Jabber HTTP Polling and I
> have written a server side implementation as a Java Servlet.

Note JEP-0025 is very insecure (in fact it is less secure than standard
connections with clear text authentification). There were some discussions
and solutions posted to the standards-jep and council mailing list but up
to now there was no response by the jabber.com people.

I think it would be best to implement one of the proposed protocols that
are secure and to patch the clients supporting HTTP polling. It's not that
much work and should be done NOW.

Regards

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev





___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] does Jabber support yahoo?

[Ben Schumacher]

See:

http://support.jabber.com/public-server/yahoostatus.html

bs.

On Thu, 6 Jun 2002, Dave wrote:
> If connecting to Yahoo! from India isn't possible (because of their
> discontinued support for the version of their protocol that we use),
> you can just connect to a transport somewhere else in the world, no?
>
> As for jabber.com, I don't think their Yahoo! transport works at all, ATM.
>
> Can somebody please confirm/deny either of the above?
>
> Thanks,
> Dave Cohen <[EMAIL PROTECTED]>
>
>
> Rajesh Kannan wrote:
> >
> > Hi,
> >
> > I could not link with yahoo using jabber com.  What i
> > have to do?.  I am from India.  Some one told that
> > Logging to yahoo from India is not possible with
> > jabber.  Is that true?.  Please reply this mail,
> >
> > Rajesh Kannan MJ
> >
>

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

[JDEV] list admin AWOL

[Peter Saint-Andre]

Hello Jabberites,

Your friendly list admin (me) will be mostly offline for the next 2 weeks.
It is possible that I will be online enough to clear out pending admin
requests, but don't count on it. So be good or I'll have to send temas
after you. :)

Happy Jabbering!

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.html

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] File transfers

[Michael F Lin]

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.

Legalities are really not an issue for Jabber file transfer.

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.

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.

That's what I want - for any sized payload.

-Mike



|-+>
| |   "Richard Dobson" |
| |   |
| |   Sent by: |
| |   jdev-admin@jabber|
| |   .org |
| ||
| ||
| |   06/06/2002 07:10 |
| |   AM   |
| |   Please respond to|
| |   jdev |
| ||
|-+>
  
>--|
  |
  |
  |   To:   <[EMAIL PROTECTED]>  
  |
  |   cc:  
  |
  |   Subject:  Re: [JDEV] File transfers  
  |
  |
  |
  |
  |
  
>--|



Small level of abuse 
The problems I outlines are not small they are very significant, there may
be better ways to get copyrighted files but it does not stop people using
jabber for that purpose now does it, and any copyrighted files that get
transfered via the jabber server open the operators of that server to
serious legal problems because they helped transfer the actual file between
the two users, remember napster got shut down because they were helping
users transfer files between each other, they werent even transfering the
files in-band via the napster servers, which jabber already supports
opening
it to possible legal problems already, but transfering files via the
servers
just takes it up to a whole new level.
Also transfering large files whether they are split up or not is just not
feasable at all because of the major jump in bandwidth use for the server
operators.
Also there is nothing stopping someone from pushing a file on someone
wether
they wanted it or not, the only way files should be sent is that the sender
sends a request to the receiver and then the receiver downloads the file
from the sender (HTTP or otherwise), not the sender pushing the file to the
receiver.
Also if the whole reason for this is because of wanting to get around a
firewall then you need to do it in the correct manor, using something like
PASS, so if a server provider is prepared to allow the transfering of files
this way they just setup a PASS server, you cant just force it on server
providers like this, that would end up making lots of the free 

Re: [JDEV] (more) File transfers

[Dave]

Yeah, you can use an HTTP POST "request" instead of an HTTP GET.
That's how your browser typically sends form data to a web server.

Dave Cohen <[EMAIL PROTECTED]>


Michael Brown wrote:
> Is there some way to do an HTTP "push".  The reason I ask, is that it would
> get around some of the NAT problems if I could get my client to initiate a
> file transfer in cases where there is a firewall blocking the normal HTTP
> "get".  Some of the file sharing apps do this, (try for a pull and if that
> fails try a push).  On my local machine (behind NAT) I have the ironic
> situation, where I can send files by ICQ, and receive them via Jabber, but
> not vice versa.  With some sort of "push-pull" method, it would mean that if
> I had my NAT port mapping set up correctly, I could transfer files to anyone
> even if they didn't.
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] does Jabber support yahoo?

[Dave]

If connecting to Yahoo! from India isn't possible (because of their
discontinued support for the version of their protocol that we use),
you can just connect to a transport somewhere else in the world, no?

As for jabber.com, I don't think their Yahoo! transport works at all, ATM.

Can somebody please confirm/deny either of the above?

Thanks,
Dave Cohen <[EMAIL PROTECTED]>


Rajesh Kannan wrote:
> 
> Hi,
> 
> I could not link with yahoo using jabber com.  What i
> have to do?.  I am from India.  Some one told that
> Logging to yahoo from India is not possible with
> jabber.  Is that true?.  Please reply this mail,
> 
> Rajesh Kannan MJ
> 
> __
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev
> 

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] how to change the group name

[Dave]

Wouldn't it be nice if clients supported a "Rename Group" feature that
essentially just replaced all occurrences of "OldName" in the group list
for each roster item with "NewName?"  This isn't exactly asking the client
to do very much thinking, and it can save the user several minutes of work
if he's got loads of guys in a particular group that he wants to rename.

Dave Cohen <[EMAIL PROTECTED]>


Peter G. Millard wrote:
> 
> To "rename" a group, you need to move all of the contacts from the old group
> into the new group with the new group name. The old should just go away once
> there are no contacts in it anymore.
> 
> Peter M.
> 
> > hi friends
> >   i got a problem regarding changing the name of the group which is
> > previously exists.
> > there is no such methode describe in jabbercom.dll for doing so.
> > nits
> 
> 
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev
> 

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Matthias Wimmer]

Hi!

[EMAIL PROTECTED] wrote:
> Note JEP-0025 is very insecure (in fact it is less secure than standard
> connections with clear text authentification). There were some discussions
> and solutions posted to the standards-jep and council mailing list but up
> to now there was no response by the jabber.com people.

Yes I read the postings at standards-jep and you're right that the 
security can be improved.

> I think it would be best to implement one of the proposed protocols that
> are secure and to patch the clients supporting HTTP polling. It's not that
> much work and should be done NOW.

As long as JEP-0025 is the only real documented protocol I prefere to 
implement this one. If I implement something else nobody will be able to 
use it because your extensions will be forgotten in some months. Also I 
couldn't wait to implement it because I need this software component 
very soon.

If there is an "agreement" over a new version of the polling protocol I 
will like to implement this enhancement.


Tot kijk
 Matthias

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] (more) File transfers

[Richard Dobson]

- Original Message -
From: "Michael Brown" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 2:58 PM
Subject: [JDEV] (more) File transfers

> And alternative, would be to create a simple(-ish) PASS type component
that
> would run as a service under WinNT/2000/XP or under Linux, and make it
very
> simple for consumers to install.  When they install a client behind ICS or
> other NAT box, you could make it very clear to them that they need to
> install this PASS component on the gateway machine that has the private IP
> address, or their files/voicechat/webcam etc will not work.  Of course
this
> isn't going to help the people that use hardware NAT boxes, but they will
> have to wait for UPnP I guess.

Thats good I like this local PASS component idea, this would mean not just
file transfers, but other oob data like voice and whiteboard etc could be
done, all you have to do it is in the client tell it where the PASS server
is, and the client connects to the PASS kind of like a server but with
little or no authentication to a local port that cannot be accessed from
outside on the internet (to prevent hackers etc on the internet taking
advantage of it) to tell it to setup ports like PASS for any purpose the
client might need.

Could also just use SOCKS5, but I dont think there are any good free SOCKS5
servers for windows platforms available, plus it wouldnt be as fun ;)

Richard



___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

RE: [JDEV] Re: [jadmin] [jadmin]Port access below 1024

[Jonathan Augenstine]

Justin,

I have two questions.  The first is that have the changes you made to
reorder the code been contributed back for inclusion with the
distribution?  If not I would be interested in knowing what changes you
made, as I have great need to implement this.  The second question is,
can you change ownership or permisions on the pid file prior to the fork
to make it writable to the designated user and rewrite the pid after the
fork()??

Jonathan

> -Original Message-
> From: Justin Georgeson [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, June 05, 2002 6:45 PM
> To: [EMAIL PROTECTED]
> Cc: jdev
> Subject: [JDEV] Re: [jadmin] [jadmin]Port access below 1024
> 
> 
> It's not so much the ownership, it's that the pid in the pidfile is 
> wrong. I couldn't get the pidfile to be written after the 
> fork. Even on 
> systems that have a tool to kill all processes with a given name 
> (killall jabberd on RedHat for example), that's not always viable, as 
> you might have multiple instances and only want to stop one.
> 
> Jonathan Augenstine wrote:
> >>only answer I was given was to have my firewall forward the
> >>priviledged 
> >>port to the unpriviledged port jabber is running on.
> > 
> > If I had that option available we would not be having this 
> exchange. 
> > Unfortunately.
> > 
> > Can you clarify what the ramifications are of the problem 
> you describe 
> > below.  I understand that the pid file is created by root and as a 
> > consequence the specified user account is unable to access the pid 
> > file. How does this impact?
> > 
> > 
> > 
> >>-Original Message-
> >>From: Justin Georgeson [mailto:[EMAIL PROTECTED]]
> >>Sent: Wednesday, June 05, 2002 11:55 AM
> >>To: [EMAIL PROTECTED]
> >>Subject: Re: [jadmin] [jadmin]
> >>
> >>
> >>Using the -B command line options you can specify what user
> >>to run as. I 
> >>have successfully reordered the code to bind to the port 
> >>before calling 
> >>setuid/setgid and forking. The problem is I have been unsuccessful 
> >>getting all this done before writing the pidfile, so I end up witha 
> >>pidfile with the wrong pid and the process owner can't read. 
> >>I've posted 
> >>to several lists (this one, jdev, and 
> >>[EMAIL PROTECTED]) and the 
> >>only answer I was given was to have my firewall forward the 
> >>priviledged 
> >>port to the unpriviledged port jabber is running on.
> >>
> >>Jonathan Augenstine wrote:
> >>
> >>>I have a question on running Jabber on non-standard ports.  Does
> >>>anyone have documentation or notes on how to run Jabber on 
> >>
> >>ports below
> >>
> >>>1024 but not run Jabber as root?
> >>>
> >>>Jonathan Augenstine ___
> >>>jadmin mailing list
> >>>[EMAIL PROTECTED]
> >>>http://mailman.jabber.org/listinfo/jadmin
> >>
> >>
> >>--
> >>Justin Georgeson
> >>UnBound Technologies, Inc.
> >>http://www.unboundtech.com
> >>Main   713.329.9330
> >>Fax713.460.4051
> >>Mobile 512.789.1962
> >>
> >>5295 Hollister Road
> >>Houston, TX 77040
> >>Real Applications using Real Wireless Intelligence(tm)
> >>
> >>___
> >>jadmin mailing list
> >>[EMAIL PROTECTED]
> >>http://mailman.jabber.org/listinfo/jadmin
> >>
> > 
> > ___
> > jadmin mailing list
> > [EMAIL PROTECTED]
> > http://mailman.jabber.org/listinfo/jadmin
> 
> 
> -- 
> Justin Georgeson
> UnBound Technologies, Inc.
> http://www.unboundtech.com
> Main   713.329.9330
> Fax713.460.4051
> Mobile 512.789.1962
> 
> 5295 Hollister Road
> Houston, TX 77040
> Real Applications using Real Wireless Intelligence(tm)
> 
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev
> 
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

[JDEV] (more) File transfers

[Michael Brown]

While we are on this topic...

It's worth noting that although we are talking about files a lot here, this
is going to affect any OOB data, such as voice chat, webcams, whiteboards
etc etc.  There is more to OOB data that sending your mates MP3's.

> Also there is nothing stopping someone from pushing a file on someone
wether
> they wanted it or not, the only way files should be sent is that the
sender
> sends a request to the receiver and then the receiver downloads the file
> from the sender (HTTP or otherwise), not the sender pushing the file to
the
> receiver.

Is there some way to do an HTTP "push".  The reason I ask, is that it would
get around some of the NAT problems if I could get my client to initiate a
file transfer in cases where there is a firewall blocking the normal HTTP
"get".  Some of the file sharing apps do this, (try for a pull and if that
fails try a push).  On my local machine (behind NAT) I have the ironic
situation, where I can send files by ICQ, and receive them via Jabber, but
not vice versa.  With some sort of "push-pull" method, it would mean that if
I had my NAT port mapping set up correctly, I could transfer files to anyone
even if they didn't.

> Also if the whole reason for this is because of wanting to get around a
> firewall then you need to do it in the correct manor, using something like
> PASS, so if a server provider is prepared to allow the transfering of
files
> this way they just setup a PASS server, you cant just force it on server
> providers like this, that would end up making lots of the free servers
> either shut down or start charging for using it. Bandwidth is not free.

About this whole PASS thing...it seems like a great idea, but really the
only efficient places to have a PASS server are locally at your ISP, or
locally at your peers ISP.  Anywhere else, and you are going to be chewing
though bandwidth for no reason.  And I don't fancy the task of trying to
explain to my ISP that I need them to set one of these somewhere on their
network...

And alternative, would be to create a simple(-ish) PASS type component that
would run as a service under WinNT/2000/XP or under Linux, and make it very
simple for consumers to install.  When they install a client behind ICS or
other NAT box, you could make it very clear to them that they need to
install this PASS component on the gateway machine that has the private IP
address, or their files/voicechat/webcam etc will not work.  Of course this
isn't going to help the people that use hardware NAT boxes, but they will
have to wait for UPnP I guess.

Michael



___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] File transfers

[Richard Dobson]

Well I myself dont like using HTTP transfers in Jabber, but as thats how
file transfers are already implemented in current clients, if you want to
interoperate with them you will have to support HTTP.

I myself am creating a method of file transfer in my own client which works
differently, by each client negotiating the file transfer connection, in
which they connect directly to each other either way so if one of them is
behind a firewall/nat and the other isnt then they just establish the
connection in the appropriate direction, otherwise they connect via a PASS
server. When a socket has been established between the two clients the file
is transfered using a basic packet framing mechanism to minimise the
overhead.

Also to get around the firewall a fixed port could be mapped at the firewall
to the client, or a PASS server could be setup on the network with a range
of ports mapped to it that could act as a proxy/gateway for external clients
to connect to, or a SOCKS gateway could be setup, there are lots of better
ways to get around the firewall problem.

That is the proper way to send files between clients, putting all the
complexity required into the server to stop potential abuses or in-band file
transfer is unfeasable, it will probably slow down the server overall as it
will have to do extra checking of packets passing thru to see if they are
file transfer packets over the specified limit. If you are wanting all this
limiting and control stuff just use PASS which is designed with that in
mind.

Also I dont see why you are trying to ignore the bandwidth (its not free for
providers, they often pay by the K) aspect of this, for one encoding things
into BASE64 (required to transporting binary in XML) increases the size by
about 33% slowing down the transfer overall at the client ends (especially
when people are on dial-up) and using more bandwidth than really necessary,
it means a lot more bandwidth used than a PASS solution, also instead of
sending all file transfers thru the server dont you think its best to
connect directly if possible.

Also why are you saying that I am saying anything constructive?? The only
reason you have stated for transferring files in-band is that it gets around
firewalls, and I have suggested a better alternative that also gets around
firewalls.

Richard

- Original Message -
From: "Andy Beetz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 12:59 PM
Subject: RE: [JDEV] File transfers


> I hear what you're saying, but there are ways you could easily stop large
> transfers (or any for that matter) from occuring (limit by filesize, limit
> bandwidth p/day or p/month, not allowing it at all full stop, content
> filtering etc etc).
>
> I'm not hearing anything constructive from you. Your use of the oxymoron
> "unofficial standard" (your other post) surprises me. For a technology
that
> wants to be a standard, I would have expected it to try and accommodate
> usage of itself.
>
> The jabber server has it's ports registered with IANA why not register one
> for the clients? Then everyone is operating on the same level and not
having
> to re-invent the wheel every time someone writes a client. All I'm trying
to
> do is get something done which could prevent possible problems later on.
>
>
> -Original Message-
> From: Richard Dobson [mailto:[EMAIL PROTECTED]]
> Sent: 06 June 2002 12:11
> To: [EMAIL PROTECTED]
> Subject: Re: [JDEV] File transfers
>
>
> Small level of abuse 
> The problems I outlines are not small they are very significant, there may
> be better ways to get copyrighted files but it does not stop people using
> jabber for that purpose now does it, and any copyrighted files that get
> transfered via the jabber server open the operators of that server to
> serious legal problems because they helped transfer the actual file
between
> the two users, remember napster got shut down because they were helping
> users transfer files between each other, they werent even transfering the

> files in-band via the napster servers, which jabber already supports
opening
> it to possible legal problems already, but transfering files via the
servers
> just takes it up to a whole new level. Also transfering large files
whether
> they are split up or not is just not feasable at all because of the major
> jump in bandwidth use for the server operators. Also there is nothing
> stopping someone from pushing a file on someone wether they wanted it or
> not, the only way files should be sent is that the sender sends a request
to
> the receiver and then the receiver downloads the file from the sender
(HTTP
> or otherwise), not the sender pushing the file to the receiver. Also if
the
> whole reason for this is because of wanting to get around a firewall then
> you need to do it in the correct manor, using something like PASS, so if a
> server provider is prepared to allow the transfering of files this way
they
> just setup a PASS server, you cant just f

Re: [JDEV] new user registration with jabberbeans

[Aaron Iba]

Thanks!

Perhaps someone should update the "Jabber Libraries" section of
 so that new developers know that
there is a Java alternative to jabberbeans.  Are there any others?

Aaron

Chris Chen wrote:
> 
> You can actually try my Echomine Muse API instead of Jabberbeans and see if
> it fits your needs.. It's alot simpler to use than Jabberbeans.
> 
> I know this isn't helping you with your current situation, but I am
> shamelessly advertising my API plus I firmly believe it's more advanced and
> easier to use than Jabberbeans. :)
> 
> http://www.echomine.org/projects/muse/
> 
> Thanks,
> Chris
> 

-- 
++
| Aaron Iba  |
| Research Engineer Intern   |
| Nokia Research Center  |
| phone: 781.993.3907|
| email: <[EMAIL PROTECTED]>   |
++
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] how to change the group name

[Peter G. Millard]

To "rename" a group, you need to move all of the contacts from the old group
into the new group with the new group name. The old should just go away once
there are no contacts in it anymore.

Peter M.

> hi friends
>   i got a problem regarding changing the name of the group which is
> previously exists.
> there is no such methode describe in jabbercom.dll for doing so.
> nits


___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[admin]

On Thu, 6 Jun 2002, Matthias Wimmer wrote:

> I have enhanced the JabberApplet to support Jabber HTTP Polling and I
> have written a server side implementation as a Java Servlet.

Note JEP-0025 is very insecure (in fact it is less secure than standard
connections with clear text authentification). There were some discussions
and solutions posted to the standards-jep and council mailing list but up
to now there was no response by the jabber.com people.

I think it would be best to implement one of the proposed protocols that
are secure and to patch the clients supporting HTTP polling. It's not that
much work and should be done NOW.

Regards

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Bharath Kumar]

Thanks Matthias , for the help
Downloaded the same and trying, will let u knw,


- Original Message -
From: Matthias Wimmer <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 6:06 PM
Subject: Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)


> Hi Bharath!
>
> Bharath Kumar wrote:
> > I am unable to download the version, it gives me the following
error.
> >
> > Access forbidden!
>
>
> I'm sorry ... wrong file permissions. Should be fixed now.
>
>
> Tot kijk
>  Matthias
>
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Matthias Wimmer]

Hi Bharath!

Bharath Kumar wrote:
> I am unable to download the version, it gives me the following error.
> 
> Access forbidden!


I'm sorry ... wrong file permissions. Should be fixed now.


Tot kijk
 Matthias

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

RE: [JDEV] File transfers

[Andy Beetz]

I hear what you're saying, but there are ways you could easily stop large
transfers (or any for that matter) from occuring (limit by filesize, limit
bandwidth p/day or p/month, not allowing it at all full stop, content
filtering etc etc). 

I'm not hearing anything constructive from you. Your use of the oxymoron
"unofficial standard" (your other post) surprises me. For a technology that
wants to be a standard, I would have expected it to try and accommodate
usage of itself.

The jabber server has it's ports registered with IANA why not register one
for the clients? Then everyone is operating on the same level and not having
to re-invent the wheel every time someone writes a client. All I'm trying to
do is get something done which could prevent possible problems later on.


-Original Message-
From: Richard Dobson [mailto:[EMAIL PROTECTED]] 
Sent: 06 June 2002 12:11
To: [EMAIL PROTECTED]
Subject: Re: [JDEV] File transfers


Small level of abuse 
The problems I outlines are not small they are very significant, there may
be better ways to get copyrighted files but it does not stop people using
jabber for that purpose now does it, and any copyrighted files that get
transfered via the jabber server open the operators of that server to
serious legal problems because they helped transfer the actual file between
the two users, remember napster got shut down because they were helping
users transfer files between each other, they werent even transfering the
files in-band via the napster servers, which jabber already supports opening
it to possible legal problems already, but transfering files via the servers
just takes it up to a whole new level. Also transfering large files whether
they are split up or not is just not feasable at all because of the major
jump in bandwidth use for the server operators. Also there is nothing
stopping someone from pushing a file on someone wether they wanted it or
not, the only way files should be sent is that the sender sends a request to
the receiver and then the receiver downloads the file from the sender (HTTP
or otherwise), not the sender pushing the file to the receiver. Also if the
whole reason for this is because of wanting to get around a firewall then
you need to do it in the correct manor, using something like PASS, so if a
server provider is prepared to allow the transfering of files this way they
just setup a PASS server, you cant just force it on server providers like
this, that would end up making lots of the free servers either shut down or
start charging for using it. Bandwidth is not free.

Richard

- Original Message -
From: "Andy Beetz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 10:03 AM
Subject: RE: [JDEV] File transfers


> I can see a small level of abuse perhaps, but there are better ways to 
> distribute/get hold of copyrighted files (kazaa to name but one). The 
> fact that the communications are 1 to 1 would not make the sharing of 
> files on
a
> massive scale feasible. I can only speak for myself obviously, but 
> I've
only
> ever used file transfer in msn messenger for small files. If I wanted 
> to download say a movie, I would use something designed for that 
> purpose,
even
> if it was from someone I knew I would find a way around not using an 
> IM
app.
>
> I know in band data transfers present a problem, but I think splitting 
> the data would make it more server friendly. Plus the clients can 
> still send
and
> receive messages etc in between parts (given higher priority). 
> Firewalls present a major problem, but if you can get a connection to 
> the server,
then
> the problem dissipates.
>
> -Original Message-
> From: Richard Dobson [mailto:[EMAIL PROTECTED]]
> Sent: 06 June 2002 09:35
> To: [EMAIL PROTECTED]
> Subject: Re: [JDEV] File transfers
>
>
> I think that allowing file transfers of very small files in-band would 
> be cool, but anything over 10k or so should be sent out of band by 
> some other means, allowing it in band at all is also a big problem 
> because of the massive potential for abuse, in ways like DOS attacks 
> against individual clients and the server itself, excessive use of 
> expensive bandwidth, also creates copyright issues if people transfer 
> copyrighted files via the
server
> because it then brings the server providors into the line of fire 
> because they facilitated the transfer, etc etc.
>
> Because of all of these problems I dont think its a good idea to 
> transfer files in-band at all.
>
> Just my 2p
> Richard
>
> - Original Message -
> From: "Andy Beetz" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 06, 2002 6:58 AM
> Subject: RE: [JDEV] File transfers
>
>
> > What about the nntp idea for very large posts? Where the file is 
> > split
> into
> > several parts, each part being only small in size could be 
> > transmitted in-band just one at a time. As long as they carry header 
> > information the client at the other end 

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Bharath Kumar]

Hi,
I am unable to download the version, it gives me the following error.

Access forbidden!
You don't have permission to access the requested object. It is either
read-protected or not readable by the server.
If you think this is a server error, please contact the webmaster

Error 403
devel.amessage.de
Thu Jun 6 13:49:04 2002
Apache/2.0.36 (Unix) mod_ssl/2.0.36 OpenSSL/0.9.6 DAV/2 PHP/4.2.1



- Original Message -
From: Matthias Wimmer <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 3:28 PM
Subject: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)


> Hi!
>
> I have enhanced the JabberApplet to support Jabber HTTP Polling and I
> have written a server side implementation as a Java Servlet.
>
> If somebody wants to help finding bugs, please feel free to download the
> code at http://devel.amessage.de/. It is not yet meant to be used for
> everyday use.
>
>
> Tot kijk
>Matthias
> --
> phone: +49-700-77007770 web: http://matthias-wimmer.de/
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] File transfers

[Richard Dobson]

Sure its a big problem, but it is a client problem, the current unoffical
standard or sending files is via the HTTP protocol, if a client with file
transfer does not work correctly email the author and tell them so, thats
the only way things are going to get fixed.

Richard

- Original Message -
From: "Andy Beetz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 11:38 AM
Subject: Re: [JDEV] File transfers


> I just performed a quick test on the client interoperability with regards
to
> file transfers and here is what I found
>
> Setup:
> Jabberd server
> myJabber client
> Winjab client
>
>
> Attempt to send a file from myJabber client to Winjab client:
> The receive dialog popped up, hit receive. The file was created but
> no data was transferred.
>
> Attempt to send a file from Winjab client to myJabber client:
> Receive dialog popped up, hit receive. Immediately a error msg is
> shown (on myJabber client)
> 'Run-time error '380': Invalid property value', clicked ok, the
> myJabber client acc vio'd and died.
>
> To me this is unacceptable, to have lots of available clients which can't
> communicate correctly with one another. I just see the same thing
happening
> as did with MIME, where everyone interpreted the RFC's in their own way,
and
> now we are left with exploits left right and centre because of
> inter-operability 'fixes'.
>
> Let me know what you think
>
>
> --
-
> Clearswift monitors, controls and protects all its messaging traffic in
> compliance with its corporate email policy using Clearswift products.
> Find out more about Clearswift, its solutions and services at
> www.clearswift.com.
>

***
> This communication is confidential and may contain privileged
> information intended solely for the named addressee(s). It may not
> be used or disclosed except for the purpose for which it has been
> sent. If you are not the intended recipient, you must not copy,
> distribute or take any action in reliance on it. Unless expressly stated,
> opinions in this message are those of the individual sender and not of
> Clearswift. If you have received this communication in error, please
> notify Clearswift by emailing [EMAIL PROTECTED] quoting the
> sender and delete the message and any attached documents. Clearswift
> accepts no liability or responsibility for any onward transmission or use
of
> emails and attachments having left the Clearswift domain.
>
> This footnote confirms that this email message has been swept by
> MIMEsweeper for Content Security threats, including computer viruses.
>
> ___
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev
>
>


___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] File transfers

[Richard Dobson]

Small level of abuse 
The problems I outlines are not small they are very significant, there may
be better ways to get copyrighted files but it does not stop people using
jabber for that purpose now does it, and any copyrighted files that get
transfered via the jabber server open the operators of that server to
serious legal problems because they helped transfer the actual file between
the two users, remember napster got shut down because they were helping
users transfer files between each other, they werent even transfering the
files in-band via the napster servers, which jabber already supports opening
it to possible legal problems already, but transfering files via the servers
just takes it up to a whole new level.
Also transfering large files whether they are split up or not is just not
feasable at all because of the major jump in bandwidth use for the server
operators.
Also there is nothing stopping someone from pushing a file on someone wether
they wanted it or not, the only way files should be sent is that the sender
sends a request to the receiver and then the receiver downloads the file
from the sender (HTTP or otherwise), not the sender pushing the file to the
receiver.
Also if the whole reason for this is because of wanting to get around a
firewall then you need to do it in the correct manor, using something like
PASS, so if a server provider is prepared to allow the transfering of files
this way they just setup a PASS server, you cant just force it on server
providers like this, that would end up making lots of the free servers
either shut down or start charging for using it. Bandwidth is not free.

Richard

- Original Message -
From: "Andy Beetz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 10:03 AM
Subject: RE: [JDEV] File transfers


> I can see a small level of abuse perhaps, but there are better ways to
> distribute/get hold of copyrighted files (kazaa to name but one). The fact
> that the communications are 1 to 1 would not make the sharing of files on
a
> massive scale feasible. I can only speak for myself obviously, but I've
only
> ever used file transfer in msn messenger for small files. If I wanted to
> download say a movie, I would use something designed for that purpose,
even
> if it was from someone I knew I would find a way around not using an IM
app.
>
> I know in band data transfers present a problem, but I think splitting the
> data would make it more server friendly. Plus the clients can still send
and
> receive messages etc in between parts (given higher priority). Firewalls
> present a major problem, but if you can get a connection to the server,
then
> the problem dissipates.
>
> -Original Message-
> From: Richard Dobson [mailto:[EMAIL PROTECTED]]
> Sent: 06 June 2002 09:35
> To: [EMAIL PROTECTED]
> Subject: Re: [JDEV] File transfers
>
>
> I think that allowing file transfers of very small files in-band would be
> cool, but anything over 10k or so should be sent out of band by some other
> means, allowing it in band at all is also a big problem because of the
> massive potential for abuse, in ways like DOS attacks against individual
> clients and the server itself, excessive use of expensive bandwidth, also
> creates copyright issues if people transfer copyrighted files via the
server
> because it then brings the server providors into the line of fire because
> they facilitated the transfer, etc etc.
>
> Because of all of these problems I dont think its a good idea to transfer
> files in-band at all.
>
> Just my 2p
> Richard
>
> - Original Message -
> From: "Andy Beetz" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 06, 2002 6:58 AM
> Subject: RE: [JDEV] File transfers
>
>
> > What about the nntp idea for very large posts? Where the file is split
> into
> > several parts, each part being only small in size could be transmitted
> > in-band just one at a time. As long as they carry header information
> > the client at the other end should be able to decode and re-assemble.
> > It
> should
> > be possible to request parts if they're missing.
> >
> >
> > -Original Message-
> > From: Michael F Lin [mailto:[EMAIL PROTECTED]]
> > Sent: 05 June 2002 19:23
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JDEV] File transfers
> >
> >
> >
> > When we generalize the Jabber network to thousands of servers, it
> > becomes something of a nightmare to transport stuff out of band. This
> > is of course why HTTP is not too good for this purpose - too many
> > people are behind firewalls. Any direct client-to-client connection
> > with whatever protocol will of course have the same problem. Relying
> > on e-mail routing is one option, but how do you negotiate what address
> > to send an e-mail to? How do you receive it? What if you need a file
> > but don't have access to your e-mail?
> >
> > There are any number of solutions you can set up with WebDAV and so
> > forth, but what we would really, really like - p

Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[David Kuczek]

Great work Matthias,

That's exactly what I've been waiting for...

Our webhost only allows access to port 80, ssh and
ftp!

Thanks

David

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Re: [JDEV] File transfers

[Andy Beetz]

I just performed a quick test on the client interoperability with regards to
file transfers and here is what I found

Setup:
Jabberd server
myJabber client
Winjab client


Attempt to send a file from myJabber client to Winjab client:
The receive dialog popped up, hit receive. The file was created but
no data was transferred.

Attempt to send a file from Winjab client to myJabber client:
Receive dialog popped up, hit receive. Immediately a error msg is
shown (on myJabber client) 
'Run-time error '380': Invalid property value', clicked ok, the
myJabber client acc vio'd and died.

To me this is unacceptable, to have lots of available clients which can't
communicate correctly with one another. I just see the same thing happening
as did with MIME, where everyone interpreted the RFC's in their own way, and
now we are left with exploits left right and centre because of
inter-operability 'fixes'.

Let me know what you think


---
Clearswift monitors, controls and protects all its messaging traffic in 
compliance with its corporate email policy using Clearswift products. 
Find out more about Clearswift, its solutions and services at 
www.clearswift.com.
***
This communication is confidential and may contain privileged 
information intended solely for the named addressee(s). It may not 
be used or disclosed except for the purpose for which it has been 
sent. If you are not the intended recipient, you must not copy, 
distribute or take any action in reliance on it. Unless expressly stated, 
opinions in this message are those of the individual sender and not of 
Clearswift. If you have received this communication in error, please 
notify Clearswift by emailing [EMAIL PROTECTED] quoting the 
sender and delete the message and any attached documents. Clearswift 
accepts no liability or responsibility for any onward transmission or use of
emails and attachments having left the Clearswift domain.

This footnote confirms that this email message has been swept by 
MIMEsweeper for Content Security threats, including computer viruses.

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

[JDEV] does Jabber support yahoo?

[Rajesh Kannan]

Hi,

I could not link with yahoo using jabber com.  What i
have to do?.  I am from India.  Some one told that
Logging to yahoo from India is not possible with
jabber.  Is that true?.  Please reply this mail,

Rajesh Kannan MJ

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

[JDEV] Custom namespaces

[Raistlin Tanis]

hi all!

i'm using a custom namespace and am passing it to the
server with the ff format:




Item One




what i can't figure out is how to handle such request
in the jabber server?  how can i add a new component?
can anyone help me, pls.

TIA,
Raist

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

[JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)

[Matthias Wimmer]

Hi!

I have enhanced the JabberApplet to support Jabber HTTP Polling and I
have written a server side implementation as a Java Servlet.

If somebody wants to help finding bugs, please feel free to download the
code at http://devel.amessage.de/. It is not yet meant to be used for
everyday use.


Tot kijk
   Matthias
-- 
phone: +49-700-77007770 web: http://matthias-wimmer.de/
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

RE: [JDEV] File transfers

[Andy Beetz]

I can see a small level of abuse perhaps, but there are better ways to
distribute/get hold of copyrighted files (kazaa to name but one). The fact
that the communications are 1 to 1 would not make the sharing of files on a
massive scale feasible. I can only speak for myself obviously, but I've only
ever used file transfer in msn messenger for small files. If I wanted to
download say a movie, I would use something designed for that purpose, even
if it was from someone I knew I would find a way around not using an IM app.

I know in band data transfers present a problem, but I think splitting the
data would make it more server friendly. Plus the clients can still send and
receive messages etc in between parts (given higher priority). Firewalls
present a major problem, but if you can get a connection to the server, then
the problem dissipates.

-Original Message-
From: Richard Dobson [mailto:[EMAIL PROTECTED]] 
Sent: 06 June 2002 09:35
To: [EMAIL PROTECTED]
Subject: Re: [JDEV] File transfers


I think that allowing file transfers of very small files in-band would be
cool, but anything over 10k or so should be sent out of band by some other
means, allowing it in band at all is also a big problem because of the
massive potential for abuse, in ways like DOS attacks against individual
clients and the server itself, excessive use of expensive bandwidth, also
creates copyright issues if people transfer copyrighted files via the server
because it then brings the server providors into the line of fire because
they facilitated the transfer, etc etc.

Because of all of these problems I dont think its a good idea to transfer
files in-band at all.

Just my 2p
Richard

- Original Message -
From: "Andy Beetz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 6:58 AM
Subject: RE: [JDEV] File transfers


> What about the nntp idea for very large posts? Where the file is split
into
> several parts, each part being only small in size could be transmitted 
> in-band just one at a time. As long as they carry header information 
> the client at the other end should be able to decode and re-assemble. 
> It
should
> be possible to request parts if they're missing.
>
>
> -Original Message-
> From: Michael F Lin [mailto:[EMAIL PROTECTED]]
> Sent: 05 June 2002 19:23
> To: [EMAIL PROTECTED]
> Subject: Re: [JDEV] File transfers
>
>
>
> When we generalize the Jabber network to thousands of servers, it 
> becomes something of a nightmare to transport stuff out of band. This 
> is of course why HTTP is not too good for this purpose - too many 
> people are behind firewalls. Any direct client-to-client connection 
> with whatever protocol will of course have the same problem. Relying 
> on e-mail routing is one option, but how do you negotiate what address 
> to send an e-mail to? How do you receive it? What if you need a file 
> but don't have access to your e-mail?
>
> There are any number of solutions you can set up with WebDAV and so 
> forth, but what we would really, really like - particularly when it 
> comes to
Jabber
> as a transport for web services - is a way to transport large payloads 
> if not directly in-band, then in a band that fully adopts JID routing.
Jeremie
> has proposed PASS, which is a step forwards but not totally 
> satisfactory.
>
> The only "good solutions" I've been able to think of basically involve 
> running a Jabber server that knows how to route s2s on every client
machine.
> Which is, not coincidentally, something I'm working towards.
>
> -Mike
>
>
>
> |-+>
> | |   Mike Oliver  |
> | || |   s.com>   |
> | |   Sent by: |
> | |   jdev-admin@jabber|
> | |   .org |
> | ||
> | ||
> | |   06/05/2002 12:21 |
> | |   PM   |
> | |   Please respond to|
> | |   jdev |
> | ||
> |-+>
>
>
>---
>
> ---|
>   |
> |
>   |   To:   [EMAIL PROTECTED]
> |
>   |   cc:
> |
>   |   Subject:  Re: [JDEV] File transfers
> |
>   |
> |
>   |
> |
>
>
>---
>
> ---|
>
>
>
> Why have just one protocol?
>
> SMTP does pretty well at file transfers that are asynch.  The Jabber 
> protocol can include a header for the attachments and the user at the
other
>
> end can decide if they want to download the file.  The a request can 
> then
be
> sent to the originating peer and an SMTP transfer begun and the remote 
> client can notify the user when the trans

Re: [JDEV] File transfers

[Richard Dobson]

I think that allowing file transfers of very small files in-band would be
cool, but anything over 10k or so should be sent out of band by some other
means, allowing it in band at all is also a big problem because of the
massive potential for abuse, in ways like DOS attacks against individual
clients and the server itself, excessive use of expensive bandwidth, also
creates copyright issues if people transfer copyrighted files via the server
because it then brings the server providors into the line of fire because
they facilitated the transfer, etc etc.

Because of all of these problems I dont think its a good idea to transfer
files in-band at all.

Just my 2p
Richard

- Original Message -
From: "Andy Beetz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 6:58 AM
Subject: RE: [JDEV] File transfers


> What about the nntp idea for very large posts? Where the file is split
into
> several parts, each part being only small in size could be transmitted
> in-band just one at a time. As long as they carry header information the
> client at the other end should be able to decode and re-assemble. It
should
> be possible to request parts if they're missing.
>
>
> -Original Message-
> From: Michael F Lin [mailto:[EMAIL PROTECTED]]
> Sent: 05 June 2002 19:23
> To: [EMAIL PROTECTED]
> Subject: Re: [JDEV] File transfers
>
>
>
> When we generalize the Jabber network to thousands of servers, it becomes
> something of a nightmare to transport stuff out of band. This is of course
> why HTTP is not too good for this purpose - too many people are behind
> firewalls. Any direct client-to-client connection with whatever protocol
> will of course have the same problem. Relying on e-mail routing is one
> option, but how do you negotiate what address to send an e-mail to? How do
> you receive it? What if you need a file but don't have access to your
> e-mail?
>
> There are any number of solutions you can set up with WebDAV and so forth,
> but what we would really, really like - particularly when it comes to
Jabber
> as a transport for web services - is a way to transport large payloads if
> not directly in-band, then in a band that fully adopts JID routing.
Jeremie
> has proposed PASS, which is a step forwards but not totally satisfactory.
>
> The only "good solutions" I've been able to think of basically involve
> running a Jabber server that knows how to route s2s on every client
machine.
> Which is, not coincidentally, something I'm working towards.
>
> -Mike
>
>
>
> |-+>
> | |   Mike Oliver  |
> | || |   s.com>   |
> | |   Sent by: |
> | |   jdev-admin@jabber|
> | |   .org |
> | ||
> | ||
> | |   06/05/2002 12:21 |
> | |   PM   |
> | |   Please respond to|
> | |   jdev |
> | ||
> |-+>
>
>
>---
> ---|
>   |
> |
>   |   To:   [EMAIL PROTECTED]
> |
>   |   cc:
> |
>   |   Subject:  Re: [JDEV] File transfers
> |
>   |
> |
>   |
> |
>
>
>---
> ---|
>
>
>
> Why have just one protocol?
>
> SMTP does pretty well at file transfers that are asynch.  The Jabber
> protocol can include a header for the attachments and the user at the
other
>
> end can decide if they want to download the file.  The a request can then
be
> sent to the originating peer and an SMTP transfer begun and the remote
> client can notify the user when the transaction is complete by asking
where
>
> to put the file.  There are SMTP libraries in almost every language you
can
>
> name, so this doesn't appear to be a big problem.
>
> FTP is another and offers the ability to transfer files without the base64
> encoding.
>
> Ollie
>
> At 11:45 AM 6/5/2002 -0400, you wrote:
>
> >In-band transport of large payloads is something we and others have
> >been looking at pretty intensely. Obviously it would be a nice thing to
> >have, but it is also very, very difficult to do properly. If you just
> >stick base64 in an X element, you have huge problems because if that
> >takes 10 minutes to transmit, you can't send anything else for those 10
> >minutes.
> You
> >could chunk them, but that hardly makes things simpler for the client
> >software. This also makes it massively more difficult to distinguish
> >legitimate traffic from a denial of service attack. Furthermore, it
> >means the server has to do a whole lot more XML processing (which may
> >already be a bottleneck), because all XML content ha

[JDEV] Info request

[Andy Beetz]

Title: Info request





Is there any documentation available for writing internal components?


Thanks in advance




---
Clearswift monitors, controls and protects all its messaging traffic in 
compliance with its corporate email policy using Clearswift products. 
Find out more about Clearswift, its solutions and services at 
www.clearswift.com.
***
This communication is confidential and may contain privileged 
information intended solely for the named addressee(s). It may not 
be used or disclosed except for the purpose for which it has been 
sent. If you are not the intended recipient, you must not copy, 
distribute or take any action in reliance on it. Unless expressly stated, 
opinions in this message are those of the individual sender and not of 
Clearswift. If you have received this communication in error, please 
notify Clearswift by emailing [EMAIL PROTECTED] quoting the 
sender and delete the message and any attached documents. Clearswift 
accepts no liability or responsibility for any onward transmission or use of
emails and attachments having left the Clearswift domain.

This footnote confirms that this email message has been swept by 
MIMEsweeper for Content Security threats, including computer viruses.