[Standards] LAST CALL: XEP-0201 (Best Practices for Message Threads)

Peter Saint-Andre stpeter at stpeter.im
Tue Aug 10 15:21:07 UTC 2010


I happened to re-read XEP-0201 late yesterday, too...

On 8/9/10 7:25 PM, Matthew Wild wrote:
> On 12 July 2010 20:15, XMPP Extensions Editor <editor at xmpp.org> wrote:
>> This message constitutes notice of a Last Call for comments on XEP-0201 (Best Practices for Message Threads).
>>
>> Abstract: This specification defines recommended handling of XMPP message threads.
>>
>> URL: http://www.xmpp.org/extensions/xep-0201.html
>>
>> This Last Call begins today and shall end at the close of business on 2010-07-30.
>>
> 
> No feedback? I believe several clients implement threads (they are
> necessary for negotiation of a few things now).

Yes. I have some feedback too, despite the fact that I'm a co-author. :)

>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
> 
> I believe so, yes. Although 3921bis defines the element, there is no
> discussion there of when to generate thread IDs, and how to handle
> thread IDs for different message types.

I agree that it would be helpful to specify those matters.

>> 2. Does the specification solve the problem stated in the introduction and requirements?
> 
> Yes.

I would say: yes, but there are some oddities (mostly related to the
fact that XEP-0201 was at one time tied to XEP-0155)...

1. In Section 3.2, the spec seems to force a client to create new
threads quite often, because the default is to generate a new ID instead
of re-using an existing ID. Is this really desirable?

2. Section 3.2 also talks about a message being sent in reply to another
message. The UI hints here are questionable (do any clients have an
interface element that enables the user to explicitly reply to a given
message of type "chat" or "groupchat"?). This notion is especially
problematic in a multi-user chat environment. Feedback from client
developers would be helpful here.

3. Section 4.1 talks about "a session with unnegotiated parameters".
That's another legacy of XEP-0155, and needs to be removed.

>> 3. Do you plan to implement this specification in your code? If not, why not?
> 
> As primarily a server developer I have yet to encounter threads.
> 
>> 4. Do you have any security concerns related to this specification?
> 
> None.
> 
>> 5. Is the specification accurate and clearly written?
>>
> 
> Largely, yes.
> 
> I wonder if the handling for type="normal" messages should be
> described more than it is. It seems to me that type="normal" could be
> provide the basis for a threaded conversation, perhaps even more so
> than type="chat". The main difference between "normal" and "chat" in
> practice is simply the user interface that the client chooses to
> display a message in.

Good point. IMHO it might be helpful here to look at how threading is
specified for email messages. I'll hunt around for the relevant RFC or
Internet-Draft (the MORG WG might be working in this area, too).

> On the other hand, "headline" is quite rightly unspecified - these
> "one-way" messages should expect no reply.

Agreed.

> My only previous complaint was on requiring the use of UUIDs to
> identify a thread - both this XEP and 3921bis are clear on that issue
> now, and so I'm happy on this point.

But Section 5 of XEP-0201 still refers to UUIDs, so that needs to be
cleaned up.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





More information about the Standards mailing list