On 9/13/11 3:57 AM, "Dave Cridland" <[email protected]> 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