Re: [Acme] Concerning alternative formats …

[Felipe Gasper <[e-mail]>]

> On Mar 5, 2018, at 5:58 PM, Matthew D. Hardeman <[e-mail]> wrote:
> 
>> On Mar 5, 2018, at 3:50 PM, Felipe Gasper <[e-mail]> wrote:
>> 
>> Quick point: the alleviation of polling would go for authz status as well as to certificate delivery.
>> 
>> A certificate order that has 10 domains needs to poll for the status of all 10 of those domains’ authorizations as well as the certificate issuance. “ACME/bidi” would remove all 11 of those needs to poll.
>> 
> 
> While it eliminates the need for those 11 targets to poll for, it adds the not insignificant infrastructure cost of nailing up a stateful connection.  It’s worth mention that the past decade has seen massive improvements in the network stack from the low layer up through application layer apis as it would pertain to handling a great many of these connections, but there is still some cost to nailing up large numbers of concurrent connections.

I would think the grand majority of such connections would go away once certificate renewals were done. There’d be no reason to hold onto the connection afterward, as it ties up resources for the client as well as the server.

> As others note, h2 offers numerous models under which you could achieve the same benefits of getting asynchronous return of results over a single TCP session.

I’ve not seen much discussion of h2 server push in this context; its use seems (by design) limited to the case of pre-sending resources that the client will either accept or reject via RST_STREAM.

There is SSE (Server-Sent Events), but my understanding is that that protocol is effectively abandoned, supported browser implementations notwithstanding. (Edge/IE in particular doesn’t support it.)

Is there another mechanism that you and Thomson have in mind, or what am I missing?

Thank you,
-Felipe Gasper
Mississauga, Ontario