This thread got a lot of good discussion, but then rather fizzled out.
What's the general standards body next step for things like this? Keep
prodding the list until a consensus forms, or is there some procedure
for bringing a formal proposal?
Thanks,
Sam
On 12/21/2014 08:19 PM, Sam Whited
On 22.12.2014 22:22, Holger Weiß wrote:
* Dave Cridland d...@cridland.net [2014-12-22 16:31]:
On 22 December 2014 at 14:47, Holger Weiß hol...@zedat.fu-berlin.de wrote:
* Kurt Zeilenga kurt.zeile...@isode.com [2014-12-22 05:31]:
I think if anything in XEP 191 needs to change, it's the
* Florian Schmaus f...@geekplace.eu [2014-12-23 11:28]:
I'm a fan of xep16 and don't see a reason to deprecated it.
The reason I see are the interoperability issues with XEP-0191 clients.
Currently, if users choose block this contact in Gajim, that contact
won't appear as blocked in clients
I think that's a bad user experience.
There’s no way to do this without bad XEP 191 user experience. You can either
confuse the XEP 191 user by saying a contact is blocked when they aren’t
completely blocked or say they aren’t blocked when they are partially blocked.
Either way is bad.
On 12/23/2014 08:23 AM, Kurt Zeilenga wrote:
I have don’t see why we’d deprecate something that’s in use simply
because it doesn’t work well with something else in use.
The blocking command bills itself as a frontend for privacy lists [1].
Privacy lists provide a superset of the features
* Kurt Zeilenga kurt.zeile...@isode.com [2014-12-23 05:23]:
I think that's a bad user experience.
There's no way to do this without bad XEP 191 user experience. You
can either confuse the XEP 191 user by saying a contact is blocked
when they aren't completely blocked or say they aren't
+1
Seems reasonably for me.
Also this line seems weird for me:
If the foregoing suggestions are followed, the user will appear offline to
the contact.
I think it should be „the contact will appear offline to the user“, but it
could be removed anyway, if Sam’s suggestion takes place.
On 22 December 2014 at 01:19, Sam Whited s...@samwhited.com wrote:
Hi all,
XEP-0191 (Blocking command) specifies that once a contact is blocked, no
stanzas are delivered from them to the user:
Once the user has blocked communications with the contact, the
user's server MUST NOT deliver
* Dave Cridland d...@cridland.net [2014-12-22 09:19]:
On 22 December 2014 at 01:19, Sam Whited s...@samwhited.com wrote:
XEP-0191 (Blocking command) specifies that once a contact is blocked, no
stanzas are delivered from them to the user:
Once the user has blocked communications with the
On Dec 21, 2014, at 5:19 PM, Sam Whited s...@samwhited.com wrote:
Hi all,
XEP-0191 (Blocking command) specifies that once a contact is blocked, no
stanzas are delivered from them to the user:
Once the user has blocked communications with the contact, the
user's server MUST NOT deliver
On Dec 22, 2014, at 5:31 AM, Kurt Zeilenga k...@isode.com wrote:
I think if anything in XEP 191 needs to change, it’s the discussion of how
one maps XEP 191 onto XEP 4 privacy lists that should change. It should be
clearly stated that the blocking entity is required to perform the
On 12/22/2014 04:19 AM, Dave Cridland wrote:
Slightly confused by this. XEP-0191 is server-side enforced, so the
behaviour will be applied and controlled by the server, not the client.
Gajim uses Privacy lists without the XEP-0191 frontend. Sorry, I was
unclear there.
This would mean that
* Kurt Zeilenga kurt.zeile...@isode.com [2014-12-22 05:31]:
I think if anything in XEP 191 needs to change, it's the discussion of
how one maps XEP 191 onto XEP 4 privacy lists that should change. It
should be clearly stated that the blocking entity is required to perform
the mapping in such
On 22 December 2014 at 13:51, Sam Whited s...@samwhited.com wrote:
On 12/22/2014 04:19 AM, Dave Cridland wrote:
Slightly confused by this. XEP-0191 is server-side enforced, so the
behaviour will be applied and controlled by the server, not the client.
Gajim uses Privacy lists without the
On 12/22/2014 08:50 AM, Kurt Zeilenga wrote:
I would go a bit further… first, I would lift the MUST use a common
backend statement and leave implementation details mostly to the
implementor.
This would make the behavior very ambiguous if you were using both the
blocking command and privacy
* Kurt Zeilenga kurt.zeile...@isode.com [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
On Dec 22, 2014, at 6:47 AM, Holger Weiß hol...@zedat.fu-berlin.de wrote:
* Kurt Zeilenga kurt.zeile...@isode.com [2014-12-22 05:31]:
I think if anything in XEP 191 needs to change, it's the discussion of
how one maps XEP 191 onto XEP 4 privacy lists that should change. It
should be
In summary (if I'm understanding correctly):
If you're using both privacy lists and blocklists, ensure that there is
a direct two way mapping between the two (probably by just using the
same backend datastore), but only if the request follows the exact
semantics of the blocking command
Le 22/12/2014 16:21, Dave Cridland a écrit :
On 22 December 2014 at 13:51, Sam Whited s...@samwhited.com
mailto:s...@samwhited.com wrote:
On 12/22/2014 04:19 AM, Dave Cridland wrote:
Slightly confused by this. XEP-0191 is server-side enforced, so the
behaviour will be
On 22 December 2014 at 14:47, Holger Weiß hol...@zedat.fu-berlin.de wrote:
* Kurt Zeilenga kurt.zeile...@isode.com [2014-12-22 05:31]:
I think if anything in XEP 191 needs to change, it's the discussion of
how one maps XEP 191 onto XEP 4 privacy lists that should change. It
should be
On Dec 22, 2014, at 7:46 AM, Holger Weiß hol...@zedat.fu-berlin.de wrote:
* Kurt Zeilenga kurt.zeile...@isode.com [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
On 12/22/2014 10:21 AM, Dave Cridland wrote:
Also bear in mind that XEP-0191 was designed to be a simple replacement to
XEP-0016, the observation being that with the exception of some extremely
rare cases, everything people actually used XEP-0016 for could be wrapped
up into XEP-0191 and
* Kurt Zeilenga kurt.zeile...@isode.com [2014-12-22 10:05]:
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.
I meant the interoperability of clients that use
* Dave Cridland d...@cridland.net [2014-12-22 16:31]:
On 22 December 2014 at 14:47, Holger Weiß hol...@zedat.fu-berlin.de wrote:
* Kurt Zeilenga kurt.zeile...@isode.com [2014-12-22 05:31]:
I think if anything in XEP 191 needs to change, it's the discussion of
how one maps XEP 191 onto XEP
* Sam Whited s...@samwhited.com [2014-12-22 13:07]:
Maybe putting it forward as a means to obsolete XEP-0016
FWIW, this sounds like the best way forward to me :-)
Holger
Hi all,
XEP-0191 (Blocking command) specifies that once a contact is blocked, no
stanzas are delivered from them to the user:
Once the user has blocked communications with the contact, the
user's server MUST NOT deliver any XML stanzas from the contact to
the user. The block remains in force
26 matches
Mail list logo
