Re: Striving for Compromise (Consensus?)

On 11 Jul 2014, at 9:33 pm, <K.Morgan@iaea.org> <K.Morgan@iaea.org> wrote:

> Hi Mark-
> 
> On Friday,11 July 2014 12:53, mnot@mnot.net wrote:
>> On 11 Jul 2014, at 7:41 pm, <K.Morgan@iaea.org> <K.Morgan@iaea.org> wrote:
>>> It eliminates both purposes of the 'Greg et al' proposal:
>>> a) Eliminate the CONTINUATION ugliness (complexity, processing, etc.), and
>>> b) add bits & settings for tuning frame lengths.
>> 
>> See my previous message to Willy. These are not issues, they're a wish list.
> 
> You lost me on this one. We (the Greg et al group) spent a considerable amount of time on our proposal with a rather detailed explanation of the issues and our proposed solutions, see [1].  There has been a lot of discussion on this proposal, IMO mostly positive from the WG, *including yourself.*
> 

> To say now that the two main goals of our proposal is a wish list totally baffles me.
> 

> I agree that since this has turned into a full-scale discussion of non-editorial changes there may be some "wishes" creeping in.  But I take issue with you calling this a wish list just because I didn't copy-and-paste each point from Greg's e-mail [1] when we introduced the proposal.


It's not that you didn't copy Greg's e-mail; it's that those are not issues as far as the WG is considered; they're not shared goals. We have identified the underlying issues (#549-553), and will address them.

I.e., while your purpose may be to get rid of CONTINUATION, we don't recognise that as a substantive technical issue. Likewise, adding bits and settings is a means to an end -- addressing the underlying issues -- not an end unto itself.

There are many ways to address those issues, and we're talking through a variety of them now. I'm looking for the minimal viable change to address these issues, gain consensus and ship the spec, because that's what our obligation is.

If your proposal is able to achieve consensus, that's great -- I'm not ruling it out by any means.


>> Let other people make their own assessments of the proposal, please. If Roberto, Patrick et al like this proposal, all the better.
> 
> Gladly! But they better have some pretty sound justification as to why the "optimal" frame length for efficient and responsive multiplexing magically changed from 16K to 64K!!!

The onus is very firmly upon those proposing a change from the WG has previously agreed to, not those who are trying to accommodate the people proposing the change. Doing it your way would only encourage people to become inflexible, and that's not what we want.


>>>> 5) Allowing interleaving of CONTINUATION frames with other frames.
>>> 
>>> Admittedly better than the status quo, but still not entirely clear why this is necessary. i.e. why not 1*HEADERS instead?
>> 
>> Let's agree on the general approach before we go into tweaking.
> 
> This is NOT a tweak!  If header fragmentation can be accomplished with 1*HEADERS instead of HEADERS+CONTINUATION*, then keeping CONTINUATION is just keeping complexity for the sake of being too bothered to remove it. I keep bringing it up because nobody has provided a satisfactory answer as to why we still need CONTINUATION of we remove the reference set from HPACK.

The fact that we have running code is good enough for now. If there's a substantive technical issue that making this change can address, we'll discuss it. If we can achieve easy consensus (i.e., no great controversy) on an aesthetic change to the protocol at this late stage, great. What I'm absolutely not willing to do is to have another 100-email thread on what colour the bikeshed is painted (nod to your collaborator there) while we still have substantive issues outstanding.

Thanks,


--
Mark Nottingham   https://www.mnot.net/

Received on Saturday, 12 July 2014 06:46:40 UTC