[standards-jig] NEW: Chat State Notifications (JEP-0085)

Peter Saint-Andre stpeter at jabber.org
Tue May 20 19:19:50 UTC 2003

On Tue, May 20, 2003 at 09:26:36AM +0200, Tijl Houtbeckers wrote:

> Peter Saint-Andre <stpeter at jabber.org> wrote on 20-5-2003 2:01:20:
> >
> >I've published a new JEP for chat state notifications. Please note well
> >that this JEP does *not* address message tracking, only notifications
> >regarding chat states such as composing a reply. We will need another
> >JEP to address message tracking.
> >
> >http://www.jabber.org/jeps/jep-0085.html
> >
> >Peter
> I think this JEP will make the use of <thread> even messier. There's 
> already a known problem when clients that do not support multiple 
> threads at the same time try to talk with clients that do. This is for 
> me reason enough not to support <thread>, since this is also the only 
> way to signal to other clients that I do not support multiple 
> simultanious threads. 

So those are not compliant clients. Do you mean they don't support
multiple simultaneous threads between one pair of full JIDs, or that
they don't support more than one thread at the same time between the
user and any other contacts?

> Currently I would not loose much functionality with this, but with this 
> JEP that would mean I can not have chat state notifications. So I'd 
> have to implement the same hack many other clients do, "just copy back 
> the last threadid you got". As if that's not bad enough, the only way 
> I'd be able to track mulitple induvidual messages is starting a new 
> thread for each one and always use type="chat". And once I do have my 
> <thread> system in place suddenly every thread I make can be closed and 
> invalidated by the other client. I can see the benifits of using thread 
> based tracking (eg you can do the focused/unfocused thing more easily) 
> but realise that using <thread> brings along it's own disadvantages. 

I submit that using threads makes a *lot* more sense than the current
system of mirroring 'id' attributes back in an <id/> element! This
really applies in the context of a chat session or thread, and makes
very little sense on a per-message basis.

> Some other questions. 
> Why am I not allowed to disco for Chat State Notifications first, and 
> send an initial message that the thread is composing/focused/etc? 

How do you know which resource to disco? Are you depending on presence
information to determine which resource has priority? 

> Under example 1 the JEP states:
> > 1. MUST send the initial message to the Contact's bare JID (user at host)
> What is the purpose of this? If I want to send a message to specific 
> resource why should I be forced to send the initial message to the 
> (potentially) wrong resource? 

This assumes that you are initiating a discussion with the contact, 
in which case you really should *not* send the message to a resource,
you should send it to the bare JID and let the server's rules determine
which resource to route it to. You are not forced to send the message to
the "wrong resource", you are sending the message to the user and not
overriding the delivery rules. Now, if the user has multiple resources
connected and you *know* that you need to send the message to a specific
resource, I suppose that is fine. So maybe I'll change this to SHOULD.


Peter Saint-Andre
Jabber Software Foundation

More information about the Standards mailing list