IETF Logo Mail Archive

Re: [Webpush] Non-blocking comments on -05

jr conlin <jconlin@mozilla.com> Thu, 09 June 2016 22:03 UTC

Return-Path: <jconlin@mozilla.com>
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 5387512D550 for <webpush@ietfa.amsl.com>; Thu, 9 Jun 2016 15:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.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 331snXtfmyoS for <webpush@ietfa.amsl.com>; Thu, 9 Jun 2016 15:03:31 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 AD33E12DA1A for <webpush@ietf.org>; Thu, 9 Jun 2016 15:03:30 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id t190so16743307pfb.3 for <webpush@ietf.org>; Thu, 09 Jun 2016 15:03:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=TYiHmc+a4C+hYwmLOjkeptipnqzh3KR4rFaMwb68s8I=; b=CZwW/yo8bTCT9SALyJgUpA+X8uAx+xpLiQY6x2HV8ysnk0iCvVYJohtTPE1YB4Gqgb Ap3rqyYoFT61TG9VeCmKKBftwxEjmOQLfIsRDhWP84p4Szwzz8A8qLzOnj5+NvmeqU0D ISjatngrPpGx1zjTJjQ98XvgVf4huTvF/CnNB4iVTaqpRghBt5UWFUIAN/57mrye2QeG 9MiPX9rTaccZ2GMxhw3J8RBKSAJsRK5QxjWOySmmOh7b0QBGN9MwkmfkBnEzjMvfllZB ccdBayiUeV6IQp5rkCNU4zft8wqitbBu73fmz3vAc6TTX4CBgzokMZPiKx81fFgK1qnD Imeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=TYiHmc+a4C+hYwmLOjkeptipnqzh3KR4rFaMwb68s8I=; b=mzI4BC/Gfyiki5LTFRqWveK8BkQxiMhLK7S44odn4fv6OukROe84DPBSMLpaJj6v/q UmN5z9U3IHU+Y0VKcy5ymoHkVA0QehuQX52Tn10MKQLEAUwwrcTENFpms4PNAbujOTJ0 fkwjdRuxyg+N/3w6A5IDVpS05t6aqjCz4fDR+PMtUErBDxHaANku87TD8LXYAPJf0mKn FYzmKkfn/ppv1E87c1KvqvlmhR83VN6taAoD77mYLsUlwSx/AGfK29OInU8W4UtxGssx zXhYLvK6pivDnHzEgxPmXQOSx+o44L6We5wMZl25aW024tXNulv71oNYS/ZjkCI7+pqO 75+A==
X-Gm-Message-State: ALyK8tLwY+HrurpXYtjqIEI44vmDVFgbakXBd3PkWO4AghlSQflLSU3gS7oV0M5Sgaf023eX
X-Received: by 10.98.85.66 with SMTP id j63mr6791116pfb.90.1465509809814; Thu, 09 Jun 2016 15:03:29 -0700 (PDT)
Received: from ?IPv6:2620:101:80fc:224:1d89:264d:e0de:18e7? ([2620:101:80fc:224:1d89:264d:e0de:18e7]) by smtp.gmail.com with ESMTPSA id y2sm12365450pfi.39.2016.06.09.15.03.28 for <webpush@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 15:03:28 -0700 (PDT)
To: webpush@ietf.org
References: <CALt3x6=_yc9TegOut_g+6W5fvhP7sfW+_gwRZnEVFA5PNgER6Q@mail.gmail.com> <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <CABkgnnWebfxnPOLMXK+n+2G=c8DOG4Eb4AWMsWXJmmdnE4pUwg@mail.gmail.com> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> <CAP8-Fq=ccph+RcKH9byKD6f-05zHYkUvMVG=OR=4=rq06dc7DA@mail.gmail.com> <CABkgnnUYH7b1N-QKs5JVuYpZGBhrQqt9cQ+Vt7LeHuLY_+LR9w@mail.gmail.com> <CAP8-Fq=adQhi3ik27CNee8Q8bZWD5vkX2cJUqOehzHaSb_+kAg@mail.gmail.com>
From: jr conlin <jconlin@mozilla.com>
Message-ID: <b5184ad4-bd50-fe22-96a6-741c6dd6cc14@mozilla.com>
Date: Thu, 9 Jun 2016 15:03:30 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Thunderbird/49.0a2
MIME-Version: 1.0
In-Reply-To: <CAP8-Fq=adQhi3ik27CNee8Q8bZWD5vkX2cJUqOehzHaSb_+kAg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------94A07E0D143253D8928A0AE0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/rFQ4MAfgRgh_qfI0JiieuZqrlHk>
Subject: Re: [Webpush] Non-blocking comments on -05
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2016 22:03:34 -0000

For some of our bridged protocols, we lose a percentage due to the
protocol exchange overhead. Our server knows the limit and usually
returns that with a 413 error (I'm fine with our server being
non-standard, since I suspect that not all implementations would use
bridges the way we do.)

Our bridge currently limits to just over 3K, however to Costin's point,
I can perceive some future bridge or device having much tighter
restrictions.

On 6/3/2016 7:48 PM, Costin Manolache wrote:
> We support 4k, and it would be great to keep it as is for regular UA
> and PS.
>
> However if the push service is proxying to other protocols - there are
> services limiting the size to 2k, and I assume for IoT or other cases
> the limit may be even lower. In such cases the PS can't deliver - so 
> should indicate the cause. 
> In most cases the AS has more information about the UA - so it shouldn't
> attempt to send 4k to a lightbulb with 256B of free RAM. 
>
> Costin
>
>
>
>
> On Fri, Jun 3, 2016 at 4:16 PM Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 4 June 2016 at 00:56, Costin Manolache <costin@gmail.com
>     <mailto:costin@gmail.com>> wrote:
>     >> In section 7.2, could we consider allowing push servers to
>     reject messages
>     >> < 4k? If the PS is proxying the message to a third-party
>     server, which
>     >> Mozilla's server does on iOS and Android, it might not be able
>     to control
>     >> the size limit.
>     >
>     >
>     > +1
>
>
>     Do either of you want to recommend an alternative limit?  The limit
>     exists so that application servers can send messages of a certain size
>     without having to worry that they will be told to go away.  That's a
>     useful property to maintain.  However, if there are practical limits
>     that make 4k too hard, please pick a more realistic limit.  Is it 2k?
>     Less?
>
>
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush

v2.8.7 | Report a Bug | By Email