Re: [Webpush] Message update PR

Martin Thomson <> Thu, 28 January 2016 04:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B6A4C1B32D5 for <>; Wed, 27 Jan 2016 20:32:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oYcJioFIzVCB for <>; Wed, 27 Jan 2016 20:32:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 090CA1B32D1 for <>; Wed, 27 Jan 2016 20:32:50 -0800 (PST)
Received: by with SMTP id mw1so4771580igb.1 for <>; Wed, 27 Jan 2016 20:32:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NyNPOGb+j3T5ehUPmLwTNQ0/5BmNL9IwINUfsgbvbro=; b=rJt7l1mcbgRyArZCIhZ/BxjInN/vDjE2LayGhmasN/d9jEZ3ilomY+Vmqk1Y/zjuM3 5FLAw8NMfXLDjiLA5FRVMnrIcpQDoWU6MJf6dqMsKp10yHBDfywvjBYV7zSOZArPxVuk zDKsNZGDJKZNVfwS2SIFS960N+0eLFqcYnCFEpq/825TIxs5CgI4kewBv4rFcBiGGIuY kI5VV6EsLO1dsG/SYPohlAGdJMuVFtNyNvahJtQLKag7l23MUstzc1LyC7gWDBZmmQhm lrO7MU+gDI1vzx4+jqncbQDdMBrz5R88b35bOUFeYLCNOfOmfvI5Z4CsrVhHFz4bDOAY Y5rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NyNPOGb+j3T5ehUPmLwTNQ0/5BmNL9IwINUfsgbvbro=; b=gSJSgEwgmnzMdYOTpTNtGS1Iq7cBqg8H7JEDKxG3HvOk2D4bNJhuSn0JNgiLuUG4bz BZmwuuWRfWdgp4/fIgM2P8U+Y8UKZ7JsmznvEKlA7/W7/jnOwhBbCusW5ZsN2VkopCQ8 Z0vbppimEz2fWTK2WT3WsqXL/eQC8A0TlJk7T5pAjXhyMrgMB2WppoIHe4BRZDqrvkm0 lj5FZq8qJ0G+dZumjRVWWteh4/h0nWqBcfgFLy2DBXm5HtpJKQ4BHupFe65axVWOBjOX Flc9YoL358xkpBkhIMeIwD5FhzjXDVS2PGxIXT30BVokT2yqKvPbc2CTmnxH7Vo/Onj5 7UrQ==
X-Gm-Message-State: AG10YORfLL7A2RzkZsukzemFoKTqmpmVcjz4fREr/dJkKCQwwcUhZUjU0LdPs7jFyFQUIXiPbeJwNaygoEJs3Q==
MIME-Version: 1.0
X-Received: by with SMTP id g6mr1015822igc.77.1453955569340; Wed, 27 Jan 2016 20:32:49 -0800 (PST)
Received: by with HTTP; Wed, 27 Jan 2016 20:32:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 28 Jan 2016 15:32:49 +1100
Message-ID: <>
From: Martin Thomson <>
To: Costin Manolache <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Brian Raymor <>, "" <>
Subject: Re: [Webpush] Message update PR
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, 28 Jan 2016 04:32:51 -0000

Sorry about the much-belated response.  I'm updating the PR with a
length restriction.  Still not sure about the

On 12 January 2016 at 12:04, Costin Manolache <> wrote:
> I know broadcast is not in scope for this release - but if/when we add it,
> it will make things
> more confusing with topic.

Hmm, that may be right.  But a short name that isn't already taken is
hard to find.  Collapse-Key is highly application-specific and I know
that HTTP have a problem with single-purpose header fields.  I was
tempted to suggest "Subject" actually as being similar, but not the

>> Would the base64(url) alphabet suit you well enough?  I didn't add
>> that restriction.
>> What about a length restriction?  I think that Ben and I discussed
>> just rejecting push messages with ridiculously long topic names.
> Agreed, base64(url) with a reasonable size is good.

UUID runs to quite a few characters, so how about 32 characters from
the base64 URL-safe alphabet.  I'll put that in the PR.

> Current patch requires the messages to include the topic header, and it
> still
> generates 3 message IDs ( "creates a new push message resource")

Yes, you are right.  Though I think that you only need a single message ID here.

> Alternative would be to just allow updating the original resource, if it was
> not sent.

Yes, but that requires knowing the identity of the original resource,
something that requires additional state at the application server.
The discussion at the last meeting revealed that many application
servers don't like this as it imposes restrictions on how they operate
and a bunch of extra state.

> BTW - there is one important change in the patch, allowing push senders to
> the resource. Allowing update would be consistent with that.

Yes, DELETE is very useful, though it does require some state.  This
isn't really new though.

Note that you can also push with the same topic and a very short TTL
to in-effect reduce the TTL of an existing message.  I struggled to
explain that clearly in the PR as Brian will tell you, but it's an
option for those who don't like maintaining the extra state.