[Standards] Proposed XMPP Extension: Message Stanza Profiles

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Aug 1 18:00:10 UTC 2007

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 

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.

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 mailing list