From owner-jdev@jabber.org Sat May 1 11:12:17 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA20061 for jdev-list; Sat, 1 May 1999 11:12:17 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-12.dialup.netins.net [209.152.71.141]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA20058 for ; Sat, 1 May 1999 11:12:14 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id JAA07964 for ; Sat, 1 May 1999 09:12:54 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 1 May 1999 09:12:53 -0500 (CDT) From: Jeremie To: Jabber Development Subject: Re: [JDEV] 0.6 release.. In-Reply-To: <000901be9346$7b1f5f80$62205e0a@tarot.telecom.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 > I DO have a small suggestion as far as the 0.6 release.. Let's not throw > it up on slashdot all that quick.. ;-P I'll have a Windows client read by > Monday to be in the package, but I think we should seewhat's obviouse first. Ahh... don't worry, it won't be showing up on /. any time soon... Rob is adamently against posting stories about software and new versions and stuff unless it is a BIG thing(mozilla, linux, WordPerfect, etc) or it's a new announcement. Heck, I had to send him a laptop to get him to post the original Jabber announcement, *grin*. IMHO Jabber has some fairly serious consequences, and we should be able to get a 1.0 announcement posted(I've still got some pull from the laptop :) when it's ready. > If it shows up on slashdot to much, aka, every release, people will look at > it what we hit 1.0 at say.. 'Oh, I looked at that thing a while ago,it > didn;t support x or y or z. Peice of junk..'.. Yup, we'll be waiting for the 1.0 release to do a major major announcement methinks. Jer From owner-jdev@jabber.org Sat May 1 11:24:23 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA20154 for jdev-list; Sat, 1 May 1999 11:24:23 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-12.dialup.netins.net [209.152.71.141]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA20151 for ; Sat, 1 May 1999 11:24:20 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id JAA07969 for ; Sat, 1 May 1999 09:24:58 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 1 May 1999 09:24:58 -0500 (CDT) From: Jeremie To: Jabber Development Subject: Re: [JDEV] 0.6 release.. 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 > you're right. ;) but it's a paradox. without people, the code is hard to > debug, few patches received, and too little new ideas/comments. with > people, when they don't like a release, some of them just throw the whole > project out the window, and they tell this all people around them. Well, version announcements will go out to at least: http://freshmeat.net/ http://filewatcher.org/ If anyone has any other suggestions please share! Jer From owner-jdev@jabber.org Sat May 1 11:56:58 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA20298 for jdev-list; Sat, 1 May 1999 11:56:58 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-12.dialup.netins.net [209.152.71.141]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA20295 for ; Sat, 1 May 1999 11:56:54 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id JAA07975 for ; Sat, 1 May 1999 09:57:35 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 1 May 1999 09:57:34 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: RE: [JDEV] Contact Methods In-Reply-To: <000801be9346$0d0e7e40$62205e0a@tarot.telecom.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 > Is this supposed to be a hint to checkin the Windows client exe to cvs? > ;-P Nope, but that would be quite fun! :) > It does, but I think we're talking about taking your idea one step further. > Aka, Using Jabber to maintain contact with anyone in any way that transports > will allow. Aka: > [mishmashSmushSmush] I see where you are going with this, and I totally understand the confusion(especially since you have the perl/pager transport). Lets see.... how can I explain this... hmm... this is going to definately be a FAQ somehow, since it's a natural and easy thing to confuse. A "transport" acts as a gateway between a single Jabber user and another communication medium, so that the Jabber user can communicate transparently with anyone in that medium. The goal/design behind transports isn't to become a gateway or another communication "path" to a Jabber user(even though it feels natural to do this). So, then, if you want to build another alternate "path" to a Jabber user, where do you do it? This is exactly why we have "sessions" :) Any/All paths of communication TO a Jabber user should happen via a client, even if this client is a gateway mechanism such as a pager gateway. Basically, the definition of a "client" is anything that mediates between a Jabber user and the Jabber server, GUI client software, pager gateway, unix shell commands, etc. After you get used to this idea, it starts to make sense and you realize that you have many more features and options this way. Such as, if your Jabber server archives your messages, you might have missed a pager message but it would have been archived automatically just like all of your other messages. When your pager gateway is logged in as one of your sessions, all of your buddies could optionally choose to send that device the message and send you a page, since it shows up automatically underneath your account. You could also have that gateway move up it's session's priority if it sees that you are not online anywhere, so that it can by default deliver your messgaes via pager for you if you so prefer. Does this all make any sense? I know it's confusing, partly because Jabber is so damn extensable, but things start to jive after awhile... A basic rule of thumb: if you want to build a new delivery mechanism to a Jabber user, it should be a client, if you want to build a new delivery mechanism to a group of non-Jabber users, it should be a transport. > Actually, while we're on the topic, is there a way in the status messages > to give 'em a person use name. Aka, perhaps I want my brother in law, > XNateReadX@aol.com simply as 'Nate' in my contact list. How is that done > via the current status system? Kind of like above, how is 'Joe Doe' passed > as a name?(As you can tell, the status box in the current Win32 client > bites.. Working on it this weekend..) Ahh... the id would be "XNateReadX@aol.com" and the nickname for that session would be 'Nate'. Each session can have it's own nickname, and that can be anything. Does this answer your Q? Jer From owner-jdev@jabber.org Sat May 1 12:11:03 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA20423 for jdev-list; Sat, 1 May 1999 12:11:03 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-12.dialup.netins.net [209.152.71.141]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id MAA20420 for ; Sat, 1 May 1999 12:11:00 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id KAA07982 for ; Sat, 1 May 1999 10:11:42 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 1 May 1999 10:11:42 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: RE: [JDEV] Contact Methods 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 > we're REALLY close now. the one problem i have with this diagram is the > pager email address. for all intents and purposes, a SMTP transort could > be used for the 167289@pagers.jabberhost.com (maybe masked as a Pager > entry?), but still vital info regarding a person's pager is given away > (straight email to that pager, etc). if however, the number you are using > here is itself an address for the transport to understand itself, nice. As in my previous message, this is solved via the pager gateway being a client session working on your behalf, the pager number would have been provided when you set up the pager gateway, and is only stored in it's configuration. > the gig is that if i have a pager, i don't want sally in san fran to know > my pager number of ID. i just want certain ppl to have access to it > through jabber (authorize on add?) and others who i know won't abuse it to > have the actual phone number. Firstly, only people on your roster would be able to even see your pager gateway and address a message to it. The pager gateway could also provide additional security and only accept messages from certian users or deny certian users. > this is interesting.. i originally thought it would be more elegant to > have a Name directly linked to a jabber ID (or not linked to one at all if > that person didn't have a jabber account). Well, the "name" would be the nickname on that session/account, and the Jabber ID would be the unique central identifier for that account. > if Joe Doe doesn't have a jabber address, but only a ICQ number we add him > with primary address being his ICQ number@ICQ. when he does finally get a > jabber address (cos he's heard so much about jabber ;) then the server > automagically switches the primary address for this user (or does this > happen as one of the user's prefs?). No automation would happen here... somehow he'd have to tell you that he's on Jabber or send you a message via Jabber. All the ICQ stuff would still work just fine though and you'd probably never know the change happened. But, after you add him as a Jabber user, all communication should/would happen via that :) I don't want to and am not trying to knock down anyone's ideas, it's just that I believe we already have all of the solutions here... it's just a large enough project that it's hard to see that the solutions are already there or where they are... actually, it's damn hard to see them if they are not documented anywhere(as this isn't), *grin* Jer From owner-jdev@jabber.org Sat May 1 13:16:53 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA20795 for jdev-list; Sat, 1 May 1999 13:16:53 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-12.dialup.netins.net [209.152.71.141]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id NAA20792 for ; Sat, 1 May 1999 13:16:50 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id LAA09440 for ; Sat, 1 May 1999 11:17:32 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 1 May 1999 11:17:31 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] Jabber DOM Proposal In-Reply-To: <002d01be93b6$247215e0$1e04a8c0@na.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 > This will change... :) Still working it out in my head...The way the > interface is setup right now, it's not gonna correctly parse certain things > like: > > data1databolddata2 > > would wind up being.. > > Tag(tag, Children(b), Datum(data1data2)) > > which obviously isn't right... :) Not right, but on the other hand, there is nowhere that this happens in the protocol. BUT, there might be an issue if a client is using something like that in an structure and needs to parse it properly. Basically, at this point I'd say what you have is great API-wise, and you can leave this out... but when someone needs it a couple of extra functions can be added to extract it. BUT, the structs will need to store this, similiar to how xpt handles it now. > >Are we missing?: > > 1.1) Name : String > >*g* > > Actually, no. The Name is stored in the NodeList. :) It's more efficient > this way. Remember, a Node is *never* (I'm pretty sure :)) stored without a > NodeList. Hrm... ok :) > Well, we get a lot of benefits from using AVL trees for this stuff. That > getTag() method you liked so much, is dependent on the DOM having the data > already organized by name. Memory wise, an AVL tree is the same size as a > linked list, and insertion time is minimally slower than a standard linked > list insertion on a small list. I'm still trying to decide if that's the way > to go, though. :) Probably what I'll do initially is implement a linked list > and set it up so I can easily plug-in a more efficient data structure > later -- after we've determined it's really needed. :) Cool, sounds great, and if AVL trees are that slick I guess why not use them! > >So when are you going to be checking it in? Hehe :) > > Soon. :) Neato! Jer From owner-jdev@jabber.org Sat May 1 14:37:13 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA21356 for jdev-list; Sat, 1 May 1999 14:37:13 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from mom.hooked.net (root@mom.hooked.net [206.80.6.10]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id OAA21353 for ; Sat, 1 May 1999 14:37:11 -0500 Received: from ankle.spine.com (mail@korea-142.ppp.hooked.net [206.169.225.142]) by mom.hooked.net (8.8.6/8.8.5) with ESMTP id LAA22455 for ; Sat, 1 May 1999 11:37:05 -0700 (PDT) Received: from jesse by ankle.spine.com with local (Exim 2.05 #1 (Debian)) id 10dedN-0003q8-00; Sat, 1 May 1999 11:37:05 -0700 Date: Sat, 1 May 1999 11:37:05 -0700 From: Jesse Montrose To: jdev@jabber.org Subject: [JDEV] jabber names Message-ID: <19990501113704.F13636@ankle.uplanet.com> Mail-Followup-To: jdev@jabber.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org I'm probably too late (catching up on old mail) but here are some ideas: I especially like this one: >From Webster's Revised Unabridged Dictionary (1913) [web1913]: 'Twixt \'Twixt\ An abbreviation of {Betwixt}, used in poetry, or in colloquial language. and some random bits: nexus (fun when we hit version 6 (nexus6 in blade runner)) babel (too bad altavista got babelfish) tob/toby (tower of babel) rosetta (perfect metaphor) switchboard switchbox liason middleman xmissive From owner-jdev@jabber.org Sat May 1 19:10:54 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id TAA22295 for jdev-list; Sat, 1 May 1999 19:10:54 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-12.dialup.netins.net [209.152.71.141]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id TAA22292 for ; Sat, 1 May 1999 19:10:51 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id RAA10022 for ; Sat, 1 May 1999 17:11:37 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 1 May 1999 17:11:36 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] jabber names In-Reply-To: <19990501113704.F13636@ankle.uplanet.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 Yeah, I renamed it already, but I've already saved this message for future reference for Jabber things and for names for servers in at work, cool stuff! :) Jer On Sat, 1 May 1999, Jesse Montrose wrote: > I'm probably too late (catching up on old mail) but here are some ideas: > > I especially like this one: > > > >From Webster's Revised Unabridged Dictionary (1913) [web1913]: > > 'Twixt \'Twixt\ > An abbreviation of {Betwixt}, used in poetry, or in > colloquial language. > > and some random bits: > > nexus (fun when we hit version 6 (nexus6 in blade runner)) > babel (too bad altavista got babelfish) > tob/toby (tower of babel) > rosetta (perfect metaphor) > switchboard > switchbox > liason > middleman > xmissive > From owner-jdev@jabber.org Sat May 1 22:25:20 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id WAA22873 for jdev-list; Sat, 1 May 1999 22:25:20 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from chimera.acm.jhu.edu (mail@chimera.acm.jhu.edu [128.220.223.63]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id WAA22870 for ; Sat, 1 May 1999 22:25:18 -0500 Received: from localhost (cklempay@localhost) by chimera.acm.jhu.edu (8.9.3/8.9.3/asi-redhat) with ESMTP id WAA03575 for ; Sat, 1 May 1999 22:25:15 -0400 Date: Sat, 1 May 1999 22:25:14 -0400 (EDT) From: "Corbett J. Klempay" To: jdev@jabber.org Subject: [JDEV] module method 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 Looking at mod_test..I see the init function...are we just allowed to add functions as we need them? I kind of need a void mod_digsig_exit(xpt *config) function, as cryptlib has a function that should be called on shutdown of the program. ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www.acm.jhu.edu/~cklempay "A commune is where people join together to share their lack of wealth." ------------------------------------------------------------------------------ From owner-jdev@jabber.org Sun May 2 00:43:17 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id AAA23473 for jdev-list; Sun, 2 May 1999 00:43:17 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-47.dialup.netins.net [209.152.71.176]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id AAA23469 for ; Sun, 2 May 1999 00:43:14 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id WAA10277 for ; Sat, 1 May 1999 22:44:03 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 1 May 1999 22:44:02 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] module method 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 Ahh... exiting... Look for an exit phase in the API in version 0.7, you can create your function, but it just won't work yet if that's ok :) Jer On Sat, 1 May 1999, Corbett J. Klempay wrote: > Looking at mod_test..I see the init function...are we just allowed to add > functions as we need them? I kind of need a > void mod_digsig_exit(xpt *config) > function, as cryptlib has a function that should be called on shutdown of > the program. > > ------------------------------------------------------------------------------ > Corbett J. Klempay Quote of the Week: > http://www.acm.jhu.edu/~cklempay "A commune is where people join > together to share their lack of > wealth." > ------------------------------------------------------------------------------ > From owner-jdev@jabber.org Sun May 2 01:14:38 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id BAA23762 for jdev-list; Sun, 2 May 1999 01:14:38 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from chimera.acm.jhu.edu (mail@chimera.acm.jhu.edu [128.220.223.63]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id BAA23759 for ; Sun, 2 May 1999 01:14:35 -0500 Received: from localhost (cklempay@localhost) by chimera.acm.jhu.edu (8.9.3/8.9.3/asi-redhat) with ESMTP id BAA04779 for ; Sun, 2 May 1999 01:14:27 -0400 Date: Sun, 2 May 1999 01:14:27 -0400 (EDT) From: "Corbett J. Klempay" To: jdev@jabber.org Subject: [JDEV] Scaling 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 Do we have any kind of goals for what kind of client load we want the servers to be able to scale up to? I'm wondering right now as I am doing a function in mod_digsig to generate a new key pair to be issued to a client (this is done one time; this basically gives them their public/private keypair they use from then on). The default is 1024 bit (pretty sure; it's in the documentation somewhere...I seem to remember that's what the ElGamal default is) and takes anywhere from 2-9 seconds (rough measurement of me putting printf's before and after and counting out loud :), totally varying on the nature of what the key's components ended up being. This is on a PPro 200. Sure, issuing an initial key pair doesn't happen very much _per client_ (like just 1 time, basically), but if your servers are as heavily loaded as, say, icq.mirabilis.com, it might be an issue. Also, I have yet to measure the time it takes to verify a signature, as a verification will happen at secure logins. (which will be a much more frequent occurence than key pair generation) Also, as far as legality, does anyone know how this works...with cryptlib being developed offshore (New Zealand)...so I have it on my machine now...is it illegal for me to give this code to someone who is offshore (even though it was developed offshore as well)? (in other words, do I have to restrict access to this code, or is it wide open?) ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www.acm.jhu.edu/~cklempay "A commune is where people join together to share their lack of wealth." ------------------------------------------------------------------------------ From owner-jdev@jabber.org Sun May 2 02:03:46 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id CAA23959 for jdev-list; Sun, 2 May 1999 02:03:46 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from hawthorne.com (host-209-214-46-146.pfn.bellsouth.net [209.214.46.146]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id CAA23956 for ; Sun, 2 May 1999 02:03:42 -0500 Received: from hawthorne.com (localhost [127.0.0.1]) by hawthorne.com (8.8.7/8.8.7) with ESMTP id BAA16704 for ; Sun, 2 May 1999 01:04:33 -0500 Message-Id: <199905020604.BAA16704@hawthorne.com> Date: Sun, 2 May 1999 01:04:30 -0500 (CDT) From: dsmith@ai.uwf.edu Subject: [JDEV] Element.h Usage To: jdev@jabber.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Hey... Okay, here's a brief rundown of the elements.h operations and data type... The base type represents an atomic chunk of a XML document. It can be one of three types: 1.) Attribute 2.) Tag 3.) CDATA Each has contains a series of pointers internally that represent the location of the element in the hierarchy of the XML document. Let's parse out a couple of samples and see what we wind up with in terms of elements... To begin, something simple: XML packet: dave dude From owner-jdev@jabber.org Sun May 2 02:50:33 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id CAA24154 for jdev-list; Sun, 2 May 1999 02:50:33 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from hawthorne.com (host-209-214-46-146.pfn.bellsouth.net [209.214.46.146]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id CAA24151 for ; Sun, 2 May 1999 02:50:29 -0500 Received: from hawthorne.com (localhost [127.0.0.1]) by hawthorne.com (8.8.7/8.8.7) with ESMTP id BAA16725 for ; Sun, 2 May 1999 01:51:19 -0500 Message-Id: <199905020651.BAA16725@hawthorne.com> Date: Sun, 2 May 1999 01:51:17 -0500 (CDT) From: dsmith@ai.uwf.edu Subject: [JDEV] *Real* element.h usage doc To: jdev@jabber.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Hey.. Sorry about that other unfinished email..hit the wrong button. :) Here's the real usage doc: -- The element.h header provides a data type , and operations (element_*)for manipulating a parsed XML stream. The base type represent an atomic chunk of a XML stream. It may be one of three types: 1.) Tag 2.) Attribute 3.) CDATA Internally, each type maintains a series of pointers that represent the location of the element in the XML stream's hierarchy. To understand how to use the type and associated operations, let's parse some sample XML streams. We'll use the following notation to represent the element in-memory: Element(type: name: , data: , children: , next: , previous: ) -------------------------------------------------------------------- Example 1: A login packet Consider the following XML stream: dave dude mellow Once parsed, we'll wind up with the following (in a more compact form within memory): Element(type: ETYPE_TAG name: "login", data: NULL, children( Element(type: ETYPE_TAG name: "user", data NULL, Children( Element(type: ETYPE_CDATA name: NULL, data: "dave"))) Element(type: ETYPE_TAG name: "pass", data NULL, Children( Element(type: ETYPE_CDATA name: NULL, data: "dude"))) Element(type: ETYPE_TAG name: "nick", data NULL, Children( Element(type: ETYPE_CDATA name: NULL, data: "mellow"))) )) As you can see, a hierarchy representing the stream is formed. Assume the a variable called "root_tag" contains the root of the hierarchy. To access the nick name CDATA element, you would make the following calls: /* Retrieve element by name of "nick" */ element nick_tag = element_get_child(root_tag, "nick"); /* Retrieve first child of nick_tag (since name is not specified) */ element nick_tag_CDATA = element_get_child(nick_tag, ""); /* Retrieve data in CDATA element; must cast to char* since it may contain any type of data */ char* nickname = (char*)element_data(nick_tag_CDATA) /* nickname == "mellow" */ Obviously, this is a drawn out approach. However, it demonstrates the way that CDATA elements are not an actual part of the tag, but rather a full-blown sub-element. This approach is necessary since a given tag may have multiple CDATA sections seperated by other sub-tags. This will be demonstrated later on. Since it is fairly common to have tags which only have one unbroken CDATA section, a shortcut method is provided that retrieves the CDATA in one call: char* nickname = element_get_child_cdata(root_tag, "nick"); /* nickname == "mellow" */ This searches the root_tag for an element by the name of "nick" and sees if it (the element named "nick") has a CDATA as the first child. more later... D. From owner-jdev@jabber.org Sun May 2 13:18:12 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA26646 for jdev-list; Sun, 2 May 1999 13:18:12 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-47.dialup.netins.net [209.152.71.176]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id NAA26643 for ; Sun, 2 May 1999 13:18:09 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id LAA12064 for ; Sun, 2 May 1999 11:19:09 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sun, 2 May 1999 11:19:08 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] Scaling 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 > Do we have any kind of goals for what kind of client load we want the > servers to be able to scale up to? I'm wondering right now as I am doing > a function in mod_digsig to generate a new key pair to be issued to a > client (this is done one time; this basically gives them their > public/private keypair they use from then on). The default is 1024 bit > (pretty sure; it's in the documentation somewhere...I seem to remember > that's what the ElGamal default is) and takes anywhere from 2-9 seconds > (rough measurement of me putting printf's before and after and counting > out loud :), totally varying on the nature of what the key's components > ended up being. This is on a PPro 200. Sure, issuing an initial key pair > doesn't happen very much _per client_ (like just 1 time, basically), but > if your servers are as heavily loaded as, say, icq.mirabilis.com, it might > be an issue. Also, I have yet to measure the time it takes to verify a > signature, as a verification will happen at secure logins. (which will be > a much more frequent occurence than key pair generation) Right now that could be a performance issue, but that should be solved before 1.0 since we are moving to a threaded model. You should be able to create a keygen thread and just queue up requests on it... this way if for some reason 100 registration requests come in within a minute you won't overload the server, it will just take some time before the last ones get their key. The goal right now is to make everything functional on a small scale and stabalize the APIs, then focus will shift onto threads/performance as the rest of the world starts building up transports, modules, and clients. > Also, as far as legality, does anyone know how this works...with cryptlib > being developed offshore (New Zealand)...so I have it on my machine > now...is it illegal for me to give this code to someone who is offshore > (even though it was developed offshore as well)? (in other words, do I > have to restrict access to this code, or is it wide open?) IANAL, so I can't help ya much there :) Jer From owner-jdev@jabber.org Sun May 2 13:23:40 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA26689 for jdev-list; Sun, 2 May 1999 13:23:40 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-47.dialup.netins.net [209.152.71.176]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id NAA26685 for ; Sun, 2 May 1999 13:23:36 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id LAA12069 for ; Sun, 2 May 1999 11:24:35 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sun, 2 May 1999 11:24:35 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] *Real* element.h usage doc In-Reply-To: <199905020651.BAA16725@hawthorne.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 Everything else looks happy, here's a quickie note: > Since it is fairly common to have tags which only have one unbroken > CDATA section, a shortcut method is provided that retrieves the CDATA > in one call: > > char* nickname = element_get_child_cdata(root_tag, "nick"); > /* nickname == "mellow" */ > > This searches the root_tag for an element by the name of "nick" and > sees if it (the element named "nick") has a CDATA as the first child. Just as an FYI: this is some text Can(and often does) get parsed by Expat into: Element "tag" CDATA "this is som" CDATA "e " CDATA "text" It will break a string into multiple CDATA sections, this is just a normal part of sream-based XML processing... All it requires is for element_get_child_cdata() to have a bit more smarts :) Jer From owner-jdev@jabber.org Sun May 2 13:28:44 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA26732 for jdev-list; Sun, 2 May 1999 13:28:44 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-47.dialup.netins.net [209.152.71.176]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id NAA26729 for ; Sun, 2 May 1999 13:28:42 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id LAA12074 for ; Sun, 2 May 1999 11:29:43 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sun, 2 May 1999 11:29:43 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: [JDEV] 0.6 FYI 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 Just to keep everyone up to date here, most of the functionality for 0.6 is checked into CVS, but were going to take a few days to a week here to do full testing and most importantly, to create a rock-solid and complete distribution that is ready to install/run/use. So it will be a few days before 0.6 yet, but this release should be very solid, documented, and ready to start building on! Jer From owner-jdev@jabber.org Sun May 2 14:36:14 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA27118 for jdev-list; Sun, 2 May 1999 14:36:14 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from hawthorne.com (host-209-214-46-116.pfn.bellsouth.net [209.214.46.116]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id OAA27115 for ; Sun, 2 May 1999 14:36:10 -0500 Received: from hawthorne.com (localhost [127.0.0.1]) by hawthorne.com (8.8.7/8.8.7) with ESMTP id NAA00506 for ; Sun, 2 May 1999 13:37:03 -0500 Message-Id: <199905021837.NAA00506@hawthorne.com> Date: Sun, 2 May 1999 13:37:03 -0500 (CDT) From: dsmith@ai.uwf.edu Subject: Re: [JDEV] *Real* element.h usage doc To: jdev@jabber.org 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 On 2 May, Jeremie wrote: > Everything else looks happy, here's a quickie note: > > Can(and often does) get parsed by Expat into: > > Element "tag" > CDATA "this is som" > CDATA "e " > CDATA "text" > > It will break a string into multiple CDATA sections, this is just a normal > part of sream-based XML processing... > Yeah, that's correct. The W3C DOM (and ours,soon) handles this by merging adjacent CDATA sections, on CDATA insertion into the DOM tree. Really, the element.h is just the basic storage and manipulation routines for dealing with elements. I'll probably move the element_get_child_cdata (and adjacent CDATA merging) to a higher level of abstraction since it's not really a basic manipulation. Hopefully tonight I'll be able to start writing the next layer that will integrate expat for packet level parsing... :) I also want to try out the latest stuff you've committed. Sounds great. :) D. From owner-jdev@jabber.org Sun May 2 17:08:11 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id RAA27755 for jdev-list; Sun, 2 May 1999 17:08:11 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-47.dialup.netins.net [209.152.71.176]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id RAA27752 for ; Sun, 2 May 1999 17:08:08 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id PAA12897 for ; Sun, 2 May 1999 15:09:11 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sun, 2 May 1999 15:09:10 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] *Real* element.h usage doc In-Reply-To: <199905021837.NAA00506@hawthorne.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 > Yeah, that's correct. The W3C DOM (and ours,soon) handles this by > merging adjacent CDATA sections, on CDATA insertion into the DOM tree. > Really, the element.h is just the basic storage and manipulation > routines for dealing with elements. I'll probably move the > element_get_child_cdata (and adjacent CDATA merging) to a higher level > of abstraction since it's not really a basic manipulation. I was going to do that(merge CDATA together during parsing)... actually, I don't know why I didn't, lazy I guess :) > Hopefully tonight I'll be able to start writing the next layer that > will integrate expat for packet level parsing... :) That should be easy stuff... take a look at the xpt Expat handlers, yours will be almost identical. The only funky thing I'm doing is the two-teir parsing via xptpool, where you are "packetizing" the branch of tags under the root tag. Let me know if you have any ?s, I'll be busy on other things for a while yet, but will be happy to help after 0.6... > I also want to try out the latest stuff you've committed. Sounds great. > :) After the last batch of checkins I just did, the only major stuff I have to really look at seriously and hook up are status-related issues. Then I'll be updating the little CLI test client and go into major testing mode. Jer From owner-jdev@jabber.org Mon May 3 00:49:17 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id AAA29676 for jdev-list; Mon, 3 May 1999 00:49:17 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from hawthorne.com (host-209-214-46-19.pfn.bellsouth.net [209.214.46.19]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id AAA29673 for ; Mon, 3 May 1999 00:49:13 -0500 Received: from hawthorne.com (localhost [127.0.0.1]) by hawthorne.com (8.8.7/8.8.7) with ESMTP id XAA00463 for ; Sun, 2 May 1999 23:50:06 -0500 Message-Id: <199905030450.XAA00463@hawthorne.com> Date: Sun, 2 May 1999 23:50:06 -0500 (CDT) From: dsmith@ai.uwf.edu Subject: [JDEV] Some jibberish...er...jabberish philosophy.. :) To: jdev@jabber.org 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 On 2 May, Jeremie wrote: > I was going to do that(merge CDATA together during parsing)... actually, I > don't know why I didn't, lazy I guess :) You lazy bum. It's not like you *ever* put any time into coding...:) > That should be easy stuff... take a look at the xpt Expat handlers, yours > will be almost identical. The only funky thing I'm doing is the two-teir > parsing via xptpool, where you are "packetizing" the branch of tags under > the root tag. Let me know if you have any ?s, I'll be busy on other > things for a while yet, but will be happy to help after 0.6... Hmm...I've been thinking about this. I think I'm going to take a little different approach (at least, based on my limited understanding of xpt_pool). I'm going to try and use a stack to keep track of new tags and data. Lemme toss this out on the table for consideration... XMLstream(s)... If you consider the nature of Jabber, it can really be summed up as the exchange and translation of XML streams between mediums (and, of course, *as* a medium). It doesn't really matter if it originates from disk I/O, network I/O, database...you get the picture. It can all be summarized as a stream of XML data. So then, a XMLstream would be a data structure that contains all the methods necessary for taking a stream of XML data and reconsituting into a data structure, and then if necessary, back to a XML stream. It would contain the expat parser, a packet stack for keeping track of packet's being assembled, and a packet queue for keeping complete packets in. Additionally, it could maintain a series of function pointers to callback functions so that when packets are ready, the user/lib is notified and can proceed accordingly. Overall, the XMLstream would be independent of where the data is coming from, it would only be interested in getting the data. Okay..brain is dead. More later. I gotta get up at 06.00 tommorow. blech. D. From owner-jdev@jabber.org Mon May 3 01:36:30 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id BAA29870 for jdev-list; Mon, 3 May 1999 01:36:30 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-23.dialup.netins.net [209.152.71.152]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id BAA29867 for ; Mon, 3 May 1999 01:36:27 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id XAA13672 for ; Sun, 2 May 1999 23:37:35 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sun, 2 May 1999 23:37:34 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] Some jibberish...er...jabberish philosophy.. :) In-Reply-To: <199905030450.XAA00463@hawthorne.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 > XMLstream(s)... > > If you consider the nature of Jabber, it can really be summed up as the > exchange and translation of XML streams between mediums (and, of course, > *as* a medium). It doesn't really matter if it originates from disk I/O, > network I/O, database...you get the picture. It can all be summarized as > a stream of XML data. So then, a XMLstream would be a data structure > that contains all the methods necessary for taking a stream of XML data > and reconsituting into a data structure, and then if necessary, back to > a XML stream. It would contain the expat parser, a packet stack for > keeping track of packet's being assembled, and a packet queue for > keeping complete packets in. Additionally, it could maintain a series of > function pointers to callback functions so that when packets are ready, > the user/lib is notified and can proceed accordingly. Overall, the > XMLstream would be independent of where the data is coming from, it > would only be interested in getting the data. Hmm... sounds very much like xpt_pool, just lots cooler :) Really, all we need is something that can accept incoming strings in bits and peices, and a way of checking for any "packets" waiting to be extracted. The xpt_pool struct handles this now for files and network streams, but could definately use a bit more abstraction as you mention above :) > > Okay..brain is dead. More later. I gotta get up at 06.00 tommorow. > blech. Ditto... *sigh* Jer From owner-jdev@jabber.org Mon May 3 02:15:57 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id CAA30024 for jdev-list; Mon, 3 May 1999 02:15:57 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-23.dialup.netins.net [209.152.71.152]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id CAA30021 for ; Mon, 3 May 1999 02:15:54 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id AAA13731 for ; Mon, 3 May 1999 00:17:03 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Mon, 3 May 1999 00:17:03 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: [JDEV] misc protocol discussion 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 message packets we have the type="" attribute available for special built-in message types, most obviously for errors. And in a status packet we have the same attribute but it's on the tag instead. Would anyone be against moving it up to the status tag to be consistent with message, and it feels more appropriate there anyway: Groovin 10 If everyone is in agreement, I can do this before 0.6. Jer From owner-jdev@jabber.org Mon May 3 02:24:46 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id CAA30071 for jdev-list; Mon, 3 May 1999 02:24:46 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from chimera.acm.jhu.edu (mail@chimera.acm.jhu.edu [128.220.223.63]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id CAA30067 for ; Mon, 3 May 1999 02:24:43 -0500 Received: from localhost (cklempay@localhost) by chimera.acm.jhu.edu (8.9.3/8.9.3/asi-redhat) with ESMTP id CAA09460 for ; Mon, 3 May 1999 02:24:43 -0400 Date: Mon, 3 May 1999 02:24:43 -0400 (EDT) From: "Corbett J. Klempay" To: jdev@jabber.org Subject: Re: [JDEV] misc protocol discussion 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 Sure...consistency is a good thing :) BTW: my crypto project is due in 8.5 hours...I have some skeleton code going...I'm in our ACM lab working on a project for my operating systems class right now, though. All nighters are fun :) I'm going to shift into Computer Integrated Surgery mode (I have a heinous project in there I have to present this Friday), but will be able to grab someone's client code to have an infrastructure present. (right now, there are some parts of the certificate issuing/verifcation process which I just have commented out because they rely on stuff which needs to be passed between the server and client). When I do grab a client to toy with, is there one in particular I should work with? ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www.acm.jhu.edu/~cklempay "A commune is where people join together to share their lack of wealth." ------------------------------------------------------------------------------ On Mon, 3 May 1999, Jeremie wrote: > In message packets we have the type="" attribute available for > special built-in message types, most obviously for errors. And in a > status packet we have the same attribute but it's on the tag > instead. Would anyone be against moving it up to the status tag to be > consistent with message, and it feels more appropriate there anyway: > > Groovin > 10 > > > If everyone is in agreement, I can do this before 0.6. > > Jer > > From owner-jdev@jabber.org Mon May 3 08:40:46 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id IAA31183 for jdev-list; Mon, 3 May 1999 08:40:46 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from ins3.netins.net (root@ins3.netins.net [167.142.225.3]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id IAA31180 for ; Mon, 3 May 1999 08:40:44 -0500 Received: from worf.netins.net (jeremie@worf.netins.net [167.142.225.4]) by ins3.netins.net (8.8.7/8.8.7) with SMTP id HAA31470 for ; Mon, 3 May 1999 07:40:39 -0500 Date: Mon, 3 May 1999 07:40:38 -0500 (CDT) From: Jeremie Miller To: jdev@jabber.org Subject: Re: [JDEV] Some jibberish...er...jabberish philosophy.. :) In-Reply-To: <199905031118.GAA03254@hawthorne.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 > I think I oughta make a little note here. I realize alot of the stuff I > throw out as "my ideas" really are just extensions of what's already > out there. I'm not under *any* illusions of grandeur that I'm cooking > up this stuff completely originally. Most of the time, I'm just looking > at what you've already done and abstracting/amalagating it into a more > cohesive concept... It definately needs it, so feel free to abstract away! :) > It's easy to come up with "cool" ideas when you've got awesome raw > material to work with. :) Thanks! > Just a little credit, where credit is due.:) Then, I also must give credit to: Rob Zombie(playing now) Crystal Method Korn Propellerheads Shoutcast(et al) Rammstein Massive Attack *grin* Jer From owner-jdev@jabber.org Mon May 3 10:30:57 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id KAA31838 for jdev-list; Mon, 3 May 1999 10:30:57 -0500 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 KAA31835 for ; Mon, 3 May 1999 10:30:52 -0500 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 RAA16081 for ; Mon, 3 May 1999 17:54:17 +0200 (TSI) Received: from [212.31.3.105] by doruk.net.tr (SMI-8.6/SMI-SVR4) id RAA16485; Mon, 3 May 1999 17:24:01 +0300 Date: Mon, 3 May 1999 17:29:36 +0300 (EEST) From: "Kemal 'disq' Hadimli" X-Sender: disq@heart_of_gold.localdomain To: jdev@jabber.org Subject: Re: [JDEV] misc protocol discussion 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 Mon, 3 May 1999, Jeremie wrote: > instead. Would anyone be against moving it up to the status tag to be > consistent with message, and it feels more appropriate there anyway: > > Groovin > 10 > Oh yes! :) bye, disqk MICROS~1 is not the answer. MICROS~1 is the question. NO (or Linux) is the answer. From owner-jdev@jabber.org Mon May 3 11:17:01 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA32127 for jdev-list; Mon, 3 May 1999 11:17:01 -0500 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 LAA32117 for ; Mon, 3 May 1999 11:16:55 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18028 for ; Mon, 3 May 1999 11:16:15 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18020 for ; Mon, 3 May 1999 11:16:14 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id LAA29570 for ; Mon, 3 May 1999 11:16:14 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id LAA29560 for ; Mon, 3 May 1999 11:16:13 -0400 (EDT) From: "Thomas Charron" To: Subject: RE: [JDEV] Contact Methods Date: Mon, 3 May 1999 11:03:42 -0400 Message-ID: <000001be9576$234422a0$62205e0a@tarot.telecom.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > From: owner-jdev@jabber.org On Behalf Of Chase Phillips > Subject: RE: [JDEV] Contact Methods > > +---------------------------------------+ > > | Contact List | > > | + Jane Doe (Jane Doe@jabberhost.com) | > > | - Joe Blow (IWuvJer@aol.com) | > > | `- 167289@pagers.jabberhost.com | > > | - Ant C. Eater (234567@pagers.jabber>| > > +---------------------------------------+ > we're REALLY close now. the one problem i have with this diagram is the > pager email address. for all intents and purposes, a SMTP transort could > be used for the 167289@pagers.jabberhost.com (maybe masked as a Pager > entry?), but still vital info regarding a person's pager is given away > (straight email to that pager, etc). if however, the number you are using > here is itself an address for the transport to understand itself, nice. > the gig is that if i have a pager, i don't want sally in san fran to know > my pager number of ID. i just want certain ppl to have access to it > through jabber (authorize on add?) and others who i know won't abuse it to > have the actual phone number. That could be done, however, I'mnot really seeing the point to limiting it. Once I have your pager number, I can page you3 different ways anyway.. (Shrug) User preference I guess. And actually, my old pager number is 167289, and the transport is at pagers.jabberhost.com.. The transport would know how to page that pager number. I'd say to take care of people getting yourID, we could make it so that alternate addy's have 'permisions' that are protected somehow. That way you could even give your home humber for some'authorized' people.. > > > > > In this diagram, I have the 'Primary address' next to their > names,and > > alternate addy's under.. Notice Joe Blow. I know I can contact him via > > AOL,or his pager. In this case, I DO care HOW ELSE I can reach > him. I may > > not care about what transports Joe Doe uses, but if he tells me > he can also > > be XSexyHoeX@icq.wuvviedovie.com, I want to be able to add that as an > > 'alternate' address, and not have it as another primary address. This > > appears to be what your saying, but the initial question (At > least it's what > > I want to know) is how will the status messages to SHOW this > roster look? > > this is interesting.. i originally thought it would be more elegant to > have a Name directly linked to a jabber ID (or not linked to one at all if > that person didn't have a jabber account). but now, after thinking about > a person only having one contact transport the idea of a Primary address > and then multiple Secondary addresses becomes clearer. > > if Joe Doe doesn't have a jabber address, but only a ICQ number we add him > with primary address being his ICQ number@ICQ. when he does finally get a > jabber address (cos he's heard so much about jabber ;) then the server > automagically switches the primary address for this user (or does this > happen as one of the user's prefs?). > > > [snip] > > > > or this: > > > > > > jenny > > 545212@ICQ > number=1/>jenny > > user@jabber.server.com > > olduser > > > > > > this looks good, but the "number" section does what exactly? if it > specifies the priority of which method of contact to use first, and the > client enforces it, perhaps there's a better way. > > otherwise, if it is something the user sets when maneuvering people around > his/her roster, nice. this would keep the order based on What You Want It > To Be. > > > > > Actually, while we're on the topic, is there a way in the > status messages > > to give 'em a person use name. Aka, perhaps I want my brother in law, > > XNateReadX@aol.com simply as 'Nate' in my contact list. How is > that done > > via the current status system? Kind of like above, how is 'Joe > Doe' passed > > as a name?(As you can tell, the status box in the current Win32 client > > bites.. Working on it this weekend..) > > > > could there be an emergence of a tag with extensions being > Pager="" ICQ="" etc etc: > > Main > \ > Joe Doe > > > or is this inefficient/not needed/too late in the game? i'm sure the > current spec will function wonderfully if so. > > regards, > Chase Phillips > -- > shepard at ameth.org ][ Only you will know > http://www.ameth.org/ ][ if I proofread this > From owner-jdev@jabber.org Mon May 3 11:17:01 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA32126 for jdev-list; Mon, 3 May 1999 11:17:01 -0500 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 LAA32114 for ; Mon, 3 May 1999 11:16:54 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18097 for ; Mon, 3 May 1999 11:16:22 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18084 for ; Mon, 3 May 1999 11:16:21 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id LAA29613 for ; Mon, 3 May 1999 11:16:21 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id LAA29601 for ; Mon, 3 May 1999 11:16:20 -0400 (EDT) From: "Thomas Charron" To: Subject: RE: [JDEV] misc protocol discussion Date: Mon, 3 May 1999 11:03:53 -0400 Message-ID: <000301be9576$28890320$62205e0a@tarot.telecom.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org The command line jabber client would probrably be the easiest to extend IMHO.. > -----Original Message----- > From: owner-jdev@jabber.org On Behalf Of Corbett J. Klempay > Sent: Monday, May 03, 1999 2:25 AM > To: jdev@jabber.org > Subject: Re: [JDEV] misc protocol discussion > > > Sure...consistency is a good thing :) > > BTW: my crypto project is due in 8.5 hours...I have some skeleton code > going...I'm in our ACM lab working on a project for my operating systems > class right now, though. All nighters are fun :) I'm going to shift into > Computer Integrated Surgery mode (I have a heinous project in there I have > to present this Friday), but will be able to grab someone's client code to > have an infrastructure present. (right now, there are some parts of the > certificate issuing/verifcation process which I just have commented out > because they rely on stuff which needs to be passed between the server and > client). > > When I do grab a client to toy with, is there one in particular I should > work with? > > ------------------------------------------------------------------ > ------------ > Corbett J. Klempay Quote of the Week: > http://www.acm.jhu.edu/~cklempay "A commune is where people join > together to share their lack of > wealth." > ------------------------------------------------------------------ > ------------ > > On Mon, 3 May 1999, Jeremie wrote: > > > In message packets we have the type="" attribute available for > > special built-in message types, most obviously for errors. And in a > > status packet we have the same attribute but it's on the tag > > instead. Would anyone be against moving it up to the status tag to be > > consistent with message, and it feels more appropriate there anyway: > > > > Groovin > > 10 > > > > > > If everyone is in agreement, I can do this before 0.6. > > > > Jer > > > > > > From owner-jdev@jabber.org Mon May 3 11:16:59 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA32122 for jdev-list; Mon, 3 May 1999 11:16:59 -0500 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 LAA32112 for ; Mon, 3 May 1999 11:16:51 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18053 for ; Mon, 3 May 1999 11:16:18 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18046 for ; Mon, 3 May 1999 11:16:18 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id LAA29578 for ; Mon, 3 May 1999 11:16:17 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id LAA29574 for ; Mon, 3 May 1999 11:16:17 -0400 (EDT) From: "Thomas Charron" To: Subject: RE: [JDEV] Contact Methods Date: Mon, 3 May 1999 11:03:49 -0400 Message-ID: <000101be9576$263f1320$62205e0a@tarot.telecom.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org (OOpsie didn't respond to everything.. ;-P) > From: owner-jdev@jabber.org On Behalf Of Chase Phillips > Subject: RE: [JDEV] Contact Methods > > +---------------------------------------+ > > | Contact List | > > | + Jane Doe (Jane Doe@jabberhost.com) | > > | - Joe Blow (IWuvJer@aol.com) | > > | `- 167289@pagers.jabberhost.com | > > | - Ant C. Eater (234567@pagers.jabber>| > > +---------------------------------------+ > > In this diagram, I have the 'Primary address' next to their > names,and > > alternate addy's under.. Notice Joe Blow. I know I can contact him via > > AOL,or his pager. In this case, I DO care HOW ELSE I can reach > him. I may > > not care about what transports Joe Doe uses, but if he tells me > he can also > > be XSexyHoeX@icq.wuvviedovie.com, I want to be able to add that as an > > 'alternate' address, and not have it as another primary address. This > > appears to be what your saying, but the initial question (At > least it's what > > I want to know) is how will the status messages to SHOW this > roster look? > this is interesting.. i originally thought it would be more elegant to > have a Name directly linked to a jabber ID (or not linked to one at all if > that person didn't have a jabber account). but now, after thinking about > a person only having one contact transport the idea of a Primary address > and then multiple Secondary addresses becomes clearer. Your seeing whatI'm getting at. I guess I look at things 'people centric', and would like to see them the same way I see things in my little flip book. Person, Primary contact, and a buncha scribbe notes of alternate contacts and the such.. > if Joe Doe doesn't have a jabber address, but only a ICQ number we add him > with primary address being his ICQ number@ICQ. when he does finally get a > jabber address (cos he's heard so much about jabber ;) then the server > automagically switches the primary address for this user (or does this > happen as one of the user's prefs?). I'd say user pref. but that's just my opinion. He may get a jabber ID, but then he decides he friggen hates jabber. All of the sudden he's never at his primary ID.. ;-P > > > > jenny > > 545212@ICQ > number=1/>jenny > > user@jabber.server.com > > olduser > > > this looks good, but the "number" section does what exactly? if it > specifies the priority of which method of contact to use first, and the > client enforces it, perhaps there's a better way. Just a way for a 'priority' of sorts to the contact addy's. Not required, just threw it in there as I was typing.. > otherwise, if it is something the user sets when maneuvering people around > his/her roster, nice. this would keep the order based on What You Want It > To Be. Actually, it could be used like that.. It would STILL be a 'priority' bit of sorts, but user configurable.. It'd have to change a bit, but that's a great idea.. From owner-jdev@jabber.org Mon May 3 11:17:04 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA32130 for jdev-list; Mon, 3 May 1999 11:17:04 -0500 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 LAA32113 for ; Mon, 3 May 1999 11:16:52 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18064 for ; Mon, 3 May 1999 11:16:20 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18060 for ; Mon, 3 May 1999 11:16:19 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id LAA29597 for ; Mon, 3 May 1999 11:16:19 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id LAA29588 for ; Mon, 3 May 1999 11:16:18 -0400 (EDT) From: "Thomas Charron" To: Subject: RE: [JDEV] 0.6 FYI Date: Mon, 3 May 1999 11:03:51 -0400 Message-ID: <000201be9576$27c8c060$62205e0a@tarot.telecom.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Thanks.. The Window Client still does some funny things here and there that I need to clean up,and add code towrite user data to the registry so you don't have to reconfigure it EVERY time you login in.. That will also allow the 'autologin' feature to work. I also have some test code that will allow jabber to run like ICQ does, aka, 'sleeps' in the tray untill connected. Upon disconnect, goes back to sleep.. I also need the whole status list thing working.. I'm targetting getting a Windows client exe in CVS for late Tuesday/Wed. > From: owner-jdev@jabber.org On Behalf Of Jeremie > Subject: [JDEV] 0.6 FYI > Just to keep everyone up to date here, most of the functionality for 0.6 > is checked into CVS, but were going to take a few days to a week here to > do full testing and most importantly, to create a rock-solid and complete > distribution that is ready to install/run/use. > So it will be a few days before 0.6 yet, but this release should be very > solid, documented, and ready to start building on! From owner-jdev@jabber.org Mon May 3 11:17:05 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA32131 for jdev-list; Mon, 3 May 1999 11:17:05 -0500 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 LAA32125 for ; Mon, 3 May 1999 11:17:00 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18115 for ; Mon, 3 May 1999 11:16:23 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA18105 for ; Mon, 3 May 1999 11:16:23 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id LAA29620 for ; Mon, 3 May 1999 11:16:22 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id LAA29616 for ; Mon, 3 May 1999 11:16:21 -0400 (EDT) From: "Thomas Charron" To: Subject: RE: [JDEV] misc protocol discussion Date: Mon, 3 May 1999 11:03:55 -0400 Message-ID: <000401be9576$29c7ebc0$62205e0a@tarot.telecom.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org I would like that veryveryvery much.. It goes along with giving a 'type' to the status tag... Will we also support type="away" and type="offline"? Speaking of which, could you spend a few minutes and document valid values for each of the message and status tags? I KNOW we can extend upon them, but I'm talking the standardly accepted ones.. > -----Original Message----- > From: owner-jdev@jabber.org On Behalf Of Jeremie > Sent: Monday, May 03, 1999 1:17 AM > To: jdev@jabber.org > Subject: [JDEV] misc protocol discussion > > > In message packets we have the type="" attribute available for > special built-in message types, most obviously for errors. And in a > status packet we have the same attribute but it's on the tag > instead. Would anyone be against moving it up to the status tag to be > consistent with message, and it feels more appropriate there anyway: > > Groovin > 10 > > > If everyone is in agreement, I can do this before 0.6. > > Jer > > From owner-jdev@jabber.org Mon May 3 11:44:57 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA32509 for jdev-list; Mon, 3 May 1999 11:44:57 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from sulu.mmm.com (sulu.mmm.com [192.28.4.21]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA32506 for ; Mon, 3 May 1999 11:44:53 -0500 From: mnygard@mmm.com Received: (from daemon@localhost) by sulu.mmm.com (8.8.6 (PHNE_14041)/8.8.1) id KAA14332 for jdev@jabber.org..; Mon, 3 May 1999 10:44:12 -0500 (CDT) X-Lotus-FromDomain: 3M-CORPORATE To: jdev@jabber.org Message-ID: <86256766.00555A82.00@em-stpmta-01.mmm.com> Date: Mon, 3 May 1999 10:39:31 -0500 Subject: Re: [JDEV] Some jibberish...er...jabberish philosophy.. :) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org On 2 May, dsmit@ai.uwf.edu said: > On 2 May, Jeremie wrote: > > > I was going to do that(merge CDATA together during parsing)... actually, I > > don't know why I didn't, lazy I guess :) > > You lazy bum. It's not like you *ever* put any time into coding...:) Yeah, what's with all these classes, anyway? > > That should be easy stuff... take a look at the xpt Expat handlers, yours > > will be almost identical. The only funky thing I'm doing is the two-teir > > parsing via xptpool, where you are "packetizing" the branch of tags under > > the root tag. Let me know if you have any ?s, I'll be busy on other > > things for a while yet, but will be happy to help after 0.6... > > Hmm...I've been thinking about this. I think I'm going to take a little > different approach (at least, based on my limited understanding of > xpt_pool). I'm going to try and use a stack to keep track of new tags > and data. Lemme toss this out on the table for consideration... > > XMLstream(s)... > > If you consider the nature of Jabber, it can really be summed up as the > exchange and translation of XML streams between mediums (and, of course, > *as* a medium). It doesn't really matter if it originates from disk I/O, > network I/O, database...you get the picture. It can all be summarized as > a stream of XML data. So then, a XMLstream would be a data structure > that contains all the methods necessary for taking a stream of XML data > and reconsituting into a data structure, and then if necessary, back to > a XML stream. It would contain the expat parser, a packet stack for > keeping track of packet's being assembled, and a packet queue for > keeping complete packets in. Additionally, it could maintain a series of > function pointers to callback functions so that when packets are ready, > the user/lib is notified and can proceed accordingly. Overall, the > XMLstream would be independent of where the data is coming from, it > would only be interested in getting the data. This is pretty similar to the approach I've taken with the Java client. I have a notion of a "Pipeline". You put Jabber packets into the head of the pipeline, and XML comes out of the other end. By hooking up segments of pipe, each with their own responsibility, I get very simple and flexible handling. A couple of examples will illustrate. I'll show the stage name, the downstream responsibilities and the upstream responsibilities. The typical pipeline for talking sockets gets constructed like this (fair warning, I don't have the code in front of me, so I might forget a stage). * PacketPreparer (calls "willSend" on packet | calls "didReceive" on packet) * PacketParser (converts packet object into mini-DOM | converts mini-DOM into packet) [1] * DomHandler (converts mini-DOM into byte-stream | converts byte-stream into mini-DOM) [2] * SocketSender (send byte-stream | receives byte-stream) If I want to test the input/output stages, I can replace the SocketSender with this structure: * PipeSplitter (sends to the "output" pipe | receives from the "input" pipe) [3] * output: OutputStreamSender (sends byte-stream to an OutputStream (like System.out) | exception!) * input: InputStreamReceiver (exception! | receives byte-stream from an InputStream (like System.in)) [1] The mini-DOM is a simple implementation of the Element and Attribute objects from the W3C's DOM. As was recently noted in this list, the whole thing is way overkill. [2] This is where the XML parser comes into play. You can see how easy it would be to support other protocols. [3] The "output" and "input" stages are both connected to the PipeSplitter. Imagine a Y connection in a pipeline.) Within the client itself, there is no awareness of XML. It just uses "Packet" objects that represent the possible communications. I've taken pains to make most of this framework generic. Supporting other streaming, packetized protocols should be relatively simple, just a matter of providing different packet classes and pipeline stages. Cheers, -Mike From owner-jdev@jabber.org Mon May 3 12:44:35 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA32753 for jdev-list; Mon, 3 May 1999 12:44:35 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from squishy.ameth.org (shepard@squishy.ameth.org [206.152.121.49]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id MAA32750 for ; Mon, 3 May 1999 12:44:32 -0500 Received: from localhost (shepard@localhost) by squishy.ameth.org (8.8.5/8.7.3) with SMTP id LAA27140 for ; Mon, 3 May 1999 11:44:58 -0500 Date: Mon, 3 May 1999 11:44:57 -0500 (CDT) From: Chase Phillips To: jdev@jabber.org Subject: RE: [JDEV] Contact Methods In-Reply-To: <000001be9576$234422a0$62205e0a@tarot.telecom.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 On Mon, 3 May 1999, Thomas Charron wrote: > > That could be done, however, I'mnot really seeing the point to limiting it. > Once I have your pager number, I can page you3 different ways anyway.. > (Shrug) User preference I guess. > > And actually, my old pager number is 167289, and the transport is at > pagers.jabberhost.com.. The transport would know how to page that pager > number. > > I'd say to take care of people getting yourID, we could make it so that > alternate addy's have 'permisions' that are protected somehow. That way you > could even give your home humber for some'authorized' people.. > the reason in limiting it is that only certain people with certain jabber addresses can page me through that transport. this way, if i authorize someone to add my pager, at a later time i can remove them from the list of people. and, in the end, they still don't know my pager number. with this method, the user who sends a message to my pager may only ever be able to find out the 167289@pagers.jabberhost.com, and even then, later may not be allowed to send a message to it. Chase Phillips -- shepard at ameth.org ][ 011010111011001010111 http://www.ameth.org/ ][ 101000111001011001001 From owner-jdev@jabber.org Mon May 3 13:25:59 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA00264 for jdev-list; Mon, 3 May 1999 13:25:59 -0500 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 NAA00261 for ; Mon, 3 May 1999 13:25:51 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id NAA00132 for ; Mon, 3 May 1999 13:25:20 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id NAA00127 for ; Mon, 3 May 1999 13:25:19 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id NAA04291 for ; Mon, 3 May 1999 13:25:19 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id NAA04278 for ; Mon, 3 May 1999 13:25:18 -0400 (EDT) From: "Thomas Charron" To: Subject: RE: [JDEV] Contact Methods Date: Mon, 3 May 1999 13:12:49 -0400 Message-ID: <000601be9588$2e0f5440$62205e0a@tarot.telecom.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org > From: owner-jdev@jabber.org On Behalf Of Chase Phillips > Subject: RE: [JDEV] Contact Methods > the reason in limiting it is that only certain people with certain jabber > addresses can page me through that transport. this way, if i authorize > someone to add my pager, at a later time i can remove them from the list > of people. and, in the end, they still don't know my pager number. with > this method, the user who sends a message to my pager may only ever be > able to find out the 167289@pagers.jabberhost.com, and even then, later > may not be allowed to send a message to it. Hrm.. I THINK I see what your saying, and it's not howI've been handling the pager transport thus far. The 167289 IS the pager number in my example, which is why I was confused when you said that you wanted them not to KNOW your pager number.. Perhaps what you mean is being able to have the pager transport maintain a list of valid users, and map them to pager numbers, hence, not giving your pager ID number away, and also allowing a list of 'Authorized users'. I think this is what you mean: I send a message to TomCharron@pagers.jabberhost.com. Pagers (the transport) would check to see if the from addy is authorized to send messages to TomCharron. Pagers would lookup TomCharron and see the pager number 167289, and send a page to that number, if the user was authorized. Else, it'd reject it and send a back to the sender,informing that they are not authorized to page this ID. At this point, what does everyone else think of this. My original point was to be able to page anyone, and it currently just pages the ID sent to (167289@pagers.jabberhost.com wouldpage # 167289). I suppose it could have some sort of ID authorization feature, but I'm unsure of how the client could configure the transport. From owner-jdev@jabber.org Mon May 3 16:01:03 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id QAA02333 for jdev-list; Mon, 3 May 1999 16:01:03 -0500 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 QAA02330 for ; Mon, 3 May 1999 16:01:00 -0500 Date: Mon, 3 May 1999 16:01:00 -0500 (CDT) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: RE: [JDEV] 0.6 FYI In-Reply-To: <000201be9576$27c8c060$62205e0a@tarot.telecom.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 > Thanks.. The Window Client still does some funny things here and there > that I need to clean up,and add code towrite user data to the registry so > you don't have to reconfigure it EVERY time you login in.. That will also > allow the 'autologin' feature to work. I also have some test code that will > allow jabber to run like ICQ does, aka, 'sleeps' in the tray untill > connected. Upon disconnect, goes back to sleep.. I also need the whole > status list thing working.. I'm targetting getting a Windows client exe in > CVS for late Tuesday/Wed. Sounds good and happy :) Jer From owner-jdev@jabber.org Mon May 3 18:08:37 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id SAA17639 for jdev-list; Mon, 3 May 1999 18:08:37 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id SAA17635 for ; Mon, 3 May 1999 18:08:33 -0500 Received: (from djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) id QAA32695; Mon, 3 May 1999 16:23:18 -0700 Date: Mon, 3 May 1999 16:23:18 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: [JDEV] Python Jabber parser 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 Hi folks :) I've written a Jabber-XML/miniDOM and minDOM/Jabber-XML converter in Python. Due to the state of the docs which I could find, I'm not sure that it is compatible with the real Jabber protocol. Would any of you who know the protocol more fully be willing to do a sanity/completeness check on it? Thanks Daniel From owner-jdev@jabber.org Mon May 3 22:34:02 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id WAA07113 for jdev-list; Mon, 3 May 1999 22:34:02 -0500 Received: from ziggy.jeremie.com (root@cscd-02-23.dialup.netins.net [209.152.71.152]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id WAA07110 for ; Mon, 3 May 1999 22:33:58 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id SAA14607 for ; Mon, 3 May 1999 18:00:39 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Mon, 3 May 1999 18:00:38 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] Python Jabber parser 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 Sure! If it's not too big, just post it to the list :) I don't know python, but I can probably figure it out enough to check it's validity. Thanks! Jer On Mon, 3 May 1999, Daniel Arbuckle wrote: > Hi folks :) > > I've written a Jabber-XML/miniDOM and minDOM/Jabber-XML converter in > Python. Due to the state of the docs which I could find, I'm not sure > that it is compatible with the real Jabber protocol. Would any of you > who know the protocol more fully be willing to do a sanity/completeness > check on it? > > Thanks > > Daniel > From owner-jdev@jabber.org Mon May 3 23:07:30 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id XAA07281 for jdev-list; Mon, 3 May 1999 23:07:30 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id XAA07278 for ; Mon, 3 May 1999 23:07:28 -0500 Received: (from djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) id VAA00841; Mon, 3 May 1999 21:22:13 -0700 Date: Mon, 3 May 1999 21:22:13 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: Re: [JDEV] Python Jabber parser In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="663157403-1176264322-925791733=:835" Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --663157403-1176264322-925791733=:835 Content-Type: TEXT/PLAIN; charset=US-ASCII OK, thanks. Here it is... Daniel On Mon, 3 May 1999, Jeremie wrote: > Sure! If it's not too big, just post it to the list :) > > I don't know python, but I can probably figure it out enough to check it's > validity. > > Thanks! > > Jer > > On Mon, 3 May 1999, Daniel Arbuckle wrote: > > > Hi folks :) > > > > I've written a Jabber-XML/miniDOM and minDOM/Jabber-XML converter in > > Python. Due to the state of the docs which I could find, I'm not sure > > that it is compatible with the real Jabber protocol. Would any of you > > who know the protocol more fully be willing to do a sanity/completeness > > check on it? > > > > Thanks > > > > Daniel > > > --663157403-1176264322-925791733=:835 Content-Type: APPLICATION/octet-stream; name="Pyre.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Jabber parser in Python H4sIADBoLjcAA+1c/2/bNhbvr9FfwakIbG+JbdlOjOUcZ8Wa2zqsa6/dcIfr ioC2aFuJLHoifYlR7H+/9/hFohTFKookvV1NtLX4+L6Qj+SHj092X29S1nny sIUMusPhEXlCCBkeDwqfpnQJOR4G/UGvd9wbEhJ0+/3eE3L0wP1SZS0kTQl5 El7SdLKFr679L1pe4/xP44glsidY+h+WtuWNvF8bQbd7XJp3d/6Do8FQz38/ GPSDACj94dHgCenebzeqyxc+/6Ozm2VMYNpFxJNTP2h3/bOxN7qkkwlLc3pC l6zDhSV0zKdPVimXfMpjEP3222+7/d7AH3veKObzKBl7e6M1LKrxJUvZMmKj jqoBdUWFGL9edJPoSow6qgbUJJpejcEyjbkcdVTNG3WMKm+0ZELQOUNOyXOd 8AwUQTdjyQTI4ROIZdxlQcGXjCeZoOQEB3fa+IklyaZ5zdOrVgO0QyVnKVvL hH58tqCLrxpjQWehmC++oyKczdv4L/7N2Bcpo+EYqUDSFfRCGvE0kptxAD6w zziW9eSSTeX4eRSSDV8TwRiRCyrPYHCmyYwYjMxnBE1dXVIx59HlH9cslUiZ 0zicX15RUeURWPNyLYwWIjcrGApP4ihhjfGvi0gQ+LPcEM1mFLj97RY7HE15 Mk54uqTxqKMqYM7aKFkbP7umm6xPOVPKhdSLg4Yhmad8vTptLGmUNMazlIWj DpBLrbMUYCsUjTEuq+/0km0bEJvyZZWIVng0OOoFve9efP+PjCdkseURG+jJ sjHmcYiKRx1ow77aHrp9nTNZUN0pMnZ0p8be597mdxaF/9pnPX0MPD7+DyA4 sPgPU6Pw//hoh/+PUR4I/x3InaV8meOnqn08XiO7gVo8D/DJ4oHV9D8HruZR w6rP0pSnvmv5LRxA5BzJt0ye36ximlAJrs1Ql93IseL+FfSNOlitBHMy+urw kFxHcUwmzEB3EdrJ4eGdPjUHnjM9D34sOCiKCGq6pBHadEc1lDlqYb9S6jby V7LdAn/D9ddC9Y8vCv9xI86imLVhYA9gowb/ATMGBv+PB90ePAe9Ya+/w//H KDv83+H/Dv8/Ef93l+fd5Xl3ef5yL8//B0XFf/96+fNbCRtr+TBvAj4+/w/x Xx/zv71gEOzy/49RSvN/HrMl5oBWm3u0URP/k0HfxP+D4Ljf62FGKDju7eL/ xyjRcsXhzPsNsPp5NJWeN40hoCBmHTQtvW0fWiceTlnIZuTiIkoieXHRFCye HaiDEFr3bom0C4wtbw8/2shOTpWUoUxDKimQfN8SFlEcpiwB2rv3XmYXjo3v TYvWCEZTJtdpQgpi704cITiplJDprOJBwYJEm65WcCg2desXce6U9j88vUj0 8/1hwPb9H3SH+M5P7/+jYf9YZYQHu/v/oxSz/+EeE0cTz9SETKNk7nnqpqhD bqgT0/q1phuIsFRTtQDiLKSmVt4G0muaAijcjSGYhMJdWZaohpCLC+QHdMCP jGZQBBDDUqa3STDp0yuXFPI3TEA8ekoCSwGhNzDyDdDesiVdLXjKmt2W0/wz V0rwo2np6KxflcugRT80YYXNle6M4zY3xN7yOWVLnjQDaDXtTHtVgOwHX8fD /olyQhvXrfxJkQ60YoAuXW8deHt7e8Q3l5aCxEtNy0UMwcroS0VB5K0i5RK6 bgV0wF4QeKNIuYCuWwFcPQX2vwMhZ8Za1hm6KfaEbpxu0I3l02u0wKq9mnPr uhWwF7CCyGtDzIUsJeuPvkEW+6RpTr80wcqwmyL/+Y3DCxXLh1e/AuMLIOSc WLOs6tJU4P0BKTmzqlpulQMocP+MlJxbVS033toKzHiM57xYy5wIG73oQCA4 zoOaZcV8RIH1FyDkrFjL5pIX55E7c8gtExznBa5noTPVULF8cPss8D1ncc4H lcyjrDhJPzCYpF94wlp/mp1IJYDiZC1ZcS9+8G0258Q/OzvzD3Bt6ayOofyp TRBnO37wMey51W633l3NuBnuaDMr4oPKNd1qVd76YJlKjcpFdzUqv5Qa/6zA LvQZQGCG6wr2bHB2vUCYDk7I039idlJijgRTRSSN5gvw8w1PScjJC5IwFhLJ yZyTyQZiNJrSKQDHmYd9IdGMuFANisvQ3bWkFAkIySgXW+DV54XqN2ZrbLtq m4HpZtwqRJm/wNbNBlE8E9p0+sc6SlmzfBy4DWluGJvfdd+XDym3NTh5X9aV AvxToXXpADdV/cs6uaBJGDMlb05QfMTugrNiEx/bE7BFxqR7YsacG1dt7w6D 9443HCoykm+U3qJtvTvp3An/DwjuEjSPs2HvEOpiAKT2egVaWFPxFE9iG3jL VvHQtnTfz10g8zlCSDAdsEYLWld8hb4LS4O1dJldOXTA08aPVRMP56L7lLYW OT3N/XfXnDsudAcgW1VyzvwWGvUSq2x1wxQWC3ZSMKk6irPWzu47YPn2tOkw wcycnTMHc8GpFuFMO0Qkjtcd+UzSTIazhdx4Y7sti4zWmGvLVVBnTEcm220Z lK0y5YjXWdIhzXZLJjKqsuSI11nCeGi7HRVQVVnJRGv9Rjc1ToOzp9JjRrDO gAmEt9owQVyVGUe8zpIN2bbbyuK/KmsFFbWu09FejftM3FjpQkdBnbHzmxpD GGxWGTkvn2R3GMAoc7sFFaZWmchE62yo4HS7ER1vVFnJhevMqKh2uxkdGVeZ yYXrzGBAvN2KiqirjGSitWsaIuma9YyheOVatqJ1NjAE325DxfBVNjLRWhTg NQjAq3c//yjtEPZvV49hcJV+K1hnAO4L2w1gKF1lwArW7gxWs70xHM8O5KKm T8z/lPJ/Ns9yry8A6vL/5Nh+/3PY63fx/c+g3z3e5f8eo1xc0Di+uMBUmG8C drzDOuk7U321lqb+/otIjH8h5Xb+P5voe8OAmv3fOw569vdf3a76/c9R0N3l /x+lfFKKH1bJj+fPnp+/OW1UfAUKz7IkpDFP2Km/YcI/G/+eNJwXA9kKq30P 4KRt6tL8n5iuv4ZAn23P1yuWCv5Sxv52s0mK5TdnvpartT3iTWr/AFpWcoHZ KxzxrJis8p7uGaVNf18cHh7m//ye+GSfNI0a9T71wHtKPqpYIZX/+GgpIVNr rtWCcdmeNf3fpU++1gNpkW9I0x/tC+yd2zklwVMSkSjJGkB8KZqtkyzDF73D lNMpUanGEwJ3Chkla6bbrcEG2Ren4A+/gR6I3nXfHyjBVp65yUZoXu3q7A2B hVls1okxJ7OTubsDq9Y3uReTesKEcD5s3zCULZZzbc4E7gsza9ZlTT3535Cg 1TooTov1F3P9ZYfjpn3MqmJ2JaEyz102o86+GJcM67k6KM8QKs2Wq1ZQzuJW 5qqqMmB3pcdYRVo0E7o7NXpbb1WCzOR4ddcznGpVuKs0WKBl+d7MLYXEb3ks FWk+K7YlkXtnku/z4L86/1dplMhLOrnfr/1kBc7/rd//Ggyz9//D7pH6/tfR cPf9n0cpT78inbVIOzGf0rgziZLOaiMXPDEv/7PIsBwDVLc614a7ObLj38u+ b7AR8Jzg2cdhHzV99wcpeP9IAWdh36rDcSPgZA2h5kU3UHe/seJ+6QDUgYzh yGNat9JElXAHz5DNolN007avfzRK8Ju2xQeLG5974u6pqP3/BkDy5fmD2aj7 /WcQDLL//6GH/xdAEPS7u/3/KMV+YV0uGJmweZQkeA3gM0KJfslDzK+Cyffr FAIPGW8g1pIYmIlISAGsHk1wj3WWEMI/f/USwhXJ0hmdMgKQErPQAQEMvyjB 3U3ENI1WEP2u4rUg1JuxayLochUzVGlt21fpWied4g9j2p73KpkynTFj4YHq utZGEgY3EbgnJJFYMPwqAifXC5bgDwEaKSMhxG/kOoIYCUawFgx2PpVKZMkA 9PQPBl69JQz6wTcCX0Urw2tQjVagO1MmBPgCwtKUx4f//hu5wlfa+4GHL7QF SaIpizeEJ+S3BFCEvJDoXIxGJHQjjq6Yfv0NmicMaCkR0XIdQy+UgWu68fDT jCBEi/MU0VOoniShfkEOKJmiTBM7fIG/+bnAH/3QCdwYoBlCFLAr0TV8PV+Q EwC5FzMcXUpeK3jX41pBXAtduKYC5nO5inCy0D2Ai+ZOSMR6hRB9oFxzzZOG 9Iwh7Af4MJ/d9udey7uyK7uyK7uyK7uyK7tSX/4Lk2taXgBQAAA= --663157403-1176264322-925791733=:835-- From owner-jdev@jabber.org Tue May 4 13:27:48 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA10842 for jdev-list; Tue, 4 May 1999 13:27:48 -0500 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 NAA10838 for ; Tue, 4 May 1999 13:27:46 -0500 Date: Tue, 4 May 1999 13:27:46 -0500 (CDT) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] STATUS 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 ==> DR0.6 (This Week/Weekend) Outstanding issues before release: -> Update release docs, READMEs, configuring, using, etc Mostly done, few more touch up things and docs to be written. -> CLI Client update, messages, roster, status, etc... In progress. -> ./configure; make; make install for the works Proposal was send to cvs@jabber.org ==> DR0.7 (May) -> Full Manpages and Docs -> Client Lib spec/base -> Sample transport structure/code -> mod_mysql? -> Querying -> Perl modules(structure)? -> AIM prototype transport? ==> DR0.8 (Juneish) -> Threading? -> ICQ/AIM/etc transports -> Full CLI architecture ==> Future -> Threads, pools, IO revamp -> File, URL, media transfers, streaming From owner-jdev@jabber.org Tue May 4 20:27:35 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id UAA13661 for jdev-list; Tue, 4 May 1999 20:27:35 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from chimera.acm.jhu.edu (mail@chimera.acm.jhu.edu [128.220.223.63]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id UAA13658 for ; Tue, 4 May 1999 20:27:31 -0500 Received: from galtgulch (jonlin06.hilander.com [207.96.113.103]) by chimera.acm.jhu.edu (8.9.3/8.9.3/asi-redhat) with SMTP id VAA04416 for ; Tue, 4 May 1999 21:28:47 -0400 Message-Id: <4.1.19990504212137.009ff270@chimera.acm.jhu.edu> X-Sender: cklempay@chimera.acm.jhu.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 04 May 1999 21:22:51 -0400 To: jdev@jabber.org From: "Corbett J. Klempay" Subject: Re: [JDEV] Python Jabber parser 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 At 06:00 PM 5/3/99 -0500, you wrote: >Sure! If it's not too big, just post it to the list :) > >I don't know python, but I can probably figure it out enough to check it's >validity. Python!!! Yes yes yes! This is cool. I'm a fan myself...been using it a lot this year for various things. If Python-fluent people are needed for help with things, I should be game :) CJK From owner-jdev@jabber.org Tue May 4 23:06:42 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id XAA16869 for jdev-list; Tue, 4 May 1999 23:06:42 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from hawthorne.com (host-209-214-46-99.pfn.bellsouth.net [209.214.46.99]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id XAA16866 for ; Tue, 4 May 1999 23:06:38 -0500 Received: from hawthorne.com (localhost [127.0.0.1]) by hawthorne.com (8.8.7/8.8.7) with ESMTP id XAA26742 for ; Tue, 4 May 1999 23:09:01 -0500 Message-Id: <199905050409.XAA26742@hawthorne.com> Date: Tue, 4 May 1999 23:08:59 -0500 (CDT) From: dsmith@ai.uwf.edu Subject: [JDEV] Element stack and Asserts To: jdev@jabber.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Greetings... :) Well, I'm almost done writing an element stack to keep track of element "trees" as they are being built. It'll make using expat trivial. The stack is setup so that it has a (nearly) 1:1 correspondence with the expat callbacks for StartElement, CharacterData, and EndElement. It's pretty nifty, IMHO. :) I've also been putting some finishing touches on the element .c/.h files. I fixed it up so that everything uses const char's and strdups to ensure that elements release *all* the memory they use properly (at least, that's my goal). :) Once I finish up the element stack, I'm hoping to write the XMLstream wrapper and that'll give us a I/O source independent, incremental XML->DOM generator. Really, my first goal with writing this piece is to make it easy for people who write clients to parse the data out. It'll be up to them to provide the I/O source (which should be trivial). Everything's looking good. :) I'm getting tired of all these CVS checkin messages. You guys are *way* too productive. :) J/K... ICQ is dead (or will be soon). Long live Jabber. D. From owner-jdev@jabber.org Wed May 5 09:51:13 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id JAA19570 for jdev-list; Wed, 5 May 1999 09:51:13 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id JAA19567 for ; Wed, 5 May 1999 09:51:10 -0500 Received: (from djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) id IAA03706; Wed, 5 May 1999 08:06:13 -0700 Date: Wed, 5 May 1999 08:06:13 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: Re: [JDEV] Element stack and Asserts In-Reply-To: <199905050409.XAA26742@hawthorne.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 Tue, 4 May 1999 dsmith@ai.uwf.edu wrote: > Well, I'm almost done writing an element stack to keep track of element > "trees" as they are being built. It'll make using expat trivial. The > stack is setup so that it has a (nearly) 1:1 correspondence with the > expat callbacks for StartElement, CharacterData, and EndElement. It's > pretty nifty, IMHO. :) > > I've also been putting some finishing touches on the element .c/.h > files. I fixed it up so that everything uses const char's and strdups > to ensure that elements release *all* the memory they use properly (at > least, that's my goal). :) > > Once I finish up the element stack, I'm hoping to write the XMLstream > wrapper and that'll give us a I/O source independent, incremental > XML->DOM generator. Really, my first goal with writing this piece is to > make it easy for people who write clients to parse the data out. It'll > be up to them to provide the I/O source (which should be trivial). Heh :) These three paragraphs pretty well describe my Python XMLStream package. Except that the interpreter takes care of memory management.... I guess I shouldn't bother porting to C when I've got it perfected. ;) Daniel From owner-jdev@jabber.org Wed May 5 11:52:48 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA20036 for jdev-list; Wed, 5 May 1999 11:52:48 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from animal.blarg.net (root@animal.blarg.net [206.124.128.1]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA20033 for ; Wed, 5 May 1999 11:52:45 -0500 Received: from animal.blarg.net (james@animal.blarg.net [206.124.128.1]) by animal.blarg.net (8.9.1/8.9.1) with SMTP id IAA02050 for ; Wed, 5 May 1999 08:52:37 -0700 Date: Wed, 5 May 1999 08:52:37 -0700 (PDT) From: "James A. Hillyerd" To: jdev@jabber.org Subject: Re: [JDEV] Python Jabber parser In-Reply-To: <4.1.19990504212137.009ff270@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 Another Pythonite here. =) -james On Tue, 4 May 1999, Corbett J. Klempay wrote: > At 06:00 PM 5/3/99 -0500, you wrote: > >Sure! If it's not too big, just post it to the list :) > > > >I don't know python, but I can probably figure it out enough to check it's > >validity. > > Python!!! Yes yes yes! This is cool. I'm a fan myself...been using it a > lot this year for various things. If Python-fluent people are needed for > help with things, I should be game :) > > CJK > [] James A. Hillyerd Python Developer [] GPG Public Key Fingerprint for 1024D/9F956CDE (Expires 2000-02-01): [] C86F B073 92DF 1E24 EF0B 0118 6061 0FEC 9F95 6CDE From owner-jdev@jabber.org Fri May 7 11:24:09 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA03123 for jdev-list; Fri, 7 May 1999 11:24:09 -0500 Received: from dillinger.io.com (kenzoid@dillinger.io.com [199.170.88.20]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id LAA03120 for ; Fri, 7 May 1999 11:24:07 -0500 Received: from localhost (kenzoid@localhost) by dillinger.io.com (8.9.1/8.9.1a) with ESMTP id KAA16586 for ; Fri, 7 May 1999 10:24:02 -0500 (CDT) X-Authentication-Warning: dillinger.io.com: kenzoid owned process doing -bs Date: Fri, 7 May 1999 10:24:02 -0500 (CDT) From: Ken Kennedy To: jdev@jabber.org Subject: [JDEV]Taking the plunge... 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, after reviewing code and mailing list ad nauseum, I'm getting ready to roll up my sleeves and jump in here. If there are no objections *grin*, I'm going to start with documentation, actually. Organizing docs helps me confirm that I understand what I'm doing, before I start coding...(I know, I'm weird. I do database development for a living, though, and if you don't START w/ ER diagrams & logical models...well, it's scary....). Obviously, I don't want to reinvent the wheel, but I'm looking at putting together READMEs, man pages, and FAQs on: protocol/API info (this will REALLY help me make sure I know what's going on) server use/functionality (both present and planned) CLI client use/functionality (both present and planned) perl script/client info (I'm a perl hack...I couldn't resist..) Sound like a plan? Any obvious things I'm missing? Ken From owner-jdev@jabber.org Fri May 7 15:09:03 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA04151 for jdev-list; Fri, 7 May 1999 15:09:03 -0500 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 PAA04148 for ; Fri, 7 May 1999 15:09:02 -0500 Date: Fri, 7 May 1999 15:09:02 -0500 (CDT) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] Jabber 0.6 Release Candidate! 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 It's finally here! Just ungzip/untar it and be on your merry way! http://jabber.org/download/jabber-0.6RC.tar.gz NOTES: This is just a candidate, not the official 0.6 release. The only planned changes are more complete READMEs, instructions, and documentation. This release includes the core base server fuctionality, so that you can use a client, communicate with other local or remote Jabber users, maintain a roster, and update your status/presence information. This release supports the complete protocol, module API, and add-on transports which are now in development. Please download and try it out everywhere. I've tested and successfully installed on Linux, Solaris, FreeBSD, BeOS, and Win32(CYGWIN). Report bugs back to either team@jabber.org or this list, and we'll fix things up for the release in a few days! *** ALL comments, suggestions, patches, discussion welcome! *** Thanks, Jer From owner-jdev@jabber.org Fri May 7 15:50:12 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA04434 for jdev-list; Fri, 7 May 1999 15:50:12 -0500 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 PAA04431 for ; Fri, 7 May 1999 15:50:10 -0500 Date: Fri, 7 May 1999 15:50:10 -0500 (CDT) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV]Taking the plunge... 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 > Well, after reviewing code and mailing list ad nauseum, I'm getting ready > to roll up my sleeves and jump in here. If there are no objections *grin* Really great! Welcome! :) > I'm going to start with documentation, actually. Organizing docs helps me > confirm that I understand what I'm doing, before I start coding...(I know, > I'm weird. I do database development for a living, though, and if you > don't START w/ ER diagrams & logical models...well, it's scary....). This is perfect, we really need some help with the documentation, since we're working hard at making the code rock solid and functional, haven't had much time to explain it to the outside world :) The models are mostly in my head, in the code, and spread around in the list archives... I'll succumb to a lobotomy if it'll help, *g*. > Obviously, I don't want to reinvent the wheel, but I'm looking at putting > together READMEs, man pages, and FAQs on: > > protocol/API info (this will REALLY help me make sure I know what's going > on) The protocol is easy to look at and understand from that angle, but it really needs a good definition of what each field is used for... I'll be adding a small guide doc to the 0.6 release before it goes out covering a few of the important parts. > server use/functionality (both present and planned) > > CLI client use/functionality (both present and planned) > > perl script/client info (I'm a perl hack...I couldn't resist..) All great great things, thanks!!! I checked in the framework for a perl module, and plan on filling that up a bit more soon too, feel free to start to spec it out a bit more if you wish. I want to split the documentation effort into it's own wing/project with it's own archive. This will probably happen as soon as jabber.org moves to a new server within the next month. Thanks again, all help is deeply appreciated! Jer From owner-jdev@jabber.org Sat May 8 14:36:20 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA08192 for jdev-list; Sat, 8 May 1999 14:36:20 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-01.dialup.netins.net [209.152.71.130]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id OAA08189 for ; Sat, 8 May 1999 14:36:17 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id MAA11723 for ; Sat, 8 May 1999 12:38:48 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 8 May 1999 12:38:47 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: [JDEV] fat clients vs. fat servers 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've written up a small "position statement" explaining the approach Jabber has taken in shifting the responsibilities to the server, and posted it to the new mozilla newsgroup: netscape.public.mozilla.rt-messaging. http://x12.dejanews.com/[ST_rn=if]/threadmsg_if.xp?AN=475556562&CONTEXT=926187001.949682210&thitnum=1 I will be (attempting to) write a small lightweight Jabber client for Mozilla, but the above message isn't related to that. They may be heading in the direction of building a "fat client" that has the potential to duplicate part of what Jabber does, and the above message is to explain the differences and approach Jabber takes. There is also the potential for Mozilla to fully back/support Jabber and really make some magic happen. Feel free to hop into the newsgroup or join the mailing list(send "subscribe" in the subject to mozilla-rt-messaging-request@mozilla.org) if you are interested in this or just want to voice your opinion. Thanks, Jer From owner-jdev@jabber.org Sun May 9 15:06:53 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id PAA12881 for jdev-list; Sun, 9 May 1999 15:06:53 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from relay1.teleport.com (relay1.teleport.com [192.108.254.28]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id PAA12878 for ; Sun, 9 May 1999 15:06:51 -0500 Received: (qmail 26448 invoked by uid 5); 9 May 1999 19:06:46 -0000 Message-ID: <19990509190646.26447.qmail@relay1.teleport.com> Received: from d88.venus.sunset.net(209.142.50.88), claiming to be "[192.168.1.216]" via SMTP by relay1.teleport.com, id smtpdAAAZz3vZ_; Sun May 9 12:06:42 1999 X-Mailer: Microsoft Outlook Express for Macintosh - 4.01 (295) Date: Sun, 09 May 1999 12:06:31 -0700 Subject: [JDEV] 0.6 not working?? From: "Carl MacDonald" 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 Just built the 0.6 release candidate. Everything appears to have built correctly, and daemons start up. But I can't connect with either the client that came in the build, or my own. Running on Redhat Linux 5.0. Has anyone else experienced this? -- Carl From owner-jdev@jabber.org Sun May 9 16:09:22 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id QAA13110 for jdev-list; Sun, 9 May 1999 16:09:22 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id QAA13107 for ; Sun, 9 May 1999 16:09:19 -0500 Received: (from djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) id OAA10220; Sun, 9 May 1999 14:25:12 -0700 Date: Sun, 9 May 1999 14:25:11 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: Re: [JDEV] 0.6 not working?? In-Reply-To: <19990509190646.26447.qmail@relay1.teleport.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 It seems to work fine for me. I've connected with both the 'jabber' client and my prototype client. Daniel On Sun, 9 May 1999, Carl MacDonald wrote: > Just built the 0.6 release candidate. Everything appears to have built > correctly, and daemons start up. But I can't connect with either the client > that came in the build, or my own. > > Running on Redhat Linux 5.0. > > Has anyone else experienced this? > -- > Carl > From owner-jdev@jabber.org Sun May 9 16:18:57 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id QAA13217 for jdev-list; Sun, 9 May 1999 16:18:57 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from mw2.texas.net (mw2.texas.net [206.127.30.12]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id QAA13214 for ; Sun, 9 May 1999 16:18:55 -0500 Received: from montague (tcnet02-087.houston.texas.net [209.99.82.87]) by mw2.texas.net (2.4/2.4) with ESMTP id PAA07757 for ; Sun, 9 May 1999 15:18:54 -0500 (CDT) Date: Sun, 9 May 1999 15:19:14 -0500 (CDT) From: Eliot Landrum X-Sender: eliot@montague To: jdev@jabber.org Subject: Re: [JDEV] 0.6 not working?? In-Reply-To: <19990509190646.26447.qmail@relay1.teleport.com> Message-ID: Organization: http://lonestar.texas.net/~landrum/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org I suppose you edited config.x properly? Eliot Landrum elandrum@bigfoot.com On Sun, 9 May 1999, Carl MacDonald wrote: > Just built the 0.6 release candidate. Everything appears to have built > correctly, and daemons start up. But I can't connect with either the client > that came in the build, or my own. > > Running on Redhat Linux 5.0. > > Has anyone else experienced this? > -- > Carl > > From owner-jdev@jabber.org Sun May 9 22:43:04 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id WAA14529 for jdev-list; Sun, 9 May 1999 22:43:04 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-04.dialup.netins.net [209.152.71.133]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id WAA14526 for ; Sun, 9 May 1999 22:43:01 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id UAA26330 for ; Sun, 9 May 1999 20:45:54 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sun, 9 May 1999 20:45:53 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] 0.6 not working?? In-Reply-To: <19990509190646.26447.qmail@relay1.teleport.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 After the daemons are running, you should be able to: prompt> telnet localhost 5222 or also prompt> telnet `hostname` 5222 and it should connect to the port, won't print anything but you'll get connected. If this isn't the case, then try starting up the daemons with a -D flag, and either try and decipher what it says or cut-n-paste it and send it this way. Thanks! Jer On Sun, 9 May 1999, Carl MacDonald wrote: > Just built the 0.6 release candidate. Everything appears to have built > correctly, and daemons start up. But I can't connect with either the client > that came in the build, or my own. > > Running on Redhat Linux 5.0. > > Has anyone else experienced this? > -- > Carl > From owner-jdev@jabber.org Mon May 10 14:20:35 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18099 for jdev-list; Mon, 10 May 1999 14:20:35 -0500 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 OAA18096 for ; Mon, 10 May 1999 14:20:32 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id OAA02564 for ; Mon, 10 May 1999 14:18:53 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id OAA02553 for ; Mon, 10 May 1999 14:18:53 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id OAA14920 for ; Mon, 10 May 1999 14:18:52 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id OAA14913 for ; Mon, 10 May 1999 14:18:51 -0400 (EDT) From: "Thomas Charron" To: "Jabber Development" Subject: [JDEV] Silly question.. Date: Mon, 10 May 1999 14:06:48 -0400 Message-ID: <000001be9b0f$e0146400$62205e0a@tarot.telecom.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.3110.3 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Silly question, but why do we not support as tag to go with the tag? PERSONALLY I can see no reason to do this, but if a user has multiple ID's for some reason, it'd make sense.. Here's an example of what I could think: A client supports multiple ID's to connect. Let's say you have an ISP that decides to try out Jabber for online Technical Support. The techshave their own personal ID's, as well as an id such as: DirtyOldMan@jabber.org support@jabber.org Currenly, the client would need to end the transaction via , reconnect, and re-login. Why not allow a as well.. This could also be good if people want to be 'away' from their computer, but allowing the connection to remain up. And, while we're at it, how's about being about to login as multiple users via multiple 's? From owner-jdev@jabber.org Mon May 10 14:26:45 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18152 for jdev-list; Mon, 10 May 1999 14:26:45 -0500 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 OAA18149 for ; Mon, 10 May 1999 14:26:43 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id OAA07181 for ; Mon, 10 May 1999 14:26:11 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id OAA07172 for ; Mon, 10 May 1999 14:26:11 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id OAA17099 for ; Mon, 10 May 1999 14:26:10 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id OAA17094 for ; Mon, 10 May 1999 14:26:09 -0400 (EDT) From: "Thomas Charron" To: "Jabber Development" Subject: [JDEV] OOhh.. Wittle Wug.. Date: Mon, 10 May 1999 14:14:05 -0400 Message-ID: <000101be9b10$e3e3ed20$62205e0a@tarot.telecom.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.3110.3 Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org Found something interesting after I sent the last message.. OPen a connection, and do this: test test Send this, everything works fine, message goes thru: testYour momma's funny lookin'.. Now for the fun.. Go ahead and send this: u p The debug screen lists: (NOTICE THE 6th LINE DOWN.. YES, IT'S CUT DIRECT FROM THE LOG There is also another one later on) [Mon May 10 13:16:13 1999] main "Delivering Locally" [Mon May 10 13:16:13 1999] lib "new_packet=testtest" [Mon May 10 13:16:13 1999] lib "writing_data_to=10.94.32.98" [Mon May 10 13:16:13 1999] lib "IO: waiting" [Mon May 10 13:16:28 1999] lib "new_data_from=10.94.32.98" "/login>p999] main "dispatch_data= [Mon May 10 13:16:28 1999] main "Processing Normally" [Mon May 10 13:16:28 1999] main "handling_normal_packet=10.94.32.98" [Mon May 10 13:16:28 1999] main "handle_login" [Mon May 10 13:16:28 1999] main "get_group_user=u" [Mon May 10 13:16:28 1999] main "get_handler_group=users" [Mon May 10 13:16:28 1999] main "handler_in_module=mod_basic" [Mon May 10 13:16:28 1999] main "get_handler=mod_basic" [Mon May 10 13:16:28 1999] main "MOD_BASIC: handler_auth =u" [Mon May 10 13:16:28 1999] main "MOD_BASIC: AUTH SUCCESSFUL!=" [Mon May 10 13:16:28 1999] main "new_session=u" [Mon May 10 13:16:28 1999] main "lookup_session=(NULL)" [Mon May 10 13:16:28 1999] main "get_handler_group=users" [Mon May 10 13:16:28 1999] main "handler_in_module=mod_basic" [Mon May 10 13:16:28 1999] main "get_handler=mod_basic" [Mon May 10 13:16:28 1999] main "MOD_BASIC: login!=u" [Mon May 10 13:16:28 1999] mod_basic "spool_file_failure=/usr/local/var/u.offline.xml" [Mon May 10 13:16:28 1999] lib "IO: waiting" [Mon May 10 13:16:39 1999] lib "new_data_from=10.94.32.98" [Mon May 10 13:16:39 1999] main "dispatch_data=testtest" [Mon May 10 13:16:13 1999] main "Delivering Locally" [Mon May 10 13:16:13 1999] lib "new_packet=testtest" [Mon May 10 13:16:13 1999] lib "writing_data_to=10.94.32.98" [Mon May 10 13:16:13 1999] lib "IO: waiting" [Mon May 10 13:16:28 1999] lib "new_data_from=10.94.32.98" "/login>p999] main "dispatch_data= [Mon May 10 13:16:28 1999] main "Processing Normally" [Mon May 10 13:16:28 1999] main "handling_normal_packet=10.94.32.98" [Mon May 10 13:16:28 1999] main "handle_login" [Mon May 10 13:16:28 1999] main "get_group_user=u" [Mon May 10 13:16:28 1999] main "get_handler_group=users" [Mon May 10 13:16:28 1999] main "handler_in_module=mod_basic" [Mon May 10 13:16:28 1999] main "get_handler=mod_basic" [Mon May 10 13:16:28 1999] main "MOD_BASIC: handler_auth =u" [Mon May 10 13:16:28 1999] main "MOD_BASIC: AUTH SUCCESSFUL!=" [Mon May 10 13:16:28 1999] main "new_session=u" [Mon May 10 13:16:28 1999] main "lookup_session=(NULL)" [Mon May 10 13:16:28 1999] main "get_handler_group=users" [Mon May 10 13:16:28 1999] main "handler_in_module=mod_basic" [Mon May 10 13:16:28 1999] main "get_handler=mod_basic" [Mon May 10 13:16:28 1999] main "MOD_BASIC: login!=u" [Mon May 10 13:16:28 1999] mod_basic "spool_file_failure=/usr/local/var/u.offline.xml" [Mon May 10 13:16:28 1999] lib "IO: waiting" [Mon May 10 13:16:39 1999] lib "new_data_from=10.94.32.98" [Mon May 10 13:16:39 1999] main "dispatch_data=testtest" I know, I know, 'Client's shouldn't be doing this, hence, it's acting funny'. But if it's not allowed, then the transport should report the error back. ;-P From owner-jdev@jabber.org Mon May 10 14:48:20 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18442 for jdev-list; Mon, 10 May 1999 14:48:20 -0500 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 OAA18439 for ; Mon, 10 May 1999 14:48:18 -0500 Date: Mon, 10 May 1999 14:48:18 -0500 (CDT) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: Jabber Development Subject: Re: [JDEV] Silly question.. In-Reply-To: <000001be9b0f$e0146400$62205e0a@tarot.telecom.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 > Silly question, but why do we not support as tag to go > with the tag? PERSONALLY I can see no reason to do this, but if > a user has multiple ID's for some reason, it'd make sense.. Here's an > example of what I could think: Actually, it does support the tag, looks like I just forgot to put it in the multi-client protocol example. > A client supports multiple ID's to connect. Let's say you have an ISP that decides to try out Jabber for online Technical Support. > The techshave their own personal ID's, as well as an id such as: > > DirtyOldMan@jabber.org > support@jabber.org > > Currenly, the client would need to end the transaction via , reconnect, and re-login. Why not allow a as well.. > This could also be good if people want to be 'away' from their computer, but allowing the connection to remain up. > > And, while we're at it, how's about being about to login as multiple users via multiple 's? Absolutely, and you'll be happy to know that it's already supported and in the server! :) (although I haven't been able to fully test it, but it is supposed to work) There are lots of great reasons for "multi" clients, yours above, proxies, special purpose client(pager one for instance), gateways, etc... one TCP socket and any number of users' data flowing across it. You don't have to do anything special to tell the server that you are a multi-client either, it will automagically assume you are after you send a second over the same connection. Jer From owner-jdev@jabber.org Mon May 10 14:54:00 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18501 for jdev-list; Mon, 10 May 1999 14:54:00 -0500 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 OAA18498; Mon, 10 May 1999 14:53:58 -0500 Date: Mon, 10 May 1999 14:53:58 -0500 (CDT) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: Jabber Development cc: cvs@jabber.org Subject: Re: [JDEV] OOhh.. Wittle Wug.. In-Reply-To: <000101be9b10$e3e3ed20$62205e0a@tarot.telecom.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 Actually, what you are seeing below is what's supposed to be happening, because of the second login it identifies you as a multi-client, and creates another session. The goofy looking lines in the log are simply an artifact of dumping data to the terminal and unix vs. win32 newlines... all the data is getting there correctly otherwise there would have been an XML processing error(Expat is VERY strict :). Jer On Mon, 10 May 1999, Thomas Charron wrote: > Found something interesting after I sent the last message.. OPen a connection, and do this: > > > > > > test > test > > > Send this, everything works fine, message goes thru: > > testYour momma's funny lookin'.. > > Now for the fun.. Go ahead and send this: > > > u > p > > > The debug screen lists: (NOTICE THE 6th LINE DOWN.. YES, IT'S CUT DIRECT FROM THE LOG There is also another one later on) > > [Mon May 10 13:16:13 1999] main "Delivering Locally" > [Mon May 10 13:16:13 1999] lib "new_packet=testtest" > [Mon May 10 13:16:13 1999] lib "writing_data_to=10.94.32.98" > [Mon May 10 13:16:13 1999] lib "IO: waiting" > [Mon May 10 13:16:28 1999] lib "new_data_from=10.94.32.98" > "/login>p999] main "dispatch_data= > [Mon May 10 13:16:28 1999] main "Processing Normally" > [Mon May 10 13:16:28 1999] main "handling_normal_packet=10.94.32.98" > [Mon May 10 13:16:28 1999] main "handle_login" > [Mon May 10 13:16:28 1999] main "get_group_user=u" > [Mon May 10 13:16:28 1999] main "get_handler_group=users" > [Mon May 10 13:16:28 1999] main "handler_in_module=mod_basic" > [Mon May 10 13:16:28 1999] main "get_handler=mod_basic" > [Mon May 10 13:16:28 1999] main "MOD_BASIC: handler_auth =u" > [Mon May 10 13:16:28 1999] main "MOD_BASIC: AUTH SUCCESSFUL!=" > [Mon May 10 13:16:28 1999] main "new_session=u" > [Mon May 10 13:16:28 1999] main "lookup_session=(NULL)" > [Mon May 10 13:16:28 1999] main "get_handler_group=users" > [Mon May 10 13:16:28 1999] main "handler_in_module=mod_basic" > [Mon May 10 13:16:28 1999] main "get_handler=mod_basic" > [Mon May 10 13:16:28 1999] main "MOD_BASIC: login!=u" > [Mon May 10 13:16:28 1999] mod_basic "spool_file_failure=/usr/local/var/u.offline.xml" > [Mon May 10 13:16:28 1999] lib "IO: waiting" > [Mon May 10 13:16:39 1999] lib "new_data_from=10.94.32.98" > [Mon May 10 13:16:39 1999] main "dispatch_data=testtest" > [Mon May 10 13:16:13 1999] main "Delivering Locally" > [Mon May 10 13:16:13 1999] lib "new_packet=testtest" > [Mon May 10 13:16:13 1999] lib "writing_data_to=10.94.32.98" > [Mon May 10 13:16:13 1999] lib "IO: waiting" > [Mon May 10 13:16:28 1999] lib "new_data_from=10.94.32.98" > "/login>p999] main "dispatch_data= > [Mon May 10 13:16:28 1999] main "Processing Normally" > [Mon May 10 13:16:28 1999] main "handling_normal_packet=10.94.32.98" > [Mon May 10 13:16:28 1999] main "handle_login" > [Mon May 10 13:16:28 1999] main "get_group_user=u" > [Mon May 10 13:16:28 1999] main "get_handler_group=users" > [Mon May 10 13:16:28 1999] main "handler_in_module=mod_basic" > [Mon May 10 13:16:28 1999] main "get_handler=mod_basic" > [Mon May 10 13:16:28 1999] main "MOD_BASIC: handler_auth =u" > [Mon May 10 13:16:28 1999] main "MOD_BASIC: AUTH SUCCESSFUL!=" > [Mon May 10 13:16:28 1999] main "new_session=u" > [Mon May 10 13:16:28 1999] main "lookup_session=(NULL)" > [Mon May 10 13:16:28 1999] main "get_handler_group=users" > [Mon May 10 13:16:28 1999] main "handler_in_module=mod_basic" > [Mon May 10 13:16:28 1999] main "get_handler=mod_basic" > [Mon May 10 13:16:28 1999] main "MOD_BASIC: login!=u" > [Mon May 10 13:16:28 1999] mod_basic "spool_file_failure=/usr/local/var/u.offline.xml" > [Mon May 10 13:16:28 1999] lib "IO: waiting" > [Mon May 10 13:16:39 1999] lib "new_data_from=10.94.32.98" > [Mon May 10 13:16:39 1999] main "dispatch_data=testtest" > > I know, I know, 'Client's shouldn't be doing this, hence, it's acting funny'. But if it's not allowed, then the transport should > report the error back. ;-P > From owner-jdev@jabber.org Wed May 12 03:06:35 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id DAA27438 for jdev-list; Wed, 12 May 1999 03:06:35 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-60.dialup.netins.net [209.152.71.189]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id DAA27435 for ; Wed, 12 May 1999 03:06:30 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id BAA04654 for ; Wed, 12 May 1999 01:09:45 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Wed, 12 May 1999 01:09:44 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: [JDEV] Jabber 0.6 Ready (the calm before the storm) 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 Alrighty, I fixed up a few more bugs and updated the READMEs, so this should be the RTR(Ready To Release) version: http://jabber.org/download/jabber-0.6.tar.gz I'll give it 24 hours then craft a little announcement and post it on all the normal places(freshmeat, etc). Things are going to be VERY busy between now and 0.7, and probably only busier after that... we've got a fairly solid base to start working on so all the "fun" things will start falling into place, such as I have a working prototype ICQ and AIM transport here at home that I'll check in this weekend as well as produce a few binaries for those that want to play :-) More tomorrow! Jer From owner-jdev@jabber.org Wed May 12 08:05:04 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id IAA28540 for jdev-list; Wed, 12 May 1999 08:05:04 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id IAA28533 for ; Wed, 12 May 1999 08:05:00 -0500 Received: (from djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) id GAA16305; Wed, 12 May 1999 06:21:22 -0700 Date: Wed, 12 May 1999 06:21:21 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: [JDEV] Denial of Service, Spam and Jabber 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 How does jabber deal with unwanted messages, particularly massively repeated ones? Does the server have a squelch list? Daniel From owner-jdev@jabber.org Wed May 12 09:04:33 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id JAA28823 for jdev-list; Wed, 12 May 1999 09:04:33 -0500 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 JAA28820 for ; Wed, 12 May 1999 09:04:31 -0500 Date: Wed, 12 May 1999 09:04:31 -0500 (CDT) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: Re: [JDEV] Denial of Service, Spam and Jabber 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 > How does jabber deal with unwanted messages, particularly massively > repeated ones? > > Does the server have a squelch list? At the moment there is nothing in the server to stop this, but it is definately an issue that will be addressed as Jabber usage ramps up. There will most likely be two areas... performance/usage limits to limit the damage of DOS attacks, and security/preference settings to reduce unwanted messages. These will happen before "1.0", but probably not for the next version or two. Jer From owner-jdev@jabber.org Wed May 12 11:10:49 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id LAA29413 for jdev-list; Wed, 12 May 1999 11:10:49 -0500 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 LAA29409; Wed, 12 May 1999 11:10:41 -0500 Received: from xavier.ups.com (localhost [127.0.0.1]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA19517; Wed, 12 May 1999 11:10:07 -0400 (EDT) Received: from revere4.telecom.ups.com (smtp.field4.ups.com [153.2.2.62]) by xavier.ups.com (8.9.3/8.9.3/UPS) with ESMTP id LAA19492; Wed, 12 May 1999 11:10:04 -0400 (EDT) Received: from revere4.telecom.ups.com (localhost [127.0.0.1]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with ESMTP id LAA15296; Wed, 12 May 1999 11:10:04 -0400 (EDT) Received: from tarot.telecom.ups.com ([10.94.32.98]) by revere4.telecom.ups.com (8.8.8+Sun/8.8.8/UPS) with SMTP id LAA15282; Wed, 12 May 1999 11:10:03 -0400 (EDT) From: "Thomas Charron" To: "Jeremie" Cc: "Jabber Development" Subject: [JDEV] RE: G'morn! :) Date: Wed, 12 May 1999 10:57:58 -0400 Message-ID: <000501be9c87$d42ba260$62205e0a@tarot.telecom.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.3110.3 In-Reply-To: Importance: Normal Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org DESPERATLY trying to finish it.. ;-P I only need to fix ONE problem and it'll be ready. Incoming xpt packets are now processed in their own thread (UBER cool.. When there are xpt packets to process, it starts a new thread, which in turn starts a new Message 'object' that works within an independant thread). The only problem is starting a new thread when a user wants to send a NEW message. For some reason that I have yet to fathom, it produces an Access Violation. Here is what the function call that dies looks like: --- DWORD * dwThreadId; int * Something; ateThread( NULL, // no security attribute 0, // default stack size (LPTHREAD_START_ROUTINE) InstanceNewMessageThread, (LPVOID) Something, // thread parameter 0, // not suspended dwThreadId); // returns thread ID --- InstantNewMessageThread looks like this: --- VOID InstanceNewMessageThread(LPVOID lpvParam) { AfxMessageBox("In New Message Thread"); CNewMessage dlg; int nReturn = dlg.DoModal(); if(nReturn == IDOK) { ServerSocket.SendData("" + dlg.m_To + "" + dlg.m_Subject + "" + dlg.m_Say + "\n\n"); } } --- What dying is when it creates the new thread, which means that the error itself is in the first code snippet. Any ideas? I think that perhaps I'm not initiating the Pointer that is the 'passed argument' correctly. Perhaps I'm just being an idiot. Any idea how to create a Pointer to a void value in C? I think I need to malloc somethingand get the pointer to point to that. I'm not USING the value, so I was trying to throw it SOMETHING.. ;-P Obviously it's only sending basic to/subject/say messages right now, but this is easily extended. Eventually, I'll have the JabberSocket class (An extention of CAsyncSocket) have message sending members of it's own, but for now I just have it using a generic 'SendData' function, that piles up data sends it as it can. The class itself handles blocking etc, itself, as CAsyncSocket provides callbacks when it's ok to send or ok to recieve when you try to send.. Anyway, I'mnot to sure how well you know C++, but my problem here is basic C, and I think I'm just thinking way to hard. Think I'll risk looking like a COMPLETE MORON and CC this to JDev and see if anyone cares to smack some sense into my skull. > -----Original Message----- > From: Jeremie > Sent: Wednesday, May 12, 1999 9:51 AM > To: tcharron@nermail.ups.com > Cc: tcharron@my-dejanews.com > Subject: G'morn! :) > > > Heya, hows the job thing coming along? > > It's been a bit quite lately on jdev, but I've got lots of fun things > coming RSN besides just 0.6. I'll be posting a big plan/outlook tonight > hopefully... > > Other than that, the ICQ and AIM transports are developing nicely, very > very "prototype" like, but still very cool. > > Any luck with the win32 stuff? I wish I had a compiler or knew win32 to > at least offer to help a little :) I'll be creating "teams" on jabber.org > and I think there will be a win32 one, do you think you'll have the time > to lead it? It wont be till late May or early June for sure. > > Anyway, just checking in! > > Thanks! > > Jer > > From owner-jdev@jabber.org Wed May 12 21:40:33 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id VAA32057 for jdev-list; Wed, 12 May 1999 21:40:33 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id VAA32054 for ; Wed, 12 May 1999 21:40:30 -0500 Received: (from djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) id TAA17806; Wed, 12 May 1999 19:56:58 -0700 Date: Wed, 12 May 1999 19:56:58 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: Re: [JDEV] Denial of Service, Spam and Jabber 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 OK, so before 1.0 the server will take care of such things. That's what I needed to know. Thanks. Daniel On Wed, 12 May 1999, Jeremie wrote: > > How does jabber deal with unwanted messages, particularly massively > > repeated ones? > > > > Does the server have a squelch list? > > At the moment there is nothing in the server to stop this, but it is > definately an issue that will be addressed as Jabber usage ramps up. > > There will most likely be two areas... performance/usage limits to limit > the damage of DOS attacks, and security/preference settings to reduce > unwanted messages. These will happen before "1.0", but probably not for > the next version or two. > > Jer > From owner-jdev@jabber.org Thu May 13 19:16:36 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id TAA05598 for jdev-list; Thu, 13 May 1999 19:16:36 -0500 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 TAA05595 for ; Thu, 13 May 1999 19:16:34 -0500 Date: Thu, 13 May 1999 19:16:34 -0500 (CDT) From: Jeremie X-Sender: jeremie@mondo.eppg.com To: jdev@jabber.org Subject: [JDEV] Net::Jabber Perl Module 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 just checked in a preliminary perl module I wrote this afternoon that will greatly ease writing Jabber clients or utility scripts with perl. It will show up in tonight's snapshot at http://jabber.org/download/ for all those that don't use CVS. Warning! I haven't written any perl5 code before(done lots of perl4 stuff) and this is my first .pm ever, so there are likely some major flaws and stupidity, any perl gods out there are welcome to criticize! I have a CPAN account and will be uploading to to CPAN tonight or tomorrow. Cool things: with Net::Jabber and a working Jabber server with ICQ/AIM transports, any SIMPLE perl script can two-way communicate instantly with any ICQ or AIM user! Just one small powerful aspect of Jabber :) Enjoy! Jer From owner-jdev@jabber.org Mon May 17 02:43:34 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id CAA20755 for jdev-list; Mon, 17 May 1999 02:43:34 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-34.dialup.netins.net [209.152.71.163]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id CAA20752 for ; Mon, 17 May 1999 02:43:28 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id AAA00699 for ; Mon, 17 May 1999 00:42:54 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Mon, 17 May 1999 00:42:53 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: [JDEV] GLOBAL 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 Jabber has been making tremendous strides lately thanks to everyone here, and the near future is going to bring this project to a whole new level of activity and interaction as it starts to become usable as a platform. I'll attempt to outline some of the changes that are happening and work that needs to be done to help Jabber grow through and beyond this next stage. Quick outline: --> New Jabber.org Server --> Software/Services Available --> Team/Project Structure --> Web Site --> Documentation --> Languages (perl/java/python/tcl) --> Jabber Architecture Updates --> Transports --> JNIX ========================================= == New Jabber.org Server Jabber.org will be moving to a new dedicated server within the next month. Besides being faster, this new server will allow us to be more flexible in the software we run on the server and the options we have for hosting other projects. I will send updates as this changeover happens. ========================================= == Software/Services Available o) Additional CVS archives will be created and current tree restructured o) Core team members will have ssh access o) Anonymous FTP access to downloadables(and upload for 3rd party projs) o) All mailing lists moved to mailman o) Dedicated Jabber server for developers o) Mirroring system for docs/downloadables ========================================= == Team/Project Structure The current "project" approach used on Jabber.org isn't filling the needs, so there will soon be "teams", "projects", and "developers". Every "team" will be able to oversee and manage multiple projects, such as the Jabber Team will manage Etherx, Jabber Transport, common lib, and other pieces of the main distribution. Each team will be provided the following resources: cvs archive, development list(where CVS checkin messages will be sent), announcement list, downloadable area that's mirrored, web space, news page, and member management resources. The team can have one main project as well as manage other related projects under that team. If the project is small or hosted on a remote site, it can still be listed as an independent project with a main developer and have access to the mirrored downloadable area. ========================================= == Web Site With the new team structure, a "Web Site Team" will be formed to maintain jabber.org. This includes the style/navigation, graphics(adding some), tools, and other related tasks. To work on Jabber.org you need to minimally have experience with HTML4 and CSS, and to work on any of the interactive pieces you'll need to be familiar with php and mysql. As the traffic increases beyond the approx 5k/day, more help will be needed to maintain it and provide a gentle introduction to Jabber. Jabber needs a logo, a hip, groovin, happy, and yet simple logo. What does everyone think of hosting a logo contest? I really don't like choosing a logo that way, but I'm no graphics designer and hence won't be creating a logo any time soon. It would probably need to be a large graphic with icon version and a companion button. Anyone interested in participating here should watch the list for the announcement of a "Web Site Team" in the next few weeks, or if you really want to get started soon, email me. ========================================= == Documentation Similarly as above, a new "Documentation Team" will soon be formed to maintain the bulk of the documentation work everywhere in Jabber. Some of the areas that need some serious work are: + General o) Introduction (gentle, easy to understand) o) Guide (more difficult pieces?) o) FAQ + Development Guides & FAQs + Jabber Architecture + Protocol Beyond this, there's READMEs, man pages, code guides, site help(for the tools available), etc... This may be one of the most critical pieces of Jabber to help it's adoption, especially due to the complexity. Concise, clear, understandable documentation makes a tremendous difference to those attempting to understand it, but its hard to create this documentation without first having something to work with. Again, anyone interested in participating here should watch the list for the announcement of a "Documentation Team" in the next few weeks, or if you really want to get started soon, email me. ========================================= == Languages (perl/java/python/tcl) Having Jabber in as many languages as possible is very important, and it brings a whole new level of real-time messaging functionality to that language. There are three ways every language can take advantage of Jabber: clients, transports, and modules. The clients and transports are fairly straight forward, just a matter of parsing some XML and decoding the protocol. Binding another language as a module on the server side is a bit more challenging(similarly to mod_perl and mod_jserv for Apache) and doesn't bring much new functionality to the language, just allows module authors to choose another language. Utilizing the new team concept, a team will be created for each language base, such as a "Perl Team" and a "Java Team". Interested developers can become part of each team, and all projects(client, transport, module) will be part of their team as well as a base of code utilizing those projects. Right now I have the following four teams: Perl Java Python TCL Please suggest any more! ========================================= == Jabber Architecture Updates There are two major components critical to Jabber that have not been added yet: File Transfers and Information Querying. Both of these will be included in 0.7 and documentation will be posted on how they work. Both of them greatly increase the complexity of the system, and will be optional for clients to implement. With those additions, the Jabber Architecture will be conceptually complete. The only updates will be minor ones brought to the surface during implementation. Anyone building software to interact with Jabber is safe to proceed forward with the assurance that it will not be fundamentally changing any time soon. ========================================= == Transports The MOST important aspect of Jabber, and the most difficult, is transports. Much of the effort of the core team over the next few months will be on transports. Here is a small list of proposed transports: ICQ AIM Yahoo Pager IRC RVP/IMPP (IETF efforts) group (acts like a mailing list) game (shows users playing on a Quake/other game server) After the first couple of transports, and with the addition of other language bindings to build transports easily, there will likely be a large amount of choices here... feel free to suggest more. Currently I have a proof-of-concept ICQ and AIM transport working here at home. All I can say is that it is truly amazing to log in using a simple Jabber client and see yourself show up online in ICQ and AIM, and be able to send messages transparently everywhere. I'll clean up the code and post it soon, so that work can get underway on the REAL ICQ and AIM transports. ========================================= == JNIX This is a secret new project that I've been harboring for some time now, and is an extension of the previous "client lib" discussions. The main jist of JNIX is to produce a Jabber compatible "service" for unix systems that is transparently compatible with the old-style unix services of talk, finger, and who. This new service, JNIX, is aimed to be a drop-in replacement for any unix based system, to upgrade the old-style services with new functionality and operate on the global Jabber network. JNIX then can be adopted by any unix distribution, Linux or otherwise, and that distribution will have a fully compatible(with old finger/talk) instant messaging suite. This is a big step for Jabber, and yet a natural progression of finger/talk. Soon I'll send this proposal and create the JNIX team. ========================================= That's all for now! It might be quiet on this list, but it's definately busy in the background! Thanks, Jer From owner-jdev@jabber.org Sun May 23 12:15:14 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id MAA21001 for jdev-list; Sun, 23 May 1999 12:15:14 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id MAA20998 for ; Sun, 23 May 1999 12:15:12 -0500 Received: (from djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) id KAA04796; Sun, 23 May 1999 10:33:38 -0700 Date: Sun, 23 May 1999 10:33:38 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: [JDEV] Online notification? 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 How can a client know which members of a roster are online? Daniel From owner-jdev@jabber.org Sun May 23 22:41:24 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id WAA22618 for jdev-list; Sun, 23 May 1999 22:41:24 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-45.dialup.netins.net [209.152.71.174]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id WAA22615 for ; Sun, 23 May 1999 22:41:21 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id UAA07156 for ; Sun, 23 May 1999 20:42:39 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sun, 23 May 1999 20:42:37 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] Online notification? 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 It will receive a packet such as: or optionally with more info: > > or optionally with more info: > > ; Tue, 25 May 1999 17:10:39 -0500 From: cce3@cornell.edu Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by travelers.mail.cornell.edu (8.8.8/8.8.5) with SMTP id RAA07770 for ; Tue, 25 May 1999 17:10:38 -0400 (EDT) Date: Tue, 25 May 1999 17:10:38 -0400 (EDT) X-Sender: cce3@travelers.mail.cornell.edu To: jdev@jabber.org Subject: Re: [JDEV] legal? In-Reply-To: <19990524043919.2064.rocketmail@web601.yahoomail.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 plus, AOL's protocol for AIM has been publicized by the (surprisingly) nice people at AOL. they encourage alternate client development and link to other AIM clients from their webpage. On Sun, 23 May 1999, bod williams wrote: > > Hi everyone I'm new to this list! > > Anyways I was wondering is this whole project legal, I mean just the > part with being able to communicate with the ICQ, AOL, etc. clients? > Like isn't there any copyright infringement with the use of their > protocols or whatever? Am I missing something here? > > Bod > _____________________________________________________________ > Do You Yahoo!? > Free instant messaging and more at http://messenger.yahoo.com > From owner-jdev@jabber.org Sat May 29 08:21:25 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id IAA17418 for jdev-list; Sat, 29 May 1999 08:21:25 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id IAA17415 for ; Sat, 29 May 1999 08:21:23 -0500 Received: from localhost (djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) with ESMTP id GAA18755 for ; Sat, 29 May 1999 06:40:54 -0700 Date: Sat, 29 May 1999 06:40:54 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: Re: [JDEV] Online notification? 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 think I've got an instance where it shouldn't be sent, but is. I have multiple instances of my jabber client running, all on the same machine and talking to a jabbertransport also on the same machine. I don't even have a rosters.xml file, so theoretically nobody should get notifications. Nevertheless, whenever any client sends an online notification, all other online clients recieve it. Also, it would be convenient if the act of deleting somebody from your roster sent you a status=offline from them. Is that a possibility? Daniel On Mon, 24 May 1999, Jeremie wrote: > > > I haven't been getting this in my experimentation with 0.6. What are the > > conditions that this happens under? > > Two things... the client that just came online has to send it, and > secondly, the recipient must be on the client's roster. As soon as the > server receives a type="online" packet it forwards it to all of the users > on the roster and to any of the user's own sessions. > > Let me know if you find an instance where you think it should be sent and > isn't, there might be a problem with the algorythm yet. > > Jer > From owner-jdev@jabber.org Sat May 29 13:58:24 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id NAA18130 for jdev-list; Sat, 29 May 1999 13:58:24 -0500 Received: from ziggy.jeremie.com (jer@cscd-02-16.dialup.netins.net [209.152.71.145]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id NAA18127 for ; Sat, 29 May 1999 13:58:21 -0500 Received: from localhost (jer@localhost) by ziggy.jeremie.com (8.8.7/8.8.7) with ESMTP id MAA12184 for ; Sat, 29 May 1999 12:01:07 -0500 X-Authentication-Warning: ziggy.jeremie.com: jer owned process doing -bs Date: Sat, 29 May 1999 12:01:06 -0500 (CDT) From: Jeremie To: jdev@jabber.org Subject: Re: [JDEV] Online notification? 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 think I've got an instance where it shouldn't be sent, but is. > I have multiple instances of my jabber client running, all on the same > machine and talking to a jabbertransport also on the same machine. I don't > even have a rosters.xml file, so theoretically nobody should get > notifications. Nevertheless, whenever any client sends an online > notification, all other online clients recieve it. Well, the only way that should be is if you logged in every time with the same user account, so each connection(session) is all under your userid. In that case the server will automatically notify yourself of any of your own chnages. If that's not the case, it's a bug, and grab a snapshot to email me from the debug (-D) output of the jabbertransport when you send a status, and I'll check it out. > Also, it would be convenient if the act of deleting somebody from your > roster sent you a status=offline from them. Is that a possibility? Sure, these are often module-level issues. The server doesn't really contain much of the intelligence itself, most of it is offloaded to the modules. This is something I'll stick in the docs for building modules though, since it's something all of them should be doing. Jer From owner-jdev@jabber.org Sat May 29 14:03:16 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18176 for jdev-list; Sat, 29 May 1999 14:03:16 -0500 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.dtu.dk [130.225.71.227]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA18161 for ; Sat, 29 May 1999 14:03:09 -0500 Message-Id: <199905291903.OAA18161@mondo.eppg.com> Received: (qmail 11582 invoked from network); 29 May 1999 18:03:10 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 29 May 1999 18:03:10 -0000 Received: from traume.nybro.dk (traume.nybro.k-net.dk [192.38.223.123]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LBXVLAZF; Sat, 29 May 1999 20:01:20 +0200 From: tue@traume.nybro.dk Date: tor 04 feb 22:50:29 1999 +0200 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 X-XCmail-Status: Tr 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 Sat May 29 14:03:17 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18177 for jdev-list; Sat, 29 May 1999 14:03:17 -0500 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.dtu.dk [130.225.71.227]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA18163 for ; Sat, 29 May 1999 14:03:09 -0500 Message-Id: <199905291903.OAA18163@mondo.eppg.com> Received: (qmail 11586 invoked from network); 29 May 1999 18:03:11 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 29 May 1999 18:03:11 -0000 Received: from traume.nybro.dk (traume.nybro.k-net.dk [192.38.223.123]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LBXVLAZJ; Sat, 29 May 1999 20:01:21 +0200 From: tue@traume.nybro.dk Date: søn 07 feb 18:38:03 1999 +0200 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 X-XCmail-Status: Tr 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 Sat May 29 14:03:20 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18184 for jdev-list; Sat, 29 May 1999 14:03:20 -0500 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.dtu.dk [130.225.71.227]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA18162 for ; Sat, 29 May 1999 14:03:09 -0500 Message-Id: <199905291903.OAA18162@mondo.eppg.com> Received: (qmail 11591 invoked from network); 29 May 1999 18:03:11 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 29 May 1999 18:03:11 -0000 Received: from traume.nybro.dk (traume.nybro.k-net.dk [192.38.223.123]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LBXVLAZL; Sat, 29 May 1999 20:01:21 +0200 From: tue@traume.nybro.dk Date: søn 07 feb 18:47:07 1999 +0200 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 X-XCmail-Status: Tr 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 Sat May 29 14:03:18 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id OAA18178 for jdev-list; Sat, 29 May 1999 14:03:18 -0500 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.dtu.dk [130.225.71.227]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id OAA18160 for ; Sat, 29 May 1999 14:03:09 -0500 Message-Id: <199905291903.OAA18160@mondo.eppg.com> Received: (qmail 11580 invoked from network); 29 May 1999 18:03:10 -0000 Received: from odin.pop.k-net.dk (192.38.220.3) by eising.k-net.dk with SMTP; 29 May 1999 18:03:10 -0000 Received: from traume.nybro.dk (traume.nybro.k-net.dk [192.38.223.123]) by odin.pop.k-net.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LBXVLAZD; Sat, 29 May 1999 20:01:20 +0200 From: tue@traume.nybro.dk Date: tor 04 feb 21:44:26 1999 +0200 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 X-XCmail-Status: Tr 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 Sat May 29 22:12:49 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id WAA19260 for jdev-list; Sat, 29 May 1999 22:12:49 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from wvc-omak.ctc.edu (djarb@wvc-omak.ctc.edu [134.39.155.250]) by mondo.eppg.com (8.8.7/8.8.7) with SMTP id WAA19257 for ; Sat, 29 May 1999 22:12:47 -0500 Received: from localhost (djarb@localhost) by wvc-omak.ctc.edu (8.6.12/8.6.9) with ESMTP id UAA19586 for ; Sat, 29 May 1999 20:32:25 -0700 Date: Sat, 29 May 1999 20:32:25 -0700 (PDT) From: Daniel Arbuckle To: jdev@jabber.org Subject: Re: [JDEV] Online notification? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="663157403-1268434179-928035145=:19580" Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --663157403-1268434179-928035145=:19580 Content-Type: TEXT/PLAIN; charset=US-ASCII > > I think I've got an instance where it shouldn't be sent, but is. > > I have multiple instances of my jabber client running, all on the same > > machine and talking to a jabbertransport also on the same machine. I don't > > even have a rosters.xml file, so theoretically nobody should get > > notifications. Nevertheless, whenever any client sends an online > > notification, all other online clients recieve it. > > Well, the only way that should be is if you logged in every time with the > same user account, so each connection(session) is all under your userid. > In that case the server will automatically notify yourself of any of your > own chnages. Nope, seperate userids. > If that's not the case, it's a bug, and grab a snapshot to email me from > the debug (-D) output of the jabbertransport when you send a status, and > I'll check it out. Attached. > > Also, it would be convenient if the act of deleting somebody from your > > roster sent you a status=offline from them. Is that a possibility? > > Sure, these are often module-level issues. The server doesn't really > contain much of the intelligence itself, most of it is offloaded to the > modules. This is something I'll stick in the docs for building modules > though, since it's something all of them should be doing. OK. In other words, it's a behavior that I can rely on in the future? Daniel --663157403-1268434179-928035145=:19580 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=out Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Output from jabbertransport Content-Disposition: attachment; filename=out W1NhdCBNYXkgMjkgMTk6MjY6NDUgMTk5OV0gbGliICJuZXdfZGF0YV9mcm9t PTEyNy4wLjAuMSINCltTYXQgTWF5IDI5IDE5OjI2OjQ1IDE5OTldIG1haW4g ImRpc3BhdGNoX2RhdGE9PGphYmJlciB2ZXJzaW9uPSJQeXJlL1B5dGhvbiAw LzAiIHByb3RvY29sPSIxOTk5MDUwNSI+DQoiDQpbU2F0IE1heSAyOSAxOToy Njo0NSAxOTk5XSBtYWluICJQcm9jZXNzaW5nIE5vcm1hbGx5Ig0KW1NhdCBN YXkgMjkgMTk6MjY6NDUgMTk5OV0gbGliICJuZXdfcGFja2V0PTw/eG1sIHZl cnNpb249JzEuMCc/PjxqYWJiZXIgdmVyc2lvbj0iSmFiYmVyVHJhbnNwb3J0 LzAuNiIgcHJvdG9jb2w9IjE5OTkwNTA1Ij4iDQpbU2F0IE1heSAyOSAxOToy Njo0NSAxOTk5XSBsaWIgIndyaXRpbmdfZGF0YV90bz0xMjcuMC4wLjEiDQpb U2F0IE1heSAyOSAxOToyNjo0NSAxOTk5XSBsaWIgIklPOiB3YWl0aW5nIg0K W1NhdCBNYXkgMjkgMTk6MjY6NDUgMTk5OV0gbGliICJuZXdfZGF0YV9mcm9t PTEyNy4wLjAuMSINCltTYXQgTWF5IDI5IDE5OjI2OjQ1IDE5OTldIG1haW4g ImRpc3BhdGNoX2RhdGE9PGxvZ2luPjx1c2VyPmdyZWxwPC91c2VyPjxwYXNz PmZsYWdnPC9wYXNzPjxuaWNrPnppZ2d5PC9uaWNrPjwvbG9naW4+Ig0KW1Nh dCBNYXkgMjkgMTk6MjY6NDUgMTk5OV0gbWFpbiAiUHJvY2Vzc2luZyBOb3Jt YWxseSINCltTYXQgTWF5IDI5IDE5OjI2OjQ1IDE5OTldIG1haW4gImhhbmRs aW5nX25vcm1hbF9wYWNrZXQ9MTI3LjAuMC4xIg0KW1NhdCBNYXkgMjkgMTk6 MjY6NDUgMTk5OV0gbWFpbiAiaGFuZGxlX2xvZ2luIg0KW1NhdCBNYXkgMjkg MTk6MjY6NDUgMTk5OV0gbWFpbiAiZ2V0X2dyb3VwX3VzZXI9Z3JlbHAiDQpb U2F0IE1heSAyOSAxOToyNjo0NSAxOTk5XSBtYWluICJNT0RfVEVTVF9nZXRn cm91cD1ncmVscCINCltTYXQgTWF5IDI5IDE5OjI2OjQ1IDE5OTldIG1haW4g Ik1PRF9HUk9VUD1ncmVscCINCltTYXQgTWF5IDI5IDE5OjI2OjQ1IDE5OTld IG1haW4gImdldF9oYW5kbGVyX2dyb3VwPXVzZXJzIg0KW1NhdCBNYXkgMjkg MTk6MjY6NDUgMTk5OV0gbWFpbiAiaGFuZGxlcl9pbl9tb2R1bGU9bW9kX2Jh c2ljIg0KW1NhdCBNYXkgMjkgMTk6MjY6NDUgMTk5OV0gbWFpbiAiZ2V0X2hh bmRsZXI9bW9kX2Jhc2ljIg0KW1NhdCBNYXkgMjkgMTk6MjY6NDUgMTk5OV0g bWFpbiAiTU9EX0JBU0lDOiBoYW5kbGVyX2F1dGggPWdyZWxwIg0KW1NhdCBN YXkgMjkgMTk6MjY6NDUgMTk5OV0gbWFpbiAiTU9EX0JBU0lDOiBBVVRIIFNV Q0NFU1NGVUwhPSINCltTYXQgTWF5IDI5IDE5OjI2OjQ1IDE5OTldIG1haW4g Im5ld19zZXNzaW9uPWdyZWxwIg0KW1NhdCBNYXkgMjkgMTk6MjY6NDUgMTk5 OV0gbWFpbiAibG9va3VwX3Nlc3Npb249KE5VTEwpIg0KW1NhdCBNYXkgMjkg MTk6MjY6NDUgMTk5OV0gbWFpbiAiZ2V0X2hhbmRsZXJfZ3JvdXA9dXNlcnMi DQpbU2F0IE1heSAyOSAxOToyNjo0NSAxOTk5XSBtYWluICJoYW5kbGVyX2lu X21vZHVsZT1tb2RfYmFzaWMiDQpbU2F0IE1heSAyOSAxOToyNjo0NSAxOTk5 XSBtYWluICJnZXRfaGFuZGxlcj1tb2RfYmFzaWMiDQpbU2F0IE1heSAyOSAx OToyNjo0NSAxOTk5XSBtYWluICJNT0RfQkFTSUM6IGxvZ2luIT1ncmVscCIN CltTYXQgTWF5IDI5IDE5OjI2OjQ1IDE5OTldIG1vZF9iYXNpYyAic3Bvb2xf ZmlsZV9mYWlsdXJlPS91c3IvbG9jYWwvamFiYmVyL3Zhci9ncmVscC5vZmZs aW5lLnhtbCINCltTYXQgTWF5IDI5IDE5OjI2OjQ1IDE5OTldIGxpYiAiSU86 IHdhaXRpbmciDQpbU2F0IE1heSAyOSAxOToyNjo0NiAxOTk5XSBsaWIgIm5l d19kYXRhX2Zyb209MTI3LjAuMC4xIg0KW1NhdCBNYXkgMjkgMTk6MjY6NDYg MTk5OV0gbWFpbiAiZGlzcGF0Y2hfZGF0YT08c3RhdHVzIHR5cGU9Im9ubGlu ZSI+PHNheT56aWdneSBpcyBoZXJlPC9zYXk+PC9zdGF0dXM+Ig0KW1NhdCBN YXkgMjkgMTk6MjY6NDYgMTk5OV0gbWFpbiAiUHJvY2Vzc2luZyBOb3JtYWxs eSINCltTYXQgTWF5IDI5IDE5OjI2OjQ2IDE5OTldIG1haW4gImhhbmRsaW5n X25vcm1hbF9wYWNrZXQ9MTI3LjAuMC4xIg0KW1NhdCBNYXkgMjkgMTk6MjY6 NDYgMTk5OV0gbWFpbiAiaGFuZGxlX3N0YXR1cyINCltTYXQgTWF5IDI5IDE5 OjI2OjQ2IDE5OTldIG1haW4gImxvb2t1cF9zZXNzaW9uPShOVUxMKSINCltT YXQgTWF5IDI5IDE5OjI2OjQ2IDE5OTldIG1haW4gImxvb2t1cF9zZXNzaW9u PWdyZWxwIg0KW1NhdCBNYXkgMjkgMTk6MjY6NDYgMTk5OV0gbWFpbiAiZ2V0 X2dyb3VwX3VzZXI9Z3JlbHAiDQpbU2F0IE1heSAyOSAxOToyNjo0NiAxOTk5 XSBtYWluICJnZXRfaGFuZGxlcl9ncm91cD11c2VycyINCltTYXQgTWF5IDI5 IDE5OjI2OjQ2IDE5OTldIG1haW4gImhhbmRsZXJfaW5fbW9kdWxlPW1vZF9i YXNpYyINCltTYXQgTWF5IDI5IDE5OjI2OjQ2IDE5OTldIG1haW4gImdldF9o YW5kbGVyPW1vZF9iYXNpYyINCltTYXQgTWF5IDI5IDE5OjI2OjQ2IDE5OTld IG1haW4gIk1PRF9CQVNJQ19zdGF0dXNvdXRfZnJvbSE9Z3JlbHAiDQpbU2F0 IE1heSAyOSAxOToyNjo0NiAxOTk5XSBtYWluICJnZXRfZ3JvdXBfdXNlcj1n cmVscCINCltTYXQgTWF5IDI5IDE5OjI2OjQ2IDE5OTldIG1haW4gImdldF9o YW5kbGVyX2dyb3VwPXVzZXJzIg0KW1NhdCBNYXkgMjkgMTk6MjY6NDYgMTk5 OV0gbWFpbiAiaGFuZGxlcl9pbl9tb2R1bGU9bW9kX2Jhc2ljIg0KW1NhdCBN YXkgMjkgMTk6MjY6NDYgMTk5OV0gbWFpbiAiZ2V0X2hhbmRsZXI9bW9kX2Jh c2ljIg0KW1NhdCBNYXkgMjkgMTk6MjY6NDYgMTk5OV0gbWFpbiAiTU9EX0JB U0lDX3N0YXR1c2luX3RvIT1ncmVscCINCltTYXQgTWF5IDI5IDE5OjI2OjQ2 IDE5OTldIG1haW4gImxvb2t1cF9zZXNzaW9uPWdyZWxwIg0KW1NhdCBNYXkg MjkgMTk6MjY6NDYgMTk5OV0gbWFpbiAiRGVsaXZlcmluZyBMb2NhbGx5Ig0K W1NhdCBNYXkgMjkgMTk6MjY6NDYgMTk5OV0gbGliICJuZXdfcGFja2V0PTxz dGF0dXMgdHlwZT0nb25saW5lJz48c2F5PnppZ2d5IGlzIGhlcmU8L3NheT48 ZnJvbSBuaWNrPSd6aWdneSc+Z3JlbHA8L2Zyb20+PC9zdGF0dXM+Ig0KW1Nh dCBNYXkgMjkgMTk6MjY6NDYgMTk5OV0gbWFpbiAiZ2V0X2dyb3VwX3VzZXI9 Z3JlbHAiDQpbU2F0IE1heSAyOSAxOToyNjo0NiAxOTk5XSBtYWluICJnZXRf aGFuZGxlcl9ncm91cD11c2VycyINCltTYXQgTWF5IDI5IDE5OjI2OjQ2IDE5 OTldIG1haW4gImhhbmRsZXJfaW5fbW9kdWxlPW1vZF9iYXNpYyINCltTYXQg TWF5IDI5IDE5OjI2OjQ2IDE5OTldIG1haW4gImdldF9oYW5kbGVyPW1vZF9i YXNpYyINCltTYXQgTWF5IDI5IDE5OjI2OjQ2IDE5OTldIG1haW4gIk1PRF9C QVNJQ19zdGF0dXNpbl90byE9Z3JlbHAiDQpbU2F0IE1heSAyOSAxOToyNjo0 NiAxOTk5XSBtYWluICJsb29rdXBfc2Vzc2lvbj1ncmVscCINCltTYXQgTWF5 IDI5IDE5OjI2OjQ2IDE5OTldIG1haW4gIkRlbGl2ZXJpbmcgTG9jYWxseSIN CltTYXQgTWF5IDI5IDE5OjI2OjQ2IDE5OTldIGxpYiAibmV3X3BhY2tldD08 c3RhdHVzPjxzYXk+SGkgZXZlcnlib2R5PC9zYXk+PGZyb20gbmljaz0nRGFu aWVsJz5kamFyYjwvZnJvbT48L3N0YXR1cz4iDQpbU2F0IE1heSAyOSAxOToy Njo0NiAxOTk5XSBsaWIgIndyaXRpbmdfZGF0YV90bz0xMjcuMC4wLjEiDQpb U2F0IE1heSAyOSAxOToyNjo0NiAxOTk5XSBsaWIgIndyaXRpbmdfZGF0YV90 bz0xMjcuMC4wLjEiDQpbU2F0IE1heSAyOSAxOToyNjo0NiAxOTk5XSBsaWIg IklPOiB3YWl0aW5nIg0KDQo= --663157403-1268434179-928035145=:19580-- From owner-jdev@jabber.org Mon May 31 18:09:31 1999 Received: (from majordomo@localhost) by mondo.eppg.com (8.8.7/8.8.7) id SAA25859 for jdev-list; Mon, 31 May 1999 18:09:31 -0500 X-Authentication-Warning: mondo.eppg.com: majordomo set sender to owner-jdev@jabber.org using -f Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mondo.eppg.com (8.8.7/8.8.7) with ESMTP id SAA25856 for ; Mon, 31 May 1999 18:09:28 -0500 Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by mail-blue.research.att.com (Postfix) with ESMTP id B66094CE07; Mon, 31 May 1999 18:09:27 -0400 (EDT) Received: from research.att.com ([135.207.8.82]) by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id SAA17587; Mon, 31 May 1999 18:09:22 -0400 (EDT) Message-ID: <375307B2.2D10D9D6@research.att.com> Date: Mon, 31 May 1999 18:05:38 -0400 From: Vijay Saraswat Organization: AT&T X-Mailer: Mozilla 4.07 [en] (WinNT; U) MIME-Version: 1.0 To: jdev@jabber.org Cc: dave@marvit.org Subject: [JDEV] Instant Messaging and Presence Protocol (impp) Charter Content-Type: multipart/mixed; boundary="------------4FD0C3E9D9E528D701262BC9" Sender: owner-jdev@jabber.org Precedence: bulk Reply-To: jdev@jabber.org This is a multi-part message in MIME format. --------------4FD0C3E9D9E528D701262BC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks ---- I would like to draw your attention to the IMPP Working Group (http://www.ietf.org/html.charters/impp-charter.html) of the Internet Engineering Task Force (IETF, http://www.ietf.org), and encourage you to participate. To participate, get onto the mailing list, browse through the archive, understand the issues currently being discussed, and contribute. The group is currently considering an Internet drafts formalizing the requirements for an Internet-wide protocol for Instant Messaging and Presence Notification: http://www.ietf.org/internet-drafts/draft-ietf-impp-model-00.txt http://www.ietf.org/internet-drafts/draft-ietf-impp-reqts-00.txt (In addition, an email message summarizing possible architectures that have come up during consideration has been circulated by Jim Malcolm.) The WG will meet at the IETF meeting in Oslo; in addition a meeting has been called by Mark Day of Lotus in Boston on June 11 to obtain feedback on the requirements document. Again, details are in the archives. If you wish to attend, write to Mark at Mark_Day/CAM/Lotus@lotus.com before June 4. If you are new to the IETF, please spend some time familiarizing yourself with the IETF; see in particular http://www.ietf.org/tao.html. Please let me know if you have questions. Best regards, Vijay Saraswat -- Try http://intercom.att.com! Home-page: http://www.research.att.com/~vj --------------4FD0C3E9D9E528D701262BC9 Content-Type: text/html; charset=us-ascii; name="impp-charter.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="impp-charter.html" Content-Base: "http://www.ietf.org/html.charters/impp -charter.html" Instant Messaging and Presence Protocol (impp) Charter

