On 8/10/10 9:21 AM, Peter Saint-Andre wrote: > I happened to re-read XEP-0201 late yesterday, too...
Gosh, now I'm replying to a message from myself about a spec for which I'm an author. This is getting weird. :) > On 8/9/10 7:25 PM, Matthew Wild wrote: >> On 12 July 2010 20:15, XMPP Extensions Editor <[email protected]> >> wrote: >> >>> 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? On re-reading that paragraph, I now think it's fine: ### Unless a <message/> stanza is written in direct reply to another <message/> stanza, if a ThreadID is included then its value SHOULD be newly generated when a human user initiates a chat conversation with another user (i.e., a <message/> stanza of type 'chat'), starts a new conversation in the context of a multi-user chat environment (i.e., a <message/> stanza of type 'groupchat'), or sends a normal message. ### > 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. Although I'd still like feedback, I think we can leave the text as-is for now because IMHO the primary case is going to be the one described in the text quoted above. > 3. Section 4.1 talks about "a session with unnegotiated parameters". > That's another legacy of XEP-0155, and needs to be removed. Removed. >>> 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. I've modified the text to read: ### 4.3 Normal Messages For <message/> stanzas of type "normal", the value of the <thread/> element shall be considered equivalent to a unique identifier for a conversation thread that proceeds outside the context of a "real-time" chat session or groupchat session. When displaying threaded messages of type "normal" within a user interface, a client SHOULD provide a visual indication of the thread to which a message belongs. Methods for such indications include (non-exhaustively) the grouping together of all messages from the same thread, providing an index of threads, or formatting all messages within a thread in a cohesive manner, e.g. with uniform coloring. ### > 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). RFC 5322 states: ### The "In-Reply-To:" and "References:" fields are used when creating a reply to a message. They hold the message identifier of the original message and the message identifiers of other messages (for example, in the case of a reply to a message that was itself a reply). The "In-Reply-To:" field may be used to identify the message (or messages) to which the new message is a reply, while the "References:" field may be used to identify a "thread" of conversation. When creating a reply to a message, the "In-Reply-To:" and "References:" fields of the resultant message are constructed as follows: The "In-Reply-To:" field will contain the contents of the "Message-ID:" field of the message to which this one is a reply (the "parent message"). If there is more than one parent message, then the "In-Reply-To:" field will contain the contents of all of the parents' "Message-ID:" fields. If there is no "Message-ID:" field in any of the parent messages, then the new message will have no "In- Reply-To:" field. The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any). If the parent message does not contain a "References:" field but does have an "In-Reply-To:" field containing a single message identifier, then the "References:" field will contain the contents of the parent's "In-Reply-To:" field followed by the contents of the parent's "Message-ID:" field (if any). If the parent has none of the "References:", "In-Reply-To:", or "Message-ID:" fields, then the new message will have no "References:" field. Note: Some implementations parse the "References:" field to display the "thread of the discussion". These implementations assume that each new message is a reply to a single parent and hence that they can walk backwards through the "References:" field to find the parent of each message listed there. Therefore, trying to form a "References:" field for a reply that has multiple parents is discouraged; how to do so is not defined in this document. ### RFC 5536 (Netnews Article Format) also points to the "References:" field from RFC 5322. IMHO the semantics of <thread/> are cleaner than trying to parse both the "References:" field, but I've added a brief pointer to both email and netnews so that folks have some insights from common messaging technologies. >> 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. Done. New version on the way. Peter -- Peter Saint-Andre https://stpeter.im/
