One document matched: draft-nakajima-webpush-problem-statement-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.23 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-nakajima-webpush-problem-statement-00" category="info">

  <front>
    <title abbrev="Problem Statement and Requirements for Web Push">Problem Statement and Requirements for Emergency Notification using Web Push</title>

    <author initials="H." surname="Nakajima" fullname="Hirotaka Nakajima">
      <organization>Keio University</organization>
      <address>
        <email>hiro@awa.sfc.keio.ac.jp</email>
      </address>
    </author>

    <date year="2015"/>

    
    
    

    <abstract>


<t>The Web Push protocol provides a means of delivering the events to clients based
on the registration made by the application. Also, the emergency alert
notification system has been developed and deployed widely with mobile phones or
smartphones, but has not deployed to Web-only devices.</t>

<t>This document outlines various existing emergency alert notification system in
other protocols and use cases with their requirements.</t>



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">

<t>The delivery of real-time events such as incoming calls or messages is an
essential feature of mobile application and its platform.  The Web Push
<xref target="I-D.thomson-webpush-http2"/> protocol has been proposed to enable delivering
the events required by W3C Web Push API <xref target="PushAPI"/>.</t>

<t>Also, emergency alerting is an apparently important feature of telecommunication
network such as cellular networks, allowing the governments or authorities to
send a warnings of natural disaster or accident.</t>

<t>This document will describe various use cases and requirements of emergency
notification system using Web Push.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>In cases where normative language needs to be emphasized, this document back on
established shorthands for expressing interoperability requirements on
implementations: the capitalized words “MUST”, “MUST NOT”, “SHOULD” and “MAY”.
The meaning of these is described in <xref target="RFC2119"/>.</t>

</section>
<section anchor="problem" title="Problem Statement">

<section anchor="issues-on-existing-emergency-alerting-system" title="Issues on existing emergency alerting system">

<t>This section describes the survey and issues of existing emergency alerting
system.</t>

<t>In the cellular network, several emergency alerting mechanisms have been
proposed and merged into Public Warning System(PWS) <xref target="_3GPP.22.268"/>. PWS
provides several functions for example:</t>

<t><list style="symbols">
  <t>Able to broadcast Warning notifications to multiple devices simultaneously.</t>
  <t>Able to broadcast Warning notifications based on geographical information.</t>
  <t>Provides reliable, secure delivery of Warning notification over 3GPP system.</t>
</list></t>

<t>Addition to PWS, some work has been made to distribute the emergency alerting
notification on different network. In the WiFi network, IEEE 802.11u
<xref target="IEEE80211u"/> has an emergency support which uses Common Alerting Protocol
(CAP) <xref target="CAP"/>. Also, Atoca WG has worked for defining the secure alerting format
to broadcast CAP-based alert over IP network.</t>

<t>Those previous contributions have been made to develop the method to distribute
an emergency alerting notification.  However, those systems require a specific
access network such as 3GPP or WiFi. There is an issue that desktop device or
device not equipped with 3GPP or WiFi is not able to receive an emergency
alerting notification.</t>

<t>The second issue is geolocation-aware system.  A major emergency alert such as
an earthquake or a tsunami is distributed at geolocation specific area based on
the cellular cell or WiFi cell. Web Push relies on HTTP/2
<xref target="I-D.ietf-httpbis-http2"/> which relies on IP network.  Geofencing
<xref target="Geofencing"/> is discussed in W3C Geolocation WG to let the application to
interact with the loose location-aware computation without knowing device’s
exact location. However, geofencing needs device’s support, Web Push emergency
alerting notification system has to have a mechanism to detect device’s
location to send a location specific alerts.</t>

</section>
<section anchor="use-case-of-web-push-emergency-alerting-notification" title="Use case of Web Push Emergency Alerting Notification">

<t>There are two potential use case of Web Push Emergency Alerting notification.</t>

<t>The first use case is a Web-based Signage. Digital signage has widely deployed
among the world. Signages located at public area such as train station or street
play a significant role in natural disaster or accident by providing the
evacuation alert or correct informations. Recent few years W3C worked on
Web-based signage which has Web browser is embedded, allowing to display or play
Web content. Disaster use case is proposed in W3C Web-based Signage Scenarios
and Use Cases <xref target="SignageUseCase"/>.</t>

