[standards-jig] JEP-85: Chat State Notifications

Dave Smith dizzyd at jabber.org
Tue Jul 22 13:10:55 UTC 2003

Hash: SHA1

On Monday, Jul 21, 2003, at 11:44 America/Denver, Peter Ronez wrote:

> Imagine an outline that gets built-up using just messaging. Messages 
> without
> IDs make up the top most level of the outline. Then the users reply to 
> messages
>  (composing with ID + the message itself) and the response becomes a 
> child of
> the message being responded to. The final result would be a tree being 
> built
> just by plain messaging. Users of the outline would be able to observe 
> where
> others are replying in "real-time" and then see the message come into 
> the
> correct position in the tree once it's received.
> OK, so the above example if full of things left unsaid and it is 
> somewhat
> impractical (can't edit), but one thing is for sure this couldn't be 
> done with
> just the thread ID without abusing the meaning of thread ID.

Wow -- that's quite an example. However, I could easily argue that each 
"branch" on the tree should have a unique thread-id (instead of simply 
not having an ID), so that responses could be tracked on a per thread 
basis (without abusing the meaning of a "thread"). What you're roughly 
describing here would be perfect for a forum/topic based discussion 
group, and a scenario I believe can easily be handled by the current 

Honestly, I have yet to see a client, or conceive of a scenario where 
per message _state_ tracking is really, truly useful. Most people who 
implement the current jabber:x:events standard only track a single 
message ID at any given time, since it is difficult (at best) to convey 
to the user that someone is editing 5 messages back and/or 
concurrently. JEP85 builds on implementation experience to satisfy the 
80/20 requirements for _chat state_ notification.  It is purposely 
specific, since there is a clear use-case (most clients need this!) for 
providing chat state notifications. One of the biggest problems with 
jabber:x:events was that it was massively overloaded functionality with 
semantics for several different, unrelated use-cases tacked on. JEP85 
is the first in a number (or so I suspect) of JEPs that will break the 
functionality out into bite-size, comprehensible pieces. (Of note, I do 
not think that per message chat state is one of those JEPs -- I just 
don't see the point).

If you can show me an implemented, viable interface which REQUIRES per 
message state tracking, then I will concede the point and help adjust 
JEP85 accordingly.


Version: GnuPG v1.2.1 (Darwin)


More information about the Standards mailing list