On Oct 6, 2011, at 4:42 AM, Matthew Wild wrote: > On 6 October 2011 07:46, Kim Alvefur <[email protected]> wrote: >>> 1. Is this specification needed to fill gaps in the XMPP protocol >>> stack or to clarify an existing protocol? >> Yes. >> >>> 2. Does the specification solve the problem stated in the introduction >>> and requirements? >> Yes. >> >>> 3. Do you plan to implement this specification in your code? If not, >>> why not? >> I just pushed some work I did on a plugin for Prosody, updating it to >> the latest spec. Only the catalog serving part though. >> >>> 4. Do you have any security concerns related to this specification? >> If this counts as security concerns: >> >> http://xmpp.org/extensions/xep-0258.html#label-catalog >>> If catalog is restrictive, as indicated by the restrict attribute with >>> value of true, the client SHOULD use one of the labels (or no label) >>> offered by the catalog. > > I second this sentence as confusing, it gets me every time.
I'll simplify and clarify per my response to Kim. > Also it would be nice to expand on the catalog-fetching flow, and how > to really use the 'from' attribute on <catalog>, which is only > mentioned in passing (it feels tacked-on). It was just tacked-on. When a server is asking another server for a catalog on behalf of a user, it may desire to indicate so to the other server so that responding server can produce a catalog specifically for that user as opposed to returning a catalog for all users of the requesting server. The responding server is free to ignore the from= (it may, for instance, have no knowledge of clearance for the user). I'll elaborate on this a bit in the spec. I'll see where else I might expand on the catalog fetching flow. Suggestions welcomed. > > There's an open question in 5.2.3. See my response to Wayne. > I'm not sure how "right" it is to be piggybacking on MUC subject > changes, as described in 5.2.5. I'm not inherently against it, mind. 5.2.5 needs a rewrite. In short, I don't think we ought to overload subject changes with a room label change side-effect. So no label should be provided with a subject change stanza. Changing security information objects (security labels, clearances, etc) associated with a room should be done through room configuration. -- Kurt
