[JDEV] File transfers

[Mike Oliver]

At 07:23 PM 6/6/2002 -0700, you wrote:
>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).

I stand corrected.  Arbitrary when picked, certainly but not in their use, 
otherwise your correction of my misuse of the SMTP port would be moot.


>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.

Exactly my point, if you "send" an internet email message, i.e. not within 
a MAPI/Exchange OR cc:mail or other user to user internal message, then 
someplace along the way you use SMTP.


>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 is a protocol and I was talking about the use of POP is always 
Client<-->Server not Client<-->Client, your fuzzy logic 
notwithstanding.  Yes the Server Application that accesses the filesystem 
store or database store or whatever...doesn't change that whether that 
Server Application is a POP, IMAP or SMTP.

>
>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.

Finally we agree on something.

>
>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.

As have I sir, having been up front on BOFs at IETF meetings and knowing 
what "cd !cmd182!usn-amac!usn-bmac!da1/project/" meant before the days of DNS.

>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.

They are only relevant if you start saying they already are, which I would 
argue they are NOT.  An application may in fact be both a client and server 
for any protocol you chose but calling POP a P2P protocol won't fly.  To 
point, the Jabber xml packets flying back and forth could carry a 
mime/base64 encoded file...but should they?  My answer is no I don't think 
so.  I think the more efficient way to do file transfers and potentially 
even more so for LARGE file transfers is to allow for out of band file 
transfers peer-to-peer ala Napster, that are initiated by an in band 
service request and an out of band transfer using a more efficient file 
transfer protocol and potentially make that optional so FTP, HTTP or a new 
JTP could be used.

The topic of this thread was what to use for that and earlier in the thread 
someone suggested SMTP.   Then a know nothing made some comments about how 
sendmail was inefficient because it had twice the number of bytes 
transferred while POP AND IMAP had only one byte transferred and that POP 
AND IMAP are "definitely not client server".....hello!  I don't give a 
blooming nickel  for what you say if you don't agree that is simply 
WRONG.  POP AND IMAP talk to the same blooming server as sendmail and the 
bytes in or out are no different and POP AND IMAP are client server....an 
application may be both POP client and POP server, but POP is  not client 
to client...ok?

>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 completely concur, see above.

>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 never did advocate that, I was just correcting the terms used.  See above.


>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.

As I, see above.


>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]
>>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
>>
>>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

Michael Oliver
Chief Technology Officer
AppsAsPeers.com
7391 S. Bullrider Ave.
Tucson, AZ 85747
520.574.1150
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20020607/5c4f62b4/attachment-0002.htm>