[Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

Joe Hildebrand joe.hildebrand at webex.com
Wed Sep 14 00:19:12 UTC 2011

On 9/13/11 3:57 AM, "Dave Cridland" <dave at cridland.net> wrote:

> - The FORM_TYPE is used to distinguish between sets of metadata; I
> think forcing all FORM_TYPEs used to be the same would effectively
> mean that only one XEP-0128 extension could be used,

Yes, that was the intent.

> and whilst I cannot think of a case where this would have problems,
> I'm not convinced there isn't either.

The intent was that if you had an existing FORM_TYPE/field combo, you could
always re-render it into {FORM_TYPE}field.  This is probably how we should
have done XEP-68 in the first place, since right now it's hard to add
semantically-useful fields as extensions to a form that is otherwise
standardized.  For example, if I've got a non-standard extension to a MUC
configuration form, what do I name it?

I think we may want to consider creating a new XEP that recommends using
XEP-68 in this way, even if we go down another path.

The good argument I've heard against this is that there are some
implementations that use the FORM_TYPE itself semantically.  That wasn't
what I expected when we first wrote 68, but it wasn't prohibited, either.

What we could do is make FORM_TYPE *only* used semantically as the name of
the form itself, not as the namespace for the fields, with a URI like Peter
suggested only used in places where we don't care what the form type is, but
it's required by some other protocol like 115.

Joe Hildebrand

More information about the Standards mailing list