Bug #3948
implement setting 'from' in XMPP packets according to RFC
Status: | Resolved | Start date: | 10/31/2014 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | - | |||
Target version: | v14.2 bug fix update! | |||
Component: |
Description
Right now, ChatSecure is leaving the from
field of XMPP chat
type Messages
as null
. The RFC says that the from
field should be set with the following behavior:
http://xmpp.org/rfcs/rfc6121.html#message-chat
The user's client SHOULD address the initial message in a chat session to the bare JID <contact@domainpart> of the contact (rather than attempting to guess an appropriate full JID <contact@domainpart/resourcepart> based on the <show/>, <status/>, or <priority/> value of any presence notifications it might have received from the contact). Until and unless the user's client receives a reply from the contact, it SHOULD send any further messages to the contact's bare JID. The contact's client SHOULD address its replies to the user's full JID <user@domainpart/resourcepart> as provided in the 'from' address of the initial message. Once the user's client receives a reply from the contact's full JID, it SHOULD address its subsequent messages to the contact's full JID as provided in the 'from' address of the contact's replies, thus "locking in" on that full JID. A client SHOULD "unlock" after having received a <message/> or <presence/> stanza from any other resource controlled by the peer (or a presence stanza from the locked resource); as a result, it SHOULD address its next message(s) in the chat session to the bare JID of the peer (thus "unlocking" the previous "lock") until it receives a message from one of the peer's full JIDs.
History
#1 Updated by hans about 3 years ago
from
seems to have been removed here:
#2 Updated by n8fr8 about 3 years ago
hans wrote:
Right now, ChatSecure is leaving the
from
field of XMPPchat
typeMessages
asnull
. The RFC says that thefrom
field should be set with the following behavior:http://xmpp.org/rfcs/rfc6121.html#message-chat
The user's client SHOULD address the initial message in a chat session to the bare JID <contact@domainpart> of the contact (rather than attempting to guess an appropriate full JID <contact@domainpart/resourcepart> based on the <show/>, <status/>, or <priority/> value of any presence notifications it might have received from the contact). Until and unless the user's client receives a reply from the contact, it SHOULD send any further messages to the contact's bare JID. The contact's client SHOULD address its replies to the user's full JID <user@domainpart/resourcepart> as provided in the 'from' address of the initial message. Once the user's client receives a reply from the contact's full JID, it SHOULD address its subsequent messages to the contact's full JID as provided in the 'from' address of the contact's replies, thus "locking in" on that full JID. A client SHOULD "unlock" after having received a <message/> or <presence/> stanza from any other resource controlled by the peer (or a presence stanza from the locked resource); as a result, it SHOULD address its next message(s) in the chat session to the bare JID of the peer (thus "unlocking" the previous "lock") until it receives a message from one of the peer's full JIDs.
Actually, that sounds like the behavior for setting a 'to', meaning how you address messages. I think you can always set your 'from' to be your full JID.
What the statement above is saying is that if you don't have an open session with someone, you should address them using the bare JID, until you receive a message from the user.
#3 Updated by hans about 3 years ago
Check the sentences further into that paragraph that specifically mention using the data in the 'from' field. Since ChatSecure is not setting the from field, it is not possible for the receiver to follow the RFC like this.
#4 Updated by hans about 3 years ago
Was I totally confused here, or did something change so that now ChatSecure is setting the from field?
#5 Updated by n8fr8 over 2 years ago
- Target version set to v14.2 bug fix update!
#6 Updated by n8fr8 over 2 years ago
- Status changed from New to Resolved
it is indeed setting the from!