[Standards] request for reviews: XEP-0045 v1.25rc5

Kevin Smith kevin at kismith.co.uk
Tue Sep 27 06:09:23 UTC 2011


On Mon, Sep 26, 2011 at 10:55 PM, Kurt Zeilenga <Kurt.Zeilenga at 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



More information about the Standards mailing list