[Standards] Proposed XMPP Extension: Message Stanza Profiles

Peter Saint-Andre stpeter at jabber.org
Thu Aug 2 23:22:18 UTC 2007

Justin Karneges wrote:
> 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.

I have no objections to optional errors if folks will find them useful.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070802/8aea0765/attachment.bin>

More information about the Standards mailing list