IETF Logo Mail Archive

Re: [Webpush] Receipt subscription follow-up

RUELLAN Herve <Herve.Ruellan@crf.canon.fr> Fri, 29 April 2016 11:21 UTC

Return-Path: <Herve.Ruellan@crf.canon.fr>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5939012D613 for <webpush@ietfa.amsl.com>; Fri, 29 Apr 2016 04:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsM_CzV4hCor for <webpush@ietfa.amsl.com>; Fri, 29 Apr 2016 04:21:48 -0700 (PDT)
Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320FD12D640 for <webpush@ietf.org>; Fri, 29 Apr 2016 04:21:47 -0700 (PDT)
Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u3TBLipR028934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2016 13:21:45 +0200
Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u3TBLirx014989; Fri, 29 Apr 2016 13:21:44 +0200
Received: from Antiope.crf.canon.fr (172.19.70.56) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 29 Apr 2016 13:21:44 +0200
Received: from Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a]) by Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a%12]) with mapi id 15.00.0995.032; Fri, 29 Apr 2016 13:21:44 +0200
From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
To: Brian Raymor <Brian.Raymor@microsoft.com>, Costin Manolache <costin@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [Webpush] Receipt subscription follow-up
Thread-Index: AQHRn07lAIBlXI24M0OiyBmRbdlP85+c15aAgAA+KoCAAAKaAIAA2iMAgAFMlWSAAAFvAf//SGGAgAAnDgCAAiHk0A==
Date: Fri, 29 Apr 2016 11:21:44 +0000
Message-ID: <63d5793ded0c4949aa7bb913ee4d04ab@Antiope.crf.canon.fr>
References: <CABkgnnXKDZvLWxkhFP0R4jW=ZyFwqiqQREFA5BFKH9i4PQCmyA@mail.gmail.com> <CO2PR03MB24076724ECF95BDBB9B83E0F83640@CO2PR03MB2407.namprd03.prod.outlook.com> <CAP8-Fqk8p1HkbJkB60UoE=jeQPa9CKorgc8kqSF7sUMS3FcAfQ@mail.gmail.com> <CABkgnnU_jnSuUX7TC+qy2SwteU1tW9DEAb0uoHmhOcYNQaYuvw@mail.gmail.com> <CO2PR03MB24079FEC854A49F60C66F81583640@CO2PR03MB2407.namprd03.prod.outlook.com> <CAP8-Fq=aufZchVdqCM=+0+7WxGvgoaez0t8J2x=U6_Mz91s+Yg@mail.gmail.com> <CABkgnnW=_3BfHGmr=fVo_gx3dE3bLrPqMFcPvHqWt6cfOJVnaQ@mail.gmail.com> <CO2PR03MB2407C751A0F725A2D8916DEE83650@CO2PR03MB2407.namprd03.prod.outlook.com> <CABkgnnWDp1QiagN3W=xZaUTWy+hScGsV-dkRZzdAHKHCRnTVXA@mail.gmail.com> <CO2PR03MB2407968C0BFB4EB5CC6741EB83650@CO2PR03MB2407.namprd03.prod.outlook.com> <CABkgnnUz8HsNoNVVKTLuZni=s=bPEstgwNE47UaYq+GyZZmy4Q@mail.gmail.com> <CAP8-FqmCezOo1M=WbeT_-0Gagp3RKPKiBbHPx-ye_BoXVEV-BA@mail.gmail.com> <CO2PR03MB2407B49956A17F641845A32B83650@CO2PR03MB2407.namprd03.prod.outlook.com>
In-Reply-To: <CO2PR03MB2407B49956A17F641845A32B83650@CO2PR03MB2407.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.5.242]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/cIJ_Y5a_H2CmsDW4xt3qKN_1BgQ>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] Receipt subscription follow-up
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2016 11:21:50 -0000

> -----Original Message-----
> From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Brian
> Raymor
> Sent: jeudi 28 avril 2016 06:40
> To: Costin Manolache <costin@gmail.com>om>; Martin Thomson
> <martin.thomson@gmail.com>om>; RUELLAN Herve
> <Herve.Ruellan@crf.canon.fr>
> Cc: webpush@ietf.org
> Subject: Re: [Webpush] Receipt subscription follow-up
> 
> +Herve - to bring to his attention.
> 
> > One option would be to have multiple GET requests on the receipt
> > resource - each would get a MAX_CONNECTION promises (receipts), after
> > that the AS would need to make another GET.  They can also have 2-3
> > concurrent GET requests if they want, and manage the flow by
> (outstanding GET * max_receipts_per_get).
> 
> To track, I opened - https://github.com/webpush-wg/webpush-
> protocol/issues/87.
> 
> Martin and I discussed earlier this evening. I suggested a similar approach to
> what you're proposing - the ability for the AS to include a header field in its
> monitor request to indicate a maximum number of receipts. Martin then
> brought to my attention Herve's related work on Push-Policy:
> 
> https://www.ietf.org/proceedings/94/slides/slides-94-httpbis-2.pdf
> https://tools.ietf.org/pdf/draft-ruellan-http-accept-push-policy-01.pdf
> 
> It seems more appropriate for HTTPbis to address policies for push promises
> rather than creating a special case in WebPush. Herve - what are your
> thoughts about including this scenario in your proposal?

I think this is adding a new interesting dimension to my proposal. 
It can be integrated as a new Push-Policy. This is easy to do, but would have limitations: it would not be possible to combine this maximum number of resources to push with other Push-Policies such a Head (pushing only HEAD responses) or Fast-Load.
So a better solution would be to define a new Push-Policy for limiting the number of resources that can be pushed, and in addition to extend the Accept-Push-Policy and Push-Policy headers to be able to combine several policies.

Hervé

> ...Brian
> 
> 
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush

v2.8.7 | Report a Bug | By Email