Instant Messaging and Presence Protocol (impp)

Last Modified: 26-Feb-99

Chair(s):

Vijay Saraswat <vj@research.att.com>
Dave Marvit <dave@marvit.org>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Patrik Faltstrom <paf@swip.net>

Mailing Lists:

General Discussion:impp@iastate.edu
To Subscribe: impp-request@iastate.edu
Archive: http://lists.fsck.com/cgi-bin/wilma/pip

Description of Working Group:

This working group will eventually define protocols and data formats necessary to build an internet-scale end-user presence awareness, notification and instant messaging system. Its initial task is to determine specific design goals and requirements for such a service. The design goals document will be submitted for IETF-wide review, and based on that review, the group's charter will be extended.

Background:

Instant messaging differs from email primarily in that its primary focus is immediate end-user delivery. Presence information was readily accessible on internet-connected systems years ago; when a user had an open session to a well-known multi-user system, his friends and colleagues could easily tell where he was connected from and whether he was using his computer. Since that time, computing infrastructure has become increasingly distributed and a given user may be consistently available," but has no standard way to make this information known to her peers. This working group will design a system to address this need.

Goals:

The working group will develop an architecture for simple instant messaging and presence awareness/notification. It will specify how authentication, message integrity, encryption and access control are integrated. It is desirable, but not required, for the working group to develop a solution that works well for awareness of and communication with entities other than human users.

Non-goals:

Providing a general notification mechanism for data other than user presence information and instant messages.

The following keywords describe the scope for the working group. Details are to be developed in the architecture document which is the output of this working group:

- PRESENCE

- INSTANT MESSAGING

- SHARED

- NAMING

- AUTHENTICATION

- ACCESS CONTROL

- SCALABILITY

Deliverables:

The working group plans to deliver the following document:

- Requirements for Instant Messaging and Presence

Goals and Milestones:

May 99   Submit Internet-Draft of Design Goals for Instant Messaging and Presence Information
Jul 99   Submit design goals Internet-Draft to IESG for publication as an RFC

Internet-Drafts:

A Model for Presence and Instant Messaging (16516 bytes)
Instant Messaging / Presence Protocol Requirements (35568 bytes)

No Request For Comments


IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to working group directory.

Return to IETF home page. --------------4FD0C3E9D9E528D701262BC9--