Details

      Description

      XEP-0085: Chat State Notifications is a client-side protocol. However, it mentions one duty on the server-side:

      a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline.

      It also explains:

      A "standalone notification" – that is, a message stanza that does not contain standard messaging content but instead is intended to specify only the chat state since it contains only a child element qualified by the "http://jabber.org/protocol/chatstates" namespace (or possibly also the XMPP <thread/> element; see the Threads section below).

      Example stanza:

      <message from='user1@domain.net/work'
               to='user2@domain.net'
               id='5eH6A-9'
               type='chat'>
        <thread>bvnyM0</thread>
        <composing xmlns='http://jabber.org/protocol/chatstates' />
        <delay xmlns='urn:xmpp:delay'
               from='domain.net'
               stamp='2012-01-13T18:02:28Z'>Offline Storage</delay>
        <x xmlns='jabber:x:delay'
           stamp='20120113T18:02:28' />
      </message>
      
      1. 961.patch
        6 kB
        Badlop
      2. 961.patch
        5 kB
        Badlop

        Activity

        badlop
        30/06/09 21:32
        View full commit
        Support XEP-0085 Chat State Notifications (EJAB-961) git-svn-id: https://svn.process-one.net/ejabberd/trunk@2350 1613c18e-e6f4-0310-972c-c3fad1d2be73
        Badlop
        30/06/09 21:33
        View full commit
        Support XEP-0085 Chat State Notifications (EJAB-961) SVN Revision: 2351
        Hide
        Badlop
        added a comment -

        Implemented in trunk svn r2350 and road-to-exmpp r2351.

        Show
        Badlop
        added a comment - Implemented in trunk svn r2350 and road-to-exmpp r2351.
        Badlop
        made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s ejabberd 2.1.0 [ 10140 ]
        Fix Version/s ejabberd 3.0.0-alpha [ 10240 ]
        Resolution Fixed [ 1 ]
        Hide
        Teymur Mammadov
        added a comment -

        There's a point you missed in XEP-0085 that is also described in the report description (see the text in bold):

        A "standalone notification" – that is, a message stanza that does not contain standard messaging content but instead is intended to specify only the chat state since it contains only a child element qualified by the "http://jabber.org/protocol/chatstates" namespace (or possibly also the XMPP <thread/> element; see the Threads section below).

        Looking at the mod_offline there's a filter condition as below:

        %% There a chatstates subelement and other stuff, but no x:event
        {false, CEl, true} when CEl /= false ->
        	true;
        

        Means we shouldn't always save messages if there's a chatstates subelement and other stuff. "other stuff" can be a <body>, <thread>, <delay> and etc. We should save only if there's a <body> in the message. See a real example below saved in my database (user names and domain names are replaced):

        <message from='user1@domain.net/work' to='user2@domain.net' id='5eH6A-9' type='chat'><thread>bvnyM0</thread><composing xmlns='http://jabber.org/protocol/chatstates'/><delay xmlns='urn:xmpp:delay' from='domain.net' stamp='2012-01-13T18:02:28Z'>Offline Storage</delay><x xmlns='jabber:x:delay' stamp='20120113T18:02:28'/></message>
        
        Show
        Teymur Mammadov
        added a comment - There's a point you missed in XEP-0085 that is also described in the report description (see the text in bold): A "standalone notification" – that is, a message stanza that does not contain standard messaging content but instead is intended to specify only the chat state since it contains only a child element qualified by the "http://jabber.org/protocol/chatstates" namespace ( or possibly also the XMPP <thread/> element; see the Threads section below). Looking at the mod_offline there's a filter condition as below: %% There a chatstates subelement and other stuff, but no x:event {false, CEl, true} when CEl /= false -> true; Means we shouldn't always save messages if there's a chatstates subelement and other stuff. "other stuff" can be a <body>, <thread>, <delay> and etc. We should save only if there's a <body> in the message. See a real example below saved in my database (user names and domain names are replaced): <message from='user1@domain.net/work' to='user2@domain.net' id='5eH6A-9' type='chat'> <thread> bvnyM0 </thread> <composing xmlns='http://jabber.org/protocol/chatstates'/> <delay xmlns='urn:xmpp:delay' from='domain.net' stamp='2012-01-13T18:02:28Z'> Offline Storage </delay> <x xmlns='jabber:x:delay' stamp='20120113T18:02:28'/> </message>
        Hide
        Badlop
        added a comment -

        That example message stanza is of "chat" type and contains content additional to XEP-0085. According to http://xmpp.org/extensions/xep-0160.html#types that stanza should be stored offline:

        chat – Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only Chat State Notifications [7] content (such messages SHOULD NOT be stored offline).

        Show
        Badlop
        added a comment - That example message stanza is of "chat" type and contains content additional to XEP-0085. According to http://xmpp.org/extensions/xep-0160.html#types that stanza should be stored offline: chat – Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only Chat State Notifications [7] content (such messages SHOULD NOT be stored offline).
        Hide
        Teymur Mammadov
        added a comment -

        Any Chat State Notification is of "chat" type whether there's a message body or not (see XEP-0085). XEP-0160 states the exception clearly:

        chat – Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only Chat State Notifications [7] content (such messages SHOULD NOT be stored offline).

        The additional content in the example is <thread>, which is also mentioned in XEP-0085 and <delay> (x:delay) that is added by ejabberd (XEP-0203)

        Information about the delivery delay is communicated by adding to the <message/> or <presence/> stanza one and only one <delay/> child qualified by a namespace to be issued when this specification advances to a status of Draft. This information is added by the server or component that delivers the stanza.

        before saving it to offline storage.

        Show
        Teymur Mammadov
        added a comment - Any Chat State Notification is of "chat" type whether there's a message body or not (see XEP-0085). XEP-0160 states the exception clearly: chat – Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only Chat State Notifications [7] content (such messages SHOULD NOT be stored offline) . The additional content in the example is <thread>, which is also mentioned in XEP-0085 and <delay> (x:delay) that is added by ejabberd (XEP-0203) Information about the delivery delay is communicated by adding to the <message/> or <presence/> stanza one and only one <delay/> child qualified by a namespace to be issued when this specification advances to a status of Draft. This information is added by the server or component that delivers the stanza. before saving it to offline storage.
        Badlop
        made changes -
        Resolution Fixed [ 1 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        Badlop
        made changes -
        Description [XEP-0085: Chat State Notifications|http://xmpp.org/extensions/xep-0085.html] is a client-side protocol. However, it mentions one duty on the server-side:

        {quote}a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline.
        {quote}

        It also explains:

        {quote}A "standalone notification" -- that is, a message stanza that does not contain standard messaging content but instead is intended to specify only the chat state since it contains only a child element qualified by the "http://jabber.org/protocol/chatstates" namespace (or possibly also the XMPP <thread/> element; see the Threads section below).{quote}
        [XEP-0085: Chat State Notifications|http://xmpp.org/extensions/xep-0085.html] is a client-side protocol. However, it mentions one duty on the server-side:

        {quote}a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline.
        {quote}

        It also explains:

        {quote}A "standalone notification" -- that is, a message stanza that does not contain standard messaging content but instead is intended to specify only the chat state since it contains only a child element qualified by the "http://jabber.org/protocol/chatstates" namespace (or possibly also the XMPP <thread/> element; see the Threads section below).{quote}

        Example stanza:
        {code}
        <message from='user1@domain.net/work'
                 to='user2@domain.net'
                 id='5eH6A-9'
                 type='chat'>
          <thread>bvnyM0</thread>
          <composing xmlns='http://jabber.org/protocol/chatstates&#39; />
          <delay xmlns='urn:xmpp:delay'
                 from='domain.net'
                 stamp='2012-01-13T18:02:28Z'>Offline Storage</delay>
          <x xmlns='jabber:x:delay'
             stamp='20120113T18:02:28' />
        </message>
        {code}
        Hide
        Badlop
        added a comment -

        Ok, Teymur, can you check if this patch solves the problem?

        Show
        Badlop
        added a comment - Ok, Teymur, can you check if this patch solves the problem?
        Badlop
        made changes -
        Attachment 961.patch [ 18973 ]
        Hide
        Teymur Mammadov
        added a comment - - edited

        It solved the problem, thanks. However if "check_has_body(Packet)" condition is not satisfied, the packet is being forwarded for further processing which ends up delivered back to the sender with an "service-unavailable error" subtag attached. And this results xmpp client show it's own chatstate notifications as it's been sent from offline contact. In other words as I start typing to a offline contact I get a message saying that contact is typing a message. This is because chatstate notification is bounced back to me. I solved it by adding "stop" when "check_has_body(Packet)" condition returns false in "store_packet" function.

        Show
        Teymur Mammadov
        added a comment - - edited It solved the problem, thanks. However if "check_has_body(Packet)" condition is not satisfied, the packet is being forwarded for further processing which ends up delivered back to the sender with an "service-unavailable error" subtag attached. And this results xmpp client show it's own chatstate notifications as it's been sent from offline contact. In other words as I start typing to a offline contact I get a message saying that contact is typing a message. This is because chatstate notification is bounced back to me. I solved it by adding "stop" when "check_has_body(Packet)" condition returns false in "store_packet" function.
        Hide
        Badlop
        added a comment -

        Looking at XEP-0160, "normal" message stanzas don't need this check, only "chat" ones. This difference is relevant because in fact the "body" element is OPTIONAL, so it's acceptable to not be included in message stanzas, and XEP-0160 does not mention that it must be included in order to store the stanza.

        I've implemented that clause to the IF, and moved the execution of the action after taking the decision. I've updated the attached patch.

        Show
        Badlop
        added a comment - Looking at XEP-0160, "normal" message stanzas don't need this check, only "chat" ones. This difference is relevant because in fact the "body" element is OPTIONAL, so it's acceptable to not be included in message stanzas, and XEP-0160 does not mention that it must be included in order to store the stanza. I've implemented that clause to the IF, and moved the execution of the action after taking the decision. I've updated the attached patch.
        Badlop
        made changes -
        Attachment 961.patch [ 18976 ]
        Hide
        Badlop
        added a comment -

        The original EJAB-961 implementation is kept. The patch discussed during the year 2012 is not included.

        Show
        Badlop
        added a comment - The original EJAB-961 implementation is kept. The patch discussed during the year 2012 is not included.
        Badlop
        made changes -
        Status Reopened [ 4 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Mickaël Rémond
        made changes -
        Workflow development v3 [ 69132 ] Development v4 [ 81182 ]

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              45 weeks, 2 days ago

              Issue deployment