From nobody Tue Jul 1 09:43:12 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5A91A0395 for ; Tue, 1 Jul 2014 09:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 mqyq2glXjMDy for ; Tue, 1 Jul 2014 09:43:09 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964591A0398 for ; Tue, 1 Jul 2014 09:43:08 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id j15so7802887qaq.26 for ; Tue, 01 Jul 2014 09:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xdW2oyiclDLn9fwtRwISUN07z73KzPEboEwdosVXDuA=; b=bWOcG47v6fLpzdikBKLUyYlDPDYj3G594SVOL7PtecEIxJo2JnS0hcKEVIpt54mqiu 3Jxdvy3RHXiErqR85y3VxbH6gJ+TXyQIdEw16Y3JcmNWBO0GIZYp7GTdQ+LcGlpkce7T 6T7dZN2eEcGK9da4BPHmFwfYxeTPuXBg1P39g5v6EDFDMnkafKxIVTSB+M4IWuk1M9vI oAZ+Pj6f9sQ0UxZPm17QbbmB318LJyHLxbXAzTmdDbbC8YWHcEqGsJzZc+TRenzZ/lqF dLSe3bFmcsutaNFTvDUEUFdFfYr6wGB4tV+CalJSlz83jRQDzYlLsoO9MbbSS+Nk9Gp/ CkMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=xdW2oyiclDLn9fwtRwISUN07z73KzPEboEwdosVXDuA=; b=JI76CClW+rqZ7La9wWPtePa3t53xp/ZVHhEx5Fi0X/vRpmP3mSKwa6P+IKT2+jRF/a LW5ImayQDRqpXvmLV43W/NFoYDoCEFpEgkK76/AvXhBfW1AK3ZLEL9xHqrT2Da87ll6J 6ypg08N2+TsyoCTrheYkEl3go0wKoqo1PtNpD307E+hi9NEpJIuwSQmoeajfT2mxw328 B3kKS6gLnun3RUdMPqvH5k6JZLvIVM01RIs24F9BVkuq2O1OF8la8QHKFkfDxBVgB3cW 9mIGGaSEice/49/+2cbSnlFtrxRxyXlmHMj7cl2JhiMc3iqm/e/XvCc/tis/7iSAl4t8 VLWQ== X-Gm-Message-State: ALoCoQkXJ1sWDB2tkH05bZcGFmu/3eMMHuQJdflZEsnREGd1+YX6adt0qFmjWsdTTZD+t38a2SEB MIME-Version: 1.0 X-Received: by 10.140.50.167 with SMTP id s36mr71130215qga.36.1404232987675; Tue, 01 Jul 2014 09:43:07 -0700 (PDT) Received: by 10.229.179.5 with HTTP; Tue, 1 Jul 2014 09:43:07 -0700 (PDT) Date: Tue, 1 Jul 2014 17:43:07 +0100 Message-ID: From: Peter Beverloo To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a113500ae69b8f504fd2478d4 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/iK5vwswEs8SDPGmCuMiAZ9195Ys Subject: [Webpush] GitHub repositories to use for the protocol X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 16:43:11 -0000 --001a113500ae69b8f504fd2478d4 Content-Type: text/plain; charset=UTF-8 I have just filed a bunch of new issues on Doug's webpush-protocol repository. https://github.com/dougt/webpush-protocol The primary reasons being that it's focused on the push protocol, and already contained some open issues filed by other people. However, the most recent draft by Martin lives in his drafts repository. https://github.com/martinthomson/drafts/tree/master/push-http2 Martin, could you move the spec draft to Doug's repository? That allows us to have the draft, issues and pull requests in a single repository. Thanks, Peter --001a113500ae69b8f504fd2478d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have just filed a bunch of new issues on Doug's webp= ush-protocol repository.
=
The primary reasons being that it's focused on the push protocol, = and already contained some open issues filed by other people.
However, the most recent draft by Martin lives in his drafts re= pository.

Martin, could you move the spec draft to = Doug's repository? That allows us to have the draft, issues and pull re= quests in a single repository.

