> On Dec 22, 2014, at 7:46 AM, Holger Weiß <[email protected]> wrote: > > * Kurt Zeilenga <[email protected]> [2014-12-22 05:50]: >> Where an implementation uses a common backend for Privacy Lists and >> Block Lists, the implementation MUST ensure that the blocking behaviors >> exposed to the user are consistent with the semantics of the particular >> request they used manage the information held in that backend as >> detailed in their respective specifications. This statement in no way >> alters the specified semantics of the requests. > > The question is how XEP-0191 could be mapped onto XEP-0016 in a sane > way. Why do you think the answer should be implementation-specific?
Because I think there may well be more than one way to map it and... > Won't that just add to the current interoperability mess? from an interoperability point of view, so long as the semantics of both 191 and 16 stanzas are maintained, the implementation should be free to choose how to map between the two. The problem we have right now is, I think, is having a section in 191 which says to map things in a way which violate the 191 semantics stated elsewhere in the XEP. The XEP really needs to be self consistent. > Maybe we just have to admit that a sane mapping isn't possible, so those > two extensions would have to be treated as unrelated and incompatible? Depends on what one considers “sane”. The problem is it really hard to maintain the flexibility of a XEP 16 framework and have the simplicity of the XEP 191 protocol. Maybe there’s only one way to solve this… but if there’s multiple, I don’t see why we have to mandate one possible mapping over another. > Either way, I think this is a protocol issue, not an implementation > issue. I disagree. See above. — Kurt
