This is quite a substantial protocol, but has, I think, two issues which
mean it is problematic to accept in my opinion:
a) It is not just presence-less MUC. It's an entirely new protocol which is
incompatible with existing XEP-0045. Even the room affiliation model is
different, allowing for examp
My initial reaction to this is that it's not providing anything beyond the
state of the art, and it implies that delivery is highly
unreliable (and suited to flood messaging), which is rather worrying.
I think XEP-0198 provides sufficient reliability to traffic that the
additional overhead here i
I think this looks good, though I think:
- The SRV label form probably ought to follow the precedent set by RFC
6186, even though I think that's uglier.
- I'm not at all convinced by abusing SNI in lieu of ALPN.
On 8 December 2015 at 17:39, XMPP Extensions Editor wrote:
> The XMPP Extensions Ed
On 9 December 2015 at 10:56, Dave Cridland wrote:
> My initial reaction to this is that it's not providing anything beyond the
> state of the art, and it implies that delivery is highly
> unreliable (and suited to flood messaging), which is rather worrying.
I think the key here is whether the XE
On 08.12.2015 18:40, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Quality of Service
>
> Abstract: This specification describes a generic method whereby messages can
> be sent between clients using a predefined Quality of Service le
FYI
-- Forwarded message --
From: Sam Whited
Date: Wed, Dec 9, 2015 at 10:40 AM
Subject: 2015-12-09 Meeting Minutes
To: coun...@xmpp.org
# 2015-12-09 Council Meeting
Logs: http://logs.xmpp.org/council/2015-12-09/#16:00:10
## Roll call
- Lance
- Dave
- PSA
- Tobias
- MattJ
Sam,
To repeat what I said in the Council MUC: Thanks for these minutes; they're
really excellent, and greatly appreciated.
Dave.
On 9 December 2015 at 16:42, Sam Whited wrote:
> FYI
>
>
> -- Forwarded message --
> From: Sam Whited
> Date: Wed, Dec 9, 2015 at 10:40 AM
> Subjec
On 12/09/2015 05:58 AM, Dave Cridland wrote:
> - The SRV label form probably ought to follow the precedent set by RFC
> 6186, even though I think that's uglier.
I am fine with changing the SRV format from the current
_xmpp-client._tls/_xmpp-server._tls to
_xmpps-client._tcp/_xmpps-server._tcp inst
On 9 December 2015 at 17:50, Travis Burtrum wrote:
> On 12/09/2015 05:58 AM, Dave Cridland wrote:
>> - The SRV label form probably ought to follow the precedent set by RFC
>> 6186, even though I think that's uglier.
>
> I am fine with changing the SRV format from the current
> _xmpp-client._tls/_x
On 12/9/15 11:28 AM, Matthew Wild wrote:
On 9 December 2015 at 17:50, Travis Burtrum wrote:
On 12/09/2015 05:58 AM, Dave Cridland wrote:
- The SRV label form probably ought to follow the precedent set by RFC
6186, even though I think that's uglier.
I am fine with changing the SRV format from
10 matches
Mail list logo