One document matched: draft-barnes-atoca-meta-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-barnes-atoca-meta-00.txt"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="AMP">Alert Metadata Protocol (AMP)</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <author fullname="Richard Barnes" initials="R.L." surname="Barnes">
      <organization>BBN Technologies</organization>

      <address>
        <postal>
          <street>9861 Broken Land Parkway</street>

          <city>Columbia</city>

          <region>MD</region>

          <code>21046</code>

          <country>US</country>
        </postal>

        <phone>+1 410 290 6169</phone>
      </address>
    </author>

    <date month="October" year="2011" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <area>RAI</area>

    <workgroup>ATOCA</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>atoca, alert, emergency, s/mime</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>Recipients of emergency alerts need to discover information about
      local alerting resources, and to register contact points where they can
      receive alerts. This document defines a mechanism for IP networks to
      advertise a local alert information resource, and a protocol that end
      hosts can use to retrieve local information and register information
      about themselves.</t>

      <t>Please send feedback to the atoca@ietf.org mailing list.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro-sec" title="Introduction">
      <t>[TODO]</t>

      <section title="Open Questions">
        <t>Allow use of JOSE to protect messages on a per-message basis?</t>
      </section>
    </section>

    <section anchor="def-sec" title="Definitions">
      <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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>

    <section title="Server Discovery">
      <t>[DHCP option, NAPTR tag]</t>

      <t>[Client process: Look for DHCP, then try reverse]</t>

      <section title="DHCP Option Format">
        <t>[TODO]</t>
      </section>

      <section title="DNS NAPTR Record Format">
        <t>[TODO]</t>
      </section>

      <section title="Client Processing">
        <t>[Look for DHCP, then try reverse]</t>
      </section>
    </section>

    <section title="Protocol ">
      <t>[JSON over HTTP or WebSocket]</t>

      <section title="Message Format">
        <t>[Overall structure: Array of JSON objects with specified fields.
        MUST include a "type" field; Implementations MUST ignore messages with
        unknown types.]</t>

        <t>[MIME media type: 'application/amp+json']</t>

        <t>[For each message type: Direction (C2S or S2C) and fields; each
        field has specified type and mandatory / optional; mandatory array
        fields MUST NOT contain the empty array]</t>

        <section title="Registration">
          <t>[Client->Server]</t>

          <t>[Field: "token", contains identifier for client]</t>

          <t>[Field: "contacts", contains array of URIs]</t>

          <t>[Field: "location", contains "location-info" element from
          PIDF-LO]</t>

          <t>[Field; "language", contains laguage tag]</t>

          <t>[Client may repeat to update information]</t>

          <t>[Empty update implies delete]</t>
        </section>

        <section title="Advertisement">
          <t>[Server->Client]</t>

          <t>[Field: "contacts", contains array of URIs from which alerts will
          be sourced]</t>

          <t>[Field: "token", contains an identifier that the client should
          use in future requests]</t>

          <t>[Field: "certs", contains array of certificates for local alert
          authorities]</t>

          <t>[Field: "public_keys", contains array of SPKI for local alert
          authorities]</t>

          <t>[Field: "hash_values", contains array of hash values for ESCAPE
          verification]</t>

          <t>[Field: "ttl", contains integer number of seconds for which this
          advertsiement is valid]</t>
        </section>

        <section title="Refer">
          <t>[Server->Client]</t>

          <t>[Field: "to", contains URI of new AMP server that client should
          contact]</t>
        </section>

        <section title="Alert">
          <t>[Server->Client]</t>

          <t>[Field: "alert_data", contains ESCAPE-encoded alert. ]</t>
        </section>
      </section>

      <section title="WebSocket Binding">
        <t>[Subprotocol 'alert-metadata'; use 'text' bodies to exchange AMP
        messages]</t>

        <t>[On connect, client SHOULD send registration, server SHOULD send
        advertisement]</t>
      </section>

      <section title="HTTP Binding">
        <t>[Request MUST be POST, response MUST be 200 unless an HTTP-layer
        error]</t>

        <t>[Request SHOULD contain registration]</t>

        <t>[Response SHOULD contain advertisement]</t>
      </section>
    </section>

    <section anchor="iana-sec" title="IANA Considerations">
      <t>This document requires several registrations by IANA into existing
      registries, and creates a new registry of AMP message codes.</t>

      <section title="DHCP Option Code">
        <t>[TODO]</t>
      </section>

      <section title="NAPTR Service Tag">
        <t>[TODO]</t>
      </section>

      <section title="WebSocket Sub-Protocol">
        <t>[TODO]</t>
      </section>

      <section title="Media type application/amp+json">
        <t>[TODO]</t>
      </section>

      <section title="AMP Message Type Registry">
        <t>[TODO]</t>
      </section>
    </section>

    <section anchor="sec-cons-sec" title="Security Considerations">
      <t>[This protocol runs over HTTP, so TLS is the security layer. Standard
      caveats about NAPTR / server-id / DNSSEC. ]</t>

      <t>[Confidentiality: If this protocol can be intercepted, clients'
      private information might be exposed, e.g., contacts or location]</t>

      <t>[Integrity: If this protocol can be modified, clients can be
      convinced to accept false alerts (advertisement), or denied alerts
      (registration), or get alerts for the wrong location
      (registration).]</t>
    </section>

    <section anchor="ack-sec" title="Acknowledgements">
      <t>[TODO]</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <reference anchor="CAP">
        <front>
          <title>Common Alerting Protocol v1.1</title>

          <author fullname="" initials="A" surname="Botterell">
            <organization></organization>
          </author>

          <author initials="E." surname="Jones">
            <organization>J</organization>

            <address>
              <postal>
                <street></street>

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date month="October" year="2005" />
        </front>
      </reference>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1421.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1952.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3370.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5754.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-atoca-requirements"?>
    </references>
  </back>
</rfc>