From nobody Thu Apr 6 07:55:30 2017 Return-Path: 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 6535412946A for ; Thu, 6 Apr 2017 07:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 paZ_GUXgFdUo for ; Thu, 6 Apr 2017 07:55:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BAB126CE8 for ; Thu, 6 Apr 2017 07:55:26 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v36EtOo2027170 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Apr 2017 09:55:25 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: webpush@ietf.org Cc: Phil Sorber From: Adam Roach Message-ID: <23e4798c-1e20-2aeb-db01-5ab13b40a954@nostrum.com> Date: Thu, 6 Apr 2017 09:55:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Webpush] New Webpush Chair X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 14:55:28 -0000 Webpush WG -- In order to facilitate moving the final Webpush items to completion, Phillip Sorber has agreed to come on as co-chair of Webpush. Thanks to Phil for stepping up to help out! /a From nobody Mon Apr 17 09:29:07 2017 Return-Path: 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 D55D61315DE for ; Mon, 17 Apr 2017 09:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 wRtJTs5V0z0u for ; Mon, 17 Apr 2017 09:29:05 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA4512706D for ; Mon, 17 Apr 2017 09:29:05 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id g60so38623863qtd.3 for ; Mon, 17 Apr 2017 09:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nhZNB1uwnyLT7pDUNn/lXXEfKWb1Zk4VXMAf59zad08=; b=AaGCxsnS2ni3jFbw4Y5PNHWWgJwq3OW2Pg3pdK4gAMytjuZL7yK+zS+3N4Ag6VYgBA mynauR3oKAzNAiZUGvJ6sSR9EnM91YOHd5NWmfZgOisex3jnpEEaFmHsbPKgBWAHg2yj BtglAI+8nLkYM5r8a++ukEhf6pw3JdTzqvRSs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nhZNB1uwnyLT7pDUNn/lXXEfKWb1Zk4VXMAf59zad08=; b=ED6IczGFCkcZfus7HFLzGlYeeavlzEEBtdd0Yv9BIiY3bxREO01pBsIef4yQ29MQan Apdr79mBblav062F3wHVFCWLDvGfKqLJsr8dxa7cmkYGs00uOkAySoR72DPwIoAuvicp Tk3LQQ0gJrap9sVlHTjTVtZlJhuIRTFf9pXL1RFzrPW2cHa+Nd0T90cldLPeWfxFrEJ3 8t0i5wKnuTxDS29NvJek94iI7urMsmC477B764U+lLtHEoHyZMMjXY2ui+SIwSMFnE9V huPjJVV5tlRn84oaW4stzZoJDn62XMW2ITLXaOkPF3gCHAVXlTmtJjy2buEiWUg5hVxC lFjw== X-Gm-Message-State: AN3rC/4gq1kw7pciSE8W2sTInfRU95L2A9PqB3UJ/TUg8VMYjWSKTwVe QkYdSR6+NLJHIuV2lLFHTS26yTaJu7T2qCY= X-Received: by 10.237.53.236 with SMTP id d41mr10799594qte.158.1492446544964; Mon, 17 Apr 2017 09:29:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.44.116 with HTTP; Mon, 17 Apr 2017 09:28:24 -0700 (PDT) In-Reply-To: References: From: Kit Cambridge Date: Mon, 17 Apr 2017 09:28:24 -0700 Message-ID: To: Martin Thomson Cc: JR Conlin , "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] Versioning aes128gcm-encoded messages X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 16:29:07 -0000 On Sun, Mar 19, 2017 at 8:52 PM, Martin Thomson wrote: > The problem with versioning inline is that it is invisible to HTTP > content negotiation. Granted, that doesn't really make any difference > to the push usage, but a label is visible. If you accept the need to > have more labels, then the inline check is redundant. This sounds good to me. No need to add a version to the payload if we can use the header. From nobody Tue Apr 18 13:43:47 2017 Return-Path: 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 5A6F31243FE for ; Tue, 18 Apr 2017 13:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 N3xMFB2-T_XF for ; Tue, 18 Apr 2017 13:43:40 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 54AF012943E for ; Tue, 18 Apr 2017 13:43:40 -0700 (PDT) Received: (qmail 51491 invoked by uid 99); 18 Apr 2017 20:43:39 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Apr 2017 20:43:39 +0000 Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id E47C21A00A6 for ; Tue, 18 Apr 2017 20:43:38 +0000 (UTC) Received: by mail-io0-f173.google.com with SMTP id a103so9479441ioj.1 for ; Tue, 18 Apr 2017 13:43:38 -0700 (PDT) X-Gm-Message-State: AN3rC/7SzXCCH/BT3gCZ44IsDMQ7SwSwnDs/Ctz3vsOvZgi+osRFa2b8 iu6N0UVyKBy57mOtR8yrXnT1FTB1DA== X-Received: by 10.107.137.148 with SMTP id t20mr15915607ioi.79.1492548218220; Tue, 18 Apr 2017 13:43:38 -0700 (PDT) MIME-Version: 1.0 From: Phil Sorber Date: Tue, 18 Apr 2017 20:43:27 +0000 X-Gmail-Original-Message-ID: Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a113ed2ae5b8f9a054d76f697 Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-vapid-02 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:43:41 -0000 --001a113ed2ae5b8f9a054d76f697 Content-Type: text/plain; charset=UTF-8 Hello All, Just getting caught up on doc status by reading the email archive and I see that both outstanding WG docs were in WGLC two months ago, however draft-ietf-webpush-vapid never got any feedback, positive or negative. If anything was sent direct to the chairs before I was added, I am not able to see that. Please reply back to the list with any feedback you have. I'll leave this open for 1 week. Thanks. --001a113ed2ae5b8f9a054d76f697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All,

Just getting caught up= on doc status by reading the email archive and I see that both outstanding= WG docs were in WGLC two months ago, however=C2=A0draft-ietf-webpush-vapid ne= ver got any feedback, positive or negative. If anything was sent direct to = the chairs before I was added, I am not able to see that. Please reply back= to the list with any feedback you have. I'll leave this open for 1 week.
Thanks.
--001a113ed2ae5b8f9a054d76f697-- From nobody Tue Apr 18 14:53:41 2017 Return-Path: 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 B7D2F12EC60 for ; Tue, 18 Apr 2017 14:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 iKsKnSjQyFAx for ; Tue, 18 Apr 2017 14:53:38 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018C312025C for ; Tue, 18 Apr 2017 14:53:37 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id g2so2774026pge.3 for ; Tue, 18 Apr 2017 14:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AfwQBOKwd1226otuexZMimCVNB+s5Vl5S5/byiH6lRs=; b=F5wLvudKsM9a4zSgG5ZGZLzh9pAJtTKmf3y0L3jBEIWk0wcuol3wjoYZ6HNRZUX3Th QjomzWjjHUQftHrmYITgTGCGjYA3OnoTVvdervc0uo/zppU3xiiIpFxfU7zT2aA7Qf2r GP90xEXXtk+0Maf7l9E0RFHtDJre5bIAx91s4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AfwQBOKwd1226otuexZMimCVNB+s5Vl5S5/byiH6lRs=; b=aCdf2LW52iB+o0qza/gpGykEyfJeQDQ3YirNaPwXu9sm1od2iGXP2o0lMnlcriBQxp 9p3fusIwpxCbaN4RauSPYIL6pCXNr9pUMYYpokYDKXvxXXOjCUhQ2fYbbMLsfwCLNh6/ 6yadXAXmhN2Meo4cgmFws71nLfnju6DddUOcr0rKYoepQMAeeRgeDxYdUontqyhGnGc7 CqEP8S6YyFX5Khq1dFOjAqulXeI1xR89cDeZdlik5Ule8SmrKwwv4OEvBdB2FLNbFw1n nrVxayZR9V9bm+Utw8BuH0Zgiws3iQzNJLvHN16+/nEzpC1Z3LvJJBhUS/UAfFmTQpOE T1rA== X-Gm-Message-State: AN3rC/67SuHZGLj/tD6FcXv3KkVWTFXKjKmAVNJeB5o76TK+vdMsgA9u ftiCuibM14YBXU6wpBhOHA== X-Received: by 10.98.62.141 with SMTP id y13mr20273916pfj.93.1492552416801; Tue, 18 Apr 2017 14:53:36 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:64f9:24bd:b39a:c201? ([2620:101:80fc:224:64f9:24bd:b39a:c201]) by smtp.gmail.com with ESMTPSA id p68sm344118pfp.104.2017.04.18.14.53.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 14:53:35 -0700 (PDT) To: webpush@ietf.org References: From: jr conlin Message-ID: Date: Tue, 18 Apr 2017 14:53:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Thunderbird/54.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2967CD2746165BCF1A5CF0C4" Content-Language: en-US Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-vapid-02 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 21:53:40 -0000 This is a multi-part message in MIME format. --------------2967CD2746165BCF1A5CF0C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I'm fine with the proposed changes, and have worked them into my support libraries. On 4/18/17 1:43 PM, Phil Sorber wrote: > Hello All, > > Just getting caught up on doc status by reading the email archive and > I see that both outstanding WG docs were in WGLC two months ago, > however draft-ietf-webpush-vapid never got any feedback, positive or > negative. If anything was sent direct to the chairs before I was > added, I am not able to see that. Please reply back to the list with > any feedback you have. I'll leave this open for 1 week. > Thanks. > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --------------2967CD2746165BCF1A5CF0C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I'm fine with the proposed changes, and have worked them into my support libraries.

