Alert Metadata Protocol (AMP)
draft-barnes-atoca-meta-00.txt

Abstract

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.

Please send feedback to the atoca@ietf.org mailing list.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 27, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Open Questions
• 2. Definitions
• 3. Server Discovery
• 3.1. DHCP Option Format
• 3.2. DNS NAPTR Record Format
• 3.3. Client Processing
• 4. Protocol
• 4.1. Message Format
• 4.1.1. Registration
• 4.1.2. Advertisement
• 4.1.3. Refer
• 4.1.4. Alert
• 4.2. WebSocket Binding
• 4.3. HTTP Binding
• 5. IANA Considerations
• 5.1. DHCP Option Code
• 5.2. NAPTR Service Tag
• 5.3. WebSocket Sub-Protocol
• 5.4. Media type application/amp+json
• 5.5. AMP Message Type Registry
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

[TODO]

1.1. Open Questions

Allow use of JOSE to protect messages on a per-message basis?

2. Definitions

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 [RFC2119].

3. Server Discovery

[DHCP option, NAPTR tag]

[Client process: Look for DHCP, then try reverse]

3.1. DHCP Option Format

[TODO]

3.2. DNS NAPTR Record Format

[TODO]

3.3. Client Processing

[Look for DHCP, then try reverse]

4. Protocol

[JSON over HTTP or WebSocket]

4.1. Message Format

[Overall structure: Array of JSON objects with specified fields. MUST include a "type" field; Implementations MUST ignore messages with unknown types.]

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

[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]

4.1.1. Registration

[Client->Server]

[Field: "token", contains identifier for client]

[Field: "contacts", contains array of URIs]

[Field: "location", contains "location-info" element from PIDF-LO]

[Field; "language", contains laguage tag]

[Client may repeat to update information]

[Empty update implies delete]

4.1.2. Advertisement

[Server->Client]

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

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

[Field: "certs", contains array of certificates for local alert authorities]

[Field: "public_keys", contains array of SPKI for local alert authorities]

[Field: "hash_values", contains array of hash values for ESCAPE verification]

[Field: "ttl", contains integer number of seconds for which this advertsiement is valid]

4.1.3. Refer

[Server->Client]

[Field: "to", contains URI of new AMP server that client should contact]

4.1.4. Alert

[Server->Client]

[Field: "alert_data", contains ESCAPE-encoded alert. ]

4.2. WebSocket Binding

[Subprotocol 'alert-metadata'; use 'text' bodies to exchange AMP messages]

[On connect, client SHOULD send registration, server SHOULD send advertisement]

4.3. HTTP Binding

[Request MUST be POST, response MUST be 200 unless an HTTP-layer error]

[Request SHOULD contain registration]

[Response SHOULD contain advertisement]

5. IANA Considerations

This document requires several registrations by IANA into existing registries, and creates a new registry of AMP message codes.

5.1. DHCP Option Code

[TODO]

5.2. NAPTR Service Tag

[TODO]

5.3. WebSocket Sub-Protocol

[TODO]

5.4. Media type application/amp+json

[TODO]

5.5. AMP Message Type Registry

[TODO]

6. Security Considerations

[This protocol runs over HTTP, so TLS is the security layer. Standard caveats about NAPTR / server-id / DNSSEC. ]

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

[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).]

7. Acknowledgements

[TODO]

8. References

8.1. Normative References

8.2. Informative References

Author's Address