Re: [Webpush] Receipt subscription follow-up

+1

But I'm not sure we can support the mode that Martin described, so I think
we may
take advantage of "PS MAY return a new receipt subscription if it is unable
to reuse".
Buffering and flow control are complicated - the choice is between dropping
receipts
or sending them to a different DC. I haven't checked, but I think there is
no guarantee
on saving receipts if AS doesn't have enough ingress capacity.

One question for HTTP/2 experts: I assumed the receipt promises are subject
to
normal 'max concurrent streams' ( and this will be the main mechanism to do
flow control/balancing from PS to AS). However I see rfc7540:

...
" Note: The client never sends a frame with the END_STREAM flag for

      a server push."

How does the PS know that AS can accept more receipts, and how does it know
a receipt has been accepted by the AS ?

Costin

On Tue, Apr 26, 2016 at 5:29 PM Brian Raymor <Brian.Raymor@microsoft.com>
wrote:

> On Mon, Apr 25, 2016 at 5:02 PM Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
> > Not wanting to steal, Brian's thunder here, but this is the change we
> > discussed during the meeting:
>
> >   https://github.com/webpush-wg/webpush-protocol/pull/84
>
> > It's good stuff, but there's a small wrinkle I thought that I'd raise:
> > https://github.com/webpush-wg/webpush-protocol/issues/85
>
> <snip>
>
> I've adopted Martin's proposal in #85 and made further clarifications
> based on the initial review of the pull request.
> If there are no further comments, I'll merge the pull request on
> Wednesday. I'd like to publish -05 before EOW.
>
> Thanks,
> ...Brian
>
>
>
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>