On 4/18/17 1:43 PM, Phil Sorber wrote:
Hello All,

Just getting caught up on doc status by reading the email archive and I see that both outstanding WG docs were in WGLC two months ago, however draft-ietf-webpush-vapid never got any feedback, positive or negative. If anything was sent direct to the chairs before I was added, I am not able to see that. Please reply back to the list with any feedback you have. I'll leave this open for 1 week.
Thanks.


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


--------------2967CD2746165BCF1A5CF0C4-- From nobody Wed Apr 19 13:18:51 2017 Return-Path: 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 B2A1F129C43 for ; Wed, 19 Apr 2017 13:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dxOgs9EQzir9 for ; Wed, 19 Apr 2017 13:18:46 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7C5129C48 for ; Wed, 19 Apr 2017 13:18:45 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j9so22638715ywj.3 for ; Wed, 19 Apr 2017 13:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H5bAoVvmgFuVPjCajpfF70Hqc1UKGJcSn60RTLxGRSw=; b=FaNFgRMb8a+AKOKeTXBhXomSP4guLpfcnUbcSxI01uustYaZHR3jlqgBhi6vLSw521 MteUDHxnGzKEyTuo/o2y1h6nBAGADuw3SasmLdsGj1UcZAUczz0FqsudQ/V8lImctiBm IeMNI0eFtyr4xUVwdfNXkRPqV3O13s9YFCXU5UcIo2mXgeRXpWANwpmodX0eCrbbQjK/ aaB7rQtz3h7WDpyYy0H4ROlMFoMaYfKULMcS0VguEYgwIXDBDglJRWUADmpgYnbuxeJe akxaB3VYhf7NMe5Ich6dqv94vKfI9MN8WgjKQST1YsycwdXn3SC29XJmvZS89r045fJZ BHZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H5bAoVvmgFuVPjCajpfF70Hqc1UKGJcSn60RTLxGRSw=; b=exo/0BZaDG8qTE1DCHvZe6ZC5zaTlHP2O+3f+qXC3hICvNQcg+p62dxQYf6HH0QJK3 1sdW04/6l8YyFBpM40NbaczHVkOSzr9X0pSkXhsgjXMGbOF4oD2JHeIbXFzP+yEkSkAe qybuAYQ906bksokradgjkvRKuXRJ22Ua6CGzR6cJv4NaryXAdnqGKyidaZwMpYqxIq8E Dk+M4NUltvkt019J9O5cYqc1gfxnQqgnMwcrJAHIcG9NxXlob4cB4Q+M8AGUO/9H6Sme oAAV7Lg6zMY/8SETGf0vrV5AYEMML4JdxhvXBK9qSFFzIUxpWrKEbI+YUszBQfV7uvGG iDiw== X-Gm-Message-State: AN3rC/4g4foQ/zPAyyJ7mG9qMagVSuRjvfHYS6Uik/3mLsBYdzkYxBXa Tttua+q6kS5eGCeEaEwD0NGapPQOkg== X-Received: by 10.202.85.3 with SMTP id j3mr2154454oib.98.1492633125289; Wed, 19 Apr 2017 13:18:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.97.161 with HTTP; Wed, 19 Apr 2017 13:18:44 -0700 (PDT) In-Reply-To: References: From: Costin Manolache Date: Wed, 19 Apr 2017 13:18:44 -0700 Message-ID: To: jr conlin Cc: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a113d37e83686cc054d8abb14 Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-vapid-02 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:18:48 -0000 --001a113d37e83686cc054d8abb14 Content-Type: text/plain; charset=UTF-8 +1 Costin On Tue, Apr 18, 2017 at 2:53 PM, jr conlin wrote: > I'm fine with the proposed changes, and have worked them into my support > libraries. > > > On 4/18/17 1:43 PM, Phil Sorber wrote: > > Hello All, > > Just getting caught up on doc status by reading the email archive and I > see that both outstanding WG docs were in WGLC two months ago, however > draft-ietf-webpush-vapid never got any feedback, positive or negative. If > anything was sent direct to the chairs before I was added, I am not able to > see that. Please reply back to the list with any feedback you have. I'll > leave this open for 1 week. > Thanks. > > > _______________________________________________ > Webpush mailing listWebpush@ietf.orghttps://www.ietf.org/mailman/listinfo/webpush > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a113d37e83686cc054d8abb14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Costin

On Tue, Apr 18, 2017 at 2:53 PM, jr= conlin <jconlin@mozilla.com> wrote:
=20 =20 =20
I'm fine with th= e proposed changes, and have worked them into my support libraries.

On 4/18/17 1:43 PM, Phil Sorber wrote:
Hello All,

Just getting caught up on doc status by reading the email archive and I see that both outstanding WG docs were in WGLC two months ago, however=C2=A0draft-ietf-webpush-vapid never got any f= eedback, positive or negative. If anything was sent direct to the chairs be= fore I was added, I am not able to see that. Please reply back to the list = with any fe= edback you have. I'll leave this open for 1 week.
Thank= s.


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/m=
ailman/listinfo/webpush



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

