Bug #3948

implement setting 'from' in XMPP packets according to RFC

Added by hans about 3 years ago. Updated over 2 years ago.

Status:ResolvedStart date:10/31/2014
Priority:HighDue 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

#2 Updated by n8fr8 about 3 years ago

hans wrote:

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.

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!

Also available in: Atom PDF