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

Matthew Wild mwild1 at gmail.com
Tue Aug 10 17:32:02 UTC 2010


On 10 August 2010 16:21, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 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.
>

"An application that generates a UUID for use as the ThreadID MUST
ensure that the UUID does not reveal identifying information about the
entity (e.g., the MAC address of the device on which the XMPP
application is running)."

Yeah... I had read this as "If an application chooses to use a UUID
for a ThreadID then it MUST ensure [...]". It could indeed be
clarified, or even removed if deemed unnecessary for this spec.

Matthew



More information about the Standards mailing list