On Nov 9, 2010, at 2:43 PM, Matthew Wild wrote: > From the XEP: > > ### > If catalog is restrictive, as indicated by the restrictive attribute > with value of true, the client SHOULD use one of the labels (or no > label) offered by the catalog.
There's a typo here (and another in one of the examples). s/restrictive attribute/restrict attribute/ (fixed in repo, not yet published) > > One and only one of the items may have a default attribute with value > of true. The client should default to this item in cases where the > user has not selected an item. > > An item may have no label. Such an item offers a choice of sending a > stanza without a label. > ### > > When initially reading the first sentence it seems like a client could > choose to use one of the supplied labels, or it could choose to use no > label. Most clients are not policy aware and hence are naturally restricted to offered catalog. restrict="true" was intended to advise clients which are policy aware, and hence might have the ability to create 'custom' labels (or any label not presented in the catalog), not to offer the ability to the user. > > Then the last sentence says a catalog may explicitly include the > choice of "no label". > > So my question is this... in a restrictive catalog without the "no > label" option, should the client be able to send stanzas without a > label? Operationally, I think it's hard to disallow clients the ability to send stanzas without a label. > If yes, why would we need the ability to offer "no label" as a catalog entry? I think it can (should?) be removed. It was added at the request of another implementor. I'll let them (assuming they are on this list) to present an argument for its continued inclusion. > If no, the first sentence could probably be clarified. Also, I'm not > sure if this would even make sense given that clients that do not > support this XEP wouldn't know about the restriction anyway and might > still send with no label. > > Thoughts? > > Matthew
