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

Tijl Houtbeckers thoutbeckers at splendo.com
Wed May 21 03:24:41 UTC 2003

Peter Saint-Andre <stpeter at jabber.org> wrote on 20-5-2003 21:19:50:
>On Tue, May 20, 2003 at 09:26:36AM +0200, Tijl Houtbeckers wrote:
>> 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?

I mean that if I have a client that supports 2 or more simultanious 
threads to the exact same full jid, and on the other end a client that 
effectivly only uses one thread (most of the clients outthere do) 
things get messy. 

Client 1 supports multiple threads, by simply using multiple 
chatwindows for multiple threads. 

Client 1, threadid 123: Hello, how are you?
Client 1, threadid 987: Oh by the way, we have to finish 

Client 2 uses only 1 chatwindow for all incoming messages from a full 
JID, because it thinks this is a better UI (as do a lot of client 
designers I think). Now user clients one want to answer the first 
question and say: "I am fine". Wich threadid should it use? 123 
ofcourse, because that's the thread it answers to. But how does client 
2 know wich threadid to use? Well, it doesn't. Most clients use a 
"hack" and just copy back the last threadid. To client 1 this would 
look like client 2 supports multiple threads, but to the user of client 
1 it looks plain awfull. The only way client 2 can (currently) know 
client 1 does not support multiple threads is if it simply does not 
send back a threadid, just type="chat". 

So currently, the situation is messy. You can avoid it by not using 
threads at all (what functionality do you currently miss here as a 
client that does not support multiple threads anyway?). However, now 
this would mean I can no longer track the state of my message. 

>> 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.

It makes sense when I send a message, that I track it on the basis of 
that message. When I want to track the state of a conversation, indeed 
it makes more sense to do that on the basis of a thread. However, this 
does not take away that there are some fundamental issues with threads 
right now. Maybe it could be solved by using disco to find out if a 
client supports multiple threads to the same full JID or not first. How 
I'm supposed to do this for messages outside of a thread I don't know 
(I guess that means you don't want me to do that at all). 

>> 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? 

If I know to wich resource I want to send a message, why would I care 
about priority? I don't always want to message the highest priority. 
Ofcourse, if I want to message to the highest resource, I can't always 
use presence to find out what that is, so I have to use the bare JID. 
This is a problem ofcourse! That hopefully doesn't mean we can't find a 
solution for it. 

Now you just say: well just don't do it then!. But I doubt this is the 
last time we'll encounter this problem, it will happen everytime we 
want to send a message to a bare JID (so that it will go to the highest 
resource). Wether we want to track the chat state, or see if they 
support XHTML, or try to figure out what emoticon set they support. 
Maybe we should introduce something like a "disco-message", sending a 
message to the bare JID with a unique ID that is echoed back so you can 
discover what the resource is, and then do a disco. 

So you probably think, why would anyone want to track the status of a 
conversation before the first message is send? For example, I could put 
a small icon behind a contacts name when he start typing a message 
and/or opens a chat. That way I could be prepared that a message is 
coming, maybe even wait a few seconds more before starting my 
lunchbreak when I see someone is typing. I think Yabber already has 
something like this, though considering the current structure of 
message-events it will not work till after the very first message. 
You're still not in the situation though were either one of the parties 
can cancel a thread and stop notifications again. 

>> 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,

I can't initiate a discussion with a lower resource JID? Why not???

>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. 

What if I *want* to override 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. 

I seriously suggest you scrap this whole rule. I have no idea why you 
should tell me wether I must talk to "work" or to "home". Just like I 
don't see why you should force Casey Crabb to introduce bad hacks into 
his program or make surthen UI decisions just so he can track the state 
of a chat. 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list