+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
Hi,
similar to my previous message about XEP-0313. I noticed some confusion
in XEP-0334 [1]:
In section 3, the hint is no-store/ but section 4 says no-storage/
and no-permanent-storage/.
If the MAM implementation in Prosody is right, no-storage/ and
no-permanent-storage/ are the good ones
* 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
I think it odd that this spec says
This specification introduces no known security considerations.
When it’s providing hints, at least in certain use cases, to an attacker as to
what the sender considers to be more sensitive. That is, it seems to be a
“look at this stanza” flag to
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'm not sure we should start new XMPP stream covered by OTR. It depends on what
we want to do. We can't hide that communication between A and B happens. Does
encrypting whole stanzas is worth of complications?
Dnia 17 grudnia 2014 17:46:18 CET,
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
On 12/22/2014 11:28 AM, Bartosz Małkowski wrote:
I'm not sure we should start new XMPP stream covered by OTR. It
depends on what we want to do. We can't hide that communication
between A and B happens. Does encrypting whole stanzas is worth of
complications?
We couldn't hide the fact that
* 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
23 matches
Mail list logo
