On Mon, Sep 26, 2011 at 10:55 PM, Kurt Zeilenga <kurt.zeile...@isode.com> wrote: > > On Sep 26, 2011, at 2:36 PM, Peter Saint-Andre wrote: > >>> >>> 5. Both <subject/> and <body/> in a single message >>> >>> "(A message with a <subject/> and a <body/> is a legitimate message, >>> but it SHALL NOT be interpreted as a subject change.)" >>> >>> I object to this. It complicates subject handling. I believe much >>> existing MUC software considers a message a subject change if it has a >>> <subject/> in it. How should software determine this? Assume it's a >>> subject change if there's no <body/>? What if there is not body, but >>> xHTML-IM is included? What if there's no body, but some >>> <unknown-element/>? >> >> IMHO a subject change should be a message with *only* a <subject/> child >> element and no other children. > > I think one ought to allow for extension elements in the subject change > message. For instance, say the subject change message is delayed at an > occupant's server, which hence adds a <delay/> element. Hence, I think it > should be a <subject/> child with a <body/>.
I don't mind if it has other children than <subject/>, but existing implementations require there to be no <body/> on a subject change, and I see no reason to break them at this stage. /K
