[JDEV] Extended error handling

[David Waite]

Two comments:
First, you would probably want to have the field errors be handled
client-logic side as much as possible. There is no need for a round-trip
with the server if you can adequately set additional information on
fields.

Ryan Eatmon and Peter Millard were both working on a more sophisticated
method for form entry (for registration and searches). You may with to
contact them for additional information, and to see what would needed to
wedge as much client side logic as possible in. These would be made
available within newer namespaces (something like a jabber:iq:form)

For instance, you could change

<firstname></firstname> within the jabber:iq:register response with

<field type='text' mask='no' required='yes' label="firstname'/>

Then in a user interface you could indicate something similar to 'fields
with stars (*) next to them are required for registration', and grey out
the 'Register' button until the '*firstname' field was entered. This
would allow for much more intuitive UI design.

Second is the issue of error reporting. I wish I could recommend a way
to do this that wouldn't hurt existing clients, but that is difficult.
Within the (imaginary) DTD of the Jabber protocol, error does not
contain mixed content. Attempting to do this would at very least break
my library (JabberBeans) so that incorrect data was returned.

It would be better to attach a new xmlns to the error so at least
clients could filter and expect that erroneous content.

Also, within the (imaginary) XML Schema for the Jabber Protocol, more
than one XML namespace embedded within a query tag is not allowed (as
Keith recommended, I believe.)

I would probably propose something like the following:

<erroneous iq ommited>

<iq type='error' id='whatever123' to='whoever at wherever'><error
code="409">Not Acceptable</error><regerr
xmlns="custom:reg:error"><message>Field 'first name' was left
blank.</message><message>Field 'last name' was left
blank</message></regerr></iq>

The original data isn't really needed as this same client just sent it
and is probably waiting on the response. So just substitute the xml
namespace data with extended error reporting, and match up the response
by the id attribute.

-David Waite

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20001206/efca5401/attachment-0002.htm>