[Standards] XEP-0115 Feedback
stpeter at stpeter.im
Tue Feb 14 04:05:41 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
Old thread alert!
On 11/16/11 10:22 AM, Mike Wacker wrote:
My apologies for the slow reply. It's been busy. :)
> (1) In 5.4. Processing Method, step 3.3 states, "If the response
> includes more than one service discovery identity with the same
> category/type/lang/name, consider the entire response to be
> ill-formed." Should that actually be category/type/lang instead?
> XEP-0030 states, "the <query/> element MUST NOT include multiple
> <identity/> elements with the same category+type+xml:lang but with
> different 'name' values." Thus, the only change here would be that
> XEP-0115 disallows results which are already disallowed by
Yes, consistency between XEP-0030 and XEP-0115 would be good on this
> (2) We may want to put a cautionary note in XEP-0128 about what
> should or should not be included as an extension. For example, if a
> client included a public encryption key in a disco#info response
> via service discovery extensions, and this key was different for
> each user (or resource), then every user would publish a different
> verification string, meaning that entity capabilities would perform
> no better than disco flooding for that given client.
I'd prefer to disallow XEP-0128 forms from the XEP-0115 algorithm (or
whatever algorithm replaces it). The primary reason we allowed
XEP-0128 forms was to include software information (XEP-0232), but
that spec never gained consensus.
> If all users of a client would coalesce around a small subset of
> all possible values for any extensions added, then entity
> capabilities would still work as designed. However, I would argue
> IMHO that clients SHOULD NOT (or maybe even MUST NOT) introduce new
> information via service discovery extensions that would likely be
> different for each user or resource.
> I'll save a longer rant about the tendency for developers to say,
> "Let's make XYZ extensible!" without considering, for example, the
> performance and/or security implications of such extensibility.
> This isn't the first context where I've seen extensibility
> potentially cause such issues, nor am I the first person to have
> such complaints :)
Sure, rant away! ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Standards