[Standards] Proposed XMPP Extension: Message Stanza Profiles

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Aug 2 23:13:04 UTC 2007


On Thursday 02 August 2007 2:20 pm, Peter Saint-Andre wrote:
> Justin Karneges wrote:
> > Great to see this as a XEP.
>
> Sure thing. BTW I can give you permissions to edit files in SVN if you
> want to tweak it. :)

Yes, set me up.  That would be useful for editing XEP-198 as well.

> > and I don't think this is ever
> > revealed.  I'd suggest putting the profile of example 1 after the rules
> > in section 3.
>
> OK. But the point of the spec is that you should not be generating such
> a monstrosity.

True, but as a reader I felt like the spec ended with a cliffhanger. :)  And I 
should correct myself: we wouldn't state the profile of Example 1, rather 
we'd state that the Example 1 stanza is invalid.

> Are RPC and SOAP part of the same profile perhaps?

Nope.  RPC and SOAP have similar purposes, but you would not put both in the 
same stanza.

> So what profiles do we need?

We need a bunch of individual-XEP profiles, and then the IM profile which 
constitutes many XEPs and an RFC.

RPC is the RPC profile.  SOAP is the SOAP profile.  IBB is the IBB profile.  
x:data is the x:data profile.  Pubsub is the pubsub profile.  And so on.

Then we'd have <body>, <subject>, chat states, etc in the IM profile.  It is 
quite possible that the IM profile is the only "mixed" one.

> > 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.
>
> OK, I suppose that makes sense. Transmission elements are all "metadata"
> (that term might be better than "trasmission" since SHIM stuff might not
> be related to transmission).

Yeah I'm fine with calling it metadata.

> > 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.
>
> Or just eat the stanza and don't return an error. What's the point of
> returning an error here?

It might help for diagnostic purposes.

For privacy reasons, I suppose something like this would need to be optional.

> > 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?).
>
> Works for me.

Ditto for this one being optional.

In current practice, messages with unsupported elements are not bounced.  This 
is not really something I was setting out to fix (if there is anything to 
fix).  I just figure errors are something cool that this XEP enables us to 
have if we want them.

-Justin



More information about the Standards mailing list