Subject: [Webpush] Updated charter proposal

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Sep 2014 07:07:18 -0700

The IESG comments on the first charter were generally favorable,
though there were a few questions and reservations.  Here's what I'm
going to propose as the updated charter.

---

Many applications require continuous access to network communications so
that real-time events - such as incoming calls or messages - can be conveyed
("pushed") to the user in a timely fashion. Uncoordinated use of the network by
multiple applications can contribute to unnecessary use of the network on
devices.  For instance, maintaining sessions can dominate costs over the long
term, since pushed events are relatively rare.  This is particularly onerous for
battery-powered devices, on which network communication contributes a
significant proportion of power usage.  Each independent session independently
incurs overheads, causing unnecessary resource usage on devices.

Several modern computing platforms provide a push notification service that
consolidates application events, distributing those events to applications as
they arrive.  The single session avoids duplicated overhead costs on devices.

This working group will develop a protocol that applications can use to request
the delivery of data to a device using a consolidated push notification service.
This protocol will include the ability to push the same message to multiple
subscribed devices.  The work may describe a protocol that allows a device to
subscribe to a push service and receive pushed messages.

This work will be done in collaboration with the W3C Webapps Working Group, who
are developing a Web Push API for use in web applications (see
<http://www.w3.org/TR/push-api/>).

---

Pete Resnick suggested we be honest and specifically call out HTTP as
the basis of the protocol.  I don't think that's appropriate here,
since this isn't necessarily HTTP-based.  And I say that even when the
proposal I have on the table is HTTP-based.

There were questions about the "exemplar protocol" statement, which in
retrospect is completely understandable.  I hope that the last
sentence of paragraph 3 is clearer on this point.

Stephen Farrell and Adrian Farrel both had concerns around security
and privacy.  I'm happy to include text if someone can avoid it being
too much of a motherhood statement, which I don't think would be
valuable.  Particularly because a fair treatment of the assumed
security architecture, problems arising from that, and the associated
privacy implications is entirely achievable within the confines of a
security considerations section.  I personally don't believe that it's
necessary to write security considerations into every charter; I'd
prefer to think that we've won hearts and minds over to the need for
good considerations such that this need is implicit. Maybe that's just
an optimistic projection on my part.

BTW, my recent realization is that hard requirements around security
will be driven from the W3C webapps WG, not the IETF.

---

From: nero <[email-masked]>
Date: Tue, 23 Sep 2014 08:39:33 -0700

a few thoughts:
1- I think security and privacy concerns should be addressed (as a matter
of fact there is strong security and privacy around the GCM model).
2-  "real time calls", it needs to be understood that there are numerous
carrier networks across the globe that are badly configured. Messages via
webpush are asynchronous by nature and might not reach devices in a
specified timeframe even if said devices are able to connect to websites
3- Can you clarify what you mean when you say HTTP should be the basis of
the protocol? Is it from the sender to the receiving Push Service? Or also
from the receiving Push Service to the connected endpoint (the ultimate
receiver of the message)?

On Tue, Sep 23, 2014 at 7:07 AM, Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

-- 

Francesco Nerieri | Eng. Manager - Mobile | [email-masked]
<[email-masked]> | 650.283.8890