[Standards] Proposed XMPP Extension: Message Stanza Profiles
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards