On 1/9/09 12:02 PM, Ben Schumacher wrote: > Peter, et al- > > I have a quick query about XEP-191.
Quick question, slow reply. :P > In Section 3, Relationship to > Privacy Lists, the XEP states that the new protocol is intended to be a > user-friendly front-end to the privacy lists protocol. While I have some > personal issues with this stated goal (in particular I don’t think that > XEP-16’s requirement for in-order processing is particularly useful), I > do have a specific question about implementation. I think the point was that if you (the server / service provider) already have XEP-0016 support in place, you could use the same backend data store for XEP-0191 support. I don't know how important that really is, though... > First, should there be some “standard” name for a list that is generated > by this protocol if it is retrieved via the XEP-16 protocol? Using the > URI of the blocking protocol would probably be sufficient (and could > provide a hint to sophisticated clients that this list was generated > using the simple protocol), but I am curious if there is guidance from > the standards body. No guidance yet, no. It's not clear to me how we would handle "lists" that are created via XEP-0191 but then migrate back to XEP-0016, for instance. > Additionally, the implications listed in Section 3 state: > > If all of a user's clients always use simple communications blocking, > then the default privacy list will be equivalent to the blocklist and > the default privacy list will be a kind of "virtual list" (in the sense > that it is never modified directly by any of the clients). > > This rule implies to me that there should be some interaction with > entity capabilities such that the server knows if the clients support > this protocol or not. This would, of course, require that the client > publish proper caps in its initial presence and the server will have to > defer this decision (i.e. should I be using the Simple Blocking list vs. > the list defined as “default” in XEP-16) until the capabilities > information has been cached by the server. That seems quite reasonable. Naturally the server could also figure this out via a disco#info request. > Finally, the 5^th implication in this section states: > > If one of a user's clients makes active something other than the default > privacy list, the user may receive communications from contacts who are > blocked in the default list. > > Is there an expectation here that a connect client that’s using the > simple blocking protocol would get the push notifications of the updated > blocklist? That question applies to the wider context of the usage of > this protocol – should privacy list modification cause simple blocking > protocol pushes and vice versa? I hadn't considered that before, but I think the answer is "yes". > Thanks for your time. Thanks for your patience. :) If you're still interested in this topic, it might be worth putting some effort into more clearly defining the relationship between XEP-0016 and XEP-0191. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