--001a113d37e83686cc054d8abb14-- From nobody Wed Apr 19 13:44:21 2017 Return-Path: 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 1193C12D574 for ; Wed, 19 Apr 2017 13:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 XZyXbPbF2yOb for ; Wed, 19 Apr 2017 13:44:17 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9AD12E6A3 for ; Wed, 19 Apr 2017 13:44:16 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id t144so18787647lff.1 for ; Wed, 19 Apr 2017 13:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=B6MPBGMIg4di2su4/S0627DZUXdFQHCx392vrsznaeA=; b=Voeb5/G22iDgqNY/Zp2YXCmUqsTLR7EEDvRdSiDd78v2TRNU+k1MsJI8iEkqynTWGQ FuVNLF+25EvLYJITXh6o9Znby2LGC6KVcdpCkIqlMWO+/iInBBzhNR2ou4kgFU/BCFb+ 5t3AL1oYwh87FZ0zZ0giwNTL6jMurRI2E9q7w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=B6MPBGMIg4di2su4/S0627DZUXdFQHCx392vrsznaeA=; b=nX/WthgVnAxk1LZe5AxGeizZv/af9TpVvh9nPsuiTvGSGzrF1KLMC1GAWda+vEZd7r swxMuuzuFX/h6LNWySASDJ31/BKOxdVJzybFxC66RcXCBX0irvEEebyCDLSrIwfqDGRx 97O6s7RrAtDVxe6pPaG2tK0Eqgr9BwqF549/fxTUtsJJvt1u4Yq2p093H8ZecwWBckRE aAcOXxUcIuQs0iDyaN9SrLpSkyjpaEa1dZk36ElJ6qoCZ8kJLJPwF9RLcVaiOIpnoRq8 3lJjlCvFCjOW4u6I5NSr6ydXCwavdx21qhn8olrGKi9kFpWzQmD78K0OFNdfZs/0bTEb 9eeQ== X-Gm-Message-State: AN3rC/4BrHoOJDhf81J0a+pSwh8+wKXIRXVf6geoABZ9zrntcXZSTUuw FB8lpJvNuTkROexmCwjLJxEKvDVIaRjWJY0RNA== X-Received: by 10.46.0.70 with SMTP id 67mr1617053lja.113.1492634654244; Wed, 19 Apr 2017 13:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.84.79 with HTTP; Wed, 19 Apr 2017 13:44:13 -0700 (PDT) Reply-To: jrconlin@mozilla.com From: JR Conlin Date: Wed, 19 Apr 2017 13:44:13 -0700 Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a1142b53658a999054d8b165e Archived-At: Subject: [Webpush] User Agents should return a list of supported encryption content types X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:44:19 -0000 --001a1142b53658a999054d8b165e Content-Type: text/plain; charset=UTF-8 Recently, a bug filed against a webpush subscription library highlighted a shortcoming. https://github.com/web-push-libs/web-push-php/issues/48#issuecomment-295416292 Currently, there are two in production encryption content types, "aesgcm" and "aes128gcm". The "voice of authority" about what types of accepted content types is the UA. The sorts of allowed encryption is not communicated to the subscription update provider. I would like to propose that the returned PublishSubscription object < https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription> "options" object be modified to include a "contenttypes" list of allowed ECE content types. (e.g. ['aesgcm', 'aes128gcm']) This method would also allow future content types to be relayed. If no "contenttypes" field is present, then the provider must assume "aesgcm" encoding, to allow for older UAs. This field would also help indicate "updated" UAs which can take advantage of the newer draft specifications. My apologies if this is the wrong group. WebPush and ECE span several and this is a case where they overlap. I will happily repost to the appropriate group. --001a1142b53658a999054d8b165e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Recently, a bug filed against a webpush subscription library highlighted a= shortcoming.

https://github.com/web-push-libs/w= eb-push-php/issues/48#issuecomment-295416292

Currently, there are two in production encryption content types, "aesgcm" a= nd=20 "aes128gcm". The "voice of authority" about what types = of accepted=20 content types is the UA. The sorts of allowed encryption is not=20 communicated to the subscription update provider.

I would like to propose that the returned PublishSubscription object=20 <https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription> "options" object be modified to include a "contenttypes&quo= t; list of=20 allowed ECE content types. (e.g. ['aesgcm', 'aes128gcm']) T= his method=20 would also allow future content types to be relayed. If no=20 "contenttypes" field is present, then the provider must assume &q= uot;aesgcm"=20 encoding, to allow for older UAs.

This field would also h= elp indicate "updated" UAs which can take advantage of the newer = draft specifications.

