Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light

2015-12-09 Thread Dave Cridland
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

Re: [Standards] Proposed XMPP Extension: Quality of Service

2015-12-09 Thread Dave Cridland
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

Re: [Standards] Proposed XMPP Extension: SRV records for XMPP over TLS

2015-12-09 Thread Dave Cridland
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

Re: [Standards] Proposed XMPP Extension: Quality of Service

2015-12-09 Thread Matthew Wild
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

Re: [Standards] Proposed XMPP Extension: Quality of Service

2015-12-09 Thread Florian Schmaus
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

[Standards] Fwd: 2015-12-09 Meeting Minutes

2015-12-09 Thread Sam Whited
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

Re: [Standards] Fwd: 2015-12-09 Meeting Minutes

2015-12-09 Thread Dave Cridland
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

Re: [Standards] Proposed XMPP Extension: SRV records for XMPP over TLS

2015-12-09 Thread Travis Burtrum
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

Re: [Standards] Proposed XMPP Extension: SRV records for XMPP over TLS

2015-12-09 Thread Matthew Wild
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

Re: [Standards] Proposed XMPP Extension: SRV records for XMPP over TLS

2015-12-09 Thread Peter Saint-Andre
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