> 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? > 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. For example, attribute names would benefit from some emphasis, like in the quoted line above. -- Kim Alvefur <[email protected]>