My apologies if this is the wrong group. WebPush and ECE span seve= ral and this is a case where they overlap. I will happily repost to the app= ropriate group.
--001a1142b53658a999054d8b165e-- From nobody Wed Apr 19 13:56:37 2017 Return-Path: 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 EA31112EA64 for ; Wed, 19 Apr 2017 13:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 GOsHuAWx2Q1G for ; Wed, 19 Apr 2017 13:56:32 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B6D12E05D for ; Wed, 19 Apr 2017 13:56:32 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id d131so30926820qkc.3 for ; Wed, 19 Apr 2017 13:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tFapyMY15W4hZfUr7p7xUt0XV1zP/XHTm7DIoKPSTVk=; b=JwsIHnxszZK33ZRd6IGWCMg+tCEyImDq2DdKh/5FJBRNyYhbQ0njZH2XQBRmV/Zmzy 9/8DBvtD5U95LXX/MrYHZI/aEHsBZbvvqHPC8UyYzS8ZGOD4NKlcM8xxKFskIHC79xK+ S9pdBHOha1S0oyupYJd4wsbOf0QdiMJPJbkkc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tFapyMY15W4hZfUr7p7xUt0XV1zP/XHTm7DIoKPSTVk=; b=rxkZ7BNLp09z96ogIW7FuJy3RHZyCtn7mg4s4f2RipRHiT9l4WARGLCYvsAGH3G/jU AzUF60YCmfcEorpRACgOyMp9wSvdNIkP0l8P73EBHrwqXPJjwlHb0aD00xYE+M/rhH5e 9GlCKnOAmu2DocqJ0GwW1X8EYq40yWa9lsAjicnpx4N2HkCj0NkCndGYJWftKgyIJC1u p3HDCn0y0p7/mkP/IpXNneTb+QHXJ+2z6qhUaO+HoBiUCmcTzDdo0x1h4TYRv1CyZz8R Yu8FjR/WoOe9M0c24DcME3xFxBMG6RuIkZThksQtEX4MlPSmNiEWeFo1LuLR8YUWlEQg x+TA== X-Gm-Message-State: AN3rC/5j0y5CqHQCBONzfmyhKf7TEae7QUzYyvvOF2Fv5HrQBk05gu2h wyigJOs6Rk+oB2zOZA7FbR1lunzr8PeFcS2XGQ== X-Received: by 10.233.232.212 with SMTP id a203mr4433375qkg.53.1492635391887; Wed, 19 Apr 2017 13:56:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.44.116 with HTTP; Wed, 19 Apr 2017 13:55:51 -0700 (PDT) In-Reply-To: References: From: Kit Cambridge Date: Wed, 19 Apr 2017 13:55:51 -0700 Message-ID: To: "Conlin, JR" Cc: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] User Agents should return a list of supported encryption content types X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:56:35 -0000 This could be handled transparently by the push server, too. A client registering with the push server would indicate which schemes it supports. When the app server tries to send a message, the push server can check if the "Content-Encoding" is supported for that client, and immediately reject the message with a 400 if not. WDYT? Cheers, - kit On Wed, Apr 19, 2017 at 1:44 PM, JR Conlin wrote: > Recently, a bug filed against a webpush subscription library highlighted a > shortcoming. > > https://github.com/web-push-libs/web-push-php/issues/48#issuecomment-295416292 > > Currently, there are two in production encryption content types, "aesgcm" > and "aes128gcm". The "voice of authority" about what types of accepted > content types is the UA. The sorts of allowed encryption is not communicated > to the subscription update provider. > > I would like to propose that the returned PublishSubscription object > > "options" object be modified to include a "contenttypes" list of allowed ECE > content types. (e.g. ['aesgcm', 'aes128gcm']) This method would also allow > future content types to be relayed. If no "contenttypes" field is present, > then the provider must assume "aesgcm" encoding, to allow for older UAs. > > This field would also help indicate "updated" UAs which can take advantage > of the newer draft specifications. > > My apologies if this is the wrong group. WebPush and ECE span several and > this is a case where they overlap. I will happily repost to the appropriate > group. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > From nobody Wed Apr 19 14:13:46 2017 Return-Path: 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 11A31129B15 for ; Wed, 19 Apr 2017 14:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 bBSRBvxepZSh for ; Wed, 19 Apr 2017 14:13:42 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78A11293D9 for ; Wed, 19 Apr 2017 14:13:41 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id 88so19104857lfr.0 for ; Wed, 19 Apr 2017 14:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zVb8u9FB1hozNNGq1QflMvIBOpeSsDVoBxGeHg5Nyn8=; b=KjrjbOARtupbAJCyeF7ZUUBQzDcdvWGibl0w+y8hLxBm4MIjBhsjEZ/q8IhROQ1SW3 T12fGIhr1RVGOn4XdVBM5oTjws2r3cf2kinnEE0dyCftovZOaqouHAokvMzD/mFjbDHD N2kgaCC/a82XOSlw2IHMcseqx4r8R1nJ6gYYo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=zVb8u9FB1hozNNGq1QflMvIBOpeSsDVoBxGeHg5Nyn8=; b=NbO4r7CC7hHl++MZhVu6cf8pbJvUiILNtsAFjcipaW4q+IFKx8KUfwuzOKFxeBAwUE kBSpfggqvPnZ5h/myCwshRXMSN8Cvwl47/BZHNt3D9wKzv6w6aYRTqIMZzlBxD1C/vGd cHJ80h7zp06kZ+luYcMw5KwSU0G52YJ4qtjiXkP9ezG9PlS80v3ZZa/8efKiFypJYcb4 H3qED1aL6e79oxONUb3b3ye1QCVu8joc9fNqykBSMcsYuCZ2V1Q7P8EHGeNSHyVFH3hM Z+fsv33M10ClrcWKoRE4p4gxnbhxGl0ataqVbr9c6jPdheVfY9OJi/NoxXqwxRa/WQQX Zbsg== X-Gm-Message-State: AN3rC/7d0QK2U13Xe/IJ4YvD3sRg12otWIuR+EK3Do0miM0g5w+kSEtz WHajUplUZF7bxJLtiz21WrLoNG35wWbt X-Received: by 10.25.67.81 with SMTP id m17mr1708940lfj.33.1492636419798; Wed, 19 Apr 2017 14:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.84.79 with HTTP; Wed, 19 Apr 2017 14:13:39 -0700 (PDT) Reply-To: jrconlin@mozilla.com In-Reply-To: References: From: JR Conlin Date: Wed, 19 Apr 2017 14:13:39 -0700 Message-ID: To: Kit Cambridge Cc: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=f403045e9e0e94d6ae054d8b7f26 Archived-At: Subject: Re: [Webpush] User Agents should return a list of supported encryption content types X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:13:44 -0000 --f403045e9e0e94d6ae054d8b7f26 Content-Type: text/plain; charset=UTF-8 The problems with that approach are: 1) it's reactive. The subscription provider must repeatedly re-encode and retry a message, potentially for each UA (which could require millions of retransmits) 2) it's non-authoritative. The push server either is told or must guess the state of an individual client. This means that it must track known UAs (since a message can be stored for later retrieval by the UA). Having the "source of truth" specify what's allowed and what's not at the time of subscription, ensures that the most accurate data is provided. Honestly, this is a coordination point between two parties. I'm not sure introducing a third is a good idea. On Wed, Apr 19, 2017 at 1:55 PM, Kit Cambridge wrote: > This could be handled transparently by the push server, too. A client > registering with the push server would indicate which schemes it > supports. When the app server tries to send a message, the push server > can check if the "Content-Encoding" is supported for that client, and > immediately reject the message with a 400 if not. > > WDYT? > > Cheers, > - kit > > On Wed, Apr 19, 2017 at 1:44 PM, JR Conlin wrote: > > Recently, a bug filed against a webpush subscription library highlighted > a > > shortcoming. > > > > https://github.com/web-push-libs/web-push-php/issues/48# > issuecomment-295416292 > > > > Currently, there are two in production encryption content types, "aesgcm" > > and "aes128gcm". The "voice of authority" about what types of accepted > > content types is the UA. The sorts of allowed encryption is not > communicated > > to the subscription update provider. > > > > I would like to propose that the returned PublishSubscription object > > > > "options" object be modified to include a "contenttypes" list of allowed > ECE > > content types. (e.g. ['aesgcm', 'aes128gcm']) This method would also > allow > > future content types to be relayed. If no "contenttypes" field is > present, > > then the provider must assume "aesgcm" encoding, to allow for older UAs. > > > > This field would also help indicate "updated" UAs which can take > advantage > > of the newer draft specifications. > > > > My apologies if this is the wrong group. WebPush and ECE span several and > > this is a case where they overlap. I will happily repost to the > appropriate > > group. > > > > _______________________________________________ > > Webpush mailing list > > Webpush@ietf.org > > https://www.ietf.org/mailman/listinfo/webpush > > > --f403045e9e0e94d6ae054d8b7f26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The problem= s with that approach are:

1) it's reactive. The subscription provider must repeatedly re-encode and= =20 retry a message, potentially for each UA (which could require millions=20 of retransmits)

2) it's non-authoritative. The push server either is told or must guess= =20 the state of an individual client. This means that it must track known=20 UAs (since a message can be stored for later retrieval by the UA).=20 Having the "source of truth" specify what's allowed and what&= #39;s not at=20 the time of subscription, ensures that the most accurate data is=20 provided.

Honestly, this is a coordination point between two parties. I= 9;m not sure introducing a third is a good idea.

On Wed, Apr 19, 2017 at 1:55 PM, Kit Cambridge <kit@mozil= la.com> wrote:
This could b= e handled transparently by the push server, too. A client
registering with the push server would indicate which schemes it
supports. When the app server tries to send a message, the push server
can check if the "Content-Encoding" is supported for that client,= and
immediately reject the message with a 400 if not.

WDYT?

Cheers,
- kit

On Wed, Apr 19, 2017 at 1:44 PM, JR Conlin <jconlin@mozilla.com> wrote:
> Recently, a bug filed against a webpush subscription library highlight= ed a
> shortcoming.
>
> https://github.co= m/web-push-libs/web-push-php/issues/48#issuecomment-295416292=
>
> Currently, there are two in production encryption content types, "= ;aesgcm"
> and "aes128gcm". The "voice of authority" about wh= at types of accepted
> content types is the UA. The sorts of allowed encryption is not commun= icated
> to the subscription update provider.
>
> I would like to propose that the returned PublishSubscription object > <https://developer.mozilla.= org/en-US/docs/Web/API/PushSubscription>
> "options" object be modified to include a "contenttypes= " list of allowed ECE
> content types. (e.g. ['aesgcm', 'aes128gcm']) This met= hod would also allow
> future content types to be relayed. If no "contenttypes" fie= ld is present,
> then the provider must assume "aesgcm" encoding, to allow fo= r older UAs.
>
> This field would also help indicate "updated" UAs which can = take advantage
> of the newer draft specifications.
>
> My apologies if this is the wrong group. WebPush and ECE span several = and
> this is a case where they overlap. I will happily repost to the approp= riate
> group.
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush=
>

