"Matthew A. Miller" <[EMAIL PROTECTED]> wrote on 26-2- 2003 2:42:45: > >The more I read this thread, the more I agree with both sides... > >Is there middle ground to be had? What if XMPP were defined in such a >way that if a connection/session attempted to auth as an already online >one, it was up to the server. If the server decided it was allowed, it >sent the appropriate iq-error to the original connection (302?) along >with the disconnect. If the server decided it wasn't, it sent a 409 or >405 iq-error to the new connection along with the diconnect. > >Does the above sound reasonable? If so, I'll make a point of >approaching the XMPP I-D authors on it.
In the current XMPP spec (draft-ietf-xmpp-core-04) we can find this: " The following codes are defined for stream-level errors: 302 - Redirect 400 - Bad XML 404 - Unknown Host 410 - Gone 500 - Internal Server Error 505 - Version Not Supported " I'd like to see 409 included here as well. 409 is already including amongst the standard error, so it's can be used for denying authentication: " 409 (Conflict) - Code 409 is returned when a request cannot be fulfilled because of an inherent conflict (e.g., because a client attempts to authorize a resouce name that is already in use). " The description would have to be changed a little too since it's not request-specific anymore. -- Tijl Houtbeckers Software Engineer @ Splendo The Netherlands _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
