[Standards] Call for Experience: XEP-0085 (Chat State Notifications)

Peter Saint-Andre stpeter at stpeter.im
Thu Nov 20 11:51:18 CST 2008

Pedro Melo wrote:
> On Oct 15, 2008, at 7:14 PM, Peter Saint-Andre wrote:
>> Peter Saint-Andre wrote:
>>> Remko Tron�on wrote:
>>>> But I agree that caps should be preferred over the old method.
>>> +1
>> BTW, I think the old method was there for the transition from message
>> events (XEP-0022) to chat state notifications. So perhaps it's time to
>> rip that out and just talk about caps/disco.
> +1.

I've been thinking about this more. Yes, service discovery and entity
capabilities provide the right tools for the job here. The concern was
caused by the use of XEP-0022 (Message Events) in older clients. Support
for message events was not determined by service discovery because that
protocol predated XEP-0030 by several years. Therefore your client could
get in this strange state of wanting to use chat state notifications but
ending up using message events.

I see two paths forward:

1. Use disco/caps only (no implicit discovery) for chat state
notifications and just wait for XEP-0022 clients to eventually disappear
from the network.

2. Clean up the implicit discovery algorithm so that it reads something
like this:


In the absence of explicit discovery or negotiation, the User MAY
implicitly request and discover the use of chat state notifications in a
one-to-one chat session by adhering to the following business rules:

   1. If the User desires chat state notifications, the message(s) that
it sends to the Contact before receiving a reply MUST contain a chat
state notification extension, which SHOULD be <active/>.

   2. If the Contact replies but does not include a chat state
notification extension, the User MUST NOT send subsequent chat state
notifications to the Contact.

   3. If the Contact replies and includes an <active/> notification (or
sends a standalone notification to the User), the User and Contact
SHOULD send subsequent notifications for supported chat states (as
specified in the next subsection) by including an <active/> notification
in each content message and sending standalone notifications for the
chat states they support (at a minimum, the <composing/> state).


Notice that this gets rid of the idea of the "initial content message"
and instead says that you send chat state notifications in all of the
messages you send to the contact before receiving a reply. If the
contact advertises support for XEP-0085 via disco/caps but never sends a
chat state notification, the user would stop sending notifications. This
saves some traffic, but I don't know how likely this scenario is.



More information about the Standards mailing list