[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