--f403045e9e0e94d6ae054d8b7f26-- From nobody Wed Apr 19 14:42:21 2017 Return-Path: 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 6586712948E for ; Wed, 19 Apr 2017 14:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 dqbZ286Zk1yj for ; Wed, 19 Apr 2017 14:42:18 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA82120046 for ; Wed, 19 Apr 2017 14:42:18 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id c45so31164711qtb.1 for ; Wed, 19 Apr 2017 14:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T6e3Y/Je3B2KIiH8x4eRONSg5/LqSZ9sFL7b6FoD6Y0=; b=Z6hKRMlpF6y1vxeW9H1tm9f5YIZ76+7wM2I2ZGiTLesrG90d1+ZrrqPB5E+RXjVTwV eKXf5H3h8kb43DIRM6ExrmOlS+64R7HaGYwVOD8tG8tj7z7VZy2z5dEzeTYIBBv+U76u 0x4qgHpeBOcD7BYSPe2eSkSrZWj7+1NriBk4E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T6e3Y/Je3B2KIiH8x4eRONSg5/LqSZ9sFL7b6FoD6Y0=; b=uYqVvxnVolbe7BMdDSjowDqyYoScOLl3nKYAfH6BjeLAs0sSBBF9Fub2xhKCGj2vUG OIVxYANP8meLn85xTXKhAB1AnsD7i0eIThZDXFk8r0bAmUGuru8Kbh1w47INaRquv65L KbPEdugFwvpsLGK5qCKUnfu75Ao2KmpdY7xl0YVXW5Qej6ondEd66v5lwbW+2p8HpZ+b MvX8yjWLXM/dLhPaYVh/onzmeC1f6moPZzBaZvhcy6jBHbtnQ4SK7ljnct6/XbJ7gtGu kkvXORpfVKCAIRTH1SCZnKdnLTgffb+a/I9DSLE0TYfz9bfpXX+iAFoU2HPbHAy+7VuK 5pHw== X-Gm-Message-State: AN3rC/6ZjeJbTFxJMfr+P89nZJbWwFi36QLr7O5+QTK9xigWxKo7QC8A ryc9B3MEnFMLfTxzM/dzlPHm94ifPZxA X-Received: by 10.237.45.194 with SMTP id i60mr4571461qtd.262.1492638137696; Wed, 19 Apr 2017 14:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.44.116 with HTTP; Wed, 19 Apr 2017 14:41:37 -0700 (PDT) In-Reply-To: References: From: Kit Cambridge Date: Wed, 19 Apr 2017 14:41:37 -0700 Message-ID: To: "Conlin, JR" Cc: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c125854f9ddc2054d8be584 Archived-At: Subject: Re: [Webpush] User Agents should return a list of supported encryption content types X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:42:20 -0000 --94eb2c125854f9ddc2054d8be584 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 19, 2017 at 2:13 PM, JR Conlin wrote: > 1) it's reactive. The subscription provider must repeatedly re-encode and > retry a message, potentially for each UA (which could require millions of > retransmits) > That's a good point, and we've already seen that many app servers will keep trying to deliver to expired subscriptions. Based on that, I suspect the more likely outcome is those messages will get dropped on the floor instead of resent. Realistically, app servers will need to keep using "aesgcm", until "aes128gcm" is supported in all browsers and encryption libraries. Once "aesgcm" usage is low enough, we can remove it entirely. > 2) it's non-authoritative. The push server either is told or must guess > the state of an individual client. This means that it must track known UAs > (since a message can be stored for later retrieval by the UA). Having the > "source of truth" specify what's allowed and what's not at the time of > subscription, ensures that the most accurate data is provided. > I don't follow, apologies. For Autopush, we already keep client info in the router table: its UAID, last connect time, and whether it uses Web Push, Simple Push, FCM, or APNs. We need to look this up regardless of whether we store or immediately deliver the message. It's not clear to me why we'd need to guess, or who the third party is. I think I'm missing something, though. Could you please elaborate? Cheers, - kit --94eb2c125854f9ddc2054d8be584 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Apr 19, 2017 at 2:13 PM, JR Conlin <jconlin@mozilla.com><= /span> wrote:
1) it's reactive. The subscription provider must repeatedly re-encode and= =20 retry a message, potentially for each UA (which could require millions=20 of retransmits)

That's a good poi= nt, and we've already seen that many app servers will keep trying to de= liver to expired subscriptions. Based on that, I suspect the more likely ou= tcome is those messages will get dropped on the floor instead of resent. Re= alistically, app servers will need to keep using "aesgcm", until = "aes128gcm" is supported in all browsers and encryption libraries= . Once "aesgcm" usage is low enough, we can remove it entirely.
=C2=A0
=
2) it's non-authoritative. The push server either is told or must guess= =20 the state of an individual client. This means that it must track known=20 UAs (since a message can be stored for later retrieval by the UA).=20 Having the "source of truth" specify what's allowed and what&= #39;s not at=20 the time of subscription, ensures that the most accurate data is=20 provided.

I don't follow, apologies. For Au= topush, we already keep client info in the router table: its UAID, last con= nect time, and whether it uses Web Push, Simple Push, FCM, or APNs. We need= to look this up regardless of whether we store or immediately deliver the = message. It's not clear to me why we'd need to guess, or who the th= ird party is. I think I'm missing something, though. Could you please e= laborate?

Cheers,
- kit
--94eb2c125854f9ddc2054d8be584-- From nobody Wed Apr 19 14:55:28 2017 Return-Path: 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 0128712785F for ; Wed, 19 Apr 2017 14:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 oBRaqGWZ7cmj for ; Wed, 19 Apr 2017 14:55:25 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB011243FE for ; Wed, 19 Apr 2017 14:55:24 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id t144so19531826lff.1 for ; Wed, 19 Apr 2017 14:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6+B7PjxtRBRTK1vqvj+NsgK5D6c+8V8qw3gFONGbsMU=; b=QKaL0diCOaHwAK3QLly2Ir9pnEB5iyq92AVpYcuNoOFZjD3oseyD8Ral/Q/awi3ILJ VJDmTJFcvpm7t0lVxbustZE5zQiu17ZED3OThlFCNPiBumbyJOC4HS6lab1/tBt8TmJm BUxVMqLF2LZJZSgcydsl6fwn2F5KJ+KIrlwfM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=6+B7PjxtRBRTK1vqvj+NsgK5D6c+8V8qw3gFONGbsMU=; b=U97RhSG7+OlFjKC3D2PA02TB8I7aR6eD6c34lI2rmQBb+rJKmzgPFuyLRMLFQyFRc9 wXsmdKVIX9nWHK8VxkyYt/z4YDLIHrOQi3XQDwglb7jpxqStqOZNt6DZ6ScrKLWC95Rl ItQGL93lXbmmsCxzyzxfkz4hV0TS1snzt3uepHydMllTUJiCBDVCKSOy837lvgYmBlTL LdY5keCU3BLpKZxRi2NvAvV714pLh2MyaNOxmbiFomDXf+jQeucYr+EJmEGfSPzWsGAs +O7+Cwldx2DoOLd1bCiZglRmN934WHoTBtoBigV/U09/gGGziMVuGtHaC/igYr7iIh2e 4+aQ== X-Gm-Message-State: AN3rC/5AHFc2qH3IMzSP3hKM2hHq2NFnD6wc4qrwb9awCTYzmUI9ZuYx GLVcZ0rZzIARgrL1PeG5AsMW4NBprAhG X-Received: by 10.25.67.81 with SMTP id m17mr1748113lfj.33.1492638922730; Wed, 19 Apr 2017 14:55:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.84.79 with HTTP; Wed, 19 Apr 2017 14:55:22 -0700 (PDT) Reply-To: jrconlin@mozilla.com In-Reply-To: References: From: JR Conlin Date: Wed, 19 Apr 2017 14:55:22 -0700 Message-ID: To: Kit Cambridge Cc: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=f403045e9e0ec4bf9d054d8c149d Archived-At: Subject: Re: [Webpush] User Agents should return a list of supported encryption content types X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:55:27 -0000 --f403045e9e0ec4bf9d054d8c149d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge wrote: > 2) it's non-authoritative. The push server either is told or must guess >> the state of an individual client. This means that it must track known U= As >> (since a message can be stored for later retrieval by the UA). Having th= e >> "source of truth" specify what's allowed and what's not at the time of >> subscription, ensures that the most accurate data is provided. >> > > I don't follow, apologies. For Autopush, we already keep client info in > the router table: its UAID, last connect time, and whether it uses Web > Push, Simple Push, FCM, or APNs. We need to look this up regardless of > whether we store or immediately deliver the message. It's not clear to me > why we'd need to guess, or who the third party is. I think I'm missing > something, though. Could you please elaborate? > =E2=80=8BCertainly. It's true that for our server, we do track the state of= a previously connected UA for up to 30 days. (If a UA has not connected in 30 days, we consider that UA to be "unavailable" and reject messages.) The problem is that the client would still need to inform the push server which content types it supported, much the same as it would need to tell the subscription provider. =E2=80=8B The crux of this is that the Push Service is the "third party". It doesn't care what the encryption format is, since it just passes the data on. The two parties of interest in this case are the User Agent (which is responsible for decoding the final message) and the Subscription Provider (which is responsible for encoding the message). The Push Service may do some minimal, superficial checks of the message it's carrying, in order to reduce the traffic costs to the UA, but it cannot do a full check since that would presumably require deciphering the message. That's why I feel it's best to keep the pertinent information in the exchange between the UA and the subscriber directly, much like how the public key comes from the UA and not the Push Server. --f403045e9e0ec4bf9d054d8c149d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge <kit@mozilla.com> wrote:
2) it's non-authoritative. The push server either is told or must guess= =20 the state of an individual client. This means that it must track known=20 UAs (since a message can be stored for later retrieval by the UA).=20 Having the "source of truth" specify what's allowed and what&= #39;s not at=20 the time of subscription, ensures that the most accurate data is=20 provided.

