[Standards] Proposed XMPP Extension: Message Stanza Profiles
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
> 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.
More information about the Standards