<t>The second use case is an over-the-top emergency alerting system operated by a
local authorities or a government. An emgergency alerting of an major natural
disaster such as an earthquake or a tsunami could be distributed by existing
emergency alerting system (e.g. PWS). However, distributing an emergency
alerting of an minor natual disaster such as heavy rain alert using existing
method is too complicated compared to the importance of the information or
alert. Web Push emergency alerting notification can provide more specific alert
or information requested by the mobile or desktop application not requiring 3GPP
or WiFi network. For example:</t>

<t><list style="symbols">
  <t>Raining alert based on the location</t>
  <t>Transit alert such as accident information or suspend.</t>
</list></t>

</section>
<section anchor="non-emergency-important-notification" title="Non-emergency, Important notification">

<t>Non-emergency but important notification is required to real-time applications.
Real-time application such as VoIP or telecommunication application, need to
deliver the notification faster than other notification.</t>

</section>
</section>
<section anchor="security-consideration" title="Security Consideration">
<t>Discovery of Push Server and application is out of scope in this document.
However, discovery of reliable Push Server and application is definitely
important. Also, it is important for Web Push Emergency Alerting notification to
have a mechanism to avoid the abuse of system.</t>

</section>
<section anchor="iana-consideration" title="IANA Consideration">
<t>TBD</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='I-D.thomson-webpush-http2'>
<front>
<title>Generic Event Delivery Using HTTP Push</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='December' day='12' year='2014' />

<abstract><t>A simple protocol for the delivery of realtime events to clients is described.  This scheme uses HTTP/2 server push.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-thomson-webpush-http2-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thomson-webpush-http2-02.txt' />
</reference>



<reference anchor='I-D.ietf-httpbis-http2'>
<front>
<title>Hypertext Transfer Protocol version 2</title>

<author initials='M' surname='Belshe' fullname='Mike Belshe'>
    <organization />
</author>

<author initials='R' surname='Peon' fullname='Roberto Peon'>
    <organization />
</author>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='February' day='10' year='2015' />

<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.  This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-http2-17' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-http2-17.txt' />
</reference>


<reference anchor="PushAPI" target="https://w3c.github.io/push-api/">
  <front>
    <title>Web Push API</title>
    <author >
      <organization>W3C</organization>
    </author>
    <date year="2015" month="February"/>
  </front>
</reference>




<reference anchor='_3GPP.22.268'>
<front>
<title>Public Warning System (PWS) requirements</title>
<author><organization>3GPP</organization></author>
<date day='18' month='December' year='2012' />
</front>

<seriesInfo name='3GPP TS' value='22.268 10.4.0' />
<format type='HTML' target='http://www.3gpp.org/ftp/Specs/html-info/22268.htm' />
</reference>


<reference anchor="CAP" >
  <front>
    <title>Common Alerting Protocol v1.2</title>
    <author fullname="Jacob Westfall">
      <organization></organization>
    </author>
    <date year="2010" month="July"/>
  </front>
</reference>
<reference anchor="IEEE80211u" >
  <front>
    <title>IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and Metropolitan networks-specific requirements-Part II: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 9: Interworking with External Networks</title>
    <author >
      <organization>IEEE</organization>
    </author>
    <date year="2011" month="February" day="25"/>
  </front>
</reference>
<reference anchor="SignageUseCase" target="http://www.w3.org/community/websignage/wiki/Web-based_Signage_Use_cases_and_Requirements">
  <front>
    <title>Web-based Signage Scenarios and Use Cases</title>
    <author initials="F." surname="Hatano" fullname="Futomi Hatano">
      <organization></organization>
    </author>
    <date year="2013" month="January"/>
  </front>
</reference>
<reference anchor="Geofencing" target="https://gmandyam.github.io/enhanced-geolocation/">
  <front>
    <title>Enhanced Geolocation</title>
    <author initials="G." surname="Mandyam" fullname="Giridhar Mandyam">
      <organization></organization>
    </author>
    <date year="2014" month="August" day="23"/>
  </front>
</reference>


    </references>



  </back>
</rfc>