Subject: [xmpp] 3920bis: 'from' address on error stanzas

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 May 2010 15:57:40 -0600

RFC 3920 is silent about what goes on the 'from' address of an error
stanza. Here are some possible approaches:

1. The 'from' on the error stanza is just the 'to' on the stanza that
triggered the error.

2. The entity that discovers the error puts its JID in the 'from' on the
error stanza (thus the error stanza could come from your server, a
remote server, a chat service, a pubsub service, etc.).

The second approach seems more helpful, but I'd bet that most
implementations just swap the 'to' and the 'from'...

Peter

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

---

From: Justin Karneges <[email-masked]>
Date: Thu, 6 May 2010 15:16:06 -0700

> 1. The 'from' on the error stanza is just the 'to' on the stanza that

This is the right approach.  At least IQs should always come from the exact 
JID that the stanza was sent to.  I'm pretty sure most implementations 
sending IQs and filtering for responses will filter based on a jid/id pair, 
and not just the id only.

Messages and presence could be allowed some wiggle room (differing resources 
in replies).

---

From: Remko Tronçon <[email-masked]>
Date: Fri, 7 May 2010 14:44:16 +0200

> JID that the stanza was sent to.

Still, I don't think clients would break if they didn't, since all
clients probably always match IDs to map responses to requests (and
ignore the from). The bigger problem is presence and messages, because
I don't think many clients match IDs on those. If a server would
suddenly start putting his JID in the from of messages and presence,
the user wouldn't always be able to tell what message actually went
wrong. So 1 seems safer to me, but on the other hand, confusing that
the message-sending entity is not really in the from attribute.

cheers,
Remko

---

From: Kevin Smith <[email-masked]>
Date: Fri, 7 May 2010 13:51:14 +0100

> remote server, a chat service, a pubsub service, etc.).

I'd love to say (2), because not knowing where the error comes from is
supremely unhelpful, but with ids not needing to be unique, you've
then got no way of matching back to the stanza that caused the error.
We're stuck with (1), I think.

/K

---

From: Matthew Wild <[email-masked]>
Date: Fri, 7 May 2010 13:56:47 +0100

> and not just the id only.

+1.

I think the most common case for example is remote-server-not-found,
which is generated by your server, but appears to be from the original
recipient of your message. I think this works out ok in the end,
despite looking illogical from some angles :)

Matthew

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 7 May 2010 21:57:27 +0900

Hi,

> and not just the id only.

I don't know if they do, but I think it should not be considered the
right way, should it?
An implementation is supposed to filter a response on id only, as far as I know.

2010/5/7 Remko Tronçon <[email-masked]>:
> The bigger problem is presence and messages, because
> wrong.

Yes but the problem is the client anyway here, then. Clients should
keep track of id of messages too (anyway an error message does not
occure that long after a stanza is sent that it would make too much of
id saving). And this is not the user to "tell what message actually
went wront", but one's client to pre-process information and display
it in a useful way to the user (I think this is a common issue that
many software simply display bare error messages to users, thus
completely non-understandable by most people).

So I think in this view, 2/ may be better as it brings more
information of where the problem may come from.

Yet maybe it can also give too much information on some cases, like
for presence leak issues, where you in fact don't want the sender to
know where the problem was coming from (is the recipient online? Does
this recipient exist? etc.).

Maybe I would consider 2/ in a general case and 1/ in specific cases
where security matters (but then it would be explicitely written in
the specific RFC/XEP).
Bye.

Jehan

---

From: Remko Tronçon <[email-masked]>
Date: Fri, 7 May 2010 15:12:49 +0200

> Clients should keep track of id of messages too

For how long? IQs have this nice property that they always need to get
a response; messages don't, which means that you need to track
virtually all message ids indefinitely (since most of them will not
get a response). This is why embedding all the info of the original
message (recipient, body) in the error message has always helped
clients to give useful messages, without memory leaks. The only way to
get rid of this is by forcing message acking.

> So I think in this view, 2/ may be better as it brings more information of where the problem may come from.

... and also drops information (the actual recipient of the message),
meaning you have to keep track of more information in the client.

Anyway, I agree that 2 would probably have been nicer theoretically,
but I think we might be breaking quite some things, and making error
reporting quite a bit harder (if not impossible to do correctly
without leaks).

cheers,
Remko

---

From: Kevin Smith <[email-masked]>
Date: Fri, 7 May 2010 14:25:16 +0100

> We're stuck with (1), I think.

Of course, we can do (1), and still know who caused the error by
putting a from attribute in the error payload, which seems the best of
all worlds to me.

/K

---

From: Remko Tronçon <[email-masked]>
Date: Fri, 7 May 2010 15:30:38 +0200

> putting a from attribute in the error payload, which seems the best of

I was actually looking for something in XEP-0033 (to avoid having to
add attributes), but didn't immediately find anything useful there.

cheers,
Remko

---

From: Matt Miller <[email-masked]>
Date: Fri, 7 May 2010 07:32:45 -0600

> We're stuck with (1), I think.

If I receive an iq-error from a different address[1] than where I sent the iq-get/-set, I'd start to wonder if something was compromised.  That could just be my paranoia, though.

- m&m

[1] Within reason: sending to a bare-JID and coming back on a full JID may not be so bad...maybe (-:

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 7 May 2010 22:34:29 +0900

Hi,

> meaning you have to keep track of more information in the client.

somehow you gave the answer above, at least for error responses. The
error message will often carry the original message as well so you
anyway know the intended recipient. Reproducing this information in
the "from" attribute of the response would then only duplicate this
information in such a case, whereas having the actual response entity
in the "from" would give an additional information (providing the
original message was embedded in the error response).

> reporting quite a bit harder (if not impossible to do correctly

I don't think this is "impossible" to do without leaks. ;-) Yet I
agree this is probably not ideal. I don't have a really absolute
opinion on the matter. There is probably something bad from the roots.
Like I would personnaly think that there should be responses for
messages as well. How many times messages happened to get lost when I
was using unstable connections, without I or my recipient ever being
aware that messages did not get through!
Regards,

Jehan

---

From: Remko Tronçon <[email-masked]>
Date: Fri, 7 May 2010 15:47:45 +0200

> The error message will often carry the original message as well so you
> anyway know the intended recipient.

That's assuming:
- You never send messages like 'ok' to more than one person at the same time.
- You show all error messages in a single dialog (since you can't send
it to the chat dialog of the recipient, since the client can't derive
that)
- You are going to show the error message contents to the user
verbatim (which, as you pointed out, is bad). What if I just want to
put a red flag in the chat dialog of the recipient, saying that it's
not receiving any messages?

cheers,
Remko

---

From: Tory Patnoe <[email-masked]>
Date: Fri, 07 May 2010 11:47:54 -0600

On 05/07/2010 06:57 AM, Jehan Pagès wrote:
> id saving).

For XEP-16 Privacy Lists, the servers need to keep track of _exceptions_
to those lists. For example, I block example.com as a general rule. But
my client then sends a disco to a [email-masked] as part of a normal
operation. A hole is then opened in the privacy lists to all 
[email-masked]
iq through. Error stanza or non-error stanza. It would be really
confusing to now track IDs.

Tory

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 May 2010 22:12:08 -0600

> putting a from attribute in the error payload, which seems the best of

That's an interesting suggestion. I'll sketch out some text and examples
along those lines soon, so that we can see what that might look like.

Peter

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