[JDEV] Jabberd 1.5 Development

[Daniel Veillard]

On Tue, Jan 15, 2002 at 06:32:38PM +0100, Fabrice DESRE - FT.BD/FTRD/DMI/GRI wrote:
> Thomas Muldowney wrote:
> > 
> > Hey all it's about time for a new development cycle for jabberd.  This
> > will be under the guise of a 1.5.x series of releases culminating in a
> > 1.6.0 release.  We won't officially start the development until 1.4.2 is
> > tagged in CVS but there is plenty for us to do before that.  My main
> > goal right now is to get the feature list put together that we're
> > working towards.  After discussing with a few of the jdev group idlers
> > we currently have this list:
> > 
> > - General cleanup and standards compliance.  This includes checking all
> >   the error reporting to make sure it makes sense, and all the other
> >   little oddities that have slipped in.
> 
>  Which standards are you talking about ? If you think of the correct
> processing of xml namespaces i'm +1 on this one.

  There is also a large amount of undescribed issues going further than
the XML Namespace specification but lying at the core of XML:
    - what happen with commnets in the XML streams
    - ditto with PI (processing instructions)
    - what about the recommended encodings, is UTF-8 mandatory
    - what about empty tags serialization from an XML point of view
      <hash/> is equivalent to <hash></hash>
    - reserved namespace names, seems jabber reserves those
      starting with "jabber:", however this is unclear what would
      happen in case of unrecognized namespace. Note also that
      "http://jabber.org/" based namespace name would probably
      have been better from a legal point of view...
  
  What I would like to avoid is a reference implementation setting up
the "standard" [*] . What I would like to see as much as possible is a
written description of the part from the underlying spec (XML XMLNs, etc...)
where there is an expected deviation in behaviour during processing.

  I would like to see a freeze in features allowing to write those down
as much as possible, and move the parts which are actaully implemented
and in use from the draft section move into the "standard" section.

  I agree it's not really a jabberd issue, though the process of tightening
the protocol(s) definition would certainly end up changing/cleaning up the
associated code in jabberd.

  If you are really in dire need of ideas to code, I would like to
see how server SSL certificate checking like in https could be done from
the client. It would be great too if the SSL server would react better if
the SSL certificate is not present or readable (it simply don't answer
the client requests without dropping the connexion), and if there was
an official way to bin all interfaces (ACCEPT *) to the SSL port with a single
certificate (something like <ssl port='5223'/> in pthcsock and
<ssl> <key ip='*'>/etc/sysconfig/jabber/jabberkey.pem</key> </ssl>
in the io section). It's just a few things I had to fight with in the
last days. 

  In general though, keep up the good work. Even if this sounds like
a complain, I think the Jabber project is very successful and the jabberd
works well except for some cornercases  !

Daniel

[*] you really don't want to put yourself in the position of maintaining
    such a code base !

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/