I don't follow, apologies.= For Autopush, we already keep client info in the router table: its UAID, l= ast connect time, and whether it uses Web Push, Simple Push, FCM, or APNs. = We need to look this up regardless of whether we store or immediately deliv= er the message. It's not clear to me why we'd need to guess, or who= the third party is. I think I'm missing something, though. Could you p= lease elaborate?


=E2= =80=8BCertainly. It's true that for our server, we do track the state o= f a previously connected UA for up to 30 days. (If a UA has not connected i= n 30 days, we consider that UA to be "unavailable" and reject mes= sages.) The problem is that the client would still need to inform the push = server which content types it supported, much the same as it would need to = tell the subscription provider. =E2=80=8B

The crux of this is that the Push Service is t= he "third party". It doesn't care what the encryption format = is, since it just passes the data on. The two parties of interest in this c= ase are the User Agent (which is responsible for decoding the final message= ) and the Subscription Provider (which is responsible for encoding the mess= age). The Push Service may do some minimal, superficial checks of the messa= ge it's carrying, in order to reduce the traffic costs to the UA, but i= t cannot do a full check since that would presumably require deciphering th= e message.

That's why I feel it's best to keep the pertinent information in= the exchange between the UA and the subscriber directly, much like how the= public key comes from the UA and not the Push Server.
--f403045e9e0ec4bf9d054d8c149d-- From nobody Wed Apr 19 15:44:37 2017 Return-Path: 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 88199127337 for ; Wed, 19 Apr 2017 15:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 GQAslhKO53Kn for ; Wed, 19 Apr 2017 15:44:33 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DF7129B63 for ; Wed, 19 Apr 2017 15:44:33 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id 75so19916866lfs.2 for ; Wed, 19 Apr 2017 15:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=k/eP00OAoxDYBK7E+I5MU4QlyVjjoBstz0lxB+LIcEM=; b=Zdscgg/wqkN7R55ZXMbgJu7vbASgNaBfhq5E56Em1nN4fRBYqEfVF5E3NYopWA36uG h2a8p+ynuXGXisbM+uu/qrkveDGqK9HVTZe50ftzoxcdfNypJCx/wFPbWjgWULV0Nyoq hHsQssOV8djDpuWKIMBz29cwSoQR6MjiNUItA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=k/eP00OAoxDYBK7E+I5MU4QlyVjjoBstz0lxB+LIcEM=; b=X7HYHt9kpK+fsnkD1zlAkBpT9OB2g8tH4UCheCFVYyCcQuT9ZwdaM7piSiwnm8UlMz DivGicaQrxQDNs1HrPrshlLH570wkBlN2dTobqrC2ah5XsU+wfhC71D6SAIIebwOMlUQ s2nemVI+OcDnm1972Bfx2EeR6XJEkefjYoD0P7ExyZ6ybHUZGSKAN0qKUqJkKHH1QaBs xFe2KUcDhbjyTypXcFHyW4UxOOgCPP2o1GWopHcRpAxfmc8nEBh2FYVogwErCItZ+k5k ejOX82unFoAKGfJQplI/1L+4qtunG08yYDlYamVBVzKiAj/uTsnqzDXeJOq5UDe0bE2Z AH+g== X-Gm-Message-State: AN3rC/7jdhgo2qMPPXPwTFp242pUoDmndy4LsWSi42R2OJFY2xyRVENL 4KHZDcZglQ37YBkkTkNVmghOuHlLKfocCHM= X-Received: by 10.25.163.134 with SMTP id m128mr1800738lfe.1.1492641871333; Wed, 19 Apr 2017 15:44:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.84.79 with HTTP; Wed, 19 Apr 2017 15:44:30 -0700 (PDT) Reply-To: jrconlin@mozilla.com In-Reply-To: References: From: JR Conlin Date: Wed, 19 Apr 2017 15:44:30 -0700 Message-ID: To: John Reid Conlin Cc: Kit Cambridge , "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a11410b4e84a77c054d8cc4c7 Archived-At: Subject: Re: [Webpush] User Agents should return a list of supported encryption content types X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:44:36 -0000 --001a11410b4e84a77c054d8cc4c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And I've just realized that I have mislabled it as "contenttypes" instead of "contentencodings". On Wed, Apr 19, 2017 at 2:55 PM, JR Conlin wrote: > > On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge wrote: > >> 2) it's non-authoritative. The push server either is told or must guess >>> the state of an individual client. This means that it must track known = UAs >>> (since a message can be stored for later retrieval by the UA). Having t= he >>> "source of truth" specify what's allowed and what's not at the time of >>> subscription, ensures that the most accurate data is provided. >>> >> >> I don't follow, apologies. For Autopush, we already keep client info in >> the router table: its UAID, last connect time, and whether it uses Web >> Push, Simple Push, FCM, or APNs. We need to look this up regardless of >> whether we store or immediately deliver the message. It's not clear to m= e >> why we'd need to guess, or who the third party is. I think I'm missing >> something, though. Could you please elaborate? >> > > > =E2=80=8BCertainly. It's true that for our server, we do track the state = of a > previously connected UA for up to 30 days. (If a UA has not connected in = 30 > days, we consider that UA to be "unavailable" and reject messages.) The > problem is that the client would still need to inform the push server whi= ch > content types it supported, much the same as it would need to tell the > subscription provider. =E2=80=8B > > The crux of this is that the Push Service is the "third party". It doesn'= t > care what the encryption format is, since it just passes the data on. The > two parties of interest in this case are the User Agent (which is > responsible for decoding the final message) and the Subscription Provider > (which is responsible for encoding the message). The Push Service may do > some minimal, superficial checks of the message it's carrying, in order t= o > reduce the traffic costs to the UA, but it cannot do a full check since > that would presumably require deciphering the message. > > That's why I feel it's best to keep the pertinent information in the > exchange between the UA and the subscriber directly, much like how the > public key comes from the UA and not the Push Server. > --001a11410b4e84a77c054d8cc4c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And I've just realized that I have mislabled it as "contenttype= s" instead of "contentencodings".

On Wed, Apr 19, 2017 at 2:5= 5 PM, JR Conlin <jconlin@mozilla.com> wrote:

On Wed, Apr 19, 2017 at 2:41 PM, Kit = Cambridge <kit@mozilla.com> wrote:
2) it's non-authoritative. The push server either is told or must guess= =20 the state of an individual client. This means that it must track known=20 UAs (since a message can be stored for later retrieval by the UA).=20 Having the "source of truth" specify what's allowed and what&= #39;s not at=20 the time of subscription, ensures that the most accurate data is=20 provided.

I don't follow, apologies.= For Autopush, we already keep client info in the router table: its UAID, l= ast connect time, and whether it uses Web Push, Simple Push, FCM, or APNs. = We need to look this up regardless of whether we store or immediately deliv= er the message. It's not clear to me why we'd need to guess, or who= the third party is. I think I'm missing something, though. Could you p= lease elaborate?


