[Standards] Proposed XMPP Extension: Message Stanza Profiles

Mridul Muralidharan 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:
>>> Hello
>>>
>>> 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 
> Negotiation.
> 
> 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 ?

- Mridul

> 
> 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?).
> 
> -Justin




More information about the Standards mailing list