[JDEV] Extended error handling
Colin Madere
colin at vedalabs.com
Thu Dec 7 13:00:04 CST 2000
Thanks David and Keith. The adding of the e<x>tended namespace tag makes
perfect sense for us. Smacked myself in the head when I read that, seems so
obvious now.
As for the jabber:iq:register response to give client info on what feilds
are required and optional, we're simply adding a "required='yes|no'"
attribute for now. If a later Jabber version comes out supporting something
like what you suggested, David, we'll certainly moved to that.
Thanks again to you both.
Colin Madere
-----Original Message-----
From: Keith Minkler [mailto:keith at digix.dyndns.org]
Sent: Wednesday, December 06, 2000 9:34 PM
To: jdev at jabber.org
Subject: Re: [JDEV] Extended error handling
Hrmm..
That isn't following the DTD for the error tag, which (though i cannot find
it right now) states that the contents of the <error/> tag may only be
CDATA.. (also error codes may be found at
http://docs.jabber.org/jpg/referror.html). Instead, as long as you are
writing both a custom server and client, it would probably be most protocol
friendly for you to use <x/> tags to extend the error... such as:
<iq type='error' id='1002'>
<query xmlns='jabber:iq:register'>
<username>newuser</username>
<email>spoon at fed.com</email>
<password>babyfood</password>
</query>
<error code='406'>Not Acceptable</error>
<x xmlns='custom:ns:error'>
<field_error>
<name>firstname</name>
<errortype>nodata</errortype>
<description>First name may not be left blank</description>
</field_error>
<field_error>
<name>lastname</name>
<errortype>nodata</errortype>
<description>Last name may not be left blank</description>
</field_error>
</x>
</iq>
this way, you are not violating the <error/> tag's DTD, and your custom
client may look for the <x/> tag with your given xmlns attribute.
this way you can extend the jabber protocol, without breaking clients that
do not support your features, by simply defining your own namespace and DTD
Keith Minkler
On Wed, Dec 06, 2000 at 07:16:08PM -0600, Colin Madere wrote:
>
> Hello JDEV,
>
> My group is currently extending the error reporting (and field
requirements)
> of the registration process in the Jabberd code. We're implementing a
> server and client that requires more fields than the default
> (username/password) and we need to report more detailed errors for these
> added fields.
>
> Basically, we have something working but I don't think it's clean enough.
> If there's suggestions, I'd like to hear them (on tag naming and
hierarchy,
> mainly).
>
> Here's an example of a registration request error returned to the client
> containing extended error codes for multiple fields:
>
> <iq type='error' id='1002'>
> <query xmlns='jabber:iq:register'>
> <username>newuser</username>
> <email>spoon at fed.com</email>
> <password>babyfood</password>
> ....possibly more fields here....
> <key>3be0ed5fa106e18761cb22baec2715baa60b217c</key>
> </query>
> <error code='xxx'>
> <field_error>
> <name>firstname</name>
> <errortype>nodata</errortype>
> <description>First name may not be left blank</description>
> </field_error>
> <field_error>
> <name>lastname</name>
> <errortype>nodata</errortype>
> <description>Last name may not be left blank</description>
> </field_error>
> </error>
> </iq>
>
> A standard error code looks like:
>
> <error code='xxx'>Username not available</error>
>
> What mainly bugs me is the <field_error/> section...
>
> ** Also, any suggestions or resources for error codes? Currently we're
just
> using arbitrarily chosen unused codes.
>
> Colin Madere
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20001207/00699852/attachment-0002.htm>
More information about the JDev
mailing list