Subject: Re: [quicwg/base-drafts] QPACK settings in HTTP (#1323)

From: Mike Bishop <[email-masked]>
Date: Fri, 18 May 2018 12:48:25 -0700

We can't really avoid them being tightly coupled -- at the very least, QPACK is defined for the payload of the HEADERS and PUSH_PROMISE frames.  Those are used for HTTP concepts, so *they* can't very well be defined by the QPACK spec.

Another dependency that currently exists:  HTTP has to reserve the unidirectional streams that QPACK needs.  And that's probably okay, as there's an existing dependency we can't get rid of.

There is an intriguing (scary) possibility there, though....  If there were a stream header on unidirectional streams and new types could be added by extensions, QPACK could simply register the new stream types it wants.  One less tight coupling, but one more extension point.

-- 
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/issues/1323#issuecomment-390313647

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 May 2018 15:44:35 -0700

You see, I like that idea.  QPACK defines its requirements in terms of streams and HPACK uses those.  It's a nice directed dependency arrangement.  The service it provides (uncompressed HEADERS -> compressed HEADERS) is provided, but only if hq provides some settings and some streams.  We might want to avoid having to put a type header on bidirectional streams though; no sense in being arbitrarily flexible.

BTW, think of what the CERTIFICATE frame stuff might do with its own stream...

-- 
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/issues/1323#issuecomment-390351392

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 May 2018 16:12:36 -0700

The more I think about this, the more appealing it becomes, actually.  Then the weird state machine from H2 with Server Push simply becomes one more type of extension-owned unidirectional stream, and if we wanted to pull Push out into an extension on its own, we could.  Let me sketch this out, and we'll see how crazy it winds up being.

-- 
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/issues/1323#issuecomment-390355480

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 18 May 2018 16:19:57 -0700

In a nutshell are you suggesting: bidirectional streams are used to provide
'core' HTTP request/response semantics. Unidirectional streams SHOULD be
used for extensibility?

On Sat, 19 May 2018, 00:12 Mike Bishop, <[email-masked]> wrote:

> The more I think about this, the more appealing it becomes, actually. Then
> the weird state machine from H2 with Server Push simply becomes one more
> type of extension-owned unidirectional stream, and if we wanted to pull
> Push out into an extension on its own, we could. Let me sketch this out,
> and we'll see how crazy it winds up being.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1323#issuecomment-390355480>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGRFtQiFwgs5AE7oNi2LB3nrYsUG5Ftsks5tz1VkgaJpZM4TiFAS>
> .
>

-- 
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/issues/1323#issuecomment-390356387

---

From: afrind <[email-masked]>
Date: Fri, 25 May 2018 16:03:32 -0700

Closed #1323 via #1358.

-- 
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/issues/1323#event-1647621458