Subject: Re: [quicwg/base-drafts] Define a mechanism for negotiating extensions (#1072)

From: Victor Vasiliev <[email-masked]>
Date: Wed, 28 Feb 2018 12:55:48 -0800

@vasilvv pushed 1 commit.

c1b55ef  Fix a syntax error

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1072/files/61700b924dbb2cc24eab5ce326de346496552d41..c1b55ef15544d838ae23edf8c2e3248b42fd6814

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 28 Feb 2018 12:59:10 -0800

Okay, it sounds like everyone wants to make ID assignments explicit.

What are people's thoughts about the negotiation pattern?  I think I am completely fine with committing to client speaking first, but if that's undesirable, it can be worked around.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1072#issuecomment-369380687

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Feb 2018 22:50:07 +0000 (UTC)

So Victor, there are two options here that don't require a lot of secondary changes (like new messages and the like):

1. Client offers a set of extensions, server indicates which of those apply and assigns mappings.  Client parameter is an array of extension codepoints.  Server parameter is an array of (frame type, extension codepoint).

2. Both client and server offer a set of extensions and mappings.  Server does the same.  Only the codepoints that the server includes are permitted for use, but each peer needs to use the mappings chosen by its peer.

The former is a straight-up negotiation; it's the first of its kind, so some caution is needed.  The second preserves - at least to some extent - the current notion that transport parameters are purely declarative.  Either way, this is slightly hazardous.

I have a slight preference for the second, but don't see a strong argument against the former.  However, I am intensely aware of the fact that this system could end up like the stepchild of RFC 3264 and that is not a place I want to end up.  We need to be VERY clear about the way transport parameters work.  Whatever decision we make, I will take an action to put text in the document clearly explaining which approach is most appropriate for future things, or if we think that's overly constraining, making it the responsibility of future designers to very clearly specify their rules.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1072#issuecomment-369411395