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 <[email protected]> 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/
