Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-03-15 Thread Cullen Jennings (fluffy)
> On Mar 15, 2016, at 1:40 PM, Cullen Jennings (fluffy) > wrote: > > > I think this draft needs WGLC in all the WGs where it limits the existing > code space. Somehow hit send trying to move this from one computer to another before finishing it. But what I was going on

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-03-15 Thread Cullen Jennings (fluffy)
I think this draft needs WGLC in all the WGs where it limits the existing code space. > On Feb 7, 2016, at 10:21 PM, Joseph Salowey wrote: > > This document is relevant to the TLS working because it reserves a large > portion of the TLS content type space. The values

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-03-03 Thread Ilari Liusvaara
On Thu, Mar 03, 2016 at 04:44:30PM +, Salz, Rich wrote: > > > The unencrypted headers need to be kept for backward compatiblity. > > Even for a new protocol revision? Well, actually, it might be possible to compress everything except ClientHello headers. One should still avoid the 15 and 16

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-03-03 Thread Salz, Rich
> The unencrypted headers need to be kept for backward compatiblity. Even for a new protocol revision? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-03-03 Thread Ilari Liusvaara
On Thu, Mar 03, 2016 at 09:48:00AM +1100, Martin Thomson wrote: > > [3] I actually hope that we can change DTLS 1.3 so that it won't mux > properly. That will have a size benefit that should outweigh the cost > of having to rev 5764 for 1.3. I thought about this a bit... It occurs to me that

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-03-02 Thread Martin Thomson
On 3 March 2016 at 09:20, Marc Petit-Huguenin wrote: > draft-ietf-avtcore-rfc5764-mux-fixes does not reserve large portions of the > ContentType codepoints, RFC 5764 did. The damage is already done as RFC 5764 > is deployed as a component of RTCWeb. I think that we can