Thanks,
Peter
--001a113500ae69b8f504fd2478d4-- From nobody Tue Jul 1 11:51:23 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1221B2854 for ; Tue, 1 Jul 2014 11:51:21 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 trAzUBfbPSpw for ; Tue, 1 Jul 2014 11:51:19 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936951A05D1 for ; Tue, 1 Jul 2014 11:51:19 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so10119700wes.25 for ; Tue, 01 Jul 2014 11:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PlKCSjAcdzO3P/2RiiO6N0xYyYEMIVmCrnzWyOs3S38=; b=1BVdoSN2CQKp+qhIZio6OPevFUXA20DN1SlIKMNPwLbnZNjBElgpUxY66zbBOB05uy Qo4IJt21UnEt3W/30Yya6/8A5CkVCUzQv/AF4KoMtsUjvJj+WhZq8AIQkzTAOQoWARX+ 4OqzkdDzE0lMYZn2fxI3tVrtkuqGxVsADDh/oqPtD6epOZocr+I9/alhjH8e60GeQ4FZ LsvCWt0Qxku2ozQYfqh0WIupe+sAiZet5/XqcLcO2gfvUZhXVmD4opdEyY0GEWqB7EHE ouL+LuegjI1vPZ2qWZ+S9P+tyn8DsK+vCzPWPHtlC3sGr7ktr9IUoAZCnSpkeEeJmDay 9H9w== MIME-Version: 1.0 X-Received: by 10.194.90.7 with SMTP id bs7mr52855140wjb.25.1404240678164; Tue, 01 Jul 2014 11:51:18 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Tue, 1 Jul 2014 11:51:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jul 2014 11:51:18 -0700 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/UiX1qHD1fjjbE-IHqiVmwXDzoho Cc: webpush@ietf.org Subject: Re: [Webpush] GitHub repositories to use for the protocol X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 18:51:21 -0000 On 1 July 2014 09:43, Peter Beverloo wrote: > I have just filed a bunch of new issues on Doug's webpush-protocol repository. So that's where they went. I thought that was dead. > Martin, could you move the spec draft to Doug's repository? That allows us > to have the draft, issues and pull requests in a single repository. I'm happy to move it, but I'm not sure that Doug's repo is the right place. Depending on how things turn out, we can create a new organization. From nobody Wed Jul 16 12:20:51 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD51A0190 for ; Wed, 16 Jul 2014 12:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 5HlQC542mpxK for ; Wed, 16 Jul 2014 12:09:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D701A01E7 for ; Wed, 16 Jul 2014 12:09:20 -0700 (PDT) Received: from [192.168.1.74] (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6GJ9JP8053494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Jul 2014 14:09:20 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be [192.168.1.74] Message-ID: <53C6CDDF.1090805@nostrum.com> Date: Wed, 16 Jul 2014 14:09:19 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: webpush@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/GIoL3dC5CWnAUAyVqXr0PEp60_Q Cc: draft-thomson-webpush-http2@tools.ietf.org Subject: [Webpush] Quick comment on webpush reliability X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2014 19:09:24 -0000 Looking over draft-thomson-webpush-http2-00, I find the final statement to be something of a zinger: "[A]pplications that rely on the content of push messages being delivered MUST ensure that they provide other means of delivering messages to devices." I suspect we're going to want to have a pretty broad set of considerations around this statement. Without clarification, implementors are likely to read it as requiring them to *also* use some other data update mechanism, unrelated to push (which, as the introduction points out, is an energy-intensive proposition). So we're probably going to want to add some mechanism to push that helps clients deal with this set of circumstances. For example, if there were an ability for a client to actively query for a version, tag, or "last updated date", it would be able to detect missed messages through the parsimonious use of polling (which could be done periodically and/or opportunistically when the radio is already in use). This allows applications to avoid doing their own (out-of-sync) polling. It seems that the 'Prefer: wait="0"' mechanism on the monitor channel would be a good place to add this functionality (although I'll admit that I can't figure out what the currently intended purpose of that mechanism is, so I might be either interfering with some other intended feature or possibly stating something that you thought should be obvious to the reader). On a separate topic: I think the description of channel URIs as bearer tokens is pretty weak right now. This seems like a good place for normative language. /a From nobody Wed Jul 16 13:57:42 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9754B1A02FA for ; Wed, 16 Jul 2014 13:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 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, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham 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 ZBP3kr8UB9YW for ; Wed, 16 Jul 2014 13:57:36 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47F51A02FE for ; Wed, 16 Jul 2014 13:57:34 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so1498268wes.24 for ; Wed, 16 Jul 2014 13:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KM8Z0T0E2avDdyUm1hTb6mPUFoAtK6TKo+t73GBrC9A=; b=ZG1P9O1AsxKQ94Ywls3dnwonYojIkvIJ5EFPBX5ie/MGjX7qF+Xhlce1J8DXycUP7r NKvVy6+uqpqr3kn8EZ+ouIPchfi0KVXBL8+Zhq9JZFhF9fswiWGRDoqpAHFGKkduiNWU EsNoNKNuhYUpEWoZLbd3djtjrUEQI73HfW9Rpl17EPcvg4civd1b2MUt+JLuxbEvwYWC QLA9NDFinSAsDArCQpY7whJFMH4/QCnfEGJF+UHTXzwGKoBbH+Go3EB9HG0qbEoOk0Mn 1GFwegFRLv2K9dynZFo7luu/lEI1Thrfjl2jio2lPQ8RSjG6WeSLrPl8t/faBxooEOy1 SdNA== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr39214217wjb.59.1405544253307; Wed, 16 Jul 2014 13:57:33 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Wed, 16 Jul 2014 13:57:33 -0700 (PDT) In-Reply-To: <53C6CDDF.1090805@nostrum.com> References: <53C6CDDF.1090805@nostrum.com> Date: Wed, 16 Jul 2014 13:57:33 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/DdKZjfdcNtnwEKRp1zLDzyxRIyI Cc: draft-thomson-webpush-http2@tools.ietf.org, webpush@ietf.org Subject: Re: [Webpush] Quick comment on webpush reliability X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2014 20:57:39 -0000 On 16 July 2014 12:09, Adam Roach wrote: > Looking over draft-thomson-webpush-http2-00, I find the final statement to > be something of a zinger: "[A]pplications that rely on the content of push > messages being delivered MUST ensure that they provide other means of > delivering messages to devices." > > I suspect we're going to want to have a pretty broad set of considerations > around this statement. Indeed. This was included only as an observation that push can't be the *only* way that an application acquires updated state. Part of the goal here is to minimize hard state commitment requirements on push servers. I'm not saying that a server couldn't provide some sort of indication that a client is up to date, which could certainly use any reasonable mechanism. That includes If-Modified-Since and If-None-Match and all the other HTTP cache-based mechanisms in addition to what we might like to invent. The problem is that if we *require* that a push server do something, then that is a hard constraint of the likes I've intentionally avoided so far. I know for a fact that some of these systems are incapable of doing that, and even those that do can't make any completely solid guarantees anyway. At least not with the reliability you want or need. This needs work to ensure that we don't create an invitation to go off and write a parallel update channel, or to have applications polling or other self-defeating practices. For most applications, it's perfectly easy to have sync code that runs at startup, resume, or when notified of a push service outage. What I want to do is avoid having the push service be responsible for facilitating that. As an application developer, you know your data/state/needs better than any middlebox. > On a separate topic: I think the description of channel URIs as bearer > tokens is pretty weak right now. This seems like a good place for normative > language. Yes, the document hasn't undergone the usual hardening in this regard. At this stage, I'm assuming our audience is familiar with prior art on the subject. I'll note that other issues on locator/identifier separation and all that nonsense have been raised on the W3C list already. Thanks for the feedback; I'm tracking these here: https://github.com/martinthomson/drafts/issues From nobody Wed Jul 16 14:34:30 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C59F1A008C for ; Wed, 16 Jul 2014 14:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 gVS_JOuwjN2C for ; Wed, 16 Jul 2014 14:34:27 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3721A0085 for ; Wed, 16 Jul 2014 14:34:26 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so1992157wiv.3 for ; Wed, 16 Jul 2014 14:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ik51al5zlhJy9vcGqLmxlI+dCdXro9Fiigo7OftjJoU=; b=lBMmip5xzwVn+hwUfuQIw2uxUxeNXT49Ddn0iQDWaw/fq1za1W/Rk5O6os5qSvC4SJ N3NI6mXpNdFSDQJb6p1FwNlKWK/z5lzyt/ZeKsrDcjVA32WnOWEvX6vr0WWxgbCDDgFB P/hZ7jHuZpkHlS0981uDgcK+/jTvd//cOswRVDm7/RH1Z+AGywxPcSWkGdzdxS363g8p y/TD0hZzfYjXcE3YdXxunEsKJs4jDhEym/xn24RErIvRnqBbNs9VkUGj2179VhFIvuz/ livceIAX6gUrEFA2CbRHsxQsGLCGpP01Gyt6bA7nxvwLdsxl5yOkX9CzvWaK7BEc4iWD LvTA== MIME-Version: 1.0 X-Received: by 10.194.191.162 with SMTP id gz2mr39537164wjc.89.1405546462695; Wed, 16 Jul 2014 14:34:22 -0700 (PDT) Received: by 10.216.79.202 with HTTP; Wed, 16 Jul 2014 14:34:22 -0700 (PDT) In-Reply-To: References: <53C6CDDF.1090805@nostrum.com> Date: Wed, 16 Jul 2014 14:34:22 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bb70adc9fdc6204fe564983 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/fqAsTXnecRMbEy1EZrms1sDdGRo Cc: Adam Roach , draft-thomson-webpush-http2@tools.ietf.org, webpush@ietf.org Subject: Re: [Webpush] Quick comment on webpush reliability X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2014 21:34:29 -0000 --047d7bb70adc9fdc6204fe564983 Content-Type: text/plain; charset=UTF-8 AFAIK a typical case is a mobile network / firewall or device policy preventing the push channel. One option would be for the push API to notify the apps if the push connection is available. Costin On Wed, Jul 16, 2014 at 1:57 PM, Martin Thomson wrote: > On 16 July 2014 12:09, Adam Roach wrote: > > Looking over draft-thomson-webpush-http2-00, I find the final statement > to > > be something of a zinger: "[A]pplications that rely on the content of > push > > messages being delivered MUST ensure that they provide other means of > > delivering messages to devices." > > > > I suspect we're going to want to have a pretty broad set of > considerations > > around this statement. > > Indeed. This was included only as an observation that push can't be > the *only* way that an application acquires updated state. > > Part of the goal here is to minimize hard state commitment > requirements on push servers. I'm not saying that a server couldn't > provide some sort of indication that a client is up to date, which > could certainly use any reasonable mechanism. That includes > If-Modified-Since and If-None-Match and all the other HTTP cache-based > mechanisms in addition to what we might like to invent. > > The problem is that if we *require* that a push server do something, > then that is a hard constraint of the likes I've intentionally avoided > so far. I know for a fact that some of these systems are incapable of > doing that, and even those that do can't make any completely solid > guarantees anyway. At least not with the reliability you want or > need. > > This needs work to ensure that we don't create an invitation to go off > and write a parallel update channel, or to have applications polling > or other self-defeating practices. For most applications, it's > perfectly easy to have sync code that runs at startup, resume, or when > notified of a push service outage. What I want to do is avoid having > the push service be responsible for facilitating that. As an > application developer, you know your data/state/needs better than any > middlebox. > > > On a separate topic: I think the description of channel URIs as bearer > > tokens is pretty weak right now. This seems like a good place for > normative > > language. > > Yes, the document hasn't undergone the usual hardening in this regard. > At this stage, I'm assuming our audience is familiar with prior art on > the subject. I'll note that other issues on locator/identifier > separation and all that nonsense have been raised on the W3C list > already. > > Thanks for the feedback; I'm tracking these here: > https://github.com/martinthomson/drafts/issues > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7bb70adc9fdc6204fe564983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AFAIK a typical case is a mobile network / =C2=A0firewall = or device policy preventing the push channel.=C2=A0
One option would be= for the push API to notify the apps if the push connection is available.= =C2=A0


Costin
=

On Wed, Jul 16, 2014 at 1:57 PM, Martin = Thomson <martin.thomson@gmail.com> wrote:
On 16 July 2014 12:09, Adam = Roach <adam@nostrum.com> wrot= e:
> Looking over draft-thomson-webpush-http2-00, I find the final statemen= t to
> be something of a zinger: "[A]pplications that rely on the conten= t of push
> messages being delivered MUST ensure that they provide other means of<= br> > delivering messages to devices."
>
> I suspect we're going to want to have a pretty broad set of consid= erations
> around this statement.

Indeed. =C2=A0This was included only as an observation that push can&= #39;t be
the *only* way that an application acquires updated state.

Part of the goal here is to minimize hard state commitment
requirements on push servers. =C2=A0I'm not saying that a server couldn= 't
provide some sort of indication that a client is up to date, which
could certainly use any reasonable mechanism. =C2=A0That includes
If-Modified-Since and If-None-Match and all the other HTTP cache-based
mechanisms in addition to what we might like to invent.

The problem is that if we *require* that a push server do something,
then that is a hard constraint of the likes I've intentionally avoided<= br> so far. =C2=A0I know for a fact that some of these systems are incapable of=
doing that, and even those that do can't make any completely solid
guarantees anyway. =C2=A0At least not with the reliability you want or
need.

This needs work to ensure that we don't create an invitation to go off<= br> and write a parallel update channel, or to have applications polling
or other self-defeating practices. =C2=A0For most applications, it's perfectly easy to have sync code that runs at startup, resume, or when
notified of a push service outage. =C2=A0What I want to do is avoid having<= br> the push service be responsible for facilitating that. =C2=A0As an
application developer, you know your data/state/needs better than any
middlebox.

> On a separate topic: I think the description of channel URIs as bearer=
> tokens is pretty weak right now. This seems like a good place for norm= ative
> language.

Yes, the document hasn't undergone the usual hardening in this re= gard.
At this stage, I'm assuming our audience is familiar with prior art on<= br> the subject. =C2=A0I'll note that other issues on locator/identifier separation and all that nonsense have been raised on the W3C list
already.

Thanks for the feedback; I'm tracking these here:
https://github.com/martinthomson/drafts/issues

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

--047d7bb70adc9fdc6204fe564983-- From nobody Wed Jul 16 15:20:53 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35541A037F for ; Wed, 16 Jul 2014 15:20:51 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 cfyAVLriLdX5 for ; Wed, 16 Jul 2014 15:20:50 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184A41A037E for ; Wed, 16 Jul 2014 15:20:49 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so1584575wes.6 for ; Wed, 16 Jul 2014 15:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g8x82KRjhfSB9jXVDdLeyW+iBMI8Sv8UkPFNkpsZhZQ=; b=KIHOnRfuW5oHhehR4j7PTC7XDn+FQh5U0qnu1M44jl4CNCpqri+1YTBaOF7Wc9mvxC ScXIsfkaXPrY0xTaiuePhAefioWUfCfWzwiQ1DzY0GQ4mCKzN5sLT6Zoank/77W8+LDI LN7C3v4hWeLdWZEImEg5EbpujCVkKUC9PGJ4gJxWuG/0vXod79KBoTNYp09cm/xDzGd0 M4GXveiSrNrdg2E8tWTEezNqqL2jx5p5Sq1m+jRIPc02iEbLnSUyhjiO6ePeUUWYZEGM mRQGY4xu1YuQHA2NLgI+QAvdrvsPpmBPeYH1oqSERFG3fRnAMHVJqQt0idlJJRv6so/g yPRw== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr40167989wjc.9.1405549248591; Wed, 16 Jul 2014 15:20:48 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Wed, 16 Jul 2014 15:20:48 -0700 (PDT) In-Reply-To: References: <53C6CDDF.1090805@nostrum.com> Date: Wed, 16 Jul 2014 15:20:48 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/bgUC6Svq47bPCfx_0mKnTBqJEZk Cc: Adam Roach , draft-thomson-webpush-http2@tools.ietf.org, webpush@ietf.org Subject: Re: [Webpush] Quick comment on webpush reliability X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2014 22:20:52 -0000 On 16 July 2014 14:34, Costin Manolache wrote: > AFAIK a typical case is a mobile network / firewall or device policy > preventing the push channel. A typical case of what? > One option would be for the push API to notify the apps if the push > connection is available. Feedback on service availability is an important API feature, yes. From nobody Wed Jul 16 15:25:45 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822961A0385 for ; Wed, 16 Jul 2014 15:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 L2FswSlMDPka for ; Wed, 16 Jul 2014 15:25:31 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2A81A0387 for ; Wed, 16 Jul 2014 15:25:23 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so1566618wgh.2 for ; Wed, 16 Jul 2014 15:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qMgjSOUQ8TE+X97GZVGzClrThOTeBc37OOk1JjK3AXA=; b=Kf5Oifzebhn+b0XxczARYkUk4CzhX9bdsFa3urqBJIdVCY3eoa6b3++tJzTzfqsfcr 6sI35YCu0v97lbWLSrELd64ukCOvb66moAAw86x8awS91aHWLXXvWXq96JKtZN1tfQQq 0bBdQ1gU2dx+2avnVOF0bDX78gbXwD1wJO3T5NE0uTaY8idxYdUCO1ak85j1+uytIaxF gxrPo/GW9W3PTfDRekC0a0pF9dDWYGol6maPSleBKbf8FDp5DvT/WY3n8YrM4+8kXkSz FJOIEjbbkIhx1dFOl79EcVOEWTytoQorUYGwnHBSuYYbXCidOk2wSLM3biG6zRPSE7EC PA3w== MIME-Version: 1.0 X-Received: by 10.180.13.208 with SMTP id j16mr17375506wic.15.1405549522072; Wed, 16 Jul 2014 15:25:22 -0700 (PDT) Received: by 10.216.79.202 with HTTP; Wed, 16 Jul 2014 15:25:21 -0700 (PDT) In-Reply-To: References: <53C6CDDF.1090805@nostrum.com> Date: Wed, 16 Jul 2014 15:25:21 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c24440fa3e5d04fe56ff10 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/bjHP2i9oj0JLEw5_E7vCrIa4oQY Cc: Adam Roach , draft-thomson-webpush-http2@tools.ietf.org, webpush@ietf.org Subject: Re: [Webpush] Quick comment on webpush reliability X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2014 22:25:42 -0000 --001a11c24440fa3e5d04fe56ff10 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 16, 2014 at 3:20 PM, Martin Thomson wrote: > On 16 July 2014 14:34, Costin Manolache wrote: > > AFAIK a typical case is a mobile network / firewall or device policy > > preventing the push channel. > > A typical case of what? > Of applications that rely on push having a need for alternative means of updating. Costin > > > One option would be for the push API to notify the apps if the push > > connection is available. > > Feedback on service availability is an important API feature, yes. > --001a11c24440fa3e5d04fe56ff10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 16, 2014 at 3:20 PM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
On 16 July 2014 14:34, Costi= n Manolache <costin@gmail.com>= ; wrote:
> AFAIK a typical case is a mobile network / =C2=A0firewall or device po= licy
> preventing the push channel.

A typical case of what?

Of applic= ations that rely on push having a need for alternative means of updating.= =C2=A0

Costin
=C2=A0

> One option would be for the push API to notify the apps if the push > connection is available.

Feedback on service availability is an important API feature, yes.

--001a11c24440fa3e5d04fe56ff10-- From nobody Wed Jul 16 15:53:44 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5BB1A0392 for ; Wed, 16 Jul 2014 15:53:43 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zzuVPYlNckJQ for ; Wed, 16 Jul 2014 15:53:42 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E012E1A0390 for ; Wed, 16 Jul 2014 15:53:41 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so1619888wes.19 for ; Wed, 16 Jul 2014 15:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JVzKGP4rBMtqwniZAiPwCSFfXBiTWkxyI4ZVi4jfXuw=; b=M7kfvE90QWlTpJRwD4Pz2Ypx5w80W/ooS/ZCFTQZy7fydbm7xYn4UkMpVpQTlgs7+Y FuL7t5zU1/1uWMWP0d2vy4GSyb/OkU0kCD+XrZlV2Wk3ZIwRXvOOM5yBv8BvbGzKFf+R qjMb6tz34sv+siEw+xJbNXR0Fa9LNk8gvMhcz8/224GLx7Eibn26fiQa4u15jWuq4nVq u3tQH3TbVbyryVJg9LQ3eNJ78U1B9WCYPa++SjhMTcpgYEcDuU6Ycs6PyCc3ZbWCEToY ptUqz8fCMDTB8kdlr6d5Va42FxpWMIYCy+yTmmlMyLsjHSxeU2H8tbiF5vsUMOFi/c/u piMw== MIME-Version: 1.0 X-Received: by 10.180.92.38 with SMTP id cj6mr17492344wib.64.1405551220605; Wed, 16 Jul 2014 15:53:40 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Wed, 16 Jul 2014 15:53:40 -0700 (PDT) In-Reply-To: References: <53C6CDDF.1090805@nostrum.com> Date: Wed, 16 Jul 2014 15:53:40 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/W1Gr6JyePCxrzKs1yoF3h6rxuDk Cc: Adam Roach , draft-thomson-webpush-http2@tools.ietf.org, webpush@ietf.org Subject: Re: [Webpush] Quick comment on webpush reliability X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2014 22:53:43 -0000 On 16 July 2014 15:25, Costin Manolache wrote: > On Wed, Jul 16, 2014 at 3:20 PM, Martin Thomson > wrote: >> On 16 July 2014 14:34, Costin Manolache wrote: >> > AFAIK a typical case is a mobile network / firewall or device policy >> > preventing the push channel. >> >> A typical case of what? > > Of applications that rely on push having a need for alternative means of > updating. I'm not sure that we want to do too much to recognize those scenarios in this context. That might do more to encourage bad behaviour. Those people that have to deal with those sorts of outages know that already. I'm more concerned here with transitory outages, devices that power off, and those sorts of failures. From nobody Wed Jul 16 18:13:06 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F471A03C8 for ; Wed, 16 Jul 2014 18:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 Zt8gb9tGSGsj for ; Wed, 16 Jul 2014 18:13:03 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2F91A03C7 for ; Wed, 16 Jul 2014 18:13:03 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so1661849wgh.21 for ; Wed, 16 Jul 2014 18:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2TEQpyj9Nc/FFaMbckO5nxapITMq21OSrrfvBzda9Sg=; b=Ibw/kPDaiIAUHtAbvG+1H/Gn5jJVqczIoeLN6Uj0i3e2I3kSaKAhPutk0yKdw4v5nN 7uDrO8XhY81uq1X9vavaQ4MTpUNVwm+H3ZqqnK3tbD1ENBA0Qg/Tkj/l9hgXqmmqIBbj 9UHIjgR66Zh805OAsZE8rXOprLKuOCyqdErFlbO5arCC+VGVmGLQ56p2LfRFo28909/a 3glIfnCaMAolaJsb+HtW0627O0Ayml+RcwtnkHhHPfznVXGxwPJhf2ZTtUcOY3YunHWk BFKs4AiCXOC1K0YPo+3HId5B9E+4Eok1ir4OalH7NtHt/PA5jnk+ikBDHjqv/IzWVokO Ugrw== MIME-Version: 1.0 X-Received: by 10.180.13.208 with SMTP id j16mr18133656wic.15.1405559581830; Wed, 16 Jul 2014 18:13:01 -0700 (PDT) Received: by 10.216.79.202 with HTTP; Wed, 16 Jul 2014 18:13:01 -0700 (PDT) In-Reply-To: References: <53C6CDDF.1090805@nostrum.com> Date: Wed, 16 Jul 2014 18:13:01 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c2444095f66c04fe595735 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/4bRHW8yl4Y3nTBjnHnX5EUv8cwM Cc: Adam Roach , draft-thomson-webpush-http2@tools.ietf.org, webpush@ietf.org Subject: Re: [Webpush] Quick comment on webpush reliability X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2014 01:13:04 -0000 --001a11c2444095f66c04fe595735 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 16, 2014 at 3:53 PM, Martin Thomson wrote: > On 16 July 2014 15:25, Costin Manolache wrote: > > On Wed, Jul 16, 2014 at 3:20 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> On 16 July 2014 14:34, Costin Manolache wrote: > >> > AFAIK a typical case is a mobile network / firewall or device policy > >> > preventing the push channel. > >> > >> A typical case of what? > > > > Of applications that rely on push having a need for alternative means of > > updating. > > I'm not sure that we want to do too much to recognize those scenarios > in this context. That might do more to encourage bad behaviour. > Those people that have to deal with those sorts of outages know that > already. > By "device policy" I mean things like roaming or low battery mode, or user choice to disable background push. Even if we don't recognize them - they are the main failure mode for push on android and probably other devices. > > I'm more concerned here with transitory outages, devices that power > off, and those sorts of failures. > I can't comment on this - my experience is with servers that store messages, so poweroff/offline is expected behavior. Costin --001a11c2444095f66c04fe595735 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jul 16, 2014 at 3:53 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 16 July 2014 15:25, Costi= n Manolache <costin@gmail.com>= ; wrote:
> On Wed, Jul 16, 2014 at 3:20 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>> On 16 July 2014 14:34, Costin Manolache <costin@gmail.com> wrote:
>> > AFAIK a typical case is a mobile network / =C2=A0firewall or = device policy
>> > preventing the push channel.
>>
>> A typical case of what?
>
> Of applications that rely on push having a need for alternative means = of
> updating.

I'm not sure that we want to do too much to recognize those scena= rios
in this context. =C2=A0That might do more to encourage bad behaviour.
Those people that have to deal with those sorts of outages know that
already.

By "device policy" I= mean things like roaming or low battery mode, or user
choice to = disable background push.
Even if we don't recognize them - th= ey are the main failure mode for push on=C2=A0
android and probably other devices.
=C2=A0

I'm more concerned here with transitory outages, devices that power
off, and those sorts of failures.

I can't comment= on this - my experience is with servers that store messages, so
poweroff/offline is expected behavior.

Costin
--001a11c2444095f66c04fe595735-- From nobody Thu Jul 31 07:23:38 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9098B1A009C for ; Thu, 31 Jul 2014 07:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 FgDIukD_c634 for ; Thu, 31 Jul 2014 07:23:33 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8603F1A0072 for ; Thu, 31 Jul 2014 07:23:33 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id u20so1803079oif.8 for ; Thu, 31 Jul 2014 07:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fWlv62FLUE2bIJEHEARWVb5A5mH/c/c7y81RbKbYbQc=; b=U3CnHjRmbbJB0zbTGXYtjIIBSnb93alLJIJL03Jeq37w0Sy/PhhxwXvgoQ1CX0B8E3 urG1UiXql8WQ9T6wcUfYJdRK5j7Omkz8XV70BgxL7XjR66EniciayKiKk++tyx4jsOZX w2xRmqLetGcnEwApYM9DD3ZpcCM+9mg8D0RH7DO5RIVmqc5eXAuzqJM72aqnlJFq3cNK H7lZnYQjA7qaoCJMhN8+Hoyo50DQQfGJSbKuHgge/D8XiAcartisxhAAD3s9FW/e6Z2F XEPJKbSucWjs1xkEplP+9TO6sx4ug5Psg5PVCoaVgejLzq8ahZfKnMz3wy/hIZlQacN/ orKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fWlv62FLUE2bIJEHEARWVb5A5mH/c/c7y81RbKbYbQc=; b=fc7W+qYYq8NT0jP4iRE49TcXczDrtat1TnH8HiD/H7XFYQQSROnrQiOXwS6pTMhTdl 11pY0saOcqSxMgLUHMh+ETtVrPcZxKMBmE9oBj3k0nMURrm+3ieHifz9HmsXljZaregr hanRIFeIdEbOqSEKmfUOAGQRWdvl25SafurTWoeDh0KzVfvaloXa1EQxoWHFKC73xGsT mXj09LpTNlZgxuip+HMKl6W9rMyIgAeQ81T5FbhGKQGvC7Y5C5Y8r6r+7D1sajkaf+re 9wcVQAcwB/w79IGEQOZ1fn0XSz8nKKC2Gelm4l66ya5EbmLVRvcIzwqMHzqG9kqLCoNj SIlA== X-Gm-Message-State: ALoCoQkyMtOBVMAKY0YEBh7/lniP3cyMLZo1gEqdcuSKVXZgdCGVZC4ypP4K4MQwHpId30hq9FVe X-Received: by 10.182.126.233 with SMTP id nb9mr6877903obb.46.1406816612016; Thu, 31 Jul 2014 07:23:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.44.169 with HTTP; Thu, 31 Jul 2014 07:23:11 -0700 (PDT) In-Reply-To: References: <53C6CDDF.1090805@nostrum.com> From: nero Date: Thu, 31 Jul 2014 15:23:11 +0100 Message-ID: To: Costin Manolache Content-Type: multipart/alternative; boundary=001a11c1e5506c960a04ff7e04cb Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/3gcfZkkNwoqNmWl0P0AoyZhT0M0 Cc: Adam Roach , Martin Thomson , draft-thomson-webpush-http2@tools.ietf.org, webpush@ietf.org Subject: Re: [Webpush] Quick comment on webpush reliability X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 14:23:35 -0000 --001a11c1e5506c960a04ff7e04cb Content-Type: text/plain; charset=UTF-8 More than reliability, push messaging is often mistakenly considered "real time". One one hand this is great since systems like GCM helped create this impression, however due to mobile network architectures and such messages are sometimes delayed for a certain amount of time. Push systems should be reliable, but cannot ensure real timeliness. I am not sure about the MUST keyword in that sentence, but we could provide use cases and examples. For instance email sync could sync-poll every hour, and reset the poll alarm every time a push is received or so... francesco On Thu, Jul 17, 2014 at 2:13 AM, Costin Manolache wrote: > > On Wed, Jul 16, 2014 at 3:53 PM, Martin Thomson > wrote: > >> On 16 July 2014 15:25, Costin Manolache wrote: >> > On Wed, Jul 16, 2014 at 3:20 PM, Martin Thomson < >> martin.thomson@gmail.com> >> > wrote: >> >> On 16 July 2014 14:34, Costin Manolache wrote: >> >> > AFAIK a typical case is a mobile network / firewall or device policy >> >> > preventing the push channel. >> >> >> >> A typical case of what? >> > >> > Of applications that rely on push having a need for alternative means of >> > updating. >> >> I'm not sure that we want to do too much to recognize those scenarios >> in this context. That might do more to encourage bad behaviour. >> Those people that have to deal with those sorts of outages know that >> already. >> > > By "device policy" I mean things like roaming or low battery mode, or user > choice to disable background push. > Even if we don't recognize them - they are the main failure mode for push > on > android and probably other devices. > > >> >> I'm more concerned here with transitory outages, devices that power >> off, and those sorts of failures. >> > > I can't comment on this - my experience is with servers that store > messages, so > poweroff/offline is expected behavior. > > Costin > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > -- Prudence is a rich, ugly old maid courted by Incapacity --001a11c1e5506c960a04ff7e04cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
More than reliability, push messaging is often mistakenly = considered "real time". One one hand this is great since systems = like GCM helped create this impression, however due to mobile network archi= tectures and such messages are sometimes delayed for a certain amount of ti= me.
Push systems should be reliable, but cannot ensure real timeliness.
I am not sure about the MUST keyword in that sentence, but we could prov= ide use cases and examples.
For instance email sync could sync-po= ll every hour, and reset the poll alarm every time a push is received or so= ...

=C2=A0 francesco



On Thu, Jul 17, 2014 at= 2:13 AM, Costin Manolache <costin@gmail.com> wrote:
=
On Wed, Jul 16, 2014 at 3:53= PM, Martin Thomson <martin.thomson@gmail.com> wrote:=
On 16 July 2014 15:25, Costin Manolache= <costin@gmail.com= > wrote:
> On Wed, Jul 16, 2014 at 3:20 PM, Martin Thomson <martin.thomson@gmail.com>= ;
> wrote:
>> On 16 July 2014 14:34, Costin Manolache <costin@gmail.com> wrote:
>> > AFAIK a typical case is a mobile network / =C2=A0firewall or = device policy
>> > preventing the push channel.
>>
>> A typical case of what?
>
> Of applications that rely on push having a need for alternative means = of
> updating.

I'm not sure that we want to do too much to recognize those scena= rios
in this context. =C2=A0That might do more to encourage bad behaviour.
Those people that have to deal with those sorts of outages know that
already.

By "device policy&q= uot; I mean things like roaming or low battery mode, or user
choi= ce to disable background push.
Even if we don't recognize the= m - they are the main failure mode for push on=C2=A0
android and probably other devices.
=C2=A0

I'm more concerned here with transitory outages, devices that power
off, and those sorts of failures.

I can't c= omment on this - my experience is with servers that store messages, so
poweroff/offline is expected behavior.

Costin

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




--
Prudence= is a rich, ugly old maid courted by Incapacity
--001a11c1e5506c960a04ff7e04cb--