One document matched: draft-barnes-atoca-meta-00.txt
ATOCA R. Barnes
Internet-Draft BBN Technologies
Intended status: Informational October 24, 2011
Expires: April 26, 2012
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 26, 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
Barnes Expires April 26, 2012 [Page 1]
Internet-Draft AMP October 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Open Questions . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Server Discovery . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. DHCP Option Format . . . . . . . . . . . . . . . . . . . . 3
3.2. DNS NAPTR Record Format . . . . . . . . . . . . . . . . . . 3
3.3. Client Processing . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 3
4.1.1. Registration . . . . . . . . . . . . . . . . . . . . . 4
4.1.2. Advertisement . . . . . . . . . . . . . . . . . . . . . 4
4.1.3. Refer . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.4. Alert . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. WebSocket Binding . . . . . . . . . . . . . . . . . . . . . 5
4.3. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5.1. DHCP Option Code . . . . . . . . . . . . . . . . . . . . . 5
5.2. NAPTR Service Tag . . . . . . . . . . . . . . . . . . . . . 5
5.3. WebSocket Sub-Protocol . . . . . . . . . . . . . . . . . . 5
5.4. Media type application/amp+json . . . . . . . . . . . . . . 5
5.5. AMP Message Type Registry . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Barnes Expires April 26, 2012 [Page 2]
Internet-Draft AMP October 2011
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
Barnes Expires April 26, 2012 [Page 3]
Internet-Draft AMP October 2011
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]
Barnes Expires April 26, 2012 [Page 4]
Internet-Draft AMP October 2011
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]
Barnes Expires April 26, 2012 [Page 5]
Internet-Draft AMP October 2011
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
[CAP] Botterell, A. and E. Jones, "Common Alerting Protocol
v1.1", October 2005.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, February 1993.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
Randers-Pehrson, "GZIP file format specification version
4.3", RFC 1952, May 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Barnes Expires April 26, 2012 [Page 6]
Internet-Draft AMP October 2011
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, January 2010.
8.2. Informative References
[I-D.ietf-atoca-requirements]
Schulzrinne, H., Norreys, S., Rosen, B., and H.
Tschofenig, "Requirements, Terminology and Framework for
Exigent Communications", draft-ietf-atoca-requirements-01
(work in progress), January 2011.
Author's Address
Richard Barnes
BBN Technologies
9861 Broken Land Parkway
Columbia, MD 21046
US
Phone: +1 410 290 6169
Barnes Expires April 26, 2012 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 04:07:16 |