Re: [Acme] Concerning alternative formats …

[Martin Thomson <[e-mail]>]

Sure.  Plenty of ways to do that.

If your primary concern is issuance, then you don't even need server
push, you can just long-poll.  In HTTP/1.1, that's gross because it
ties up a connection and has some disgusting keep-alive properties.
In h2 there is no opportunity cost to worry about, the connection
remains usable for other things while you wait.  (You can use
prefer:wait to control timing if you want a standards-based solution:
https://tools.ietf.org/html/rfc7240#section-4.3)

On Tue, Mar 6, 2018 at 9:27 AM, Richard Barnes <[e-mail]> wrote:
> Thomson: Could h2 push replace some of the polling here?
>
> On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper <[e-mail]>
> wrote:
>>
>>
>> > On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman <[e-mail]>
>> > wrote:
>> >
>> > Especially with CT logging being a pragmatic requirement,
>> > time-to-delivery for certificates is likely to increase (slightly) rather
>> > than decrease.
>>
>> 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.
>>
>> Thanks for those who have given this suggestion their consideration. I
>> don’t mean to “gum up the gears” for the main ACME work, but as I’ve been
>> writing ACME clients the polling stuff has stuck out to me like a sore
>> thumb.
>>
>> It’s worth noting, too, that concerns about overhead may be alleviated if
>> we do get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone
>> will expose an SCTP endpoint, or a raw TCP endpoint that implements a simple
>> message-boundary layer. I think the question of pure-message, bidirectional
>> transport is more relevant than a specific transport implementation.
>>
>> -F
>
>