On 9/27/11 12:09 AM, Kevin Smith wrote: > 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.
+1. But I think a few things could be clarified to address the concerns that Waqas has. I'll do that for the next release candidate. Peter -- Peter Saint-Andre https://stpeter.im/
