On Tue, 22 May 2012, Peter Saint-Andre wrote:
pro: works with multiplexing and retains the current security properties
of xep-0138. Additionally, that still enables the receiving server to
use the (authenticated) peer name to selectively offer/deny certain
features based on black/whitelists.
On Tue, 2012-06-05 at 10:39 +0200, Philipp Hancke wrote:
No backward compability issues with m-link or prosody. Is anyone else
doing s2s-compression or 0198?
Prosody currently (not sure if Matthew is already ahead of my
testing version) doesn't offer compression or session managment on
mostly xsf-land but since this touches multiplexing...
Am 22.05.2012 19:04, schrieb Peter Saint-Andre:
On 5/22/12 9:23 AM, Philipp Hancke wrote:
On Tue, 22 May 2012, Peter Saint-Andre wrote:
On 5/21/12 7:22 AM, Matthew Wild wrote:
On 21 May 2012 09:08, Philipp Hanckefi...@goodadvice.pages.de
On 5/22/12 2:42 PM, Philipp Hancke wrote:
mostly xsf-land but since this touches multiplexing...
Am 22.05.2012 19:04, schrieb Peter Saint-Andre:
On 5/22/12 9:23 AM, Philipp Hancke wrote:
On Tue, 22 May 2012, Peter Saint-Andre wrote:
On 5/21/12 7:22 AM, Matthew Wild wrote:
On 21 May 2012
Am 22.05.2012 23:06, schrieb Peter Saint-Andre:
[...]
Pandoras box actually... XEP 0138 might need restrictions similar to
those described in the security considerations of RFC 3749. I'd like to
avoid that if possible by retaining the assumption that the peer is
authenticated.
It seems to me
