Re: draft-30 non-implementable, please

[Ian Swett <[e-mail]>]

I'm not aware of anything that I expect to cause interop problems, but the
other editors may have something in mind.  In particular, there are no wire
format changes or new mechanisms that if you don't implement, the
connection fails.

I was thinking we would roll the changes into the existing -29, rather than
shipping -30 as an ALPN and Alt-Svc.

On Tue, Aug 11, 2020 at 2:04 PM Martin Duke <[e-mail]> wrote:

> I am happy to defer to the editors as to whether their change requires
> interoperability changes or not. My quick scan of the diff doesn't
> immediately reveal anything that would actually cause an issue, but I might
> be wrong.
>
> On Tue, Aug 11, 2020 at 10:55 AM Lucas Pardue <[e-mail]>
> wrote:
>
>> whoops [1]
>>
>> [1] -
>> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt
>>
>> On Tue, Aug 11, 2020 at 6:54 PM Lucas Pardue <[e-mail]>
>> wrote:
>>
>>>
>>> On Tue, Aug 11, 2020 at 6:46 PM Ryan Hamilton <[e-mail]> wrote:
>>>
>>>> Completely agree. If -30 is compatible with -29 let's keep the same "on
>>>> the wire" versioning so that we can maximize the probability of successful
>>>> communication!
>>>>
>>>
>>> Speaking as an individual, the struggle I have is that 29 to 30 is not a
>>> no-op. You can look at the current diff for transport [1] and see that
>>> we're sarig down the barrel of 10 design issues with proposals. So as an
>>> endpoint that implements 30-not-30, if I speak to an endpoint that is
>>> barely-29 and I have issues, what is my recourse? I really don't want to
>>> get into UA sniffing to build in branching code...
>>>
>>> Lucas
>>>
>>>
>>>