Subject: [xmpp] 6122bis: error handling

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Jul 2011 14:04:45 -0600

As far as I can see, most i18n-related error conditions fall into the
following categories:

1. Initiating entity includes a non-conforming JID in the 'from' or 'to'
attribute of a stream header. Handle via <improper-addressing/> stream
error?

2. [I assume that TLS-related errors will be handled at that layer.]

3. Client includes a non-conforming authcid or authzid in a SASL
authentication request. Handle via <not-authorized/> SASL error, or do
we need a new condition?

4. Client attempts to bind a non-conforming resourcepart. Handle via
<jid-malformed/> stanza error, or should the server generate a
conforming resourcepart? (The latter is more friendly.)

5. Server or client includes a non-conforming 'to' or 'from' address on
a stanza. Handle via <jid-malformed/> stanza error?

6. Client includes a non-conforming JID in a JID slot that is not used
for routing purposes (e.g., 'jid' attribute of roster set). Handle via
<jid-malformed/> stanza error? Is checking of such JID slots a MUST or a
SHOULD or a MAY on the part of the server? Do we leave this up to the
relevant XMPP extension?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Waqas Hussain <[email-masked]>
Date: Sun, 17 Jul 2011 00:28:27 +0500

> attribute of a stream header. Handle via <improper-addressing/> stream

+1, that seems appropriate

> 2. [I assume that TLS-related errors will be handled at that layer.]

+1

> authentication request. Handle via <not-authorized/> SASL error, or do

I don't think we need a new condition.

> conforming resourcepart? (The latter is more friendly.)

Both. The choice should be left to implementations/deployments.
Prosody currently does the latter I believe.

> a stanza. Handle via <jid-malformed/> stanza error?

+1

> SHOULD or a MAY on the part of the server? Do we leave this up to the

I'm for <jid-malformed/> if the JID is expected to be used for routing
in the future. A JID being stored in the roster may not be used for
routing when it's being added, but is expected to be used for routing
in the future. Rather than validating every time there's a roster
broadcast, I prefer not letting invalid data in the system at all
(though an invalid JID would have a hard time getting a subscription,
but that's besides the point).

There is the question of who enforces this. Only the entity actually
processing the data should return an error, and any intermediate
entities which are simply routing it should not.

---

From: Matt Miller <[email-masked]>
Date: Mon, 18 Jul 2011 08:19:20 -0600

> attribute of a stream header. Handle via <improper-addressing/> stream

Seems reasonable.

> authentication request. Handle via <not-authorized/> SASL error, or do

I'd rather use <not-authorized/> than something specific.

> conforming resourcepart? (The latter is more friendly.)

For the most part, I think we can leave it up to implementations.  I can see a server, even if it disregards the requested resource, would want to error the bind request because of "bad characters", with the (possibly erroneous) reasoning that if the client sent bad data once, it'll do it again.

> a stanza. Handle via <jid-malformed/> stanza error?

Seems reasonable.

> SHOULD or a MAY on the part of the server? Do we leave this up to the

There's two things here to consider: what implementations ought to do, and how implementations ought to report the problem.

For the first, I think it's mostly up to the individual specifications the method of enforcement, although the majority of the time the server MUST verify (or Very Bad Things® happen at inopportune times).  I lean toward leaving it to the relevant stewards to help do the Right Thing™ here.

For the second...well, it depends on if we want <jid-malformed/> to only pertain to addressing, or for anywhere a JID is used.  RFC 6120 § 8.3.3.8 only mentions resource binding and addressing as reasons to return this error.  I know some implementations will do different things for different error conditions, so there might be some impact to extending this error condition's reach.

Personally, I'm fine with <jid-malformed/> meaning "anywhere an XMPP address is expected".

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Jul 2011 16:34:32 -0600

Hi Matt,

Your feedback seems consistent with what Waqas posted a few days ago. 
I'll work on appropriate text for the next version of 6122bis.

Peter

On 7/18/11 8:19 AM, Matt Miller wrote:
>> As far as I can see, most i18n-related error conditions fall into
>> the following categories:
>>
>> 1. Initiating entity includes a non-conforming JID in the 'from' or
>> 'to' attribute of a stream header. Handle via<improper-addressing/>
>> stream error?
>
> Seems reasonable.
>
>>
>> authentication request. Handle via<not-authorized/>  SASL error, or
>> do we need a new condition?
>>
>
> I'd rather use<not-authorized/>  than something specific.
>
>> 4. Client attempts to bind a non-conforming resourcepart. Handle
>> via <jid-malformed/>  stanza error, or should the server generate
>> a conforming resourcepart? (The latter is more friendly.)
>
> For the most part, I think we can leave it up to implementations.  I
> can see a server, even if it disregards the requested resource, would
> want to error the bind request because of "bad characters", with the
> (possibly erroneous) reasoning that if the client sent bad data once,
> it'll do it again.
>
>>
>> 5. Server or client includes a non-conforming 'to' or 'from'
>> address on a stanza. Handle via<jid-malformed/>  stanza error?
>>
>
> Seems reasonable.
>
>> 6. Client includes a non-conforming JID in a JID slot that is not
>> used for routing purposes (e.g., 'jid' attribute of roster set).
>> Handle via <jid-malformed/>  stanza error? Is checking of such JID
>> slots a MUST or a SHOULD or a MAY on the part of the server? Do we
>> leave this up to the relevant XMPP extension?
>
> There's two things here to consider: what implementations ought to
> do, and how implementations ought to report the problem.
>
> For the first, I think it's mostly up to the individual
> specifications the method of enforcement, although the majority of
> the time the server MUST verify (or Very Bad Things® happen at
> inopportune times).  I lean toward leaving it to the relevant
> stewards to help do the Right Thing™ here.
>
> For the second...well, it depends on if we want<jid-malformed/>  to
> only pertain to addressing, or for anywhere a JID is used.  RFC 6120
> § 8.3.3.8 only mentions resource binding and addressing as reasons to
> return this error.  I know some implementations will do different
> things for different error conditions, so there might be some impact
> to extending this error condition's reach.
>
> Personally, I'm fine with<jid-malformed/>  meaning "anywhere an XMPP
> address is expected".