=E2=80=8BCertainly. It's true that for our server, we do track the = state of a previously connected UA for up to 30 days. (If a UA has not conn= ected in 30 days, we consider that UA to be "unavailable" and rej= ect messages.) The problem is that the client would still need to inform th= e push server which content types it supported, much the same as it would n= eed to tell the subscription provider. =E2=80=8B

The crux of this is that the Push Servi= ce is the "third party". It doesn't care what the encryption = format is, since it just passes the data on. The two parties of interest in= this case are the User Agent (which is responsible for decoding the final = message) and the Subscription Provider (which is responsible for encoding t= he message). The Push Service may do some minimal, superficial checks of th= e message it's carrying, in order to reduce the traffic costs to the UA= , but it cannot do a full check since that would presumably require deciphe= ring the message.

That's why I feel it's best to keep the pertinent informa= tion in the exchange between the UA and the subscriber directly, much like = how the public key comes from the UA and not the Push Server.

--001a11410b4e84a77c054d8cc4c7-- From nobody Wed Apr 19 17:14:34 2017 Return-Path: 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 03DC512EAD4 for ; Wed, 19 Apr 2017 17:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iEKx2lrfdv1W for ; Wed, 19 Apr 2017 17:14:31 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A0212EAC8 for ; Wed, 19 Apr 2017 17:14:30 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id c80so20507334lfh.3 for ; Wed, 19 Apr 2017 17:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dmx+25jfzztJ/0QnPwUPKuVq2k6bIPSB3Hb3Wkf5Lc0=; b=Sw7odCrpdsNe3VOzvSEz3B6XLp1KjyEXxOnc0YOKsR/A1hfXql7GHRbRTfjw013Asp CooGiLdf68ReOgau8ZTtohBuz5vlqYkPJCSnAfu8XppYwYgcmK0acrcwm1Jwuvcy3YI8 F6xnOrm3pgTkMATZUeSLrxJqUXNq9PkKjycEg+mbFe6DDkaRB1BQs6EQaGfcgY3Nu8NT Uy46l+T3q2WCDHM6heATlM7qym3tXfPA+ehrsi6pwngNJNUz5K/TpyaZcihOdPwqTySz JT/R8zbAgsUdEKC2cegOIAZSbJcYj4MKRozhCH/pEp/x/PXv4l9I3hBNn6W0mZIxglHn w4Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dmx+25jfzztJ/0QnPwUPKuVq2k6bIPSB3Hb3Wkf5Lc0=; b=ukm0pxifhJqqnRdJReTEFizOutEcaV8k1t/kW2Q2H7opbXzlqEJSrEZYoDbRLd0xKQ qgUXnGMdodA82Cr/veOX9ZObDKZFU2K4m3bRJpST0yMJjyA60fzBImO6E++cJyShwZHa fZbAnhOdpeOELozVnVDeB6DYQSf23QolqyvXTLj10eT6bkqhfeDBWPh0x13BqxiqNDUW WHwpXS577/fwrJNR8im0VY7hmJHdzgH6WnF8u0ariW0OPtnF6kyMCuzT1FJU0gG4UENq ObUvBZyuf+igguHhHyU+56rClH4thAVFtuXTPa2phg329mesmnmztOLkPg+Jn8LbNCKH OljQ== X-Gm-Message-State: AN3rC/5IO/X14kqDZWcfh6Zor7wwyV5BnIGGgDBYeUF1Y5eH8jz3agv9 z0fjzlnZS9E5bjLZ2oUJ2ifTiM1kk+m7PGY= X-Received: by 10.25.79.27 with SMTP id d27mr1663642lfb.76.1492647269071; Wed, 19 Apr 2017 17:14:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Wed, 19 Apr 2017 17:14:28 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 20 Apr 2017 10:14:28 +1000 Message-ID: To: JR Conlin Cc: "webpush@ietf.org" , Kit Cambridge Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] User Agents should return a list of supported encryption content types X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 00:14:33 -0000 I think that JR's proposed solution works best (no need for intermediation of the information via the push service, immediate availability of the information, etc...). As a procedural matter, this is the wrong place to discuss the API. I'd recommend opening an issue (or a pull request, but that's only for the brave) against the API: https://github.com/w3c/push-api (As an aside, this isn't a per-subscription property, so I'd probably angle for a FrozenArray property on PushManager. That way, an application can know whether or not to even bother creating a subscription. There's also a separate question about whether we also use this to signal support for empty messages, which have no content coding.) On 20 April 2017 at 08:44, JR Conlin wrote: > And I've just realized that I have mislabled it as "contenttypes" instead of > "contentencodings". > > On Wed, Apr 19, 2017 at 2:55 PM, JR Conlin wrote: >> >> >> On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge wrote: >>>> >>>> 2) it's non-authoritative. The push server either is told or must guess >>>> the state of an individual client. This means that it must track known UAs >>>> (since a message can be stored for later retrieval by the UA). Having the >>>> "source of truth" specify what's allowed and what's not at the time of >>>> subscription, ensures that the most accurate data is provided. >>> >>> >>> I don't follow, apologies. For Autopush, we already keep client info in >>> the router table: its UAID, last connect time, and whether it uses Web Push, >>> Simple Push, FCM, or APNs. We need to look this up regardless of whether we >>> store or immediately deliver the message. It's not clear to me why we'd need >>> to guess, or who the third party is. I think I'm missing something, though. >>> Could you please elaborate? >> >> >> >> Certainly. It's true that for our server, we do track the state of a >> previously connected UA for up to 30 days. (If a UA has not connected in 30 >> days, we consider that UA to be "unavailable" and reject messages.) The >> problem is that the client would still need to inform the push server which >> content types it supported, much the same as it would need to tell the >> subscription provider. >> >> The crux of this is that the Push Service is the "third party". It doesn't >> care what the encryption format is, since it just passes the data on. The >> two parties of interest in this case are the User Agent (which is >> responsible for decoding the final message) and the Subscription Provider >> (which is responsible for encoding the message). The Push Service may do >> some minimal, superficial checks of the message it's carrying, in order to >> reduce the traffic costs to the UA, but it cannot do a full check since that >> would presumably require deciphering the message. >> >> That's why I feel it's best to keep the pertinent information in the >> exchange between the UA and the subscriber directly, much like how the >> public key comes from the UA and not the Push Server. > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > From nobody Tue Apr 25 14:34:48 2017 Return-Path: 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 7089F12EC9D for ; Tue, 25 Apr 2017 14:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 VFIn1ZbbQ01d for ; Tue, 25 Apr 2017 14:34:45 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id A5C95129436 for ; Tue, 25 Apr 2017 14:34:45 -0700 (PDT) Received: (qmail 2458 invoked by uid 99); 25 Apr 2017 21:34:44 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Apr 2017 21:34:44 +0000 Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id A10BA1A0A97 for ; Tue, 25 Apr 2017 21:34:44 +0000 (UTC) Received: by mail-io0-f175.google.com with SMTP id r16so218620104ioi.2 for ; Tue, 25 Apr 2017 14:34:44 -0700 (PDT) X-Gm-Message-State: AN3rC/6haNBR/EYdmox7Wc3rnhw2295X2jhGViYhMtml0MPplISi6ZTR 9kjK/Oujl0EH1MdQVw2TsfqEopY8Rw== X-Received: by 10.107.131.224 with SMTP id n93mr19873650ioi.39.1493156083923; Tue, 25 Apr 2017 14:34:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Tue, 25 Apr 2017 21:34:33 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Costin Manolache , jr conlin Cc: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a113ed108fa30e5054e047d60 Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-vapid-02 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:34:47 -0000 --001a113ed108fa30e5054e047d60 Content-Type: text/plain; charset=UTF-8 Ok, it seems like we have consensus on this. I am going to move this doc to "waiting for writeup" and I'll shepherd it. Thanks. On Wed, Apr 19, 2017 at 2:19 PM Costin Manolache wrote: > +1 > > Costin > > On Tue, Apr 18, 2017 at 2:53 PM, jr conlin wrote: > >> I'm fine with the proposed changes, and have worked them into my support >> libraries. >> >> >> On 4/18/17 1:43 PM, Phil Sorber wrote: >> >> Hello All, >> >> Just getting caught up on doc status by reading the email archive and I >> see that both outstanding WG docs were in WGLC two months ago, however draft-ietf-webpush-vapid >> never got any feedback, positive or negative. If anything was sent direct >> to the chairs before I was added, I am not able to see that. Please reply >> back to the list with any feedback you have. I'll leave this open for 1 >> week. >> Thanks. >> >> >> _______________________________________________ >> Webpush mailing listWebpush@ietf.orghttps://www.ietf.org/mailman/listinfo/webpush >> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a113ed108fa30e5054e047d60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, it seems like we have consensus on this. I am going to= move this doc to "waiting for writeup" and I'll shepherd it.=

