Subject: [Wocky] SIPB Jabber

From: "Timothy G. Abbott" <[email-masked]>
Date: Sat, 24 Jun 2006 21:33:57 -0400 (EDT)

Hello,

 	Some SIPB people were planning on working on adding features to 
jabberd that people felt were missing in the current implementation being 
worked on by IS&T.  In particular, people have been talking about the 
following problems (I have not personally verified all of these, so some 
of them are probably rumor.):

 	- the lack of a useful "instance" feature

 	- the lack of something to fill the role of owl (a text-based 
client that can reasonably thread several classes)

 	- the fact that one does not seem to be able to usefully log in 
from more than one place at once.  (currently, it seems to send to the 
most recent place you sent from)

 	- the fact that jabber conferences don't really work like zephyr 
classes: in particular, they don't provide an opportunity for anonymous 
presence.  It should in principle be possible to have conferences working 
both ways, possibly running on different servers/ports.

 	- there doesn't seem to be support for inauthentic sending, or 
logging in with a weird kerberos principal (such as one might want for 
sending authentically as a daemon).

 	We would like to know which of these issues are likely to be 
receiving active development within IS&T before a release.  We don't want 
to step on the toes of IS&T developers, but a lot of people seem to want 
these features, and if there is a coherent set of issues that IS&T is 
unlikely to work on in the future, then we would be happy to direct our 
efforts towards those.  Thanks,

 	-Tim Abbott
 	for the SIPB Jabber effort

---

From: Jacob Morzinski <[email-masked]>
Date: Sat, 24 Jun 2006 22:38:20 -0400

I believe that there is "testing" code on the wocky.mit.edu test server
that addresses the "multiple logins" issue.  Instructions for how to
sign into the test server should be in the list archives.

 -Jacob

---

From: Greg Hudson <[email-masked]>
Date: Mon, 26 Jun 2006 11:57:20 -0400

Hi, Timothy.  Here's what I know.

>  	- the lack of a useful "instance" feature

Do you mean the ability to subscribe to all or a part of a discussion
node, or the ability to tag messages with a topic field within a
discussion node?

The Jabber protocol includes <subject/> and <thread/> elements within
messages, and I believe our server supports them just fine.  This is
more an issue of client support; I think popular Jabber clients
generally do nothing with those fields.

> client that can reasonably thread several classes)

I would dearly love to see Jabber support within owl, and I think kretch
would also like to have that.  (He started working on it, in fact,
although I don't know if he gave up.)  At the moment, I don't know of
any plan to allocate IS&T resources towards making that happen.

jwgc can be used in text mode like zwgc can, and I expect to hack up vt
support for my own use using jwgc, but that's not really a satisfying
end-user solution.

> most recent place you sent from)

We have a change in testing to send messages to bare JIDs to all
connected resources at the highest priority level.  I will try to get
that into production soon.  A more serious problem is not being able to
use the same nickname for multiple resources within a multi-user chat.
I believe that could be solved in practice by the MUC component, but I'm
not sure if JEP 045 has considered the problem.

> both ways, possibly running on different servers/ports.

There may be movement on this front in the future, but I don't think I
can give details.

Certainly, the open source world could use a better implementation of
Jabber multi-user chats than the one we're currently using, and we could
as well.  I've heard of one project in this space (Palaver), but I think
it was stillborn; its dev list only contained traffic in the first month
of the project's life.

> sending authentically as a daemon).

We're concerned about the spam potential of allowing unauthenticated
access; as a federated system, Jabber is more likely to attract spammers
than an obscure local system like Zephyr.  Jabber's solution to spam is
to filter at the domain level (as it's somewhat difficult to forge your
domain), and that only works if domains are authenticating reasonably
well at the user level.

Allowing logins with multi-component Kerberos principals is an easy
problem to solve at a technical level; the hard part is deciding what a
JID should look like for a multi-component principal, since you can't
have a / within a Jabber username.  We would ideally like that decision
made at a standards-body level, but it doesn't look like that's going to
happen easily, so we may just make something up.

> receiving active development within IS&T before a release.

We don't really have a roadmap at the moment; there are some big
unknowns which need to be resolved first.  I would suggest that effort
spent in the client space (working with the upstream client authors) is
least likely to be wasted.

---

From: Timothy G Abbott <[email-masked]>
Date: Mon, 3 Jul 2006 23:39:08 -0400 (EDT)

> support for my own use using jwgc, but that's not really a satisfying

Agreed.  I guess we should probably talk to kretch, since there are all 
sorts of rumors regarding the status of his Jabber in owl efforts.

> not sure if JEP 045 has considered the problem.

Unfortunately, multi-user chat is one of the most important features of 
zephyr, and the one where having more than one resource using the same 
nickname is most useful.

> to filter at the domain level (as it's somewhat difficult to forge your

That seems to be a quite reasonable concern.  Would it be possible to do 
some form of unauthenticated access that only worked inside the MIT 
domain, and required the accessor to be net18?

> least likely to be wasted.

Okay.  Thanks for the extensive information.

 	-Tim Abbott

---

From: Michael Lieberman <[email-masked]>
Date: Tue, 4 Jul 2006 18:54:15 -0400 (EDT)

I believe we care mostly about instances as tags.

Reading RFC 3921, it seems like the <thread/> element is innappropriate to 
serve as an instance:

"The value of the <thread/> element MUST be treated
    as opaque by entities; no semantic meaning may be derived from it,
    and only exact comparisons may be made against it."

The <subject/> element should work, however it goes against Draft 
JEP-0045 (Jabber Enhancement Proposal) that treats <subject/> as a global 
variable of the room. It expects changing the subject to be done 
separately from sending a message. We could write a client that uses it as 
an "instance", but users of the current version of gaim would instead see 
each time the subject "changes".

-Mike