On 06/09/2010 04:25 PM, Peter Saint-Andre wrote:
On 6/9/10 2:21 PM, "Alejandro R. Sedeño" wrote:
On 06/09/2010 02:16 PM, Matthew Wild wrote:
2010/6/9 "Alejandro R.
Sedeño"<asedeno-3s7WtUTddSA-XMD5yJDbdMSQIYZ4X/[email protected]>:
A client I work on, BarnOwl [1], has been, perhaps incorrectly, using
the former wording to allow for a<subject/> element along with a
<body/> element to indicate a subject for the particular message,
without changing the topic of MUC. This is used to emulate a feature
that every IM since Zephyr [2] is lacking, which allows for multiple
threaded conversations to exist in a single forum [3].
I'm interested in getting feedback on this usage and perhaps getting it
standardized.
Can you not use<thread>?:
http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-06#section-5.2.5
No, thread is not quite right.
"The value of the<thread/> element is not human-readable and MUST be
treated as opaque by entities; no semantic meaning can be derived from
it, and only exact comparisons can be made against it. The value of the
<thread/> element MUST be a universally unique identifier (UUID) as
described in [UUID]."
We're looking for threading on topics like 'xmpp', 'cooking', 'physics',
etc.
Right. I think you want to use both thread and subject.
That sounds alright, so long as the use of a subject tag along with a body
tag (and perhaps a thread tag) is explicitly allowed, and isn't
interpreted as a possible change in MUC topic.
I guess my point is that I find the current "SHOULD NOT" in section 8.1 to
be a bit weak. A server could still interpret a message with a subject and
a body as a topic change because even if the client "SHOULD NOT" send that
as a topic change, it still *might*.
Perhaps instead it should state that a subject change "MUST NOT" include
other elements and that the server "MUST NOT" treat a message with
elements besides a subject as a subject change? That, to me, feels more in
line with the older text.
-Alejandro