Thanks.

On Wed, Apr 19, 2017 at 2:19 PM Costin Manolache <costin@gmail.com> wrote:
+1

Costin

On Tue, Apr 18, 2017 at 2:53 PM, jr conlin <jconlin@mozilla.com&g= t; wrote:
=20 =20 =20
I'm fine with the proposed changes, and have worked them into my support libraries.


On 4/18/17 1:43 PM, Phil Sorber wrote:
Hello All,

Just getting caught up on doc status by reading the email archive and I see that both outstanding WG docs were in WGLC two months ago, however=C2=A0draft-ietf-webpush-vapid never got any feedba= ck, positive or negative. If anything was sent direct to the chairs before = I was added, I am not able to see that. Please reply back to the list with = any feedbac= k you have. I'll leave this open for 1 week.
Thank= s.


_______________________________________________
Webpush mailing list
Webpush@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/webpush



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


_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
--001a113ed108fa30e5054e047d60-- From nobody Tue Apr 25 15:05:03 2017 Return-Path: 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 DDC12129442 for ; Tue, 25 Apr 2017 15:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 cNF8e6EC28nC for ; Tue, 25 Apr 2017 15:04:59 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 5AC301275AB for ; Tue, 25 Apr 2017 15:04:59 -0700 (PDT) Received: (qmail 74115 invoked by uid 99); 25 Apr 2017 22:04:58 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Apr 2017 22:04:58 +0000 Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 43C371A00A2 for ; Tue, 25 Apr 2017 22:04:58 +0000 (UTC) Received: by mail-it0-f42.google.com with SMTP id x188so85103776itb.0 for ; Tue, 25 Apr 2017 15:04:58 -0700 (PDT) X-Gm-Message-State: AN3rC/4qd54YtMJZeYEXDccQAJNf4ALYmx8cDAbSMQuO1jbadX3ZPwrC af8yfblI6CU5K1USlqMcl5AI1xMPHQ== X-Received: by 10.36.83.144 with SMTP id n138mr3356082itb.71.1493157897498; Tue, 25 Apr 2017 15:04:57 -0700 (PDT) MIME-Version: 1.0 From: Phil Sorber Date: Tue, 25 Apr 2017 22:04:47 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a114054d4131f69054e04eaf9 Archived-At: Subject: [Webpush] WGLC for draft-ietf-webpush-encryption-08 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:05:01 -0000 --001a114054d4131f69054e04eaf9 Content-Type: text/plain; charset=UTF-8 This is an announcement to commence WGLC on draft-ietf-webpush-encryption: https://tools.ietf.org/html/draft-ietf-webpush-encryption-08 The duration for this last call will be a minimum of 2 weeks ending no earlier than May 9th. Please help with the following: 1. Read the draft and address any issues (please try to provide constructive suggestion/fixes) 2. If you only find nits, they can be sent directly to the author(s) 3. If you have read the draft but you see no issues and you are satisfied to progress, then please let the WG know by submitting an ACK or +1 to the list. Thanks. --001a114054d4131f69054e04eaf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
This is an announcement to commence WGLC on draft-ietf-webpush-encrypt=
ion:

https://tools.ietf.org/htm=
l/draft-ietf-webpush-encryption-08

The duration for this last call will be a minimum of 2 weeks ending =
no earlier than May 9th.

Please help with the following:

1. Read the draft and address any issues (please try to provide constructiv=
e suggestion/fixes)
2. If you only find nits, they can be sent directly to the author(s)
3. If you have read the draft but you see no issues and you are satisfied t=
o progress, then please let the WG know by submitting an ACK or +1 to the l=
ist.

Thanks.
--001a114054d4131f69054e04eaf9-- From nobody Tue Apr 25 23:25:37 2017 Return-Path: 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 5B299131820 for ; Tue, 25 Apr 2017 23:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UshD6kaxOmBS for ; Tue, 25 Apr 2017 23:25:34 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D594131818 for ; Tue, 25 Apr 2017 23:25:33 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id c80so102051236lfh.3 for ; Tue, 25 Apr 2017 23:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cryUHyYqn+BnsmMCWB5mhYLnJTjkVEb7/YTygKwzM+0=; b=D7ME+vm0HfOYtTBfPcMJI+LCs7WuG2egxIGnuP8UIM6N3RVEujpQBxXiN/L/79VV0Z uACEw2EECntTEF5RgPt6TYErQpvlXWAjXV/sw486Ed1G3Chkc6SKCGBILm8x9U7t80MD R2l5/e00cYncaZPYDhtPCkVULUlSsdwuLz5SQH95sP06ydchPvvKYe7uN0mJ11jRXs1d RX8BAvYedvx9uSwSN1xww+SN7h5p4VCQZ62UQJFxADPrzDgSqUH59eqJAUTpIAFjnZ9G XvtAH+ShLorhtIQuhautRkpeHwtD5nR2Wl6F3wFKAP6nBA4Atcdjvwf9wvyQolRJbGQb h15g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cryUHyYqn+BnsmMCWB5mhYLnJTjkVEb7/YTygKwzM+0=; b=TRR4OEFjtYJbpOZuNq+bwslEdGh2y2ZTRg3ymEwX7Um4qKoo7Qz4NKP7aBNkPfFQcM PFXcQMuS5Sx97o6MydIcYoFF+Gx6beKVG9Ns285IxaTplkcEaqx/+NDqVzqatdWmxQdG FeQ4sWOk/GrHp0lKISfLk2GB9xitFENC3pflWI6aGh9Gn/Gl2fyCVEsDQQkInzCiwlmS kZSHMIoplhiLGHqKpaEm+Sh9Hakv9SmYjMzQJGXxkirFh5zgiwJYqKrRAhZvj4Ok8Zsd S6PCHJj9u4n6sAnzg091oLTRoGmgAblmnu/jbzC5EoVg3NxAfRR8PZf6r6iECOAXwHlj /y7A== X-Gm-Message-State: AN3rC/4E9fbPIF1ZuTokD4bCa8Y/+mPeM2fNUqOrJZijyhPW3xzHB8V+ SeAuH6JDXNHpmurBgzSLcaViynzx2Q== X-Received: by 10.25.212.19 with SMTP id l19mr1470236lfg.169.1493187931653; Tue, 25 Apr 2017 23:25:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 25 Apr 2017 23:25:30 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 26 Apr 2017 16:25:30 +1000 Message-ID: To: Phil Sorber Cc: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-encryption-08 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 06:25:35 -0000 Aside from thinking that this is ready (author bias notwithstanding), if you want to send nits (or open issues), the draft is on github here: https://github.com/webpush-wg/webpush-encryption I'd be happy to take an input there. On 26 April 2017 at 08:04, Phil Sorber wrote: > 2. If you only find nits, they can be sent directly to the author(s)