[JDEV] EVERYTHING (re: mime/file-xfer/ctcp/etc)

[Scott Robinson]

Interleaved response.

Scott.

* Jeremie translated into ASCII [Mon, Aug 09, 1999 at 06:45:10PM -0500][<Pine.LNX.4.10.9908091818440.14509-100000 at lor.jeremie.com>]
> I'm about half-way through the last few days messages on the various above
> subjects, and I can't procede any further without stating a few things:
> 
> First, I apologize for not responding sooner.  I was quite busy getting
> things moved to the new server and then I was gone on vacation for a few
> days, and WOW lots can happen over that short time!
> 

Slashdot effect? ;)

> Now, first things first: client to client connections.  This has been
> brought up before and is simply outside the scope of Jabber.  I'm not
> going to write up a dissertation on the subject, but it goes something
> like this:
> 
> The main goal behind Jabber is to provide an architecture that can support
> absolutely simple clients that can speak transparently to a variety of
> different real-time messaging services.  Jabber is a solution based around
> the server.  (for lots of other reasons, which IS a dissertation I'll be
> writing sometime soon :)  For a client to be able to do client to client
> conenctions it would have to understand ICQ, AIM, etc, etc protocols
> directly, and that is exactly what Jabber is NOT.  The other BIG reason
> against client to client connections is that as it stands, you can use
> Jabber without exposing your computer at all.  The only place that knows
> your IP is the server, nowhere is your IP published.  There are various
> other reasons as well, but this is already long enough... Maybe I will end
> up writing a large document on this subject, but I'd rather be coding *g*.
> 

Whoa! I may be missing something here. While Jabber, in it's current state,
is a server-to-server paradigm, if we want Jabber to be any type of success
in the real world it's clients will support CTCP. From that, there are two
options. a) Do not put out a standard on CTCP and allow fragmentation or
worse another standard which does spec CTCP to roll over us. b) Release a
standard, while not REQUIRED for Jabber support, at leasts places a working
environment for people will need to use it.

I don't think anyone has implied that CTCP would be forced as a part of the
Jabber architecture. If someone has, they should be flogged.

> That being said, there is no reason that any particular client CAN'T do
> client to client connections, it's just outside the scope of Jabber,
> Jabber is all about the server. If a client author chooses to impliment
> anything like client to client connections, it's something specific for
> that client.
> 

I would rather hope that CTCP protocols weren't client specific.

> With that out of the way, the next big question/topic is File Transfers.
> I have a proposal for File Transfers and Jabber partially written, and I
> will finish it over the next 24-48 hours and post it.  It should answer
> many questions and appease many developers.
> 

I guess I'll be holding off on my MIME, CTCP, and Security posts.

> Last thing: MIME.  It will not become part of the standard
> <message></message> packet any time soon, if ever.  All of the
> functionality that people want MIME for will be part of the File Transfer
> feature(s) that I'll be proposing soon.
> 

Hmm. File transfer doesn't sound very MIME'ish, but I know I'll be waiting.

> I'm going to go back and reread some of the thread and respond to anything
> outside of this post, but if there is any further discussion on these
> topics please reply to this message.
> 

On a side note, most of your post implies you have ultimate control over the
Jabber protocol? Are we in any way open source? If so, how will submissions
work? For ideas to be added to the protocol, do we work on convincing you?
Just wondering...

> Thanks,
> 
> Jer
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev