[JDEV] Re: jdev digest, Vol 1 #1470 - 4 msgs
Brijesh
brijesh at india.hp.com
Thu Jun 6 23:54:29 CDT 2002
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: <jdev-request at jabber.org>
To: <jdev at jabber.org>
Sent: Friday, June 07, 2002 7:58 AM
Subject: jdev digest, Vol 1 #1470 - 4 msgs
> Send jdev mailing list submissions to
> jdev at jabber.org
>
> 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
> jdev-request at jabber.org
>
> You can reach the person managing the list at
> jdev-admin at jabber.org
>
> 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 <denis at math.mit.edu>
> To: jadmin at jabber.org
> cc: jdev at jabber.org
> Subject: [JDEV] Re: [jadmin] visit to Prague
> Reply-To: jdev at jabber.org
>
> 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 (stpeter at jabber.org).
> >
> > Dekuji vam!
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > Jabber Software Foundation
> > http://www.jabber.org/people/stpeter.html
> >
> >
> > _______________________________________________
> > jadmin mailing list
> > jadmin at jabber.org
> > http://mailman.jabber.org/listinfo/jadmin
> >
>
>
> --__--__--
>
> Message: 2
> Date: Thu, 6 Jun 2002 13:44:23 -0600
> From: Jeremy Nickurak <atrus at rifetech.com>
> To: jdev at jabber.org
> Subject: Re: [JDEV] File transfers
> Reply-To: jdev at jabber.org
>
>
> --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.
> --envbJBWh7q8WU6mo
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD4DBQE8/7uWtjFmtbiy5uYRAt3uAJ9J2BbgEoqSyQyzk8abq1tC4QG0JgCWM2L2
> IYpB0Nha6lzkQxhy/UmaEA==
> =hH3j
> -----END PGP SIGNATURE-----
>
> --envbJBWh7q8WU6mo--
>
> --__--__--
>
> Message: 3
> From: "Ivan M. Hendricks" <ivan at microshock.com>
> To: <jdev at jabber.org>
> Subject: Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)
> Date: Thu, 6 Jun 2002 17:33:01 -0700
> Reply-To: jdev at jabber.org
>
> 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" <mass at akuma.org>
> To: <jdev at jabber.org>
> 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" |
> > >| | <me at pgmillard.com|
> > >| | > |
> > >| | Sent by: |
> > >| | jdev-admin at jabber|
> > >| | .org |
> > >| | |
> > >| | |
> > >| | 06/06/2002 01:05 |
> > >| | PM |
> > >| | Please respond to|
> > >| | jdev |
> > >| | |
> > >|---------+---------------------------->
> > >
>
>---------------------------------------------------------------------------
> ---------------------------------------------------|
> > > |
> |
> > > | To: <jdev at jabber.org>
> |
> > > | 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
> > >jdev at jabber.org
> > >http://mailman.jabber.org/listinfo/jdev
> > >
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >jdev mailing list
> > >jdev at jabber.org
> > >http://mailman.jabber.org/listinfo/jdev
> > >
> > >
> >
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> >
> >
>
>
>
> --__--__--
>
> Message: 4
> From: Max Metral <Max.Metral at PeoplepcHQ.com>
> To: "'jdev at jabber.org'" <jdev at jabber.org>
> Subject: RE: [JDEV] File transfers
> Date: Thu, 6 Jun 2002 19:23:21 -0700
> Reply-To: jdev at jabber.org
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C20DCA.4B5EE3E0
> Content-Type: text/plain;
> charset="iso-8859-1"
>
> 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:ollie at appsaspeers.com]
> Sent: Thursday, June 06, 2002 8:34 PM
> To: jdev at jabber.org
> Subject: RE: [JDEV] File transfers
>
>
> 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:ollie at appsaspeers.com
> <mailto:ollie at appsaspeers.com> ]
>
> Sent: Thursday, June 06, 2002 7:38 PM
>
> To: jdev at jabber.org
>
> 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 <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
>
>
>
>
> Michael Oliver
> Chief Technology Officer
> AppsAsPeers.com
> 7391 S. Bullrider Ave.
> Tucson, AZ 85747
> 520.574.1150
>
>
> ------_=_NextPart_001_01C20DCA.4B5EE3E0
> Content-Type: text/html;
> charset="iso-8859-1"
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
>
>
> <META content="MSHTML 5.50.4915.500" name=GENERATOR></HEAD>
> <BODY>
> <DIV><SPAN class=312185301-07062002><FONT face=Arial color=#0000ff
size=2>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).</FONT></SPAN></DIV>
> <DIV><SPAN class=312185301-07062002><FONT face=Arial color=#0000ff
> size=2></FONT></SPAN> </DIV>
> <DIV><SPAN class=312185301-07062002><FONT face=Arial color=#0000ff
size=2>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.</FONT></SPAN></DIV>
> <DIV><SPAN class=312185301-07062002><FONT face=Arial color=#0000ff
> size=2></FONT></SPAN> </DIV>
> <DIV><SPAN class=312185301-07062002><FONT face=Arial color=#0000ff
size=2>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)</FONT></SPAN></DIV>
> <DIV><SPAN class=312185301-07062002><FONT face=Arial color=#0000ff
> size=2></FONT></SPAN> </DIV>
> <DIV><SPAN class=312185301-07062002><FONT face=Arial color=#0000ff
size=2>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.</FONT></SPAN></DIV>
> <BLOCKQUOTE>
> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
> size=2>-----Original Message-----<BR><B>From:</B> Mike Oliver
> [mailto:ollie at appsaspeers.com]<BR><B>Sent:</B> Thursday, June 06, 2002
8:34
> PM<BR><B>To:</B> jdev at jabber.org<BR><B>Subject:</B> RE: [JDEV] File
> transfers<BR><BR></FONT></DIV>oh, right and ports 25, 143 and 110 are
> arbitrary.<BR><BR>At 04:50 PM 6/6/2002 -0700, you wrote:<BR>
> <BLOCKQUOTE class=cite cite type="cite"><FONT face=arial color=#0000ff
> size=2>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. :)</FONT><BR> <BR><FONT face=arial color=#0000ff size=2>Hard
> distinctions between client and server are SOOO last century. :)
> </FONT></BLOCKQUOTE><BR>Geez and I thought last century was just a
couple of
> years ago.<BR><BR><BR>
> <BLOCKQUOTE class=cite cite type="cite"><FONT face=arial color=#0000ff
> size=2>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.</FONT><BR></BLOCKQUOTE><BR>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.<BR><BR>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. <BR><BR>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.<BR><BR>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.<BR><BR>Knowing the words is only half the battle knowing what
they mean
> takes a little more effort.<BR><BR>
> <BLOCKQUOTE class=cite cite type="cite"><FONT face=Arial color=#0000ff
> size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT
face=Arial
> color=#0000ff size=2></FONT><BR><FONT face=arial color=#0000ff
size=2>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.</FONT>
> <DL><FONT face=tahoma size=2>
> <DD>-----Original Message-----
> <DD>From:</B> Mike Oliver [<A href="mailto:ollie at appsaspeers.com"
> eudora="autourl">mailto:ollie at appsaspeers.com</A>]
> <DD>Sent:</B> Thursday, June 06, 2002 7:38 PM
> <DD>To:</B> jdev at jabber.org
> <DD>Subject:</B> RE: [JDEV] File transfers<BR><BR></FONT>
> <DD>Ok adding value, you simply don't know what you are talking
> about.<BR><BR>
> <DD>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.<BR><BR>
> <DD>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 <A href="http://www.ietf.org/"
> eudora="autourl">http://www.ietf.org</A><BR><BR>
> <DD>I completely agree it depends on where you are standing and you
are
> standing in the dark. <BR><BR><BR><BR>
> <DD>At 02:06 PM 6/6/2002 -0700, you wrote:<BR><BR>
> <BLOCKQUOTE class=cite cite type="cite"><FONT size=2>
> <DD>Mike cogently queries:</FONT> <FONT size=2>
> <DD>> What planet are you from? </FONT><FONT size=2>
> <DD>There's a great way to add value to a thread. :)</FONT>
> <BR><BR><FONT size=2>
> <DD>> POP, IMAP and MAPI (Exchange) ARE NOT "client-to-client",
> PLEASE! </FONT><FONT size=2>
> <DD>Sure, why not? user --> sendmail --> mail spool
> accessible via POP,</FONT> <FONT size=2>
> <DD>at which point the server stops being so much of a server and
> starts</FONT> <FONT size=2>
> <DD>acting a little more like a peer (POP, IMAP and MAPI being ad
> hoc,</FONT> <FONT size=2>
> <DD>connected, conversational programs, unlike SMTP, which is
largely
> a</FONT> <FONT size=2>
> <DD>batch-oriented bulk drop). It all depends where you're
> standing.</FONT> <FONT size=2>
> <DD>No need to question my mudball of origin.</FONT> <BR><BR><FONT
> size=2>
> <DD>> sendmail is just an SMTP mail transfer agent program and
no
> different than</FONT> <FONT size=2>
> <DD>> any other SMTP mail transfer agent program like those
from
> Netscape and </FONT><FONT size=2>
> <DD>> Microsoft...ARG!</FONT> <BR><BR><FONT size=2>
> <DD>Netscape makes an MTA? What's it called? I've seen
their
> MUA, but</FONT> <FONT size=2>
> <DD>I'm surprised to hear they have an MTA. I bet it crashes
a
> lot. :)</FONT> <BR><BR><FONT size=2>
> <DD>F.</FONT> <BR><BR><BR><BR>
>
<DD>**********************************************************************
>
> <DD>E-mail sent through the Internet is not secure. Western Asset
> therefore
> <DD>recommends that you do not send any confidential or sensitive
> information to
> <DD>us via electronic mail, including social security numbers,
account
> numbers,
> <DD>or personal identification numbers. Delivery, and or timely
delivery
> of
> <DD>Internet mail is not guaranteed. Western Asset therefore
recommends
> that
> <DD>you do not send time sensitive or action-oriented messages to
us via
>
> <DD>electronic mail.
>
<DD>**********************************************************************</
DD></BLOCKQUOTE>
> <DD>Michael Oliver
> <DD>Chief Technology Officer
> <DD>AppsAsPeers.com
> <DD>7391 S. Bullrider Ave.
> <DD>Tucson, AZ 85747
> <DD>520.574.1150 </DD></DL></BLOCKQUOTE><X-SIGSEP>
> <P></X-SIGSEP>
> <DL></DL>Michael Oliver<BR>Chief Technology
Officer<BR>AppsAsPeers.com<BR>7391
> S. Bullrider Ave.<BR>Tucson, AZ 85747<BR>520.574.1150
> </BLOCKQUOTE></BODY></HTML>
>
> ------_=_NextPart_001_01C20DCA.4B5EE3E0--
>
>
> --__--__--
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>
>
> End of jdev Digest
>
More information about the JDev
mailing list