[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Auth]A Proposal for a Solution (please read the end at least )

From: Nick Lothian
Subject: RE: [Auth]A Proposal for a Solution (please read the end at least )
Date: Mon, 16 Jul 2001 14:41:54 +0930

(Removed the cross post, because I'm not subscribed to developers)

I had a poke around in the (Delphi client) Jabber code back last year. It
seems to have taken off a lot since then.

> No one can even control the naming system, since this follows email as
> well, using the well-known user*host.domain naming convention, instead
> of 'global' names like AIM's 'Adam Theo 2000' or ICQ's '3617306'. So
> no-one controls the naming system of it anymore than they can now.

Don't you guys do mapping between things like AOL-IM identities, Yahoo IDs
and Jabber IDs? Or am I smoking something and it is just that the client is
compatible with non-Jabber forms of transport.

Where are the identity relationships stored?

> And for Authentication and Identity for the Jabber system, 
> this is being
> taken care of, as well. By none other than myself and a small group of
> others who are making fast progress on an open, flexible, 
> powerful, and
> very secure Identity system that runs using Jabber. For more 
> information
> on this, head over to .

I wasn't aware of this. 

I quite like your "TicketPlan"
( and the
"SimplePlan" ( The
"ImmerPlan" looks nice, but relies too much on Jabber Forms to be useful in
the general case.

All those plans sound like they have had a good deal of though go into them,

For those of you that haven't read them I should point out that there is
nothing in them that ties them to Jabber or any form of instant messaging at
all (apart from the ImmerPlan). They are just schenarios for ways a user
could get access to a system, and could be run over HTTP posts, XML-RPC,
SOAP or Jabber.  Jabber does have (I think) some ID infrastructure already
exisiting, though.

However, all the plans outlined do require some form of non-HTML programming
for the webmaster to implement them. I don't think that is a bad thing, but
it does move us away from the simple just-do-some-HTML-stuff thing that has
been put forward here. (Although it could be implemented as an Apache Module
- since that seems to be everyone's favourite catchcry for some reason).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]