[standards-jig] Outstanding Issues
jeremie at jabber.org
Tue Jul 9 20:40:39 UTC 2002
> Hi Thomas, this was a well-needed post. Thanks.
Agreed, thanks for the pokage :)
> > #2) Browse/Disco - Similar but different. Seems there might be a way
> > to find a common ground, but there has been some tension about the
> > creation of Disco. Do we need a group hug and then mind melding time?
> > I don't know but it sure would be nice to figure that out =)
> Tension? I didn't notice (well, a little bit, but hey, these are emotive
> subjects. What do we need RL for? ;-) I never saw anything bad in Disco,
> apart from overlap with Browse. But that's always going to happen with
> progressive protocol development. So what's the deal?
The deal was that browse was on the standards track and most of the way of
through being positively voted on (after delicate negotiations :) and then
all of a sudden it magically became informational, coincidentally the
same time disco was proposed. I don't mind working towards a better set
of mechanisms, but we could have had an already tested and working
standard to use in the meantime.
> > #4) Packet Headers - status update?
There is a lot of potential in this one, particularly for mailing-list
style support, client driven spontaneous conference rooms (like msn and
the new ichat, just invite additional people into any chat), better
tracking, forwarding, etc.
> > #5) i18n - another idle, any status?
I think the JEP just needs updating to be simplified as a first step, if
Max doesn't get a chance soon I can hack it up as well.
> > #6) SASL - Should be going to vote shortly, since last call ends
> > tomorrow.
I think I volunteered to add a section/paragraph demonstrating SASL usage
for any stream, such as component-server or server-server, not just
> > #7) Improved semantics for offline msgs and msg storage - JEP 13
> > touched on this, but it seemed to die away. This is one of those
> > selfish ones, but a lot more people seem interested in it recently as
> > well.
The xdbid namespace thing is very strange in that JEP, but the concept is
good. I've always wanted to apply the same idea to any message archive
and access to it, a namespace that handles a simple subset of
pop/imap/nntp, allowing a client to display a box of messages (could be
your offline messages, server message board, conference room history,
mailing list gateway, newsgroups, view of your imap folders,
slashdot/webboard comments, and so on). If it's simple enough to get a
few clients to support it and build some services to use it, it could be
quite handy, and if you need anything beyond it's simple offerings, use
> the areas of how mod_xml could be improved/changed, and offline store-n-
> forward of IQs (and packets generally, selectively).
Eek, yes, I forgot I was going to experimentally support store-n-forward
IQs via watching for x:expire on packets to disconnected resources, I'll
try to play with that soon before I forget again.
More information about the Standards