On Oct 5, 2011, at 11:46 PM, Kim Alvefur 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. > [...] >> An item may have no security label. Such an item offers a choice of >> sending a stanza without a label. > > Does that mean that with an non-restrictive catalog, a client may send > no label even if there's no label-less item? Ie can restrictive=false be > interpreted as pretending there's a item without label?
The restrict flag was intended to inform a client capable of producing custom labels that it should not offer a custom label choice in the context which the catalog was provided. I should clarify the spec that restrict flag just means this, removing any semantic overload that might be suggested. There's also the question of whether a client is or not allowed to send stanzas without any label. This question shouldn't be answered by the restrict attribute as that would be a semantic overload. In initially writing the spec, my view was that a client should always be allowed to send a stanza with no label, mostly for backward compatibility with clients which don't support XEP 258. Most XEP258 clients I've seen generally allow generation of messages without labels. I suggest that XEP 258 that this is generally allowed unless someone can make a damn good argument that we should add a flag indicating to the client they should not generate messages with no label (unless the catalog contains an empty item). > >> 5. Is the specification accurate and clearly written? > It's a bit heavy to read, and could benefit from some formating. > Currently it feels like a wall of text at some places. I'll see if I can find a way to make it an easier read. > For example, attribute names would benefit from some emphasis, like in > the quoted line above. I can certainly do that. -- Kurt > > -- > Kim Alvefur <[email protected]> >
