From owner-jdev@jabber.org Mon Feb 1 01:52:19 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id BAA31669 for jdev-list; Mon, 1 Feb 1999 01:52:19 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from ins6.netins.net (ins6.netins.net [167.142.225.6]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id BAA31666 for ; Mon, 1 Feb 1999 01:52:17 -0600 Received: from worf.netins.net (jeremie@worf.netins.net [167.142.225.4]) by ins6.netins.net (8.8.7/8.8.7) with SMTP id BAA04258 for ; Mon, 1 Feb 1999 01:52:15 -0600 (CST) Date: Mon, 1 Feb 1999 01:52:15 -0600 (CST) From: Jeremie Miller To: jdev@jabber.org Subject: [JDEV] I'm back! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Hi all, I just hopped on quick to let everyone know that I've finally recovered from a nasty flu/cold and am almost 100% better! I'm very sorry I haven't posted my "big update" yet, it's been pretty crazy this week between mother nature and my hardware troubles. But, I'm back to work on it and am finding out that it's growing larger than I expected... It will be broken into 10 big chunks/emails, here's a quick TOC in no particular order: - Intro - Overview - Protocol - JabberBox - Jabber Transport - Transports - Clients - Client Lib - Web Site - Code/CVS I'll try to include enough information in these so we can start to form a common base to move forward from. Jer From owner-jdev@jabber.org Mon Feb 1 14:12:43 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA01953 for jdev-list; Mon, 1 Feb 1999 14:12:43 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from mail.rdc1.sdca.home.com (imail@ha1.rdc1.sdca.home.com [24.0.3.66]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id OAA01950 for ; Mon, 1 Feb 1999 14:12:40 -0600 Received: from cx67088-a.dt1.sdca.home.com ([24.0.146.12]) by mail.rdc1.sdca.home.com (InterMail v4.00.03 201-229-104) with SMTP id <19990201201236.FBEA6903.mail.rdc1.sdca.home.com@cx67088-a.dt1.sdca.home.com> for ; Mon, 1 Feb 1999 12:12:36 -0800 Message-Id: <3.0.5.32.19990201120231.03a91100@mail.dt1.sdca.home.com> X-Sender: robertl1@mail.dt1.sdca.home.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 01 Feb 1999 12:02:31 -0800 To: jdev@jabber.org From: Bob La Quey Subject: Re: [JDEV] I'm back! In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org At 01:52 AM 2/1/99 -0600, you wrote: >Hi all, I just hopped on quick to let everyone know that I've finally >recovered from a nasty flu/cold and am almost 100% better! Welcome back. It's hard to do allnighters forever. Ah Youth! I am working with a group called the Linux Programmers Study Group which is affiliated with the San Diego Kernel-Panic Linux Users Group. I hope to interest them in Jabber. With luck we could contribute to your effort. You have done a superb job of laying things out and getting some core code together. hopefully I can get the LPSG to pick up some pieces to nibble on. Regards, Bob La Quey From owner-jdev@jabber.org Tue Feb 2 16:02:00 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id QAA11857 for jdev-list; Tue, 2 Feb 1999 16:02:00 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from smtp.doruk.net.tr (smtp.doruk.net.tr [212.58.4.4]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id QAA11853 for ; Tue, 2 Feb 1999 16:01:54 -0600 Received: from doruk.net.tr (zeus.doruk.net.tr [212.58.4.10]) by smtp.doruk.net.tr (8.8.5/SCO5) with SMTP id AAA28315 for ; Wed, 3 Feb 1999 00:18:24 +0200 (TSI) Received: from cn-async-host-00057.comnet.com.tr by doruk.net.tr (SMI-8.6/SMI-SVR4) id XAA02779; Tue, 2 Feb 1999 23:56:04 +0200 Date: Wed, 3 Feb 1999 00:00:43 +0200 (EET) From: "Kemal 'Disq' Hadimli" X-Sender: root@heart_of_gold.localdomain To: jdev@jabber.org Subject: [JDEV] new cabbar snapshot Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Hi guys. I uploaded a new cabbar snapshot at http://disq.bir.net.tr/cabbar The roster functions are nearly finished, we only need someone to fix the "Remove group" code. now I'm waiting for the client library. :) (I'll start coding the "Transport configuration" window soon) bye, disqk From owner-jdev@jabber.org Wed Feb 3 17:08:32 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA22862 for jdev-list; Wed, 3 Feb 1999 17:08:32 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA22859 for ; Wed, 3 Feb 1999 17:08:30 -0600 Date: Wed, 3 Feb 1999 17:08:30 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] I'm back! In-Reply-To: <3.0.5.32.19990201120231.03a91100@mail.dt1.sdca.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > >Hi all, I just hopped on quick to let everyone know that I've finally > >recovered from a nasty flu/cold and am almost 100% better! > > Welcome back. It's hard to do allnighters forever. Ah Youth! Allnighters, wow... it's been awhile since I've done one of those, but hitting the sack around 4-5 has been all too common :) > I am working with a group called the Linux Programmers Study Group which > is affiliated with the San Diego Kernel-Panic Linux Users Group. I hope > to interest them in Jabber. With luck we could contribute to your > effort. You have done a superb job of laying things out and getting some > core code together. hopefully I can get the LPSG to pick up some pieces > to nibble on. That would be really great! My "big status update" is coming in a few minutes here, take a look at it... I'd love some help working with expat if anyone wants to jump in! Thanks! Jer From owner-jdev@jabber.org Wed Feb 3 17:17:45 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA22956 for jdev-list; Wed, 3 Feb 1999 17:17:45 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA22953 for ; Wed, 3 Feb 1999 17:17:44 -0600 Date: Wed, 3 Feb 1999 17:17:44 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] Intro, aka: "Big Status Update" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Welcome(finally)! In the messages that follow are poorly written and loosely organized collections of ideas on where to head with Jabber ;-) Most of it has already been mentioned in one way or another, but I've tried to collect the ideas along with how the server currently operates as well as what I was planning on doing. I've made no effort to differentiate between what already works and what doesn't. What I want to do is start to collect some form of agreement(and silence will count as agreement, *grin*) on the different topics, then go make it work that way. All ideas, comments, criticisms, and flames welcome. All topics will be broken into their own email, and threads can be followed by topic as well as displayed on the threaded view of the archive at http://jabber.org/developers/archive/ Each topic will have a version number associated with it "[1.0]" and as discussion progresses on certain versions, I'll collect changes and release a new version. This way progress can be followed, and discussions on different versions can be tracked separately. If anyone wants to take any particular topic and completely rewrite it since my writing style isn't that great, feel free! Here are the topics that will be arriving shortly in your Inbox: Overview Quick catch-up on the terms and how all of the pieces work together. Protocol Some discussion about how to "correct" how the protocol works. JabberBox How the JabberBox works. Transports Quick and dirty guide on Transports and how to write one. Jabber Transport The main "server" process that Jabber clients connect to/deal with. Clients The different kind of clients and what's expected of them. Client Lib Library to make writing command line clients easier on multi-user systems. Misc Topics: Web Site Some restructuring and new ideas Code/CVS Issues/Topcs on these things, style guide, etc... From owner-jdev@jabber.org Wed Feb 3 17:20:58 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23012 for jdev-list; Wed, 3 Feb 1999 17:20:58 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23009 for ; Wed, 3 Feb 1999 17:20:57 -0600 Date: Wed, 3 Feb 1999 17:20:57 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [Overview 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Here is a QUICK intro to Jabber and the terms being tossed about. Jabber is just a collection of applications that all speak a similar protocol. They come in different forms, and connect in different ways. The most important aspect of Jabber is it's ability to talk transparently to other messaging services, so lets start there. Each "application" that can translate from Jabber(the protocol) to another service such as ICQ or AIM is identified as a TRANSPORT. A transport can operate completely independent of any other element, except for the fact that it needs to talk to other transports using Jabber. All of the transports on a physical server connect and talk to each other through a single router-like application, it is called the JABBERBOX. The JabberBox simply passes chunks of the Jabber Protocol around to different transports, and connects to other JabberBoxes to pass data to them if needed. Now, there is a special Transport, the Jabber Transport. This special transport doesn't translate to other messaging systems, it IS a messaging system. It accepts connections from Jabber clients and uses a similar protocol to accept data from them. So, if you are using a Jabber client, you will be connecting to a Jabber Server(really just a Transport) which connects to the JabberBox on that server. If you need to send messages to another system(ICQ/AIM) or another Jabber user, the Jabber Transport forwards it to the JabberBox, which connects to the correct Transport for your data, and forwards it on. From owner-jdev@jabber.org Wed Feb 3 17:24:18 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23109 for jdev-list; Wed, 3 Feb 1999 17:24:18 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23104 for ; Wed, 3 Feb 1999 17:24:15 -0600 Date: Wed, 3 Feb 1999 17:24:15 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [Protocol 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org #### Intro The protocol is currently only half-complete, as many have pointed out. The reason it is currently not implemented "correctly" is simply because it was easier to write software to process it on the server side when it was done with one common main level tag(). I thought it might be able to work just fine that way, but after looking at it again it's probably worth the effort to write the code and do it the right way. The proposal here is to model the protocol after a typical XML document. All communications between the clients and the server(Jabber Transport) will look like: ...rest of client communication happens in here Comments should be allowed anywhere, and will be ignored. When the client sends a it will signal a close, but is not necessary(just closing the connection will work identically). The server should respond in an identical fashion, with the exception that it will be type="server". #### Example protocol jeremie Ph0niks jabalot jeremie test someone jenny jeremie safdsgh@asdfg.asdfasdf sdfa 1 Did you see that? asdgf asdfkjasgoijqwert asdgaldgjkas This is my status 10 normal fred user@jabber.server.com 545212@ICQ olduser #### Server to client fred sdfa 1 Did you see that? asdgf asdfkjasgoijqwert asdgaldgjkas jenny This is my status 10 normal jenny user@jabber.server.com 545212@ICQ olduser From owner-jdev@jabber.org Wed Feb 3 17:31:20 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23278 for jdev-list; Wed, 3 Feb 1999 17:31:20 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23274 for ; Wed, 3 Feb 1999 17:31:18 -0600 Date: Wed, 3 Feb 1999 17:31:18 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [JabberBox 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org #### Intro The JabberBox is simply a "data router". It resolves the transport/server names and routes chunks of XML between them, creating sockets where needed. When the JabberBox starts, it reads in the main configuration file for itself and all of the local transports. It then starts two listening sockets, one on localhost:5269 and the localnetaddress:5269. Connections to the localhost:5269 are most likely from transports. When a transport connects it has the special permission to receive its chunk of the main configuration file. After it initializes, it provides the names/aliases it is to be known as. #### Protocol The transport might send: Then the server would respond: --this is raw data from the main config file for TPNAME Then the transport would initialize and send: TPNAME tp.server.com At this point the JabberBox is ready to start delivering incoming data to the transport and the transport is configured and ready to receive. What the transport would send/receive would look like: --raw XML data Connections from other servers come in on the local Internet socket on port 5269, and are only allowed to send data and receive errors/bounces. Any data destined for another server is delivered through a new socket to that server, and that socket remains open until there is an internal idle timeout or the JabberBox exits. A typical connection from another server and chunk of data might look like: --raw XML data The JabberBox resolves the "to" sides of these "packets" and delivers them, otherwise it bounces them with another packet: --raw XML data The error will then be delivered back to the original sender server/transport. Essentially, the JabberBox is just a server routing XML documents in chunks to other JabberBox's or local transports. It doesn't touch the contents of the packets. Since it's the main server process, it also provides an easy way to centrally manage the configuration data for local transports. #### Ideas What I would like to see, is some slight additions made to the protocol between a transport and the JabberBox, so that transports can feed the JabberBox two types of administrative information. When they connect, they could optionally send a public info packet, stating whether they allow public registrations, what type of transport they are, if they have a web site, number of registered users, a whole host of one shot information. Also, periodically, they could send in temp stats such as number of connected users, number of users logged in so far today, etc... The local JabberBox could then send all of this collected data upon request, mostly for the local administrator or as cool statistics for the website for this Jabber installation. The next step would be to have the JabberBox send in this information to a central Jabber server(@jabber.org) and global stats can be kept as well as a current list of online servers that anyone can register with and information about them. For an example of something similar, check out http://www.shoutcast.com/ Another idea that would fit in with the JabberBox, is for users that are running a server and multiple transports, and don't have the ability to easily add DNS aliases to make those transports publicly addressable. A possibility would be to build a DB driven DNS server and do the ml.org thing but IP registrations would be done through Jabber, but hopefully someone will step up to the plate and do this before we have to :) Another easier possibility would be to allow the JabberBox to send in an automated registration request to a special JabberBox server running possibly @jabber.org. This special server would take those registrations as if they were real transports and route data to those servers. Then this special JabberBox could have a wildcard DNS address like *.home.jabber.org or *.public.jabber.org, and the registration request would contain what name they wanted like scoobydoo.public.jabber.org. Other than bandwidth, this is definitely an option that would work and be fairly easy to implement. From owner-jdev@jabber.org Wed Feb 3 17:32:28 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23314 for jdev-list; Wed, 3 Feb 1999 17:32:28 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23309 for ; Wed, 3 Feb 1999 17:32:26 -0600 Date: Wed, 3 Feb 1999 17:32:26 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [Transports 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org I don't have all that much to put here right now, but I'd like this to become a guide to writing transports. A transport is really just an addressable namespace, @transportname.server.com or if it's only available on one local server, just @TRANSPORTNAME. Right now, the only types of information that is routable is messages and status updates, so that is all a transport has to deal with. And if it it's transporting to a system that doesn't reflect "status", then it can ignore those. The first thing that a transport will do is open a connection to the local JabberBox. If it has a section in the main config file loaded by the JabberBox, it will then receive that config data and initialize itself. After it knows what names it will be addressed as, it should feed those names/aliases back to the JabberBox so that it can start receiving/sending data. >From that point forward, it's quite simple. It will receive messages/status updates sent to it over the socket with the JabberBox, from which it can parse out and deliver to whatever system it's translating to. All messages/status updates sent out through the socket with the JabberBox should be delivered normally or bounced back. Now, some of the issues a Transport will have to deal with, is how to handle user accounts for the systems it's translating to and how to associate Jabber users with their IDs on the other system. We should probably agree on a set of special address that every transport is required to respond to, maybe: register@ Allows interactive registration via messages help@ Give assistance, possibly w/ URL's info@ Talks about this transport, what it does url@ Just sends back a URL for a page with more information Let's use ICQ as an example... First, an association needs to happen between a Jabber user(John) and a user account on ICQ. Let's say that John is already an ICQ user, so he has an ID# and a password. He would send a message to register@ICQ and configure it to use #123456 and his password. If it looks/works ok, the ICQ transport would then send a roster list invite("Please add me to your roster...") to John, and John would have 123456@ICQ on his roster. Whenever John logs in, the ICQ transport would receive that status update, and then log into ICQ for John and translate all messages/status updates between both systems. If John never had an ICQ #, the ICQ transport should be able to create one on the fly for him, either by asking for the needed information or by querying the public Jabber information available for John. From owner-jdev@jabber.org Wed Feb 3 17:36:07 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23390 for jdev-list; Wed, 3 Feb 1999 17:36:07 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23387 for ; Wed, 3 Feb 1999 17:36:06 -0600 Date: Wed, 3 Feb 1999 17:36:05 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [Jabber Transport 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org #### Intro The Jabber Transport is the heart of the whole system. It is what all Jabber clients connect to, and what most data will pass through at some point. It starts and operates just like any other Transport would, but it also starts listening on a network socket port 5222 for connections from clients. The protocol used when talking to the clients is a superset of the main Jabber protocol, containing many little two way special exchanges just between the clients and this server. Most of the client-server architecture here is based around a smart-server, where all of the intelligence and decision making is going on in the server. All data and configuration information is stored on the server. This allows for roaming users, simple clients, and a user being able to use any client and have it be configured the way they want it with all of their information available as soon as they log in. The incoming data is processed into simple C structures, then passed to the modules through the API. The modules handle almost all of the important functions and decision making for each user, allowing new modules to be written to add significant new functionality without affecting the rest of the server. #### Modules The current proposal for configuring modules and associating users to modules is to use a "group" idea, so that each user belonged in a group. Then each group could be configured to just use bits and pieces of certain modules, or all of one module. All of the auth handlers would return a group ID when they authorize a user to tell the server what group to place that user in. Example, start with the following modules: mod_mysql: provides all handlers based on DB tables mod_unix: provides auth and info/search only via /etc/passwd mod_roster: file based fast hashed roster management mod_archive: stores all messages for web based searchable archive And have the main config file like: archive roster archive mysql roster archive mysql Obviously, this is a really simplified example, but hopefully enough to convey the idea. All the modules are asked to authenticate a user, and when they do they return one of the group names from above(locals, general, special) which the server uses to figure out what module's handlers to call for that user for each of the handlers. The current module API, straight from the C file: typedef struct { int module; void (*init)(jpair *); int (*authenticate)(char *, char *); ## Authentication handler int (*notify)(char *, int); ## Tells the module when other users go online/offline jpair *(*status)(char *, int); ## Notifies the module of its user's status jpair *(*roster)(int, char *, char *, char *); ## Requested changes to the roster for the user jpair *(*offline_message)(char *, jpair *); ## Store an offline message for the user jpair *(*online_message)(char *); ## The users back, are there any stored messages? jpair *(*search)(char *); ## Return any information for the user(incomplete!) void (*log)(char *); ## Simple raw data logging } module; I need to take some time and rethink this API, it's definitely not complete yet. I also need to figure out if there is a better way of making modules. The way I'm doing it is sudo Apache-style, creating a global array and identifying each module by a compiled in int. Anyone familiar with C and allowing 3rd party modules, please feel free to jump in here :) #### Privacy Right now the server is using a simple 4-level privacy indicator, which is identified by the module that authenticated the user. #define SEC_INVISIBLE 1 Nobody can ever even know this user exists unless the receive a message for them. Status doesn't work at all, nobody can see this user's status. #define SEC_LIST 2 No information is available(name/address/etc) except for username. Status only works for those that are on this users roster. #define SEC_SAFE 3 Everything works normally, name/address is available for searching/info requests. Everyone can see current online status. #define SEC_NONE 4 Same as 3, but anything that can be automated is, such as when a user adds this user to their roster and sends an invitation, the server will automatically add them to this users roster. I don't like how this works, and if possible I would like to get rid of it completely and move all of these decisions into the module API. #### Code MUCH work needs to be done here. After expat replaces tsp in the common lib, a complete cleanup of the Jabber Transport needs to happen. The module API mentioned above needs to be solidified and the new group idea needs to be written. There's not really all that much that the transport does, just parsing out the protocol into structures, calling the module API where appropriate, maintaining a list of connected users and their current status, and dealing with errors/conflicts. I'd like to make the code as straight forward as this sounds :) From owner-jdev@jabber.org Wed Feb 3 17:37:44 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23453 for jdev-list; Wed, 3 Feb 1999 17:37:44 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23449 for ; Wed, 3 Feb 1999 17:37:42 -0600 Date: Wed, 3 Feb 1999 17:37:42 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [Clients 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org #### Intro A Jabber client is simply an application that talks to the Jabber server(really talking to a Jabber Transport) using a simple text/xml protocol over a single TCP connection. Clients can be incredibly simple or large full blown interactive applications. There might be a simple command line app that sends anonymous messages to a Jabber user, or maybe a background server application that signals to a Jabber user when there are errors. There can be normal GUI buddy-list like apps, and there might a game that uses a Jabber server to pass information to another player to set up a direct socket and start a network game. It can be built into a web browser to have interactive discussions with other visitors to a web page and see the page owners current online status and talk to them, or the client could be a simple CGI script on the server accessed through an HTML form. A client could even be built into a cellular phone or wireless handheld device to see the owners current status and send them messages instantly, or the client could be a server app that forwards messages to a pager. All of these are possible :) #### Security It's been proposed that a client could implement secure communications similar to email, using a PGP-style encryption. Either messages could be signed to guarantee identity of the sender, or completely encrypted to hide their contents. All of the extra encryption data or signatures could possibly be sent along with the messages in the extension tags. #### GUI Some of the issues that a client implementing a GUI will need to take into account, is how users are named. All users are identified by their ID such as user@jab.server.com. Every user may have multiple "sessions" where they are logged into their account more than once, each session is identified by the nickname they choose when they start that session. So on a roster list showing online and offline users, a client might have a tree like: Users-- |- fred@jabber.org (online) | |- web server shell | |- WaterBoy at work |- jane@jabber.org (offline) Above, fred is on at work and through a shell account, and jane isn't on at all. To make things even easier for the user to view, the client could do some name mangling and hide the user@server.com address with something the user might type in, OR, if there is only ONE session active for that user it could just place that session overtop the address, so when jane comes online it might look like: Users-- |- fred@jabber.org (online) | |- web server shell | |- WaterBoy at work |- GIJane (online) This way, when special users like ICQ users(12343@ICQ) can be displayed consistently with Jabber users in a nice way. The client shouldn't be differentiating between different types of accounts at all(since it can't always tell they are different). #### Multi-Clients There are two ways the server will talk to a client, either as a single user or as a multi-user proxy. All this means, is that clients can be written that make a single TCP connection to the server but send/receive data for multiple users. When this happens, the client/server identifies each chunk of XML data with the session it's for. This is most useful for: Unix daemon that automatically registers local users when they login to the server. Web server CGI background process, placeholder for sessions through web interface. Simple client-proxies, possibly useful for tunneling through firewalls. Devices, like a pager server, that logs in on behalf of multiple users and accepts special messages From owner-jdev@jabber.org Wed Feb 3 17:45:51 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23678 for jdev-list; Wed, 3 Feb 1999 17:45:51 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23675 for ; Wed, 3 Feb 1999 17:45:50 -0600 Date: Wed, 3 Feb 1999 17:45:50 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [Client Lib 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org This is a rough draft! CLI=Command Line Interface I want Jabber to be 100% accessible EASILY through the command line. This is not nearly as easy as one might think. Since an authenticated connection must be made and maintained to the server, there will always need to be a background process. Data often trickles into that background process from the server, the user should be notified immediately about some of it(incoming messages), and later about other data(status changes). This requires the background process to attach to the users TTY and send messages, similar to unix talk. There are three models that need to be addressed. A main background process that runs server-wide and handles all users, similar to unix talk. A process that runs and forks when the user logs in under that users shell/account(so the user can still use Jabber CLI tools even if the server admin doesn't support it server-wide). Thirdly, each app starts and maintains it's own connection to the server when it runs. What I would like to see happen, is a static library written with simple functions that any app that wants to talk to a jabber server can call, and it doesn't have to worry about how it's talking to the server. This library can try/support each of the ways above. This will all resolve around a hidden folder in the users home dir, ~/.jabber/ and a few files in there, "secret", "config" and "port". The secret file will contain some simple config data like "usernamemypassword". This file should be protected so that ONLY the user can read it, 0700. Now, say the sysadmin has a system wide background process running. when it notices that a user logs in or is logged in, it will scan that user's home dir, and upon finding a ~/.jabber/secret it will fork a process, setuid for that user, and connect to the jabber server defined in "config". It will also start listening on a random unused high port above 10000 or so, and save that port in ~/.jabber/port. Any CLI jabber utilities used by the user will check for the port file and connect to that port to talk to the jabber server. Any incoming messages will be sent to the users TTY. Lets say that the sysadmin hasn't installed this background process server-wide. Then if the user wants to still use Jabber, they can setup the ~/.jabber folder and put something like "jabber -background" in their shell startup script and it will do the same thing, connect to the server, log in, listen on a local high port, and put that port in the ~/.jabber/port file. All CLI utilities will work identically. What if the user has never configured Jabber and uses a CLI utility? The library would, after not finding any config data, fork a background process and log into the server anonymously. All CLI utilities would work normally at that point. The last scenario is a GUI Jabber client that is compiled with the library, it could then share the same login/connection as all CLI apps, it would just display the current status graphically. Here are some proposed CLI apps: jwrite: Compose/send simple messages, either typed or from STDIN jmesg: Change/check current status, online, offline, away, etc... jwho: View roster and status of users on your roster. Add/remove entries jtalk: Start a threaded chat-like message communication with a user jabber: This is the main app, allowing you to fork a background log in, or run interactively and browse/compose messages, change status, check roster, all the same functionality in an interactive app. It's possible that all of the other apps are just hard links to this one since it will contain all of the needed functionality. This all sounds great, and should work fairly cleanly, but there needs to be a special API of calls in the library, as well as a special protocol between the background process and the intermittently run CLI apps. This is because the background process will pool messages and status updates, and the CLI apps will just ask for them when they are run. Hmm... I'm thinking that we might be able to make this REALLY easy, where the apps just use a standard IO just like they were talking to the real server, but when talking to this background process the process acts just like a "caching proxy" where all packets are passed on through it to the real server, but incoming messages and status's of other users are cached, and when say "jwho" asks for the roster, it might be cached in the proxy and sent down to "jwho" along with the status's of the users that were cached. The only exception would be that maybe the user wanted to browse or re-read incoming messages, so when they were doing that with the "jabber" app, it would send a special message that would be intercepted by the proxy telling it to dump X number of recent messages to the "jabber" app. Are there any situations that this wouldn't work? It would be great to build the library with built in simple exposed callable functions to do Jabber things simply, like message("recipient@server","subject","real message content") and could be statically linked to any app that wanted to do Jabber stuff... all the CLI apps could be based around this library. It would make writing a Jabber client painless, you wouldn't need to know/understand XML, the protocol, or anything like that. IMHO, this is an important area that needs lots of work and meshing out. From owner-jdev@jabber.org Wed Feb 3 17:49:39 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23735 for jdev-list; Wed, 3 Feb 1999 17:49:39 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23732 for ; Wed, 3 Feb 1999 17:49:37 -0600 Date: Wed, 3 Feb 1999 17:49:37 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [Web Site 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org #### Structure Two sides of the site, one for the "Public" and one for the "Developers" #### Public Public site has two mostly separate sections, one for normal users and one for server operators. Users side contains list of stable clients(links, download, os/features). General overview, introduction, and getting started guide available. Special page "Invite your ISP to try Jabber" w/ link to special ISP only page and simple ISP only server. Server operators side has stable server releases and documentation for that release. Also, has server operation overview, introduction, setup guide. Special area for using a *.public.jabber.org DNS name if you don't have one available for your server. Special dynamic site/area similar to shoutcast.com where all Jabber servers are listed, with searching by location, allow public registrations, type, link, etc. #### Developers Structure: Docs: Overview Code/CVS guidelines Extending Jabber Writing Clients Writing Transports Writing Modules Main Distro (JabberBox, Jabber Transport, Client Lib, CLI Clients) Download/CVS Snapshots TODO CHANGELOG Bug List/Reporting Special API's Module Client Lib Protocol JabberBox/Transports Jabber Transport/Clients Developers Team Mailing List/Archive Developer List/Registration Contrib/Links Clients Transports Modules Misc In the Developers area, what I'm thinking of for the "Developer List/Registration" section is a public list of everyone who's helping out in any way, and it can allow a developer to register with a(yet another) username/password and log in to maintain their entry in the Contrib/Links section if they have one, as well as enter/track bugs. I'm also trying to draw a clear line between the special API's for the main distro(in the modules and client lib) and the official public protocol specs. Jabber is the protocol, not the distro/code available, anyone can write the code, we're just providing a base implementation. #### Design The HTML/Layout nees some help, and any CSS wizzards are welcome to contribute a few new stylesheets. As we draw closer to a full public release, I'm hoping someone will do a professional clean nice looking site for normal users. From owner-jdev@jabber.org Wed Feb 3 17:51:37 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23784 for jdev-list; Wed, 3 Feb 1999 17:51:37 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23781 for ; Wed, 3 Feb 1999 17:51:36 -0600 Date: Wed, 3 Feb 1999 17:51:35 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] [Code/CVS 1.0] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org #### CVS I need to figure out how to make CVS work on the server side safely. I'd like to do everything through pserver, but I don't know that it's possible yet. After I have CVS working: +Set up a commit message mailing list for the core developers +Host other clients/transports as needed +Allow others to check in changes #### Code There are lots of issues that need to be addressed here: ==> Makefile/Configuration -> Use the standard configure [I'm not sure we really need this and I've never liked it much, but if someone is really good with it and want's to maintain this part I'm not going to get in the way] -> Roll our own [Similar to how Apache works(pre 1.3) with the ./Configure shell script. I really like this idea and I think we might be able to get away with it, but I don't like shell scripts and don't plan on writing it] -> Get away with just basic Makefile's [I'm not sure if we can do this, I'd like to if possible, but I don't know if we'll hit some things that will be impossible to get around on certain platforms if we don't dynamically generate parts of the Makefiles] ==> Platform Specific Code [There's none right now, that's right, not a drop. I'd love to keep it this way, but I'm thinking that there will be certain things that should be tweaked on certain platforms. Simple ifdef's and a make-passed uname -s definition for OS should suffice, no?] ==> Code Style [I'm open to suggestions, and now that I have a fast *nix platform here at home I can start happily learning emacs(again) and fix the indentation. Right now it's a simple whitespace-happy style, all {}'s on their own lines and spaces around all operators and after all commas] ==> Expat [All XML needs to start passing through expat. I started looking at it, and am definitely going to need some help making it work, not sure I totally understand it yet but it's integration will happen] ==> String functions [I want to clean up all string use. Add to the common lib a wrapper around all OS string operations and make all string calls safe to pass NULL's and empty strings to, and make sure it's known when new memory is being allocated/returned] From owner-jdev@jabber.org Wed Feb 3 17:57:51 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA23934 for jdev-list; Wed, 3 Feb 1999 17:57:51 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA23931 for ; Wed, 3 Feb 1999 17:57:49 -0600 Date: Wed, 3 Feb 1999 17:57:49 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] Followup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org I'm hoping we can spurr some good discussion on some of these, feel free to voice your opinion now before we get too much of it locked in code! I'll try to follow the discussions as closely as possible, but while this happens, I'll be playing with expat and trying to get a good feel for how to integrate it. I have no doubt in my mind that Jabber has the potential to become the de-facto standard for instant messaging, my only problem is that I want this "tomorrow" :) Thanks, Jer From owner-jdev@jabber.org Wed Feb 3 22:22:00 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id WAA25575 for jdev-list; Wed, 3 Feb 1999 22:22:00 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from smtp.doruk.net.tr (smtp.doruk.net.tr [212.58.4.4]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id WAA25572 for ; Wed, 3 Feb 1999 22:21:55 -0600 Received: from doruk.net.tr (zeus.doruk.net.tr [212.58.4.10]) by smtp.doruk.net.tr (8.8.5/SCO5) with SMTP id GAA11055 for ; Thu, 4 Feb 1999 06:38:28 +0200 (TSI) Received: from cn-async-host-00081.comnet.com.tr by doruk.net.tr (SMI-8.6/SMI-SVR4) id GAA01053; Thu, 4 Feb 1999 06:16:29 +0200 Date: Thu, 4 Feb 1999 06:21:25 +0200 (EET) From: "Kemal 'Disq' Hadimli" X-Sender: disq@heart_of_gold.localdomain To: jdev@jabber.org Subject: [JDEV] Updates 1.0 ;) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org IMO everything Jeremie said is OK. Maybe we should also have a "Transport Library", as well as a "Client Library". (btw, uploaded new cabbar snapshot to disq.bir.net.tr/cabbar, implementing right-click popup menus. also a stratch of transport config window is there, in glade-readable xml format. comments are welcome) bye, disqk 'looking forward for the implementation stage' From owner-jdev@jabber.org Wed Feb 3 23:18:20 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id XAA25867 for jdev-list; Wed, 3 Feb 1999 23:18:20 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from biznatch.nick.org (gypsy.ups.edu [192.124.98.165]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id XAA25864 for ; Wed, 3 Feb 1999 23:18:18 -0600 Received: from localhost (nkirsch@localhost) by biznatch.nick.org (8.9.1/8.9.0) with SMTP id WAA01737 for ; Wed, 3 Feb 1999 22:19:19 -0800 Date: Wed, 3 Feb 1999 22:19:19 -0800 (PST) From: "Nicholas M. Kirsch" To: jdev@jabber.org Subject: Re: [JDEV] [Code/CVS 1.0] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On Wed, 3 Feb 1999, Jeremie wrote: > > #### CVS > > I need to figure out how to make CVS work on the server side safely. I'd > like to do everything through pserver, but I don't know that it's possible > yet. > > After I have CVS working: > +Set up a commit message mailing list for the core developers > +Host other clients/transports as needed > +Allow others to check in changes > There are a couple of problems with using the CVS pserver. Anyone who has write access can do almost anything on the system. But assuming you let trusted developers, you shouldn't have a problem. The CVS passwords are encoded using a very simple scheme. However, also assuming that your CVS passwords are different from users on the box, you shouldn't have a problem. If you need any help setting this up, feel free to contact me. > #### Code > > There are lots of issues that need to be addressed here: > > ==> Makefile/Configuration > -> Use the standard configure > > [I'm not sure we really need this and I've never liked it much, > but if someone is really good with it and want's to maintain this part I'm > not going to get in the way] I think this is the best way. We want to make this easy to use, flexible, and compatible. Autoconf/Automake are two of the best utilities to ensure this. I have some experience in this area, as I'm sure others do as well. > ==> Platform Specific Code > > [There's none right now, that's right, not a drop. I'd love to > keep it this way, but I'm thinking that there will be certain things that > should be tweaked on certain platforms. Simple ifdef's and a make-passed > uname -s definition for OS should suffice, no?] This is one place using the traditional Autoconf/Automake combination can really make a difference. > > ==> Code Style > > [I'm open to suggestions, and now that I have a fast *nix platform > here at home I can start happily learning emacs(again) and fix the > indentation. Right now it's a simple whitespace-happy style, all {}'s on > their own lines and spaces around all operators and after all commas] I'm not a fan of the old K&R style, but love the whitespace friendly environment.. However, C is C, so whatever works best.. > > ==> Expat > > [All XML needs to start passing through expat. I started looking > at it, and am definitely going to need some help making it work, not sure > I totally understand it yet but it's integration will happen] > > ==> String functions > > [I want to clean up all string use. Add to the common lib a > wrapper around all OS string operations and make all string calls safe to > pass NULL's and empty strings to, and make sure it's known when new memory > is being allocated/returned] > > Nicholas Kirsch nkirsch@biznatch.nick.org From owner-jdev@jabber.org Wed Feb 3 23:20:40 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id XAA25898 for jdev-list; Wed, 3 Feb 1999 23:20:40 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from biznatch.nick.org (gypsy.ups.edu [192.124.98.165]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id XAA25895 for ; Wed, 3 Feb 1999 23:20:38 -0600 Received: from localhost (nkirsch@localhost) by biznatch.nick.org (8.9.1/8.9.0) with SMTP id WAA01743 for ; Wed, 3 Feb 1999 22:21:45 -0800 Date: Wed, 3 Feb 1999 22:21:45 -0800 (PST) From: "Nicholas M. Kirsch" To: jdev@jabber.org Subject: Re: [JDEV] [Transports 1.0] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org I really like the idea of these transports, especially the ICQ one. I'm not sure how much (if any) progress is being made, but I'd like to volunteer my efforts.. The project seems a little hectic, at least until there is a good CVS tree setup. Nicholas Kirsch nkirsch@biznatch.nick.org On Wed, 3 Feb 1999, Jeremie wrote: > I don't have all that much to put here right now, but I'd like this to > become a guide to writing transports. > > A transport is really just an addressable namespace, > @transportname.server.com or if it's only available on one local server, > just @TRANSPORTNAME. Right now, the only types of information that is > routable is messages and status updates, so that is all a transport has to > deal with. And if it it's transporting to a system that doesn't reflect > "status", then it can ignore those. > > The first thing that a transport will do is open a connection to the local > JabberBox. If it has a section in the main config file loaded by the > JabberBox, it will then receive that config data and initialize itself. > After it knows what names it will be addressed as, it should feed those > names/aliases back to the JabberBox so that it can start receiving/sending > data. > > >From that point forward, it's quite simple. It will receive > messages/status updates sent to it over the socket with the JabberBox, > from which it can parse out and deliver to whatever system it's > translating to. All messages/status updates sent out through the socket > with the JabberBox should be delivered normally or bounced back. > > Now, some of the issues a Transport will have to deal with, is how to > handle user accounts for the systems it's translating to and how to > associate Jabber users with their IDs on the other system. > > We should probably agree on a set of special address that every transport > is required to respond to, maybe: > register@ Allows interactive registration via messages > help@ Give assistance, possibly w/ URL's > info@ Talks about this transport, what it does > url@ Just sends back a URL for a page with more information > > Let's use ICQ as an example... > > First, an association needs to happen between a Jabber user(John) and a > user account on ICQ. Let's say that John is already an ICQ user, so he > has an ID# and a password. He would send a message to register@ICQ and > configure it to use #123456 and his password. If it looks/works ok, the > ICQ transport would then send a roster list invite("Please add me to your > roster...") to John, and John would have 123456@ICQ on his roster. > Whenever John logs in, the ICQ transport would receive that status update, > and then log into ICQ for John and translate all messages/status updates > between both systems. > > If John never had an ICQ #, the ICQ transport should be able to create one > on the fly for him, either by asking for the needed information or by > querying the public Jabber information available for John. > > From owner-jdev@jabber.org Thu Feb 4 14:11:40 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA29387 for jdev-list; Thu, 4 Feb 1999 14:11:40 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from eising.k-net.dk (eising.k-net.dk [192.38.208.81]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA29384 for ; Thu, 4 Feb 1999 14:11:36 -0600 Received: (qmail 12401 invoked from network); 4 Feb 1999 20:11:42 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 4 Feb 1999 20:11:42 -0000 Received: from nybro.dk (traume.nybro.k-net.dk [192.38.223.251]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 110GRA0R; Thu, 4 Feb 1999 21:08:58 +0100 Received: (from tue@localhost) by nybro.dk (8.8.7/8.8.7) id VAA00825; Thu, 4 Feb 1999 21:15:56 +0100 Date: Thu, 4 Feb 1999 21:15:56 +0100 From: Tue Wennerberg Message-Id: <199902042015.VAA00825@nybro.dk> To: jdev@jabber.org Subject: Re: [JDEV] [Client Lib 1.0] In-Reply-To: X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5 X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org --- Jeremie wrote: > > I want Jabber to be 100% accessible EASILY through the command line. This > is not nearly as easy as one might think. Since an authenticated > connection must be made and maintained to the server, there will always > need to be a background process. I dont see any reason for any CLI daemon, if the CLI clients works like this: jwrite: Compose/send simple messages, either typed or from STDIN [Connect to server;authenticate;send message;disconnect] jmesg: Change/check current status, online, offline, away, [Connect to server;authenticate;get/set status;disconnect] jwho: View roster and status of users on your roster. Add/remove entries. [Connect to server;authenticate;get/set roster;disconnect] jtalk: Start a threaded chat-like message communication with a user. (This is IMO not a command-line interface job. This can by it's very nature not be done as a one-shot deal. Start the real curses/gui-based client instead) This solution requires that you can set your status to "semi-online", in which case the jabber server should buffer messages. I think a daemon on the client side is basically a bad idea, and can be avoided. Correct me, if I'm wrong. - Tue Wennerberg PS. Great job, Jeremie. Keep it going! From owner-jdev@jabber.org Fri Feb 5 06:16:11 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id GAA03232 for jdev-list; Fri, 5 Feb 1999 06:16:11 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from brain.resj.insa-lyon.fr (lhaeffel@J340-a.resJ.insa-lyon.fr [134.214.166.70]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id GAA03229 for ; Fri, 5 Feb 1999 06:16:08 -0600 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by brain.resj.insa-lyon.fr (8.8.7/8.8.7) id NAA12252 for jdev@jabber.org; Fri, 5 Feb 1999 13:15:48 +0100 From: Laurent Haeffele To: jdev@jabber.org Subject: Re: [JDEV] [Client Lib 1.0] Date: Fri, 5 Feb 1999 13:12:02 +0100 X-Mailer: KMail [version 1.0.9] Content-Type: text/plain References: <199902042015.VAA00825@nybro.dk> MIME-Version: 1.0 Message-Id: <99020513154800.12223@brain> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mondo.eppg.com id GAA03230 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On Thu, 04 Feb 1999, you wrote : |I think a daemon on the client side is basically a bad idea, and can be |avoided. Correct me, if I'm wrong. I don't think so. The idea is to know if someone is connected or not. If you don't run a deamon on the client side, when your machine is down, you could be seen as "online" (which is false). Laurent -- Laurent Haeffele mailto:Laurent.Haeffele@insa-lyon.fr http://www.insa-lyon.fr/People/AEDI/lhaeffel From owner-jdev@jabber.org Fri Feb 5 11:33:47 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA05525 for jdev-list; Fri, 5 Feb 1999 11:33:47 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from eising.k-net.dk (eising.k-net.dk [192.38.208.81]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id LAA05518 for ; Fri, 5 Feb 1999 11:33:43 -0600 Received: (qmail 5606 invoked from network); 5 Feb 1999 17:33:49 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 5 Feb 1999 17:33:49 -0000 Received: from nybro.dk (traume.nybro.k-net.dk [192.38.223.251]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 110GRDBW; Fri, 5 Feb 1999 18:31:03 +0100 Received: (from tue@localhost) by nybro.dk (8.8.7/8.8.7) id WAA00979; Thu, 4 Feb 1999 22:44:32 +0100 Date: Thu, 4 Feb 1999 22:44:32 +0100 From: Tue Wennerberg Message-Id: <199902042144.WAA00979@nybro.dk> To: jdev@jabber.org Subject: Re: [JDEV] [Code/CVS 1.0] In-Reply-To: X-Mailer: XCmail 0.99.7devel - with PGP support, PGP engine version 0.5 (Linux) X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org First, a general evaluation of the first month of open source: Jeremie, you've done an excellent job! One thing that has lacked, however, is the fundamental rule of Open Source Development: "Release often!" This means updating something in the CVS daily (or at *least* bi-weekly). The best way to accomplish this is if you put all your effort from now on into getting CVS up running, and distributing responsibility to various persons. All IMHO, of course. :-) --- Jeremie wrote: > > #### CVS > > I need to figure out how to make CVS work on the server side safely. I'd > like to do everything through pserver, but I don't know that it's possible > yet. I think I saw somewhere that you could make CVS work with SSH access. That'd be great. SSH is God's gift to network administration (which you probably know, since jabber.org runs a sshd). BTW, the CVS source tree should be cleaned up. My suggestion is: /jabberserver /transports /jabber-transport /icq-transport /irc-transport /clientlib /clients /my-cli-client /my-windows-client1 /my-windows-client2 /my-gtk-client /my-java-client Maybe the "jabber-transport" should be placed under /jabberserver. > #### Code > > [...] > ==> Code Style > > [I'm open to suggestions, ...] The coding style for the linux kernel is in /usr/src/linux/Documentation/CodingStyle on a standard linux system. We might want to use 4 instead of 8 spaces for indentation. - Tue Wennerberg From owner-jdev@jabber.org Fri Feb 5 11:33:49 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA05528 for jdev-list; Fri, 5 Feb 1999 11:33:49 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from eising.k-net.dk (eising.k-net.dk [192.38.208.81]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id LAA05516 for ; Fri, 5 Feb 1999 11:33:43 -0600 Received: (qmail 5603 invoked from network); 5 Feb 1999 17:33:49 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 5 Feb 1999 17:33:49 -0000 Received: from nybro.dk (traume.nybro.k-net.dk [192.38.223.251]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 110GRDB4; Fri, 5 Feb 1999 18:31:03 +0100 Received: (from tue@localhost) by nybro.dk (8.8.7/8.8.7) id XAA01196; Thu, 4 Feb 1999 23:50:40 +0100 Date: Thu, 4 Feb 1999 23:50:40 +0100 From: Tue Wennerberg Message-Id: <199902042250.XAA01196@nybro.dk> To: jdev@jabber.org Subject: Re: [JDEV] [Code/CVS 1.0] In-Reply-To: X-Mailer: XCmail 0.99.7devel - with PGP support, PGP engine version 0.5 (Linux) X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org --- Jeremie wrote: > > [...] > ==> Expat > > [All XML needs to start passing through expat. I started looking > at it, and am definitely going to need some help making it work, not sure > I totally understand it yet but it's integration will happen] Anyone should compile the sample/elements.c file from the expat package, and pipe something like jeremie Ph0niks jabalot into it. That was an ahaaa experience for me. It's a very small example on how to use expat. - Tue From owner-jdev@jabber.org Fri Feb 5 11:33:46 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA05523 for jdev-list; Fri, 5 Feb 1999 11:33:46 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from eising.k-net.dk (eising.k-net.dk [192.38.208.81]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id LAA05517 for ; Fri, 5 Feb 1999 11:33:43 -0600 Received: (qmail 5609 invoked from network); 5 Feb 1999 17:33:49 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 5 Feb 1999 17:33:49 -0000 Received: from nybro.dk (traume.nybro.k-net.dk [192.38.223.251]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 110GRDBZ; Fri, 5 Feb 1999 18:31:03 +0100 Received: (from tue@localhost) by nybro.dk (8.8.7/8.8.7) id WAA00888; Thu, 4 Feb 1999 22:02:01 +0100 Date: Thu, 4 Feb 1999 22:02:01 +0100 From: Tue Wennerberg Message-Id: <199902042102.WAA00888@nybro.dk> To: jdev@jabber.org Subject: Re: [JDEV] [Web Site 1.0] X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5 X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Jeremie wrote: > > [snip] > In the Developers area, [... a developer can ...] enter/track bugs. I would suggest using Bugzilla some day. It's a web-based bugtracking utility developed and used at mozilla.org, as well as used by RedHat for bugtracking. I checked it out a few days ago, and it's pretty cool for large projects. > [snip] Jabber is the protocol, not the distro/code available, > anyone can write the code, we're just providing a base implementation. We might want to give the Client Lib a special "reference implementation" licence, allowing proprietary software to be built upon it. I'm not sure. The rest could be GPL'ed, or something, as long as it's Open Source [tm]. - Tue From owner-jdev@jabber.org Fri Feb 5 11:53:09 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA05966 for jdev-list; Fri, 5 Feb 1999 11:53:09 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from gulf.csc.UVic.CA (gulf.csc.UVic.CA [142.104.105.200]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA05963 for ; Fri, 5 Feb 1999 11:53:07 -0600 From: qbradley@csc.UVic.CA Received: from dowager.csc.UVic.CA (dowager.csc.UVic.CA [142.104.105.58]) by gulf.csc.UVic.CA (8.8.8/8.8.8) with SMTP id JAA16144 for ; Fri, 5 Feb 1999 09:53:03 -0800 (PST) Received: from localhost by dowager.csc.UVic.CA (AIX 4.1/UCB 5.64/4.03) id AA11038; Fri, 5 Feb 1999 09:53:02 -0800 Date: Fri, 5 Feb 1999 09:53:02 -0800 (PST) To: jdev@jabber.org Subject: Re: [JDEV] [Web Site 1.0] In-Reply-To: <199902042102.WAA00888@nybro.dk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On Thu, 4 Feb 1999, Tue Wennerberg wrote: > We might want to give the Client Lib a special "reference implementation" > licence, allowing proprietary software to be built upon it. I'm not sure. > The rest could be GPL'ed, or something, as long as it's Open Source [tm]. That is what the LGPL is for, I believe. When someone gets around to writing a client library, we will see what license they use I suppose. There was recently an article on slashdot.org where RMS suggested LGPL should be "Lesser GPL" instead of "Library GPL", but in any case, the decision rests with the author of the client library. This brings up a sticky point perhaps someone could help me understand. I was working with an artist on an interface for a Jabber client. In my opinion it looks very cool, and operates very effectively. However, it makes use of a lot of original art created by the artist. Artists are an order of magnitude more concerned about IP issues than comptuer scientists. I've looked through the GPL and I'm not sure it would apply well to the art. Either the art would fall under the category of something that stands alone, in which case it would not be GPL when seperated from the code, or perhaps not. In any case, if a client library was LGPL, I could use it while keeping other parts of the program, such as the artwork, "proprietary". If I can't come up with a decent solution, my other options are just using a traditional interface (Will we be stuck with last decades GUI concepts forever?!) because the artist won't risk losing his reputation by letting go of control of his art, or to write a completely proprietary client, which would be boring and useless, IMHO. Any thoughts? Quetzalcoatl Bradley qbradley@csc.uvic.ca From owner-jdev@jabber.org Fri Feb 5 14:21:40 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA07527 for jdev-list; Fri, 5 Feb 1999 14:21:40 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA07524 for ; Fri, 5 Feb 1999 14:21:38 -0600 Date: Fri, 5 Feb 1999 14:21:38 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] [Code/CVS 1.0] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > There are a couple of problems with using the CVS pserver. Anyone who has > write access can do almost anything on the system. But assuming you let > trusted developers, you shouldn't have a problem. The CVS passwords are > encoded using a very simple scheme. However, also assuming that your CVS > passwords are different from users on the box, you shouldn't have a > problem. Unfortunately, although I administer this box(holding the site/CVS/etc), it's not one that I can let anyone have shell access to. I've got no problem allowing trusted developers to have full CVS access, but I don't know how to do that yet :) > > If you need any help setting this up, feel free to contact me. Absolutely! Let's take this offline then, and see if we can't get a solid safe CVS archive up and running, thanks! > [zap'd part on autoconf/automake] > > I think this is the best way. We want to make this easy to use, flexible, > and compatible. Autoconf/Automake are two of the best utilities to ensure > this. I have some experience in this area, as I'm sure others do as well. Good, after we get the CVS archive up and running, anyone knowing how to do this can take over this part and add in support for it, I'll try to pick it up as we go... > I'm not a fan of the old K&R style, but love the whitespace friendly > environment.. However, C is C, so whatever works best.. I don't know what style I'm using, the only part I really care about is putting the {}s on their own lines: if(x > 1) { code; } I'm sure we can find some nicely written style guide out there to agree on??? Apache's is here: http://dev.apache.org/styleguide.html and we could use that as a base to go from? Jer From owner-jdev@jabber.org Fri Feb 5 14:24:25 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA07557 for jdev-list; Fri, 5 Feb 1999 14:24:25 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA07554 for ; Fri, 5 Feb 1999 14:24:23 -0600 Date: Fri, 5 Feb 1999 14:24:23 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] [Transports 1.0] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > I really like the idea of these transports, especially the ICQ one. I'm > not sure how much (if any) progress is being made, but I'd like to > volunteer my efforts.. Great! From my playing, it's really really easy to write a transport that will half-way work, it will be quite a bit more work to make it "complete" though. > The project seems a little hectic, at least until there is a good CVS tree > setup. It is a little hectic :-) And yes, most of it should stabilize after we have a working CVS archive and multiple developers with write access and working on it, as well as a few people working on updating the web site regularly and writing docs. Jer From owner-jdev@jabber.org Fri Feb 5 14:37:13 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA07815 for jdev-list; Fri, 5 Feb 1999 14:37:13 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA07808 for ; Fri, 5 Feb 1999 14:37:11 -0600 Date: Fri, 5 Feb 1999 14:37:11 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] [Client Lib 1.0] In-Reply-To: <199902042015.VAA00825@nybro.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > I dont see any reason for any CLI daemon, if the CLI clients works like this: > > jwrite: > Compose/send simple messages, either typed or from STDIN > [Connect to server;authenticate;send message;disconnect] It should work this way when it can't find a background daemon... > > jmesg: > Change/check current status, online, offline, away, > [Connect to server;authenticate;get/set status;disconnect] Woops, nope, won't work. The server will only hold your status as long as there is an open TCP connection, disconnecting will drop everything. > jwho: > View roster and status of users on your roster. Add/remove entries. > [Connect to server;authenticate;get/set roster;disconnect] This can work this way also, BUT there are some drawbacks... > jtalk: > Start a threaded chat-like message communication with a user. > (This is IMO not a command-line interface job. This can by it's > very nature not be done as a one-shot deal. Start the real > curses/gui-based client instead) Well, I'm expecting that it would work just like normal "talk" > > This solution requires that you can set your status to "semi-online", in > which case the jabber server should buffer messages. This by it's very nature isn't how Jabber works... you can only be "online" when you have an open TCP connection. Having the server show you as "online" when you are not really connected introduces some complexity and problems that I don't really want to deal with for V1.0. > I think a daemon on the client side is basically a bad idea, and can be > avoided. Correct me, if I'm wrong. It can only be avoided if the server will keep you online when you are not really connected... Right now, IMHO the background daemon isn't that big of a deal when compared to what you would have to do on the server side to support this... the background daemon can act like a fairly simple "proxy" providing this added functionality for those that need it. The other thing is, I REALLY want to be notified immediately in my shell when a message arrives, just like the standard "write" or "talk", and the ONLY way this can happen is via a background daemon. So even though some might not want this, the functionaly will need to be there anyway :) Jer From owner-jdev@jabber.org Fri Feb 5 14:59:58 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA08145 for jdev-list; Fri, 5 Feb 1999 14:59:58 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA08142 for ; Fri, 5 Feb 1999 14:59:56 -0600 Date: Fri, 5 Feb 1999 14:59:56 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] [Code/CVS 1.0] In-Reply-To: <199902042144.WAA00979@nybro.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > > First, a general evaluation of the first month of open source: > > Jeremie, you've done an excellent job! One thing that has lacked, however, > is the fundamental rule of Open Source Development: > > "Release often!" Absolutely 100% in agreement here! If I(both me and my home computer) wasn't under-the-weather half the month so far there would have been many more updates and progress *grin*. > This means updating something in the CVS daily (or at *least* bi-weekly). > The best way to accomplish this is if you put all your effort from now on > into getting CVS up running, and distributing responsibility to various > persons. This is absolutely correct, and I've been considering my options lately... it's just that I'm fairly restricted in how much access I can give to the server, I just want to be safe or trust those that have access... > I think I saw somewhere that you could make CVS work with SSH access. > That'd be great. SSH is God's gift to network administration (which you > probably know, since jabber.org runs a sshd). Yup, I've been using SSH for a few months now... it's a bit slow from home over the modem, but it works and looks like a good solution, but it requires that I give out shell accounts and I'm not sure I can tighten up the server enough to be doing that. I think that is the way I'm going to go though, tidy up the server and let trusted developers have CVS access through SSH. Can I get away without allowing telnet though? Is there any way to configure SSH w/o telneting into the box first? I could probably just set it up for each account individually and email the pub keys, no? > BTW, the CVS source tree should be cleaned up. My suggestion is: Hehe... it's not really structured right now, so ANYTHING would be better :-) > > /jabberserver > /transports > /jabber-transport > /icq-transport > /irc-transport > /clientlib > /clients > /my-cli-client > /my-windows-client1 > /my-windows-client2 > /my-gtk-client > /my-java-client > > Maybe the "jabber-transport" should be placed under /jabberserver. Looks good, but /jabberserver should be /jabberbox, there needs to be a /commonlib, or maybe: /libs /common /transport (don't know if it's needed yet) /client Also, there should probably be an area for modules, maybe under /jabber-transport. > > The coding style for the linux kernel is in > /usr/src/linux/Documentation/CodingStyle > on a standard linux system. We might want to use 4 instead of 8 spaces for > indentation. Looks good after a quick scan, except that I like putting my {'s on their own lines(find it much more readable) for everything, not just functions... but I'll cede to the masses if nobody else does, *g*. Jer From owner-jdev@jabber.org Fri Feb 5 15:04:12 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA08205 for jdev-list; Fri, 5 Feb 1999 15:04:12 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id PAA08201 for ; Fri, 5 Feb 1999 15:04:10 -0600 Date: Fri, 5 Feb 1999 15:04:10 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] [Code/CVS 1.0] In-Reply-To: <199902042250.XAA01196@nybro.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > Anyone should compile the sample/elements.c file from the expat package, > and pipe something like > > > jeremie > Ph0niks > jabalot > > > into it. That was an ahaaa experience for me. It's a very small example on > how to use expat. I did EXACTLY that :) And am now forming ideas on how I'm going to integrate it... I'll probably build a tree-like structure and have individual chunks(like logins, or messgaes, whatever) be parsed into a common tree-like data structure, and have a few handy functions to pull data out of that structure... still thinking, but I wont start playing/coding till I get the CVS stuff figured out though... Jer From owner-jdev@jabber.org Fri Feb 5 15:14:58 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA08365 for jdev-list; Fri, 5 Feb 1999 15:14:58 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id PAA08362 for ; Fri, 5 Feb 1999 15:14:56 -0600 Date: Fri, 5 Feb 1999 15:14:56 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] [Web Site 1.0] In-Reply-To: <199902042102.WAA00888@nybro.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > > I would suggest using Bugzilla some day. It's a web-based bugtracking > utility developed and used at mozilla.org, as well as used by RedHat > for bugtracking. I checked it out a few days ago, and it's pretty cool > for large projects. That's the plan... all in good time... > > [snip] Jabber is the protocol, not the distro/code available, > > anyone can write the code, we're just providing a base implementation. > > We might want to give the Client Lib a special "reference implementation" > licence, allowing proprietary software to be built upon it. I'm not sure. > The rest could be GPL'ed, or something, as long as it's Open Source [tm]. Hmmm... yes, I considered this, but decided to wait until it was written and see how much it ends up containing. I'm thinking that it will not really be all that difficult for "proprietary software" to impliment their own ways of accessing the server, and most GUI clients on other OS's will probably also do the same. IMHO the client lib will really only be handy on platforms where a user might be using multiple pieces of software(CLI or GUI) to access one single account/connection, where the client lib can negotiate a shared connection to the server. Say, on Windows or the Mac, using the available XML parser for that platform and doing simple TCP connections isn't going to be all that challenging that a client lib would offer much help, but I haven't thought about it much and might very well be quite wrong. I guess, my real take on this is if the client isn't GPL, then they can write their own code since it's relatively simple to do so ;-) Jer From owner-jdev@jabber.org Fri Feb 5 15:20:37 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA08476 for jdev-list; Fri, 5 Feb 1999 15:20:37 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id PAA08472 for ; Fri, 5 Feb 1999 15:20:35 -0600 Date: Fri, 5 Feb 1999 15:20:35 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] [Web Site 1.0] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > > This brings up a sticky point perhaps someone could help me understand. I > was working with an artist on an interface for a Jabber client. In my > opinion it looks very cool, and operates very effectively. However, it > makes use of a lot of original art created by the artist. Artists are > an order of magnitude more concerned about IP issues than comptuer > scientists. I've looked through the GPL and I'm not sure it would apply > well to the art. Either the art would fall under the category of > something that stands alone, in which case it would not be GPL when > seperated from the code, or perhaps not. In any case, if a client library > was LGPL, I could use it while keeping other parts of the program, such as > the artwork, "proprietary". > > If I can't come up with a decent solution, my other options are just using > a traditional interface (Will we be stuck with last decades GUI concepts > forever?!) because the artist won't risk losing his reputation by letting > go of control of his art, or to write a completely proprietary client, > which would be boring and useless, IMHO. > > Any thoughts? First, I'm very intersted to see a cool interface, it could be the "killer app" for Jabber :) IANAL(I Am Not A Lawyer) but I really don't think the GPL specifically covers anything but source code, and if the "art" is just some graphics/skins for the app, it wouldn't be covered. If the art was turned into a big hex array and included in the source, it might be covered, but otherwise I would think you're safe... but that's just IMHO. Jer From owner-jdev@jabber.org Fri Feb 5 15:24:36 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA08582 for jdev-list; Fri, 5 Feb 1999 15:24:36 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from dsmail.dstm.com (maintainit.com [208.147.204.3]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id PAA08576; Fri, 5 Feb 1999 15:24:32 -0600 Received: by DSMAIL with Internet Mail Service (5.0.1460.8) id ; Fri, 5 Feb 1999 16:19:12 -0500 Message-ID: From: Jon Wight To: "'jdev@jabber.org'" , "'jeremie@jabber.org'" Subject: RE: [JDEV] [Code/CVS 1.0] Date: Fri, 5 Feb 1999 16:19:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org This is of interest to me. I'm sooooo not an expert on XML but how are you going to partially form a XML document from transaction between client and server? Doesn't XML require a whole document to work? (Am I missing something obvious here?) Jon > -----Original Message----- > From: Jeremie [mailto:jeremie@jabber.org] > Sent: Friday, February 05, 1999 4:04 PM > To: jdev@jabber.org > Subject: Re: [JDEV] [Code/CVS 1.0] > > > > Anyone should compile the sample/elements.c file from the > expat package, > > and pipe something like > > > > > > jeremie > > Ph0niks > > jabalot > > > > > > into it. That was an ahaaa experience for me. It's a very > small example on > > how to use expat. > > I did EXACTLY that :) And am now forming ideas on how I'm going to > integrate it... I'll probably build a tree-like structure and have > individual chunks(like logins, or messgaes, whatever) be parsed into a > common tree-like data structure, and have a few handy > functions to pull > data out of that structure... still thinking, but I wont start > playing/coding till I get the CVS stuff figured out though... > > Jer > From owner-jdev@jabber.org Fri Feb 5 15:38:32 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA08819 for jdev-list; Fri, 5 Feb 1999 15:38:32 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from gulf.csc.UVic.CA (gulf.csc.UVic.CA [142.104.105.200]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id PAA08816 for ; Fri, 5 Feb 1999 15:38:30 -0600 From: qbradley@csc.UVic.CA Received: from dowager.csc.UVic.CA (dowager.csc.UVic.CA [142.104.105.58]) by gulf.csc.UVic.CA (8.8.8/8.8.8) with SMTP id NAA03236 for ; Fri, 5 Feb 1999 13:38:26 -0800 (PST) Received: from localhost by dowager.csc.UVic.CA (AIX 4.1/UCB 5.64/4.03) id AA15184; Fri, 5 Feb 1999 13:38:25 -0800 Date: Fri, 5 Feb 1999 13:38:25 -0800 (PST) To: "'jdev@jabber.org'" Subject: RE: [JDEV] [Code/CVS 1.0] In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On Fri, 5 Feb 1999, Jon Wight wrote: > This is of interest to me. I'm sooooo not an expert on XML but how are you > going to partially form a XML document from transaction between client and > server? Doesn't XML require a whole document to work? (Am I missing > something obvious here?) One key point to remember is that Jabber sends multiple XML "documents" over one network connection. Each message from the server to the client or from thet client to the server is a complete XML document. One network connection, many many many XML documents :-) Quetzalcoatl Bradley qbradley@csc.uvic.ca From owner-jdev@jabber.org Fri Feb 5 16:53:41 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id QAA09293 for jdev-list; Fri, 5 Feb 1999 16:53:41 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id QAA09290 for ; Fri, 5 Feb 1999 16:53:40 -0600 Date: Fri, 5 Feb 1999 16:53:39 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: "'jdev@jabber.org'" Subject: RE: [JDEV] [Code/CVS 1.0] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > This is of interest to me. I'm sooooo not an expert on XML but how are you > going to partially form a XML document from transaction between client and > server? Doesn't XML require a whole document to work? (Am I missing > something obvious here?) You're not missing anything at all :) This is what I was originally worried about, and why the protocol was really originally just a stream of mini-documents... It ends up just being an issue with the XML parser: will the parser eat up one single XML document in chunks? Yes, as far as I can tell they all do at some low level. With Expat, you can just give it the string chunks coming in over the wire and as it finds tags and other interesting XML things in those strings, it calls functions to handle them. So it should work just fine, as pieces of the XML document come in, they are sequentially analyzed for tags and functions are called immediately when a tag is found. Jer From owner-jdev@jabber.org Fri Feb 5 19:07:14 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id TAA09846 for jdev-list; Fri, 5 Feb 1999 19:07:14 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from iridium.medianet.ie (root@iridium.medianet.ie [194.133.7.1]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id TAA09843 for ; Fri, 5 Feb 1999 19:07:05 -0600 Received: from domain .(justdoit@lucas.clubi.ie [195.17.145.68]) by iridium.medianet.ie (DIESPAM/NR) with ESMTP id BAA18294 for ; Sat, 6 Feb 1999 01:06:56 GMT Received: (qmail 14524 invoked by uid 1000); 5 Feb 1999 23:27:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Feb 1999 23:27:43 -0000 Date: Fri, 5 Feb 1999 23:27:43 +0000 ( ) From: "Aaron Brady (INSOMNIAK)" To: jdev@jabber.org Subject: Re: [JDEV] [Code/CVS 1.0] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org : This is absolutely correct, and I've been considering my options lately... : it's just that I'm fairly restricted in how much access I can give to the : server, I just want to be safe or trust those that have access... how about a patches@jabber.org list, for outgoing official patches (CVS/RCS diffs), and incoming proposed patches, like undernet's coder-com ? . o O ( insomnike is rewt@clubi.ie :Aaron Brady ) O o . From owner-jdev@jabber.org Sun Feb 7 12:34:27 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA24000 for jdev-list; Sun, 7 Feb 1999 12:34:27 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from eising.k-net.dk (eising.k-net.dk [192.38.208.81]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id MAA23997 for ; Sun, 7 Feb 1999 12:34:24 -0600 Received: (qmail 28891 invoked from network); 7 Feb 1999 18:34:18 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 7 Feb 1999 18:34:18 -0000 Received: from traume.nybro.dk (traume.nybro.k-net.dk [192.38.223.251]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 1N4BB0T9; Sun, 7 Feb 1999 19:31:37 +0100 Received: (from tue@localhost) by traume.nybro.dk (8.8.7/8.8.7) id TAA00615; Sun, 7 Feb 1999 19:38:04 +0100 Date: Sun, 7 Feb 1999 19:38:04 +0100 From: Tue Wennerberg Message-Id: <199902071838.TAA00615@traume.nybro.dk> To: jdev@jabber.org Subject: Re: [JDEV] [Code/CVS 1.0] In-Reply-To: X-Mailer: XCmail 0.99.7devel - with PGP support, PGP engine version 0.5 (Linux) X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org --- Jeremie wrote: >> >> "Release often!" > > Absolutely 100% in agreement here! Great! >> The coding style for the linux kernel is in >> /usr/src/linux/Documentation/CodingStyle > > Looks good after a quick scan, except that I like putting my {'s on their > own lines(find it much more readable) for everything, not just > functions... but I'll cede to the masses if nobody else does, *g*. I dont like that. Just so you know there's at least one. btw, the Apache and the Linux-kernel styles are very similar. The Apache style is just very explicit, and may feel strict to some. But at least that uses 4 space indentation. - Tue From owner-jdev@jabber.org Sun Feb 7 12:42:47 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA24096 for jdev-list; Sun, 7 Feb 1999 12:42:47 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from eising.k-net.dk (eising.k-net.dk [192.38.208.81]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id MAA24093 for ; Sun, 7 Feb 1999 12:42:45 -0600 Received: (qmail 28984 invoked from network); 7 Feb 1999 18:42:45 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 7 Feb 1999 18:42:45 -0000 Received: from traume.nybro.dk (traume.nybro.k-net.dk [192.38.223.251]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 1N4BB04J; Sun, 7 Feb 1999 19:40:04 +0100 Received: (from tue@localhost) by traume.nybro.dk (8.8.7/8.8.7) id TAA00631; Sun, 7 Feb 1999 19:47:07 +0100 Date: Sun, 7 Feb 1999 19:47:07 +0100 From: Tue Wennerberg Message-Id: <199902071847.TAA00631@traume.nybro.dk> To: jdev@jabber.org Subject: Re: [JDEV] [Client Lib 1.0] In-Reply-To: X-Mailer: XCmail 0.99.7devel - with PGP support, PGP engine version 0.5 (Linux) X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org --- Jeremie wrote: > > The other thing is, I REALLY want to be notified immediately in my shell > when a message arrives, just like the standard "write" or "talk", and the > ONLY way this can happen is via a background daemon. So even though some > might not want this, the functionaly will need to be there anyway :) I realize now that there are two cases. 1. There's an actual user at the keyboard. 2. It's all run from a script. I guess I've been talking about the latter (and you the first?). Anyway, what you wrote above, is difficult to script. In any case, let's just leave it up to the coder. We'll probably end up covering both scenarios anyway. - Tue Wennerberg From owner-jdev@jabber.org Mon Feb 8 15:11:05 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA31402 for jdev-list; Mon, 8 Feb 1999 15:11:05 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id PAA31399 for ; Mon, 8 Feb 1999 15:11:03 -0600 Date: Mon, 8 Feb 1999 15:11:03 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] [Client Lib 1.0] In-Reply-To: <199902071847.TAA00631@traume.nybro.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > I realize now that there are two cases. > > 1. There's an actual user at the keyboard. > 2. It's all run from a script. > > I guess I've been talking about the latter (and you the first?). Anyway, > what you wrote above, is difficult to script. In any case, let's just > leave it up to the coder. We'll probably end up covering both scenarios > anyway. Yup, that sounds right... BTW, my masq box at home crapped out over the weekend so I've been "offline" :-( I'll try to catch up and start getting some coding done this week, as well as work on getting CVS working right. Jer From owner-jdev@jabber.org Tue Feb 16 00:28:53 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id AAA11232 for jdev-list; Tue, 16 Feb 1999 00:28:53 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id AAA11229 for ; Tue, 16 Feb 1999 00:28:51 -0600 Date: Tue, 16 Feb 1999 00:28:51 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] Update/CVS access Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Hello all! Things have been a bit quiet here on the list lately, but not in the background... thanks to the gracious assistance of Nicholas Kirsch, we seem to have CVS up and running correctly, and can now start letting others have write access to the tree AS WELL AS hosting related code bases such as other clients, transports, and modules. If you are intersted in either of these, email me and let me know. Nick also configured cvsweb which I'll be putting up online this week, and I'm looking at configuring a cvs mailing list for notifications of checkins to the tree. Hopefully soon here things can start calming down and I can start checking in code for 0.6 that includes expat(and new proto changes) and autoconf(thank you again, Nick!), as well as a solid cleanup of the base code and work on the new module api. Were still kickin people, coders welcome to join in! :) Jer From owner-jdev@jabber.org Tue Feb 16 10:44:25 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id KAA13565 for jdev-list; Tue, 16 Feb 1999 10:44:25 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id KAA13561; Tue, 16 Feb 1999 10:44:08 -0600 Date: Tue, 16 Feb 1999 10:44:08 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org cc: "Corbett J. Klempay" Subject: [JDEV] Re: Jabber sigs/crypto In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Corbett sent this to me directly, and said it was OK if I just reply directly to the list. > Hey there...I think I wrote one comment when the Jabber list first got > going, saying how we needed digital sigs and/or (preferably an and) crypto > in Jabber. Well, this semester I have a crypto class...with a final > project that's 40% of our grade...and got to thinking...perhaps I might be > able to make adding one or both of these things into Jabber? I then wrote > my professor...she said it sounded pretty cool, and then even wrote > another response about 10 minutes later, saying she'd been to the Jabber > site and it looked to be a neat project :) So, I'm not yet totally for > sure on it...since she's going to start teaching the class this coming > week (the TA has been teaching it so far, as it was just classic > old-school ciphers; kind of background stuff) and will soon be having us > create project proposals that will have to be turned in to her...but since > she's already pretty much given a thumbs-up to the concept, I expect I'll > probably be working on it. Something extra tasty I noticed while wasting > time in the library yesterday...I picked up some several-year old (like > 92-93ish, I think) proceedings from a math and/or crypto conference...and > just flipping through the contents...she (along with one or two other > people) had published a paper about some aspect of digital sigs....so I > think that's a pretty good sign she'll be a good source of expertise on > what/how I should do things (algorithmicly, at least). (If you're > curious, you can see her page...she's a professor in the Math Sci dept, > but I think she has some CS association, as her page is hosted there (but > linked off of Math Sci): www.cs.jhu.edu/~cowen). So, some things I was > thinking of: First off, this is WONDERFUL! It would be GREAT to have someone dedicated to adding in a decent level of security/encryption! > > - What's the best way for me to figure out how I'll plug this > stuff into the Jabber architecture? Should I just start sifting through > the protocol or something? Well, there are different things that can(need to) be done and each of them may need to be done differently. IMHO, here are the needs: --Identity Verifying that the user you received a message from is really them (and that the message hasn't been modified) --Privacy Encrypting a message so that only the recipient can decode it --Authentication Validating a login to the server and granting access to resources > - Annoying export bullshit...if I just do digital sigs (which is a > strong possibility, as sigs aren't export controlled, and she'll probably > want me to have an intermediary level (i.e. just sigs instead of > sigs+crypto) deliverable work that can be done by the end of the > semester), it won't be a problem...but where crypto is concerned...how do > we handle that? Make a 40-bit weak version and a 128-bit one (a la the > browsers)? IANAL, and I don't follow the crypto stuff, but I'd like to totally avoid any hairy mess here at all... Luckily, I believe that as it stands Jabber and the protocol is completely ready to be outfitted with any crypto setup and not have to modify anything internally to allow this... Here's my take, since as I understand it we'll get into a mess if we even think about including crypto stuff or even making special "hooks" for it in the code: --> Those wanting to work on crypto for jabber set up completely separate server to host the code(probably best if it's international?) but are free to use this list to discuss it as long as no code snippets are sent to the list :) --> Jabber.org can point all security/crypto/encryption inquiries and pages/links to the other server, as a separate project(similar to SSL for Apache) --> All crypto solutions can piggyback ontop of the protocol and modularization of the server, and provide libs or assist client authors in including crypto I might be a little bit "too safe" here, but I'd rather start out as safe as possible, and relax a little more when we know we can :-) > - Patent issues...I'm starting to look into this...I think the > strong frontrunner is the El Gamal public key cryptosystem...like RSA, it > can be used for both authentication _and_ encryption...but unlike RSA, > it's totally free of patent baggage (it's the first one to have its patent > expire..I think it's been free since some time in 97). While RSA gets its > strength from the difficulty of factoring large primes, El Gamal is based > on discrete logs. I forget, but I think that PGP 5.x and up might use El > Gamal in the free versions (and the commercial version allows you to use > RSA as well...which also makes it backward-compatible with PGP 2.6.x > keys). Like I said, I know little to nothing about this stuff(although I find it quite interesting), but others feel free to jump in here! > - Architecture changes/extensions? If a public-key based > cryptosystem is in place, there will have to be some kind of > infrastructure to deal with key distribution/management. This is not > really too nasty, I think...but the one nasty thing I haven't thought of > how to handle yet is how to totally avoid (or keep to a BARE minimum) the > authentication between client and server...I'd like to keep pretty much > all authentication between client->client (with the server just acting as > an intermediary)...but I fear that you'll need server-client authetication > at each step to prevent a man-in-the-middle attack...but the problem is, > considering how computationally expensive these operations are, server > scaling would be _severely_ hampered, as too much authentication would > bring these machines to their knees (and we can't be like: "minimum server > platform: 21264" :) The best way to start adding crypto in, is going to be via the mechanisms built into the protocol. For identity, public keys could be sent in the tags. For privacy the actual message content could be encrypted and the keys again could be in the ext tags to help decode the message. But for authentication(since it's client<->server instead of client<->client like the others) the tags could contain any of the needed char data to validate the incoming connection, and would be passed on to a special crypto module to actually handle the authentication for that user. I really don't know how the mechanics of the actual encryption/decryption would work, but I'm pretty sure they can all easily be employed on top of and independently of the main distro... If nothing else, Jabber isn't that complicated, and it wouldn't be difficult to create "secure" clients and a "secure" server that is completely separate, but can talk to other "insecure" Jabber servers directly. > > Any thoughts/suggestions? I'm just starting to try to sift this stuff out > in my head, as I'll have to have a decent idea of how it will work for > when I write my project proposal. I'm really excited about this! I definately want crypto/mondo-security, but don't know enough about it so I just tried to make sure Jabber is extensable enough so that someone who _does_ know can add it easily :) Thanks!!! Jer > > ------------------------------------------------------------------------------ > Corbett J. Klempay Quote of the Week: > http://www2.acm.jhu.edu/~cklempay "Don't judge a man's wealth -- or his > piety -- by his appearance on Sunday." > ------------------------------------------------------------------------------ > > > From owner-jdev@jabber.org Wed Feb 17 10:46:00 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id KAA17703 for jdev-list; Wed, 17 Feb 1999 10:46:00 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from spartacus.hula.net (root@spartacus.hula.net [206.127.232.5]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id KAA17700 for ; Wed, 17 Feb 1999 10:45:57 -0600 Received: from sculdheizo (halau15.hula.net [206.127.234.207]) by spartacus.hula.net (8.9.0/8.9.0) with SMTP id GAA14103 for ; Wed, 17 Feb 1999 06:44:01 -1000 (HST) Message-ID: <000a01be5a95$10349120$cfea7fce@sculdheizo> From: "Donovan Schulteis" To: Subject: Re: [JDEV] Re: Jabber sigs/crypto Date: Wed, 17 Feb 1999 06:45:54 -1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org >> - What's the best way for me to figure out how I'll plug this >> stuff into the Jabber architecture? Should I just start sifting through >> the protocol or something? I would think that having the client programs implement this in full, without the knowledge of the server programs (with the exception of doing a user authentication thing) would be relatively simple to implement without disrupting the current protocols. You could just have the client program grab the string (actual message) prior to transmiting and encrypt it, throwing a begin encrypt/ end encrypt string at the ends, and send the entire phrase as the string (message). When the recieving client program sees the proper begin phrase, it will decrypt the message and display that message to the screen (probably with some code to indicate that the message was sent encrypted, ie, red text or the words: secure message, or the like). A "lock/unlock" button on the client program could toggle secure and non-secure modes. Backlashes: A user would have to be careful not to use the exact same phrase at the beginning of an instant message that the encryption function places to denote encrypted text (ie, ---begin encrypted text here --- ; or whatever) or else the recieving client program will try to decipher the plain text. Users would have to have the same client program, or compatible programs (which could be easily accomplished by releasing the lib and code to developers. Users without client programs would be unable to decrypt secure messages, and should have a intercepting routine that would stop the message from appearing, and send a return message stating so. This would have to be included in all clients to ensure there is no confusion. Another thing for the enabled clients would be to not allow encryption to Jabber-only "buddies", I don't think ICQ or AIM would work :) And remember to code for the least common denominator machine, the PC's little endian, to ensure platform portability. As with any uses of keys, this could seriously hamper "roaming" capabilities of the user (for secure modes, that is). Unless the keys were stored on the server, which would kinda disrupt the whole idea of the thing :) >Well, there are different things that can(need to) be done and each of >them may need to be done differently. IMHO, here are the needs: >--Identity > Verifying that the user you received a message from is really them > (and that the message hasn't been modified) Digital signatures attached automatically to the end of message strings that are not displayed to the users (or displayed in some subtle form - like the word "Authenticated"). These could easily be added in the same way to the end of a message string (using ---begin sig here --- ; or the like). Once again, not displayed to the unenabled user. Better yet, make an "aware" client program disable the encryption and sigs for "buddies" that are not tagged with "encryption aware" options (like a check-box within a "buddy config" menu). This would allow unaware clients to not be "readied" for encryption tags. Aware clients would just alert "their own user" that they cannot send sigs or encrypted text to that particular buddy. >--Privacy > Encrypting a message so that only the recipient can decode it As above (my first paragraph of babble). >--Authentication > Validating a login to the server and granting access to resources This would require changes to the Jabber server program, to accept and verify users as they log on, but the program would have to be flexible enough to allow non-enabled clients to logon without. But if implemented, could be done by just verifying the digital signature. >> Make a 40-bit weak version and a 128-bit one (a la the browsers)? I would think that 40-bit would be quite suffencient for just one or two line messages between friends. To go the 128-bit route, is to open a whole can of legal worms in distribution and all that. Although, I think it would be cool if we went one step further, to say 512-bit, and became the de-facto standard for transmitting credit card numbers and the like through the internet, but then again, that's just dreaming. >Here's my take, since as I understand it we'll get into a mess if we even >think about including crypto stuff or even making special "hooks" for it >in the code: Should be planned for in the code, but not tailored for it. I think that, with the exception of authentication, it should be a client to client thing, that the Jabber servers and transports would pass without knowledge of, or even being able to tell, the encryption. >--> Jabber.org can point all security/crypto/encryption inquiries and >pages/links to the other server, as a separate project(similar to SSL for >Apache) As soon as my server comes up (should be a month or so, life, you know), I would be glad to host it, if no other host is found by then. >--> All crypto solutions can piggyback ontop of the protocol and >modularization of the server, and provide libs or assist client authors in >including crypto Yes, exactly. >> - Patent issues...I'm starting to look into this...I think the >> strong frontrunner is the El Gamal public key cryptosystem... >> [...] I think it's been free since some time in 97). [...] It has been freed up since Apr 97. El Gamal sounds good (although I think I read somewhere that it is "relatively easy" to break, ie, the NSA would have no problems at all). The only other non-patented system I can think of off-hand would be the Blowfish algorithm, by Bruce Schneier, which he distributes freely. It can handle up to, I think, 448-bit encryption, but has a larger memory footprint. Either would work, I would guess. >> - Architecture changes/extensions? If a public-key based >> cryptosystem is in place, there will have to be some kind of >> infrastructure to deal with key distribution/management. This is not >> really too nasty, I think...but the one nasty thing I haven't thought of >> how to handle yet is how to totally avoid (or keep to a BARE minimum) the >> authentication between client and server...I'd like to keep pretty much >> all authentication between client->client (with the server just acting as >> an intermediary) That would do it. And key distribution could be done on a special server somewhere, or done through file transfers with buddies. Say you're talking with someone and decide to go secure for one reason or another, do a public key transfer via the client program, and get his public key by doing an IP to IP transfer (hey, you trust the guy enough to talk secure with him, so you can trust him with your IP). The key management should be part of the same interface as everything else. After the keys have been transferred, then secure talking can begin. >> ...but I fear that you'll need server-client authetication >> at each step to prevent a man-in-the-middle attack... Not necessarily, because you'll be going client to client, and your digital sig will be at the end of each message to verify it's you. And as far as sniffing your key transfers - they're PUBLIC keys, so anyone can have them anyways. The only way someone is going to attack is to spoof as you by logging on to a your server with your digital sig, and then talking securely with your private keys. If they have gotten all this, the game is done already. >The best way to start adding crypto in, is going to be via the >mechanisms built into the protocol. For identity, public keys could be >sent in the tags. For privacy the actual message content >could be encrypted and the keys again could be in the ext tags to help >decode the message. But for authentication(since it's client<->server >instead of client<->client like the others) the >tags could contain any of the needed char data to validate the incoming >connection, and would be passed on to a special crypto module to actually >handle the authentication for that user. That sounds really good, I think that this is a do-able plan, and should be implemented as such. >I'm really excited about this! I definately want crypto/mondo-security, >but don't know enough about it so I just tried to make sure Jabber is >extensable enough so that someone who _does_ know can add it easily :) I am too!!! I don't think that any of the other IM's offer encryption options, and we could go so far as to include functions to encrypt files for transfer as well. I really don't think it would be too hard to implement at all, with the way Jabber is already set up, so it just becomes an issue of choosing how and doing it. If any help is needed, I would gladly TRY to be of some assistance. Deej From owner-jdev@jabber.org Wed Feb 17 14:17:51 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18441 for jdev-list; Wed, 17 Feb 1999 14:17:51 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from gulf.csc.UVic.CA (gulf.csc.UVic.CA [142.104.105.200]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id OAA18438 for ; Wed, 17 Feb 1999 14:17:48 -0600 From: qbradley@csc.UVic.CA Received: from dowager.csc.UVic.CA (dowager.csc.UVic.CA [142.104.105.58]) by gulf.csc.UVic.CA (8.8.8/8.8.8) with SMTP id MAA24224 for ; Wed, 17 Feb 1999 12:17:38 -0800 (PST) Received: from localhost by dowager.csc.UVic.CA (AIX 4.1/UCB 5.64/4.03) id AA14128; Wed, 17 Feb 1999 12:17:36 -0800 Date: Wed, 17 Feb 1999 12:17:35 -0800 (PST) To: jdev@jabber.org Subject: Re: [JDEV] Re: Jabber sigs/crypto In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On Tue, 16 Feb 1999, Jeremie wrote: > > - Architecture changes/extensions? If a public-key based > > cryptosystem is in place, there will have to be some kind of > > infrastructure to deal with key distribution/management. This is not > > really too nasty, I think...but the one nasty thing I haven't thought of > > how to handle yet is how to totally avoid (or keep to a BARE minimum) the > > authentication between client and server...I'd like to keep pretty much > > all authentication between client->client (with the server just acting as > > an intermediary)...but I fear that you'll need server-client authetication > > at each step to prevent a man-in-the-middle attack...but the problem is, > > considering how computationally expensive these operations are, server > > scaling would be _severely_ hampered, as too much authentication would > > bring these machines to their knees (and we can't be like: "minimum server > > platform: 21264" :) Remember that there is no reason for one central monolithic server. Many small servers would be better. Many servers might only serve a few people and authentication only takes place when the client starts up probably. For encryption, the server can absolutely be taken entirely out of the loop. What you would do is encrypt the message text but not the tags or recipient information. This way the server just passes on the message, not knowing or caring that the text of the message can't be read without being decrypted. Good luck! I'm looking forward to a secure jabber :-) Quetzalcoatl Bradley qbradley@csc.uvic.ca From owner-jdev@jabber.org Thu Feb 18 09:33:59 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id JAA03722 for jdev-list; Thu, 18 Feb 1999 09:33:59 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from smtp.doruk.net.tr (smtp.doruk.net.tr [212.58.4.4]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id JAA03719 for ; Thu, 18 Feb 1999 09:33:52 -0600 Received: from doruk.net.tr (zeus.doruk.net.tr [212.58.4.10]) by smtp.doruk.net.tr (8.8.5/SCO5) with SMTP id RAA12876 for ; Thu, 18 Feb 1999 17:51:27 +0200 (TSI) Received: from cn-async-host-00073.comnet.com.tr by doruk.net.tr (SMI-8.6/SMI-SVR4) id RAA17763; Thu, 18 Feb 1999 17:28:04 +0200 Date: Thu, 18 Feb 1999 17:32:37 -0700 (MST) From: "Kemal 'Disq' Hadimli" X-Sender: disq@heart_of_gold.localdomain To: jdev@jabber.org Subject: Re: [JDEV] Re: Jabber sigs/crypto In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On Wed, 17 Feb 1999 qbradley@csc.UVic.CA wrote: > loop. What you would do is encrypt the message text but not the tags or > recipient information. This way the server just passes on the message, > not knowing or caring that the text of the message can't be read without > being decrypted. yes. there should be a standard for encryption/decryption and the server should contain no encryptic/decryptic code. > Good luck! I'm looking forward to a secure jabber :-) yeah. if we have a secure system before we reach 1.0, it will be cool. it will also help jabber to be popular. :) ICQ is at v5 (v6?) and they're not there yet. (icq sucks anyway) bye, disqk From owner-jdev@jabber.org Thu Feb 18 09:56:50 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id JAA03846 for jdev-list; Thu, 18 Feb 1999 09:56:50 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from dsmail.dstm.com (dstm.com [208.147.204.3]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id JAA03843 for ; Thu, 18 Feb 1999 09:56:48 -0600 Received: by DSMAIL with Internet Mail Service (5.0.1460.8) id <14DC1958>; Thu, 18 Feb 1999 10:50:55 -0500 Message-ID: From: Jon Wight To: jdev@jabber.org Subject: [JDEV] MacOS Client? Date: Thu, 18 Feb 1999 10:50:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Has any as yet offered to work on a MacOS Client? If not then I could be prodded into making a start... Jon. --- Jonathan Wight Datastream Systems Inc. Development Rm: 429B, Ext: 5441 Voice: +1 (864) 422-5001, Fax: +1 (864) 422-5000 Email: jwight@dstm.com From owner-jdev@jabber.org Thu Feb 18 11:51:25 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA04321 for jdev-list; Thu, 18 Feb 1999 11:51:25 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from islanddata.com (islanddata.com [204.253.170.3]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id LAA04318 for ; Thu, 18 Feb 1999 11:51:19 -0600 Message-Id: <199902181751.LAA04318@mondo.eppg.com> Received: (qmail 6561 invoked from network); 18 Feb 1999 17:50:45 -0000 Received: from mrbigglesworth.islanddata.com (HELO ?207.110.37.47?) (207.110.37.47) by islanddata.com with SMTP; 18 Feb 1999 17:50:45 -0000 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Thu, 18 Feb 1999 09:51:10 -0800 Subject: Re: [JDEV] MacOS Client? From: "Brandon Lewis" To: jdev@jabber.org Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org I'm currently working on a Mac Jabber client. I didn't announce it until I knew what I was getting myself into. But It's definitely a project I could do. -Brandon ---------- >From: Jon Wight >To: jdev@jabber.org >Subject: [JDEV] MacOS Client? >Date: Thu, Feb 18, 1999, 7:50 AM > > Has any as yet offered to work on a MacOS Client? > > If not then I could be prodded into making a start... > > Jon. > > --- > Jonathan Wight > Datastream Systems Inc. > Development Rm: 429B, Ext: 5441 > Voice: +1 (864) 422-5001, Fax: +1 (864) 422-5000 > Email: jwight@dstm.com > > > From owner-jdev@jabber.org Thu Feb 18 12:15:10 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA04462 for jdev-list; Thu, 18 Feb 1999 12:15:10 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from chimera.acm.jhu.edu (root@chimera.acm.jhu.edu [128.220.223.63]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id MAA04459 for ; Thu, 18 Feb 1999 12:15:07 -0600 Received: from galtgulch (jonlin06.hilander.com [207.96.113.103]) by chimera.acm.jhu.edu (8.9.1/8.9.1) with SMTP id NAA16447 for ; Thu, 18 Feb 1999 13:15:04 -0500 Message-Id: <4.1.19990218130206.00a6da00@chimera.acm.jhu.edu> X-Sender: cklempay@chimera.acm.jhu.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 18 Feb 1999 13:11:36 -0500 To: jdev@jabber.org From: "Corbett J. Klempay" Subject: [JDEV] Re: Jabber sigs/crypto In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org >Well, there are different things that can(need to) be done and each of >them may need to be done differently. IMHO, here are the needs: >--Identity > Verifying that the user you received a message from is really them > (and that the message hasn't been modified) >--Privacy > Encrypting a message so that only the recipient can decode it >--Authentication > Validating a login to the server and granting access to resources > Question: she will likely have me (in my proposal) outline an intermediary level of completion which is pretty much for certain achievable within the semester. So the question is: if I only have time to implement one or the other, which is more key: encryption or authentication? >IANAL, and I don't follow the crypto stuff, but I'd like to totally avoid >any hairy mess here at all... Luckily, I believe that as it stands Jabber >and the protocol is completely ready to be outfitted with any crypto setup >and not have to modify anything internally to allow this... > >Here's my take, since as I understand it we'll get into a mess if we even >think about including crypto stuff or even making special "hooks" for it >in the code: >--> Those wanting to work on crypto for jabber set up completely >separate server to host the code(probably best if it's international?) but >are free to use this list to discuss it as long as no code snippets are >sent to the list :) Hmmm...won't that make it difficult for me to do any work, since I'm in the US? Or am I allowed to conduct work here, but have the work actually be taking place on a foreign server (like ssh'ed into some server in Australia or something)? Damn US export controls are retarded. >--> Jabber.org can point all security/crypto/encryption inquiries and >pages/links to the other server, as a separate project(similar to SSL for >Apache) >--> All crypto solutions can piggyback ontop of the protocol and >modularization of the server, and provide libs or assist client authors in >including crypto > One approach that was suggested to me (that is apparently fairly commonplace; I don't know how it does or doesn't work as far as export controls go) is to have it so that the encryption framework is set up to work with 128 bit keys, but all of the key-related stuff "dumbs-down" the key down from 128 to an effective length of whatever is desired by just applying 0xFFFF as much as needed to leave as much 'real' key as is desired. >The best way to start adding crypto in, is going to be via the >mechanisms built into the protocol. For identity, public keys could be >sent in the tags. For privacy the actual message content >could be encrypted and the keys again could be in the ext tags to help >decode the message. But for authentication(since it's client<->server >instead of client<->client like the others) the >tags could contain any of the needed char data to validate the incoming >connection, and would be passed on to a special crypto module to actually >handle the authentication for that user. > Hmmm...yeah, I think the encryption can be done without requiring any server changes, but key distribution requirements for any authentication work will need server changes... CJK From owner-jdev@jabber.org Thu Feb 18 12:30:14 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA04561 for jdev-list; Thu, 18 Feb 1999 12:30:14 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from rave.dorm.org (dorm@storms-177-211.res.iastate.edu [129.186.177.211]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id MAA04558 for ; Thu, 18 Feb 1999 12:30:11 -0600 Received: from localhost (dorm@localhost) by rave.dorm.org (8.8.7/8.8.7) with ESMTP id MAA13702 for ; Thu, 18 Feb 1999 12:28:59 -0600 Date: Thu, 18 Feb 1999 12:28:59 -0600 (EST) From: Mike Dorman To: jdev@jabber.org Subject: Re: [JDEV] MacOS Client? In-Reply-To: <199902181751.LAA04318@mondo.eppg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On Thu, 18 Feb 1999, Brandon Lewis wrote: > I'm currently working on a Mac Jabber client. I didn't announce it until I > knew what I was getting myself into. But It's definitely a project I could > do. > > > Has any as yet offered to work on a MacOS Client? > > > > If not then I could be prodded into making a start... I talked about working on it several weeks ago, but with school and all I realistically really won't have time at least until this summer. :( But I'm available for help/testing/etc., too :) mike From owner-jdev@jabber.org Thu Feb 18 12:53:02 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA04686 for jdev-list; Thu, 18 Feb 1999 12:53:02 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from chimera.acm.jhu.edu (root@chimera.acm.jhu.edu [128.220.223.63]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id MAA04682 for ; Thu, 18 Feb 1999 12:52:55 -0600 Received: from galtgulch (jonlin06.hilander.com [207.96.113.103]) by chimera.acm.jhu.edu (8.9.1/8.9.1) with SMTP id NAA17179 for ; Thu, 18 Feb 1999 13:52:45 -0500 Message-Id: <4.1.19990218125921.00a6cf10@chimera.acm.jhu.edu> X-Sender: cklempay@chimera.acm.jhu.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 18 Feb 1999 13:49:17 -0500 To: jdev@jabber.org From: "Corbett J. Klempay" Subject: Re: [JDEV] Re: Jabber sigs/crypto In-Reply-To: <000a01be5a95$10349120$cfea7fce@sculdheizo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > Backlashes: > A user would have to be careful not to use the exact same phrase at >the beginning of an instant message that the encryption function places to >denote encrypted text (ie, ---begin encrypted text here --- ; or whatever) >or else the recieving client program will try to decipher the plain text. Hmmm...I'm not sure of an obvious way around this right now, but this seems to be an unacceptable (to me at least) requirement...if I were a user of a problem like this and was told 'yeah, type your message here, but whatever you do, don't start with this particular string'...it just would give me the impression that the system was somehow shoddy. There must be one way or another around it... > Users would have to have the same client program, or compatible >programs (which could be easily accomplished by releasing the lib and code >to developers. Users without client programs would be unable to decrypt >secure messages, and should have a intercepting routine that would stop the >message from appearing, and send a return message stating so. This would >have to be included in all clients to ensure there is no confusion. Another >thing for the enabled clients would be to not allow encryption to >Jabber-only "buddies", I don't think ICQ or AIM would work :) And >remember to code for the least common denominator machine, the PC's little >endian, to ensure platform portability. I would have assumed the code would be designed such that it could run on either big or little endian, depending on compilation constants. > As with any uses of keys, this could seriously hamper "roaming" >capabilities of the user (for secure modes, that is). Unless the keys were >stored on the server, which would kinda disrupt the whole idea of the thing >:) Perhaps key distribution could work sort of like this: - when the user originally registers, the server that registered them stores their public key. None of the other servers have it. - when you add someone to your 'buddy' list (or if you explicitly request it, I guess), your client contacts its current server to retrieve the key. If the server does not have it, then it radiates out in a DNS kind of manner...contacting another to see if he has it, and so forth. Once the server has retrieved the key, it can give it to the client. The server will keep keys it had to retrieve from elsewhere for a configurable amount of time (like say 2 weeks) and then delete them; this way, dead/unused keys will not just infinitely fill up everywhere; the 'dead wood' bloat will go on at all servers (as all servers will likely take initial registrations), but this way the 'dead wood' redundancy will be kept to a minimum. Some other method could perhaps be implemented at each server to periodically kill dead accounts (like if the account/key hasn't been accessed in 6 months (or some other configurable period) and no other servers have retrieved the key, then you can consider him dead). This way, we prevent the case where each server (as time approaches infinity) has an unwieldy amount of usued accounts filling up space on it. So, with such a design, the average user who uses it on a daily/several times a week basis will have quick response; he'll be talking to other people who are on a lot, and their keys will be floating around at various servers. The worst case is on the first time ever key retrieval when the server must traverse the servers all the way to the other user's registration server...but even this won't take too long (and that would only happen if the other user had never had their key requested anywhere before). So, in the general case, it should be pretty good behavior. > Better yet, make an "aware" client program disable the encryption and >sigs for "buddies" that are not tagged with "encryption aware" options (like >a check-box within a "buddy config" menu). This would allow unaware clients >to not be "readied" for encryption tags. Aware clients would just alert >"their own user" that they cannot send sigs or encrypted text to that >particular buddy. > Hmm...this is a good idea. Anything to make it easier on people with encryption unaware clients (like the average AOL-type person). > This would require changes to the Jabber server program, to accept and >verify users as they log on, but the program would have to be flexible >enough to allow non-enabled clients to logon without. But if implemented, >could be done by just verifying the digital signature. > Yeah, so this is what I was talking about earlier...if the Jabber server needs to verify a digital sig for every user as they log on, will this place an unacceptable processing burden on the server's CPU? (or in other words will server scalability suck because of this processing overhead) I think I need to do some investigation into how fast verification is with a variety of algorithms. >>> Make a 40-bit weak version and a 128-bit one (a la the browsers)? > >I would think that 40-bit would be quite suffencient for just one or two >line messages between friends. Yeah, _you_ might feel that it's adequate, but lots of people would disagree. I mean, don't get me wrong: I myself am one of those people who doesn't bother getting the 128-bit versions of Netscape to do my online purchases; I figure if someone feels like taking the effort to get my credit card number, they almost deserve it (then again, it would be Mastercard who'd be taking the hit, I think). I think especially if people would want to use Jabber in a business environment, they'd be looking for > 40 bit. This appears to have already been an issue with ICQ; I guess several businesses complained to Mirabilis when they realized how easy it was to sniff and spoof with ICQ, and how they couldn't talk about business-related matters with confidence when using it. (to which Mirabilis responded that ICQ was never intended for use in a business environment, blah blah) Applied Crypto recommends: tactical military info (minutes/hours) 56-64 bits product announcements, mergers, interest rates (days/weeks) 64 bits long-term business plans (years) 64 bits trade secrets (decades) 112 bits >To go the 128-bit route, is to open a whole >can of legal worms in distribution and all that. Although, I think it would >be cool if we went one step further, to say 512-bit, and became the de-facto >standard for transmitting credit card numbers and the like through the >internet, but then again, that's just dreaming. As I mentioned a few paragraphs above, I'm wondering if the 'dumbed-down key' approach is workable here. >As soon as my server comes up (should be a month or so, life, you know), I >would be glad to host it, if no other host is found by then. > I'm sure I can host some stuff on our ACM machines (hey, we even have an 8 node Beowulf cluster we're just finishing bringing online, too! :)...our main user machine (chimera.acm.jhu.edu) might be of use. >It has been freed up since Apr 97. El Gamal sounds good (although I think I >read somewhere that it is "relatively easy" to break, ie, the NSA would have >no problems at all). ? Are you sure about this one, or perhaps you have it crossed in your mind with another one? If you have seen evidence of this and remember where, can you point me there? All of the reading I've done so far has made no mention of known major flaws in El Gamal; it is still regarded as being secure (unless some new developments to indicate otherwise have gone on more recently than my literature) >The only other non-patented system I can think of >off-hand would be the Blowfish algorithm, by Bruce Schneier, which he >distributes freely. It can handle up to, I think, 448-bit encryption, but >has a larger memory footprint. Either would work, I would guess. > Well, no. El Gamal is a public key (asymmetric) system; Blowfish is symmetric (like DES). There is no way to use Blowfish for authentication. It might be possible to use a hybrid approach (like PGP) and use an asymmetric algorithm for signing and authentication, and key management, but while still using a symmetric (and thus MUCH faster...on the order of 1000x faster) algorithm to do the encryption of the bulk data. CJK From owner-jdev@jabber.org Thu Feb 18 13:49:58 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA04888 for jdev-list; Thu, 18 Feb 1999 13:49:58 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from olaf.nick.org (nkirsch@nicholas-kirsch2.ups.edu [209.181.136.247]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id NAA04885 for ; Thu, 18 Feb 1999 13:49:55 -0600 Received: from localhost (nkirsch@localhost) by olaf.nick.org (8.9.1/8.9.0) with SMTP id LAA03027 for ; Thu, 18 Feb 1999 11:49:46 -0800 Date: Thu, 18 Feb 1999 11:49:46 -0800 (PST) From: "Nicholas M. Kirsch" To: jdev@jabber.org Subject: Re: [JDEV] Re: Jabber sigs/crypto In-Reply-To: <4.1.19990218125921.00a6cf10@chimera.acm.jhu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > Hmmm...I'm not sure of an obvious way around this right now, but this seems > to be an unacceptable (to me at least) requirement...if I were a user of a > problem like this and was told 'yeah, type your message here, but whatever > you do, don't start with this particular string'...it just would give me > the impression that the system was somehow shoddy. There must be one way > or another around it... I agree with this. The jabber protocol is specified by xml tags, it would be relatively easy to simply add it as an option to a tag. > I would have assumed the code would be designed such that it could run on > either big or little endian, depending on compilation constants. Most definitly should be. I'm not sure how the sources are now, but anything that is sent over the network should first be put into big-endian format if we are going to look for true cross-platform compatibility. This should be relatively easy to add to the existing code base, since we now have a good build environment (with autoconf/automake). > Yeah, so this is what I was talking about earlier...if the Jabber server > needs to verify a digital sig for every user as they log on, will this > place an unacceptable processing burden on the server's CPU? (or in other > words will server scalability suck because of this processing overhead) I > think I need to do some investigation into how fast verification is with a > variety of algorithms. We currently verify a user based on a login name and password. Surely the digital signature can be incorporated into some type of password scheme. Verifying the digital signature shouldn't be any more computationally intensive than verifying a password, ideally anyway. > >>> Make a 40-bit weak version and a 128-bit one (a la the browsers)? > > > >I would think that 40-bit would be quite suffencient for just one or two > >line messages between friends. > > Yeah, _you_ might feel that it's adequate, but lots of people would > disagree. I mean, don't get me wrong: I myself am one of those people who > doesn't bother getting the 128-bit versions of Netscape to do my online > purchases; I figure if someone feels like taking the effort to get my > credit card number, they almost deserve it (then again, it would be > Mastercard who'd be taking the hit, I think). I think especially if people > would want to use Jabber in a business environment, they'd be looking for > > 40 bit. This appears to have already been an issue with ICQ; I guess > several businesses complained to Mirabilis when they realized how easy it > was to sniff and spoof with ICQ, and how they couldn't talk about > business-related matters with confidence when using it. (to which > Mirabilis responded that ICQ was never intended for use in a business > environment, blah blah) Applied Crypto recommends: > tactical military info (minutes/hours) 56-64 bits > product announcements, mergers, interest rates (days/weeks) 64 bits > long-term business plans (years) 64 bits > trade secrets (decades) 112 bits I don't think it would be difficult to setup parameters in the CVS tree to check the hostname of the user attempting to download the source and replace it with 40 bit versions instead of 128. US export laws are strict, and we have to do our best to be sure not to violate them. > Well, no. El Gamal is a public key (asymmetric) system; Blowfish is > symmetric (like DES). There is no way to use Blowfish for authentication. > It might be possible to use a hybrid approach (like PGP) and use an > asymmetric algorithm for signing and authentication, and key management, > but while still using a symmetric (and thus MUCH faster...on the order of > 1000x faster) algorithm to do the encryption of the bulk data. > > CJK > This is really the only option. To use a public-key system for all the data encryption would be _extremely_ CPU intensive. SSH uses a hybrid approach, using a public-key system to negotiation a session key, which is then a symmetric algorithm. Nick From owner-jdev@jabber.org Fri Feb 19 01:03:31 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id BAA06620 for jdev-list; Fri, 19 Feb 1999 01:03:31 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wacko.com (dsl.wacko.com [207.173.19.110]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id BAA06617 for ; Fri, 19 Feb 1999 01:03:27 -0600 Received: from [192.168.1.12] (cx481688-c.fed1.sdca.home.com [24.0.39.10]) by wacko.com (8.9.3/8.9.3) with ESMTP id AAA22639 for ; Fri, 19 Feb 1999 00:03:19 -0700 (MST) Message-Id: <199902190703.AAA22639@wacko.com> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Thu, 18 Feb 1999 23:03:09 -0800 Subject: [JDEV] Servers and specs From: "Brandon Lewis" To: jdev@jabber.org Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Okay. I have a lot of the main MacOS functionality down. My next project is actually interfacing with the servers. I looked through the web site hoping to find definitions for some of the features and which parts of the config.x file to change. Is there a more in depth list of definitions? I'm assuming is the IP address of my machine. But I don't really know for sure. I'm pretty stupid. I'll even let you configure it for my server. What is 'priority'? Can we make a manual of all the XML commands that Jabber uses similar to the W3C definitions of HTML? Please let me know. -Brandon Lewis From owner-jdev@jabber.org Fri Feb 19 02:53:49 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id CAA06846 for jdev-list; Fri, 19 Feb 1999 02:53:49 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from spartacus.hula.net (root@spartacus.hula.net [206.127.232.5]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id CAA06843 for ; Fri, 19 Feb 1999 02:53:46 -0600 Received: from sculdheizo (halau31.hula.net [206.127.234.223]) by spartacus.hula.net (8.9.0/8.9.0) with SMTP id WAA30503 for ; Thu, 18 Feb 1999 22:51:57 -1000 (HST) Message-ID: <004301be5be5$7797fb80$dfea7fce@sculdheizo> From: "Donovan Schulteis" To: Subject: Re: [JDEV] Re: Jabber sigs/crypto Date: Thu, 18 Feb 1999 21:01:58 -1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org [Two messages compiled to one reply] >> Backlashes: >> A user would have to be careful not to use the exact same phrase at >>the beginning of an instant message that the encryption function places to >>denote encrypted text (ie, ---begin encrypted text here --- ; or whatever) >>or else the recieving client program will try to decipher the plain text. > >Hmmm...I'm not sure of an obvious way around this right now, but this seems >to be an unacceptable (to me at least) requirement...if I were a user of a >problem like this and was told 'yeah, type your message here, but whatever >you do, don't start with this particular string'...it just would give me >the impression that the system was somehow shoddy. There must be one way >or another around it... >I agree with this. The jabber protocol is specified by xml tags, it would >be relatively easy to simply add it as an option to a encrypted="yes"> tag. This would make the most sense, because if we block enabled clients from sending encrypted messages to unenabled buddies, we wouldn't have to worry about catching the encrypted string at the other end or making part of it readable to the unenabled user. Enabled Jabbers would check for the tag before displaying a string, and ~walla~ red text if it came encrypted or black if not (or something like that). But we must ensure that enabled clients have the facilities to tag buddies as to whether or not they can recieve encrypted messages. >I would have assumed the code would be designed such that it could run on >either big or little endian, depending on compilation constants. >Most definitly should be. I'm not sure how the sources are now, but >anything that is sent over the network should first be put into big-endian >format if we are going to look for true cross-platform compatibility. This >should be relatively easy to add to the existing code base, since we now >have a good build environment (with autoconf/automake). I'm sorry, I'm still relatively new to programming, and especially new to cross platform stuff, so I do not really have much of a clue about that (I don't think Borland C++ ever made me worry about endians during college projects!). Disregard. I just thought if using high level math we may wish to remember cross platform stuff. Maybe someone, someday, can email me with info on endians to set me straight. That would be very appreciated. :) >> As with any uses of keys, this could seriously hamper "roaming" >>capabilities of the user (for secure modes, that is). Unless the keys were >>stored on the server, which would kinda disrupt the whole idea of the thing >>:) > >Perhaps key distribution could work sort of like this: > >- when the user originally registers, the server that registered them >stores their public key. None of the other servers have it. >- when you add someone to your 'buddy' list (or if you explicitly request >it, I guess), your client contacts its current server to retrieve the key. >If the server does not have it, then it radiates out in a DNS kind of >manner...contacting another to see if he has it, and so forth. [...cut...] This seems to me that it would complicate things in the server severly. IMOHO - If a person wanted anyone to get their public key, they could register it with a central "yellow pages" or the like (best if jabber.org had that for user ease). The keys could be available for retrieval by the client program or at the client's account at the server. The other way to access someone's public key would be to have them send it to you while chatting in non secure mode, directly without the servers involved (IP to IP). That would allow more discreet persons to control (somewhat) who gets their public keys. This could be incorporated with the file transfer mode (I assume Jabber will eventually get that, like ICQ?!?!?) What I meant by "hamper roaming" was the private key and use at both home and work. I for one would not want my private key stored on a server machine! >> Make a 40-bit weak version and a 128-bit one (a la the browsers)? >>I would think that 40-bit would be quite suffencient for just one or two >>line messages between friends. > >Yeah, _you_ might feel that it's adequate, but lots of people would >disagree. I mean, don't get me wrong: I myself am one of those people who >doesn't bother getting the 128-bit versions of Netscape to do my online >purchases; I figure if someone feels like taking the effort to get my >credit card number, they almost deserve it (then again, it would be >Mastercard who'd be taking the hit, I think). I think especially if people >would want to use Jabber in a business environment, they'd be looking for > >40 bit. This appears to have already been an issue with ICQ; I guess >several businesses complained to Mirabilis when they realized how easy it >was to sniff and spoof with ICQ, and how they couldn't talk about >business-related matters with confidence when using it. (to which >Mirabilis responded that ICQ was never intended for use in a business >environment, blah blah) Applied Crypto recommends: >tactical military info (minutes/hours) 56-64 bits >product announcements, mergers, interest rates (days/weeks) 64 bits >long-term business plans (years) 64 bits >trade secrets (decades) 112 bits Conceed and agree. I only meant that just chatting with a buddy and not wanting to be sniffed would only need 40bit. I also did mention that I would love to go higher for business purposes. To quote: "Although, I think it would be cool if we went one step further, to say 512-bit, and became the de-facto standard for transmitting credit card numbers and the like through the internet, but then again, that's just dreaming." I think if we went a very secure route, Jabber _could_ become the business transaction program of choice (at least for transactions where two PEOPLE were actually engaged in conversation). >[...cut...] I'm wondering if the 'dumbed-down key' approach is workable here. You would most likely know more than I would, like I said before, I'm pretty much starting on all of this. :) >>[...cut...] (although I think I read somewhere that it is "relatively easy" to break [...] >? Are you sure about this one, or perhaps you have it crossed in your mind >with another one? If you have seen evidence of this and remember where, >can you point me there? All of the reading I've done so far has made no >mention of known major flaws in El Gamal; it is still regarded as being >secure (unless some new developments to indicate otherwise have gone on >more recently than my literature) Sorry, I must have read it wrong. It was Applied Cryptography 2/e - B Schneier pg 477. Please confirm my misconceptions for me. I looked up ElGamal to get an idea what you were on to (I'm only up to about pg 100 in my reading of it), and caught this: If Eve ever gets two messages signed or encrypted using the same k, even if she doesn't know what it is, she can recover x. But it is talking about signatures, and, as I'm not that far, I'm not sure what this really means. By all means, set me straight or flat out ignore my comments on that. But, I hope that I have shown at least some knowledge of what you're doing, and not insulted you. I'm starting, I'm trying, and I'm very interested. Thank you for putting up with me! :) Deej From owner-jdev@jabber.org Fri Feb 19 09:44:37 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id JAA07732 for jdev-list; Fri, 19 Feb 1999 09:44:37 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id JAA07729 for ; Fri, 19 Feb 1999 09:44:35 -0600 Date: Fri, 19 Feb 1999 09:44:35 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] Re: Jabber sigs/crypto In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > > Hmmm...I'm not sure of an obvious way around this right now, but this seems > > to be an unacceptable (to me at least) requirement...if I were a user of a > > problem like this and was told 'yeah, type your message here, but whatever > > you do, don't start with this particular string'...it just would give me > > the impression that the system was somehow shoddy. There must be one way > > or another around it... > > I agree with this. The jabber protocol is specified by xml tags, it would > be relatively easy to simply add it as an option to a encrypted="yes"> tag. Well, I'd like to avoid extending the protocol for specific purposes, but instead use the built in extension mechanisms. A message looks like this: jeremie Hey! This is just a test message. To extend it, you just have to add: ANYTHING CAN GO HERE So, a signed message *could* be: jeremie asdf asdg ashqrtq134643yqd Hey! This is just a test message. Or, based on above, you could put just about anything you wanted between the tags. Everything the the gets passed right through the server untouched. I'm guessing that different projects for different purposes will create their own little "namespace" within the ext tags, such as the security/encryption stuff might use . > > Yeah, so this is what I was talking about earlier...if the Jabber server > > needs to verify a digital sig for every user as they log on, will this > > place an unacceptable processing burden on the server's CPU? (or in other > > words will server scalability suck because of this processing overhead) I > > think I need to do some investigation into how fast verification is with a > > variety of algorithms. > > We currently verify a user based on a login name and password. Surely the > digital signature can be incorporated into some type of password scheme. > Verifying the digital signature shouldn't be any more computationally > intensive than verifying a password, ideally anyway. Well, wouldn't the digital sig used for authentication just BE the password? Such as: myuserid Q#$^@#%Yqfdgq346 My DIGITAL SIGNATURE My NickName This would work GREAT, because the user/pass is fed to the module API so you could just have an optional "secure" module that allows you to have digital sigs as the password and authenticates the user. Jer From owner-jdev@jabber.org Fri Feb 19 09:51:12 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id JAA07813 for jdev-list; Fri, 19 Feb 1999 09:51:12 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id JAA07810 for ; Fri, 19 Feb 1999 09:51:10 -0600 Date: Fri, 19 Feb 1999 09:51:10 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] Servers and specs In-Reply-To: <199902190703.AAA22639@wacko.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > Okay. I have a lot of the main MacOS functionality down. My next project is > actually interfacing with the servers. > > I looked through the web site hoping to find definitions for some of the > features and which parts of the config.x file to change. Is there a more in > depth list of definitions? I'm assuming is the IP address of my > machine. But I don't really know for sure. I'm pretty stupid. I'll even > let you configure it for my server. config.x is just a "prototype" for testing, there are only a few parts that actually do anything and need to be configured, and the important one is yourhostname so that it will answer queries sent to that address. Everything else should work fine as-is. > What is 'priority'? Can we make a manual of all the XML commands that > Jabber uses similar to the W3C definitions of HTML? Priority isn't really in use or defined much at this point, it's intended to be able to provide the functionality of telling a client that a message is "high priority" even if it is in do not disturb mode... This is something that I'd like to work out after we have a few working test clients and many of the currently planned changes done on the server side. And definately yes, I'd love to improve the manual, but I've been focusing on making the code/server work before writing how it works at this point :) Jer From owner-jdev@jabber.org Fri Feb 19 11:58:15 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA08262 for jdev-list; Fri, 19 Feb 1999 11:58:15 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA08259 for ; Fri, 19 Feb 1999 11:58:12 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id MAA25305 for ; Fri, 19 Feb 1999 12:57:41 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id MAA22808 for ; Fri, 19 Feb 1999 12:57:40 -0500 (EST) From: "Thomas Charron" To: Subject: [JDEV] Another Hat in the Ring.. Date: Fri, 19 Feb 1999 13:19:25 -0500 Message-ID: <000501be5c34$61740200$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Hello, everyone.. I've finally went and joined the list, as I'm nearly to a point where I'm ready to start talking.. To make a long story short, here's what I'm working on currently (And have been for roughly a week) 1) An MFC based 'JabberClient' class that can be used by programmers to add jabber functionality to roughly anything, including using it to write new clients without dealing with the protocol and sockets and the such.. 2) The above in DLL form, so that ANY language that can use DLL's can use the above.. 3) Compiling the jabberbox and jabber.transport into NT based services. Haven't really worked on this yet past design stages, really.. Most of my work currently is based on #1 above. My main goal is to make it as easy as possible for people to write clients with different user interfaces, and tap into the vast market of (PLEASE no one take offence to this) idiotic VB programmers who aren't really at a level of programming to deal with Blocking socket connections and the such.. The actual JabberClient class I'm currently using is now Threaded, so it takes care of all communications to/from the server on it's own, and allows the application itself to go on it's merry way. Currently, the application needs to check for messages and the such that the JabberClient class stores in a buffer. In the future, the client can 'register' what ype of messages it can recieve, so as to inform users that send messages that the client can't handle that particular type current.. This is to support future expansion of . Perfect example is if Jabber interfaced with irc in any way in the future, and there where for an IRC user to invite a Jabber user to a channel on irc. If the client did not support it in any way, a short message stating this would be sent back to the sender.. I'm blabbering, aren't I? ;-P -- Thomas Charron United Parcel Service Northeast Region IE Software Developer "Moving at the speed of a T3 Trunk Line!" From owner-jdev@jabber.org Fri Feb 19 13:08:02 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA08566 for jdev-list; Fri, 19 Feb 1999 13:08:02 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id NAA08563 for ; Fri, 19 Feb 1999 13:07:54 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id OAA23029 for ; Fri, 19 Feb 1999 14:07:22 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id OAA20222 for ; Fri, 19 Feb 1999 14:07:21 -0500 (EST) From: "Thomas Charron" To: Subject: RE: [JDEV] Well-formed XML. Date: Fri, 19 Feb 1999 14:29:06 -0500 Message-ID: <000c01be5c3e$1dd86040$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-To: <36A78CCE.6B4C40B8@usa.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org A bit of a dated reply, but I just imported all of the archives into my mail box.. Anyhow.. The problem with most of the XML parsers currently out there is that they are for parsing an XML DOCUMENT, and NOT a XML Protocol packet.. This is the reason why it wants well formed XML to be contained in a single root element, becouse that's how it is supposed to work in a document centric view of XML data. The way this should be approached is to only send ONE element to the parser at a time. In your solution below, you STILL have the problem of a single root element if you attempt to send more then one packet to the engine. You are simply adding an additional level of elements that is not needed.. In response to your last comment, everything wrapped in for the exact reason you pointed out.. To provide a base level root element, being j. ;-P -- Thomas Charron United Parcel Service Northeast Region IE Software Developer "Moving at the speed of a T3 Trunk Line!" > -----Original Message----- > From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of > Jason Diamond > Sent: Thursday, January 21, 1999 3:24 PM > To: jdev@jabber.org > Subject: [JDEV] Well-formed XML. > > > Hi, I have another protocol related suggestion. I've been experimenting > with a Java client and have been using several of the major XML parsers > to test it out. Apparently, a well-formed XML document needs to have a > single root element. Much like the root element in HTML. All of the parsers I've tried so far, > stopped parsing at the second element. There are several ugly > workarounds but I think it would be much more conducive to our goals if > we could take any off the shelf XML parser and not have to modify it in > order to write a Jabber client. So, I propose that both the server and > client wrap all their messages in a root element. > Attributes could be used to specify the client and protocol much like > the current element. Maybe something like this: > > > foobar > > > > The end element could be used to indicate that the server or > client is getting ready to close the connection. Comments? I'm in the > process of downloading Cygwin32 so that I can make the necessary changes > to the server to test it out. > > Just out of curiosity, why are all the messages between client and > server wrapped in a element? Why not or > ? If we used element names rather than attribute types to > distinguish the purpose of a message, we could create a DTD specifying > what elements are allowed to be nested in others. For example, > and would only be allowed in a element. I'm not proposing > that we validate the XML as it comes in from the server, but it could be > used as a specification. Much like EBNF is for more traditional > protocols. And who knows, maybe while implementing and debugging our > clients we could have it validate the XML as an aid to determine a > source of errors. > > Bye, > Jason. > > From owner-jdev@jabber.org Fri Feb 19 13:21:31 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA08670 for jdev-list; Fri, 19 Feb 1999 13:21:31 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id NAA08667 for ; Fri, 19 Feb 1999 13:21:29 -0600 Date: Fri, 19 Feb 1999 13:21:29 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: RE: [JDEV] Well-formed XML. In-Reply-To: <000c01be5c3e$1dd86040$14225e0a@tarot.nhl02.us.ups.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org In case you missed it, you might want to check out the protocol changes/updates at: http://jabber.org/developers/archive/9902/msg00006.html I'm currently working on integrating expat: http://jclark.com/xml/expat.html into the core lib and redoing any related XML parsing code to use it and follow the protocol changes... On Fri, 19 Feb 1999, Thomas Charron wrote: > A bit of a dated reply, but I just imported all of the archives into my > mail box.. Anyhow.. > > The problem with most of the XML parsers currently out there is that they > are for parsing an XML DOCUMENT, and NOT a XML Protocol packet.. This is > the reason why it wants well formed XML to be contained in a single root > element, becouse that's how it is supposed to work in a document centric > view of XML data. > > The way this should be approached is to only send ONE element to > the parser at a time. In your solution below, you STILL have the problem of > a single root element if you attempt to send more then one > packet to the engine. You are simply adding an additional level of elements > that is not needed.. > > In response to your last comment, everything wrapped in for the > exact reason you pointed out.. To provide a base level root element, being > j. ;-P > > -- > Thomas Charron > United Parcel Service > Northeast Region > IE Software Developer > "Moving at the speed of a T3 Trunk Line!" > > > > -----Original Message----- > > From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of > > Jason Diamond > > Sent: Thursday, January 21, 1999 3:24 PM > > To: jdev@jabber.org > > Subject: [JDEV] Well-formed XML. > > > > > > Hi, I have another protocol related suggestion. I've been experimenting > > with a Java client and have been using several of the major XML parsers > > to test it out. Apparently, a well-formed XML document needs to have a > > single root element. Much like the root element in HTML. All of the parsers I've tried so far, > > stopped parsing at the second element. There are several ugly > > workarounds but I think it would be much more conducive to our goals if > > we could take any off the shelf XML parser and not have to modify it in > > order to write a Jabber client. So, I propose that both the server and > > client wrap all their messages in a root element. > > Attributes could be used to specify the client and protocol much like > > the current element. Maybe something like this: > > > > > > foobar > > > > > > > > The end element could be used to indicate that the server or > > client is getting ready to close the connection. Comments? I'm in the > > process of downloading Cygwin32 so that I can make the necessary changes > > to the server to test it out. > > > > Just out of curiosity, why are all the messages between client and > > server wrapped in a element? Why not or > > ? If we used element names rather than attribute types to > > distinguish the purpose of a message, we could create a DTD specifying > > what elements are allowed to be nested in others. For example, > > and would only be allowed in a element. I'm not proposing > > that we validate the XML as it comes in from the server, but it could be > > used as a specification. Much like EBNF is for more traditional > > protocols. And who knows, maybe while implementing and debugging our > > clients we could have it validate the XML as an aid to determine a > > source of errors. > > > > Bye, > > Jason. > > > > > From owner-jdev@jabber.org Fri Feb 19 14:47:50 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA09008 for jdev-list; Fri, 19 Feb 1999 14:47:50 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id OAA09005 for ; Fri, 19 Feb 1999 14:47:48 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id PAA06664 for ; Fri, 19 Feb 1999 15:47:13 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id PAA02438 for ; Fri, 19 Feb 1999 15:47:12 -0500 (EST) From: "Thomas Charron" To: Subject: RE: [JDEV] Well-formed XML. Date: Fri, 19 Feb 1999 16:08:59 -0500 Message-ID: <000101be5c4c$12da0320$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of > Jeremie > Subject: RE: [JDEV] Well-formed XML. > In case you missed it, you might want to check out the protocol > changes/updates at: > http://jabber.org/developers/archive/9902/msg00006.html Actually, I had some questions regarding this.. Is the entire connection going to be treated as one large XML transaction, or will each conversation between the client and server be a seperate XML transaction? I.E., will it work like this: jeremie Ph0niks jabalot This is my status 10 normal ...rest of client communication happens in here or this? jeremie Ph0niks jabalot This is my status 10 normal From owner-jdev@jabber.org Fri Feb 19 14:51:49 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA09029 for jdev-list; Fri, 19 Feb 1999 14:51:49 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from dsmail.dstm.com (dstm.com [208.147.204.3]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id OAA09026 for ; Fri, 19 Feb 1999 14:51:47 -0600 Received: by DSMAIL with Internet Mail Service (5.0.1460.8) id ; Fri, 19 Feb 1999 15:45:56 -0500 Message-ID: From: Jon Wight To: "'jdev@jabber.org'" Cc: "'JWight@bigfoot.com'" Subject: RE: [JDEV] Well-formed XML. Date: Fri, 19 Feb 1999 15:45:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Speaking of expat... I was looking at the expat code in Visual C++ with an eye to porting it to MacOS. It started to get a little bit hairy when I noticed all the file mapping code. Why is it there? Is there an expat expert in the group? (Jeremie???) Jon. > -----Original Message----- > From: Jeremie [mailto:jeremie@jabber.org] > Sent: Friday, February 19, 1999 2:21 PM > To: jdev@jabber.org > Subject: RE: [JDEV] Well-formed XML. > > > In case you missed it, you might want to check out the protocol > changes/updates at: > http://jabber.org/developers/archive/9902/msg00006.html > > I'm currently working on integrating expat: > http://jclark.com/xml/expat.html > into the core lib and redoing any related XML parsing code to > use it and > follow the protocol changes... From owner-jdev@jabber.org Fri Feb 19 15:06:26 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA09094 for jdev-list; Fri, 19 Feb 1999 15:06:26 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from jhunix.hcf.jhu.edu (jhunix.hcf.jhu.edu [128.220.2.5]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id PAA09091 for ; Fri, 19 Feb 1999 15:06:24 -0600 Received: from [128.220.196.35] (jhu2101.res.jhu.edu [128.220.196.35]) by jhunix.hcf.jhu.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id QAA99465 for ; Fri, 19 Feb 1999 16:06:12 -0500 (EST) Message-Id: <199902192106.QAA99465@jhunix.hcf.jhu.edu> Subject: RE: [JDEV] Well-formed XML. Date: Fri, 19 Feb 99 16:06:12 -0500 x-sender: dka13@jhunix.hcf.jhu.edu x-mailer: Claris Emailer 2.0, March 15, 1997 From: Dylan Adams To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On 2/19/99 3:45 PM, Jon Wight wrote: >Speaking of expat... > >I was looking at the expat code in Visual C++ with an eye to porting it to >MacOS. It started to get a little bit hairy when I noticed all the file >mapping code. Why is it there? > >Is there an expat expert in the group? (Jeremie???) expat ports very easily to MacOS. Just make sure you define the correct bit-gender (little vs big indian) I've ported it and can make it available. dylan From owner-jdev@jabber.org Fri Feb 19 15:35:40 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA09292 for jdev-list; Fri, 19 Feb 1999 15:35:40 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id PAA09289 for ; Fri, 19 Feb 1999 15:35:38 -0600 Date: Fri, 19 Feb 1999 15:35:38 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] Another Hat in the Ring.. In-Reply-To: <000501be5c34$61740200$14225e0a@tarot.nhl02.us.ups.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > Hello, everyone.. > > I've finally went and joined the list, as I'm nearly to a point where I'm > ready to start talking.. To make a long story short, here's what I'm > working on currently (And have been for roughly a week) > > 1) An MFC based 'JabberClient' class that can be used by programmers to add > jabber functionality to roughly anything, including using it to write new > clients without dealing with the protocol and sockets and the such.. > > 2) The above in DLL form, so that ANY language that can use DLL's can use > the above.. > > 3) Compiling the jabberbox and jabber.transport into NT based services. > Haven't really worked on this yet past design stages, really.. This is GREAT stuff!!! Allowing the win32 platform developers easy access to add Jabber functionality will really help the adoption of Jabber, not just in making it easy to write clients, but other pieces of software could easily adopt Jabber as a way to open a "channel" to others users using the software, for gaming, messaging, data transfer, anything! If someone doesn't get to it before me, I've been thinking about how nicely Jabber would go with Winamp's Shoutcast. You could set up a special Jabber server that would accept connections from clients(Winamp plugin on those who are listening to a shoutcast broadcast) and connections from servers(Winamp broadcasters), and the servers would send a message to the special server every time a new song started playing, and the listeners/clients would send a special message when they connect telling the custom jabber server what "servers" they want to get messages from or just get messages from all servers playing "rock" songs or look for particular names of songs, etc... that was all a bit rushed but I'm otta time and gotta take off(go skiing) soon... and it would all just be a prototype system based on jabber anyway :) > > I'm blabbering, aren't I? ;-P Not at all, this is really great! I just have to get to work on the server and update it using expat and other changes, and we can start making some serious progress towards a true public release. Also, we have CVS available if you'd like to host your source tree up here and use it for development... just let me know! :-) Jer From owner-jdev@jabber.org Fri Feb 19 15:40:55 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA09317 for jdev-list; Fri, 19 Feb 1999 15:40:55 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from ins8.netins.net (ins8.netins.net [167.142.225.8]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id PAA09314 for ; Fri, 19 Feb 1999 15:40:52 -0600 Received: from worf.netins.net (jeremie@worf.netins.net [167.142.225.4]) by ins8.netins.net (8.8.7/8.8.7) with SMTP id PAA18447 for ; Fri, 19 Feb 1999 15:40:51 -0600 (CST) Date: Fri, 19 Feb 1999 15:40:51 -0600 (CST) From: Jeremie Miller To: jdev@jabber.org Subject: RE: [JDEV] Well-formed XML. In-Reply-To: <199902192106.QAA99465@jhunix.hcf.jhu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > > >Speaking of expat... > > > >I was looking at the expat code in Visual C++ with an eye to porting it to > >MacOS. It started to get a little bit hairy when I noticed all the file > >mapping code. Why is it there? > > > >Is there an expat expert in the group? (Jeremie???) > expat ports very easily to MacOS. Just make sure you define the correct > bit-gender (little vs big indian) > > I've ported it and can make it available. Cool! I'm guessing the file mapping part you were talking about is part of the xmlwf app, which is just an example unix application utilizing expat. The real heart of expat is the xmltok and xmlparse sits on that to make it a little more paletable... I'm no expat-expert though :) Jer From owner-jdev@jabber.org Fri Feb 19 16:25:03 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id QAA09631 for jdev-list; Fri, 19 Feb 1999 16:25:03 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id QAA09626 for ; Fri, 19 Feb 1999 16:25:00 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id RAA21423 for ; Fri, 19 Feb 1999 17:24:28 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id RAA09860 for ; Fri, 19 Feb 1999 17:24:27 -0500 (EST) From: "Thomas Charron" To: Subject: RE: [JDEV] Well-formed XML.(Correction) Date: Fri, 19 Feb 1999 17:46:14 -0500 Message-ID: <000201be5c59$a78af8a0$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-To: <000101be5c4c$12da0320$14225e0a@tarot.nhl02.us.ups.com> X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org A quick correction to something I wrote earlier.. I MEANT if the transactions would look like this: jeremie Ph0niks jabalot This is my status 10 normal (Notice the xml version declerations multiple times..) If you are going to transaction based XML, adding the xml version statment at the start of each XML transaction would allow for a greater flexibility in what XML parser to use, as many use this as part of validation.. From owner-jdev@jabber.org Fri Feb 19 20:24:36 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id UAA10544 for jdev-list; Fri, 19 Feb 1999 20:24:36 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from islanddata.com (islanddata.com [204.253.170.3]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id UAA10541 for ; Fri, 19 Feb 1999 20:24:34 -0600 Message-Id: <199902200224.UAA10541@mondo.eppg.com> Received: (qmail 18489 invoked from network); 20 Feb 1999 02:23:32 -0000 Received: from mrbigglesworth.islanddata.com (HELO ?207.110.37.47?) (207.110.37.47) by islanddata.com with SMTP; 20 Feb 1999 02:23:32 -0000 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Fri, 19 Feb 1999 18:23:56 -0800 Subject: [JDEV] Mac Client From: "Brandon Lewis" To: jdev@jabber.org Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org For those of you interested I have posted a VERY PRELIMINARY version of Jabber for MacOS. It does almost nothing. But I have made the source available to anyone who wants to help. I'll start to modularize things this week-end and make the prefs reading and writing a lot better. Be gentile. You can find this at http://24.0.39.10/~brandon/jabber/index.html Have a good week-end! From owner-jdev@jabber.org Sat Feb 20 00:33:29 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id AAA11164 for jdev-list; Sat, 20 Feb 1999 00:33:29 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from tscnet.com (root@tscnet.com [207.227.236.10]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id AAA11160 for ; Sat, 20 Feb 1999 00:33:26 -0600 Received: from tscnet.com (ppp-tnt-24.tscnet.net [207.227.238.24]) by tscnet.com (8.9.3/8.7.3) with ESMTP id WAA04355 for ; Fri, 19 Feb 1999 22:33:11 -0800 Message-ID: <36CE5664.B9CB3574@tscnet.com> Date: Fri, 19 Feb 1999 22:29:56 -0800 From: William Graham X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: jdev@jabber.org Subject: [JDEV] Java Client References: <199902200224.UAA10541@mondo.eppg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Hello, all -- been lurking for a few days. Normally I like to lurk longer before butting in to a list, but this is so darned exciting I can't help it ... apologies accepted, I hope? Anyway, I've seen some messages on Java stuff, and would just like to offer to help anyone writing a Java client. I'm not the absolute hottest coder around, but I do pretty good, and enjoy Swing gui coding (by hand, in Emacs -- none of those visual ide's here ;-). Anyway, my thanks to all of you who are already helping to create this *really* cool project, and if anyone wants help with Java coding, please let me know! Thanks, Bill Graham www2.tscnet.com/~wwg (nuthin' special there, really) Linux Hacker Emacs Fanatic Penguin Worshipper From owner-jdev@jabber.org Mon Feb 22 17:01:34 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA21633 for jdev-list; Mon, 22 Feb 1999 17:01:34 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id RAA21630 for ; Mon, 22 Feb 1999 17:01:32 -0600 Date: Mon, 22 Feb 1999 17:01:32 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: RE: [JDEV] Well-formed XML.(Correction) In-Reply-To: <000201be5c59$a78af8a0$14225e0a@tarot.nhl02.us.ups.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Originally(and still in the current codebase) it works kind of like what you have below, but the headers are implied. Where I'm heading with what I've been working on is towards a communication based on a single document, where each sub-tag is an exchange between the client and server. Technologically, it's not going to make a big difference, but it seems that it's easier to understand when the protocol "looks" and "acts" like a normal XML document. Also, with the entire communication exchange looking like a big document, it should be easiy to whip up a DTD to verify it or just simply define it. jeremie Ph0niks jabalot This is my status 10 normal Jer On Fri, 19 Feb 1999, Thomas Charron wrote: > A quick correction to something I wrote earlier.. I MEANT if the > transactions would look like this: > > > protocol="19990101"> > > jeremie > Ph0niks > jabalot > > > > protocol="19990101"> > > This is my status > 10 > normal > > > > (Notice the xml version declerations multiple times..) If you are going to > transaction based XML, adding the xml version statment at the start of each > XML transaction would allow for a greater flexibility in what XML parser to > use, as many use this as part of validation.. > From owner-jdev@jabber.org Tue Feb 23 10:24:29 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id KAA24884 for jdev-list; Tue, 23 Feb 1999 10:24:29 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id KAA24881 for ; Tue, 23 Feb 1999 10:24:25 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id LAA14548 for ; Tue, 23 Feb 1999 11:23:54 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id LAA24844 for ; Tue, 23 Feb 1999 11:23:54 -0500 (EST) From: "Thomas Charron" To: Subject: [JDEV] Sources trees, CVS, and other ramblings.. Date: Tue, 23 Feb 1999 11:45:42 -0500 Message-ID: <000201be5f4b$f3a33d20$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Well, I guess my next question would be is if we have any sort of tentative date for a working server that will use this protocol? My suggestion would be to get the transport using it for the client connections first, so anyone workingon clients can get their act together the fastest.. Also, I know there was mention of a CVS archive.. How often is it updated on the server side? Looking at the snaps on jabber.org, it appears to only be updated every so often. Also I'd be interested in checking things in once I have these C++ classes ironed out. I'm attempting to remove all dependencies on MFC so that they would be much more cross platform. (IF anyone has plugin replacements for CString and CAsyncSocket, Email me, we'll do lunch!! ;-P) -- Thomas Charron United Parcel Service Northeast Region IE Software Developer "Moving at the speed of a T3 Trunk Line!" > -----Original Message----- > From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of > Jeremie > Sent: Monday, February 22, 1999 6:02 PM > To: jdev@jabber.org > Subject: RE: [JDEV] Well-formed XML.(Correction) > > > Originally(and still in the current codebase) it works kind of like what > you have below, but the headers are implied. > > Where I'm heading with what I've been working on is towards a > communication based on a single document, where each sub-tag is an > exchange between the client and server. Technologically, it's not going > to make a big difference, but it seems that it's easier to understand when > the protocol "looks" and "acts" like a normal XML document. Also, with > the entire communication exchange looking like a big document, it should > be easiy to whip up a DTD to verify it or just simply define it. > > > protocol="19990101"> > > jeremie > Ph0niks > jabalot > > > This is my status > 10 > normal > > > > Jer > > On Fri, 19 Feb 1999, Thomas Charron wrote: > > > A quick correction to something I wrote earlier.. I MEANT if the > > transactions would look like this: > > > > > > > protocol="19990101"> > > > > jeremie > > Ph0niks > > jabalot > > > > > > > > > protocol="19990101"> > > > > This is my status > > 10 > > normal > > > > > > > > (Notice the xml version declerations multiple times..) If you > are going to > > transaction based XML, adding the xml version statment at the > start of each > > XML transaction would allow for a greater flexibility in what > XML parser to > > use, as many use this as part of validation.. > > > From owner-jdev@jabber.org Tue Feb 23 10:31:08 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id KAA24946 for jdev-list; Tue, 23 Feb 1999 10:31:08 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id KAA24943 for ; Tue, 23 Feb 1999 10:31:06 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id LAA17171 for ; Tue, 23 Feb 1999 11:30:36 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id LAA28037 for ; Tue, 23 Feb 1999 11:30:35 -0500 (EST) From: "Thomas Charron" To: "Jabber Development" Subject: [JDEV] Windows XML classes.. Date: Tue, 23 Feb 1999 11:52:25 -0500 Message-ID: <000301be5f4c$e3dfc9c0$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On another note, anyone developing applications dealing with XML may want to look at the CExtensibleMarkup classes in the WFC (Win32 Foundation Classes), a free set of classes available at http://ourworld.compuserve.com/homepages/Sam_Blackburn/wfc.htm. -- Thomas Charron United Parcel Service Northeast Region IE Software Developer "Moving at the speed of a T3 Trunk Line!" From owner-jdev@jabber.org Tue Feb 23 11:53:03 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA25339 for jdev-list; Tue, 23 Feb 1999 11:53:03 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from gulf.csc.UVic.CA (gulf.csc.UVic.CA [142.104.105.200]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA25336 for ; Tue, 23 Feb 1999 11:52:55 -0600 From: mskala@csc.UVic.CA Received: from trutch.csc.UVic.CA (trutch.csc.UVic.CA [142.104.105.63]) by gulf.csc.UVic.CA (8.8.8/8.8.8) with SMTP id JAA17673; Tue, 23 Feb 1999 09:52:52 -0800 (PST) Date: Tue, 23 Feb 1999 09:52:50 -0800 (PST) To: jdev@jabber.org cc: qbradley@csc.UVic.CA Subject: Re: [JDEV] Re: Jabber sigs/crypto (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Hello... Quetzalcoatl Bradley asked me to look at this and comment to the list, as I'm a crypto geek too. I'm not *on* the list (probably will join very soon) so ccing responses to me would be appreciated. (Ideally, responses would be cced to the reply-to address above instead of this school account that gets checked less frequently, but that may be too much to ask.) On Wed, 17 Feb 1999 qbradley@csc.UVic.CA wrote: > --Identity > Verifying that the user you received a message from is really them > (and that the message hasn't been modified) > --Privacy > Encrypting a message so that only the recipient can decode it > --Authentication > Validating a login to the server and granting access to resources I think authentication in the other direction may be important, too - in other words, the client has to know that the server they're talking to is really the server they want to be talking to. I don't know much about how Jabber works, but my understanding is that the server, not client, is responsible for things like knowing who is on my "friends" list and notifying me when one of them logs on. Well, my "friends" list (or whatever you call it) could reveal things about me that I don't want just anyone to know - e.g. my wife gets a copy and finds my mistress's name on it. I'd rather have some assurance that the server I'm giving my personal data out to is really the server I intend to be giving it out to. Reading further I see that this is probably something you want to avoid.. you want to treat the server as just a dumb insecure message forwarder. That makes very good sense as far as protocol design is concerned.. it does mean, though, that clients have to understand that the server isn't trusted in the crypto sense. In other words, my mistress had better be using a meaningless psuedonym everywhere outside the end-to-end encrypted connection between her client and mine. > > - Annoying export bullshit...if I just do digital sigs (which is a > > strong possibility, as sigs aren't export controlled, and she'll probably > > want me to have an intermediary level (i.e. just sigs instead of > > sigs+crypto) deliverable work that can be done by the end of the > > semester), it won't be a problem...but where crypto is concerned...how do > > we handle that? Make a 40-bit weak version and a 128-bit one (a la the > > browsers)? IMHO, it is a *really bad idea* to have a "weak" version, because then people will use it. They'll have a false sense of security, and that seems to me like a bad thing. With something like crypto that the general public isn't qualified to make judgements about, I think those of us who *are* capable of making judgements about it, have a responsibility not to give the masses enough rope to hang themselves. I'd prefer to see a protocol with two options: no security, or meaningful security. As for export control, if you're in the USA, yes, you have a problem. Really, you need an export license (IANAL either, but I'm pretty sure of this) *even for 40-bit crypto*... it's just that they're much easier to get, for 40-bit crypto. One reason is that it's possible to make 40-bit crypto strong enough to inconvenience the NSA if you, for instance, use a really time-consuming key setup that makes brute force difficult. I think digital signatures can be exported, although I heard something about a 1024-bit limit (which is the minimum length of public-key I'd consider acceptable). Or maybe that's just the limit built into DSA. My opinion on export control: move. :-) Actually, my opinion is that you should try to make a good protocol, fully document the protocol, and then either do the print-out-and-scan dance like PGP did, or seek volunteers outside the USA to implement the protocol. (You have one here, subject to my time availability...) I think it'd be a real shame to allow the US rules to stop you from building the best possible product. Incidentally, it's worth asking: why not just use the IETF's version of SSL (I think it may be called TSA)? That protocol has the advantage of being widely peer-reviewed, and also if Jabber built a library for it that could be used in other things, it'd be a significant contribution to the community. OTOH, I don't know how well that protocol would co-exist with whatever other protocol stuff you're doing. > --> Those wanting to work on crypto for jabber set up completely > separate server to host the code(probably best if it's international?) but > are free to use this list to discuss it as long as no code snippets are > sent to the list :) > --> Jabber.org can point all security/crypto/encryption inquiries and > pages/links to the other server, as a separate project(similar to SSL for > Apache) > --> All crypto solutions can piggyback ontop of the protocol and > modularization of the server, and provide libs or assist client authors in > including crypto This sounds okay to me, although the desire for "no modifications to the server" does limit the authentication *of* the server that I mentioned before. The system would still be leaps and bounds ahead of any other I know of, even without server authentication, but it does serve to underscore the fact that true security is not really something you can add on as a separate feature - it really has to be built into a system from the ground up. > > - Patent issues...I'm starting to look into this...I think the > > strong frontrunner is the El Gamal public key cryptosystem...like RSA, it > > can be used for both authentication _and_ encryption...but unlike RSA, > > it's totally free of patent baggage (it's the first one to have its patent > > expire..I think it's been free since some time in 97). While RSA gets its > > strength from the difficulty of factoring large primes, El Gamal is based > > on discrete logs. I forget, but I think that PGP 5.x and up might use El I think those facts are correct. El Gamal is also subject to stronger mathematical proof of its security. It's been proven that if you can break El Gamal then you can do discrete logarithms; it is *not* certain that you must factor to break RSA (in fact, there was an article about this just now in the latest _Science News_). So the possibility exists that RSA could be broken more easily than by factoring; this argues for El Gamal being stronger. El Gamal is the preferred choice of the several supported by GNU Privacy Guard (to which I contributed code). My own instinctive reaction still favors RSA just because it seems simpler to me, and I think any results against it would then have to be more general, i.e. less likely to happen. But that's not really a very scientific argument; the engineering considerations, especially patents, make El Gamal look like the best choice. > > - Architecture changes/extensions? If a public-key based > > cryptosystem is in place, there will have to be some kind of > > infrastructure to deal with key distribution/management. This is not > > really too nasty, I think...but the one nasty thing I haven't thought of > > how to handle yet is how to totally avoid (or keep to a BARE minimum) the > > authentication between client and server...I'd like to keep pretty much > > all authentication between client->client (with the server just acting as > > an intermediary)...but I fear that you'll need server-client authetication > > at each step to prevent a man-in-the-middle attack...but the problem is, Not really, if the client-to-client authentication is carried through *every single communication between clients*... i.e. in your initial signature/handshake/etc., you agree on a secret MAC (message authentication check) and you use it on all subsequent messages. A man in the middle can't forge the MAC. The only problem is knowing that the public key you used for the initial handshake really belonged to the right person; that requires, as you say, some kind of key authentication mechanism. (I don't like the word "infrastructure" because that seems to imply an hierarchical structure.) I'd prefer to see some kind of web-of-trust similar to PGP. Ideally, it should be easy to transfer trust from existing PGP (and, better, GPG, plug plug) trust networks. For instance, you could spit out a Jabber public key as text, sign it with another product, and send it off to a recipient who could say, "I trust this signature, so I'll trust that this key is real". From owner-jdev@jabber.org Tue Feb 23 12:04:57 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA25439 for jdev-list; Tue, 23 Feb 1999 12:04:57 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id MAA25436 for ; Tue, 23 Feb 1999 12:04:55 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id NAA20837 for ; Tue, 23 Feb 1999 13:04:24 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id NAA08458 for ; Tue, 23 Feb 1999 13:04:23 -0500 (EST) From: "Thomas Charron" To: Subject: RE: [JDEV] Well-formed XML.(Correction) Date: Tue, 23 Feb 1999 13:26:14 -0500 Message-ID: <000201be5f59$ff3453a0$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of > Jeremie > Subject: RE: [JDEV] Well-formed XML.(Correction) Alrighty, additional questions regarding the XML conversations (See Below).. Will this part: be sent with each data exchange, or ONLY to register this data on the first connection? Also, I'm taking for granted that the servers response would include: As another simple question, shouldn't the transport be reporting: so as to distinguish 'client', 'transport', and 'server'? Hypothetically, one could build a client as a transport (I'm not saying I can think of a reason to DO that, but I'm sure someone may think of one..) This would also keep a firm distinction in the type of connections (Such as another server contacting a transport directly..) This would also ease the ability to merge a server and a transport into one daemon, such as is requested on jaber.org (Easy to install server for ISP's with one executable). Basically, one would only need to use the tags to tell if it's a client, transport, or another server connecting, also allowing the above to only use one port (Once again, easing development and administration, only having to deal with one port) I'm blabbering (Or should I say Jabbering?) again, aren't I? ;-P -- Thomas Charron > > protocol="19990101"> > > jeremie > Ph0niks > jabalot > > > This is my status > 10 > normal > > > > Jer > > On Fri, 19 Feb 1999, Thomas Charron wrote: > > > A quick correction to something I wrote earlier.. I MEANT if the > > transactions would look like this: > > > > > > > protocol="19990101"> > > > > jeremie > > Ph0niks > > jabalot > > > > > > > > > protocol="19990101"> > > > > This is my status > > 10 > > normal > > > > > > > > (Notice the xml version declerations multiple times..) If you > are going to > > transaction based XML, adding the xml version statment at the > start of each > > XML transaction would allow for a greater flexibility in what > XML parser to > > use, as many use this as part of validation.. > > > From owner-jdev@jabber.org Tue Feb 23 12:52:37 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA25622 for jdev-list; Tue, 23 Feb 1999 12:52:37 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id MAA25619 for ; Tue, 23 Feb 1999 12:52:35 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id NAA06569 for ; Tue, 23 Feb 1999 13:52:04 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id NAA28389 for ; Tue, 23 Feb 1999 13:52:04 -0500 (EST) From: "Thomas Charron" To: "Jabber Development" Subject: [JDEV] FIX in io.c Date: Tue, 23 Feb 1999 14:13:57 -0500 Message-ID: <000301be5f60$a984bba0$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org I just stumbled accross a comment in io.c in the lib/common directory.. /* There has got to be a better way to do this! */ old = c->buff; c->buff = malloc(strlen(c->buff) + strlen(buffer) + 1); c->buff[0] = '\0'; strcpy(c->buff, old); free(old); strcat(c->buff, buffer); There is a better way.. ;-P realloc(c->buff, strlen(c->buff) + strlen(buffer) + 1); strcat(c->buff, buffer); MUCH prettier, isn't it?? ;-P Under Unix do a man malloc, it explains realloc fairly well.. realloc does exactly what you where doing, but in a much less overhead way.. -- Thomas Charron United Parcel Service Northeast Region IE Software Developer "Moving at the speed of a T3 Trunk Line!" From owner-jdev@jabber.org Tue Feb 23 13:00:30 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA25672 for jdev-list; Tue, 23 Feb 1999 13:00:30 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from xavier.ups.com (xavier.ups.com [198.80.14.117]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id NAA25669 for ; Tue, 23 Feb 1999 13:00:28 -0600 Received: from revere2.telecom.ups.com (smtp.field2.ups.com [153.2.0.50]) by xavier.ups.com (8.9.1a/8.9.1/UPS) with ESMTP id NAA09098 for ; Tue, 23 Feb 1999 13:59:55 -0500 (EST) Received: from tarot.nhl02.us.ups.com ([10.94.34.20]) by revere2.telecom.ups.com (8.8.7/UPS) with SMTP id NAA01570 for ; Tue, 23 Feb 1999 13:59:54 -0500 (EST) From: "Thomas Charron" To: "Jabber Development" Subject: [JDEV] FIX in io.c (TOM do DUMMY..;-P ) Date: Tue, 23 Feb 1999 14:21:48 -0500 Message-ID: <000401be5f61$c1d23d80$14225e0a@tarot.nhl02.us.ups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org (Resent due to recessive stupid genes temporarily taking over control) (ReRead the source snippet ;-P ) I just stumbled across a comment in io.c in the lib/common directory.. /* There has got to be a better way to do this! */ old = c->buff; c->buff = malloc(strlen(c->buff) + strlen(buffer) + 1); c->buff[0] = '\0'; strcpy(c->buff, old); free(old); strcat(c->buff, buffer); There is a better way.. ;-P (Note the change in the first line over first message) c->buff = realloc(c->buff, strlen(c->buff) + strlen(buffer) + 1); strcat(c->buff, buffer); MUCH prettier, isn't it?? ;-P Under Unix do a man malloc, it explains realloc fairly well.. realloc does exactly what you where doing, but in a much less overhead way.. The only time that this would be REALLY BAD is if realloc fails, c->buff is now NULL, but heck, your initial source didn't check for the failure, so why should mine.. ;-P It really should be checked, though.. At least send a message of some sort of a bad error to the client, and drop the connection.. Actually, one COULD hypothetically crash the server this way.. On a machine with 32 megs free, send 33 megs to the socket.. Eventually, becouse of the above malloc or realloc routines, 'KABOOM!!' ;-P -- Thomas Charron United Parcel Service Northeast Region IE Software Developer "Moving at the speed of a T3 Trunk Line!" From owner-jdev@jabber.org Thu Feb 25 14:55:32 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA01439 for jdev-list; Thu, 25 Feb 1999 14:55:32 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA01436 for ; Thu, 25 Feb 1999 14:55:30 -0600 Date: Thu, 25 Feb 1999 14:55:29 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: Jabber Development Subject: Re: [JDEV] FIX in io.c (TOM do DUMMY..;-P ) In-Reply-To: <000401be5f61$c1d23d80$14225e0a@tarot.nhl02.us.ups.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Ya know, it's strange but when I wrote this code(last summer) I tried using realloc but couldn't get it to work at all, but I was learning C at the time and was probably doing something wrong which I'm not remembering. The code below is going away anyway, but I'll try using realloc in other places again :) Jer On Tue, 23 Feb 1999, Thomas Charron wrote: > (Resent due to recessive stupid genes temporarily taking over control) > (ReRead the source snippet ;-P ) > > I just stumbled across a comment in io.c in the lib/common directory.. > > /* There has got to be a better way to do this! */ > old = c->buff; > c->buff = malloc(strlen(c->buff) + strlen(buffer) + 1); > c->buff[0] = '\0'; > strcpy(c->buff, old); > free(old); > strcat(c->buff, buffer); > > There is a better way.. ;-P (Note the change in the first line over first > message) > > c->buff = realloc(c->buff, strlen(c->buff) + strlen(buffer) + 1); > strcat(c->buff, buffer); > > MUCH prettier, isn't it?? ;-P Under Unix do a man malloc, it explains > realloc fairly well.. realloc does exactly what you where doing, but in a > much less overhead way.. The only time that this would be REALLY BAD is if > realloc fails, c->buff is now NULL, but heck, your initial source didn't > check for the failure, so why should mine.. ;-P It really should be > checked, though.. At least send a message of some sort of a bad error to > the client, and drop the connection.. > > Actually, one COULD hypothetically crash the server this way.. On a > machine with 32 megs free, send 33 megs to the socket.. Eventually, becouse > of the above malloc or realloc routines, 'KABOOM!!' ;-P > > -- > Thomas Charron > United Parcel Service > Northeast Region > IE Software Developer > "Moving at the speed of a T3 Trunk Line!" > From owner-jdev@jabber.org Thu Feb 25 15:16:18 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA01662 for jdev-list; Thu, 25 Feb 1999 15:16:18 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id PAA01658 for ; Thu, 25 Feb 1999 15:16:16 -0600 Date: Thu, 25 Feb 1999 15:16:16 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: RE: [JDEV] Well-formed XML.(Correction) In-Reply-To: <000201be5f59$ff3453a0$14225e0a@tarot.nhl02.us.ups.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > Will this part: > > > > be sent with each data exchange, or ONLY to register this data on the first > connection? It is sent upon the initial connection, it starts the communication with the server. The connection stops with , the entire process looks/acts just like a normal XML "document". > Also, I'm taking for granted that the servers response > would include: > > Yup. > As another simple question, shouldn't the transport be reporting: > > protocol="19990101"> It's not really necessary, since clients and transports use different ports(clients connect on 5222 and transports on 5269). Jer From owner-jdev@jabber.org Thu Feb 25 15:18:50 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA01690 for jdev-list; Thu, 25 Feb 1999 15:18:50 -0600 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from localhost (jeremie@localhost) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id PAA01687 for ; Thu, 25 Feb 1999 15:18:49 -0600 Date: Thu, 25 Feb 1999 15:18:48 -0600 (EST) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] Sources trees, CVS, and other ramblings.. In-Reply-To: <000201be5f4b$f3a33d20$14225e0a@tarot.nhl02.us.ups.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > Well, I guess my next question would be is if we have any sort of tentative > date for a working server that will use this protocol? My suggestion would > be to get the transport using it for the client connections first, so anyone > workingon clients can get their act together the fastest.. It's always been "tomorrow" but I've barely had a chance to sit down and catch up on email(obviously) in the last month... things seem to be slowing down a bit though, so hopefully we'll see something this weekend! > Also, I know there was mention of a CVS archive.. How often is it updated > on the server side? Looking at the snaps on jabber.org, it appears to only > be updated every so often. Also I'd be interested in checking things in > once I have these C++ classes ironed out. I'm attempting to remove all > dependencies on MFC so that they would be much more cross platform. (IF > anyone has plugin replacements for CString and CAsyncSocket, Email me, we'll > do lunch!! ;-P) It's updated nightly, but there hasn't been all that much activity over the last month. After I get some of the new XML stuff done and checked in, things will start picking up dramatically. Jer