[Standards] Proposed XMPP Extension: Message Stanza Profiles
mridul at sun.com
Wed Aug 1 18:26:07 UTC 2007
Justin Karneges wrote:
> On Wednesday 01 August 2007 10:10 am, Peter Saint-Andre wrote:
>> Michal 'vorner' Vaner wrote:
>>> Wouldn't it be better to discourage _sending_ such messages instead of
>>> recommending how to handle them?
>>> At last a notice that sending such message is a bad thing (dumb clients,
>>> whatever) anyway?
>> Yes, we need to add that. This is a very early draft and I'm looking for
>> Justin to provide some feedback, but I wanted to get something out there
>> for discussion.
> Great to see this as a XEP.
> First, the example 1 is an invalid message, and I don't think this is ever
> revealed. I'd suggest putting the profile of example 1 after the rules in
> section 3.
> We should probably have a set of example message stanzas where we state the
> profile next to each one. Maybe this could be section 4.
> The IM profile looks good.
> The Data negotiation profile confuses me. There are six specs listed in this
> section, and IMO these should be six separate profiles. A question to ask
> yourself, for example, is if you'd mix Jabber-RPC and Stanza Session
> I don't know if we should consider Transmission to be a profile. Maybe it
> should be moved out of section 2. Also, it is stated, "If a message stanza
> includes only transmission elements, it can be considered in the transmission
> profile." I think in this case the message would rather be considered to
> have no profile.
> I think Chat State Notifications falls under IM.
You can have chat state along with a body/xhtml - I thought the proposal
said you cant have more than one element from a profile within a message ?
> If a client receives a message stanza with no profile (this can occur if the
> stanza is actually empty, or contains only transmission elements and/or
> unknown elements), maybe we should define a <unknown-profile> or such error
> code (or reuse a nearby code) for the client to bounce back.
> It is possible for a client to determine conclusively that there is a profile
> conflict, if two types of differing profile elements that it understands
> happen to be present in the same message. Maybe we should define an error
> code for this as well (not-acceptable?).
More information about the Standards