draft-ietf-ecrit-data-only-ea-17.txt   draft-ietf-ecrit-data-only-ea-18.txt 
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft Internet-Draft
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: September 12, 2019 Columbia U. Expires: October 19, 2019 Columbia U.
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
R. Gellens R. Gellens
Core Technology Consulting Core Technology Consulting
March 11, 2019 April 17, 2019
Data-Only Emergency Calls Data-Only Emergency Calls
draft-ietf-ecrit-data-only-ea-17 draft-ietf-ecrit-data-only-ea-18
Abstract Abstract
RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
describes how devices use the Internet to place emergency calls and describes how devices use the Internet to place emergency calls and
how Public Safety Answering Points (PSAPs) handle Internet multimedia how Public Safety Answering Points (PSAPs) handle Internet multimedia
emergency calls natively. The exchange of multimedia traffic for emergency calls natively. The exchange of multimedia traffic for
emergency services involves a Session Initiation Protocol (SIP) emergency services involves a Session Initiation Protocol (SIP)
session establishment starting with a SIP INVITE that negotiates session establishment starting with a SIP INVITE that negotiates
various parameters for that session. various parameters for that session.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on October 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 11, line 48 skipping to change at page 11, line 48
involves making the data available via HTTPS (either at the involves making the data available via HTTPS (either at the
originator or at another entity), placing a URI to the data in the originator or at another entity), placing a URI to the data in the
'Call-Info' header field, and the recipient using HTTPS to retrieve 'Call-Info' header field, and the recipient using HTTPS to retrieve
the data. The CAP message itself can be sent by-reference using this the data. The CAP message itself can be sent by-reference using this
mechanism, as well as any or all of the Additional Data blocks that mechanism, as well as any or all of the Additional Data blocks that
may contain sensor-specific data. may contain sensor-specific data.
8. Example 8. Example
The following example shows a CAP document indicating a BURGLARY The following example shows a CAP document indicating a BURGLARY
alert issued by a sensor called 'sensor1@domain.com'. The location alert issued by a sensor called 'sensor1@example.com'. The location
of the sensor can be obtained from the attached location information of the sensor can be obtained from the attached location information
provided via the 'geolocation' header field contained in the SIP provided via the 'geolocation' header field contained in the SIP
MESSAGE structure. Additionally, the sensor provided some data along MESSAGE structure. Additionally, the sensor provided some data along
with the alert message, using proprietary information elements with the alert message, using proprietary information elements
intended only to be processed by the receiver, a SIP entity acting as intended only to be processed by the receiver, a SIP entity acting as
an aggregator. an aggregator.
MESSAGE sip:aggregator@domain.com SIP/2.0 MESSAGE sip:aggregator@example.com SIP/2.0
Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70 Max-Forwards: 70
From: sip:sensor1@domain.com;tag=49583 From: sip:sensor1@example.com;tag=49583
To: sip:aggregator@domain.com To: sip:aggregator@example.com
Call-ID: asd88asd77a@2001:DB8:0:0FF Call-ID: asd88asd77a@2001:DB8:0:0FF
Geolocation: <cid:abcdef@domain.com> Geolocation: <cid:abcdef@example.com>
;routing-allowed=yes ;routing-allowed=yes
Supported: geolocation Supported: geolocation
Accept: application/pidf+xml,application/EmergencyCallData.cap+xml Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Call-Info: cid:abcdef2@domain.com;purpose=EmergencyCallData.cap Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.cap+xml Content-Type: application/EmergencyCallData.cap+xml
Content-ID: <abcdef2@domain.com> Content-ID: <abcdef2@example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1"> <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>S-1</identifier> <identifier>S-1</identifier>
<sender>sip:sensor1@domain.com</sender> <sender>sip:sensor1@example.com</sender>
<sent>2008-11-19T14:57:00-07:00</sent> <sent>2008-11-19T14:57:00-07:00</sent>
<status>Actual</status> <status>Actual</status>
<msgType>Alert</msgType> <msgType>Alert</msgType>
<scope>Private</scope> <scope>Private</scope>
<incidents>abc1234</incidents> <incidents>abc1234</incidents>
<info> <info>
<category>Security</category> <category>Security</category>
<event>BURGLARY</event> <event>BURGLARY</event>
<urgency>Expected</urgency> <urgency>Expected</urgency>
<certainty>Likely</certainty> <certainty>Likely</certainty>
skipping to change at page 13, line 12 skipping to change at page 13, line 12
<parameter> <parameter>
<valueName>SENSOR-DATA-NAMESPACE2</valueName> <valueName>SENSOR-DATA-NAMESPACE2</valueName>
<value>TRUE</value> <value>TRUE</value>
</parameter> </parameter>
</info> </info>
</alert> </alert>
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <abcdef2@domain.com> Content-ID: <abcdef2@example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence <presence
xmlns="urn:ietf:params:xml:ns:pidf" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp= xmlns:gbp=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
skipping to change at page 14, line 16 skipping to change at page 14, line 16
Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa
Max-Forwards: 70 Max-Forwards: 70
From: sip:aggregator@example.com;tag=32336 From: sip:aggregator@example.com;tag=32336
To: 112 To: 112
Call-ID: asdf33443a@example.com Call-ID: asdf33443a@example.com
Route: sip:psap1.example.gov Route: sip:psap1.example.gov
Geolocation: <cid:abcdef@example.com> Geolocation: <cid:abcdef@example.com>
;routing-allowed=yes ;routing-allowed=yes
Supported: geolocation Supported: geolocation
Accept: application/pidf+xml,application/EmergencyCallData.cap+xml Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
Call-info: cid:abcdef2@domain.com;purpose=EmergencyCallData.cap Call-info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.cap+xml Content-Type: application/EmergencyCallData.cap+xml
Content-ID: <abcdef2@example.com> Content-ID: <abcdef2@example.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1"> <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>S-1</identifier> <identifier>S-1</identifier>
<sender>sip:sensor1@domain.com</sender> <sender>sip:sensor1@example.com</sender>
<sent>2008-11-19T14:57:00-07:00</sent> <sent>2008-11-19T14:57:00-07:00</sent>
<status>Actual</status> <status>Actual</status>
<msgType>Alert</msgType> <msgType>Alert</msgType>
<scope>Private</scope> <scope>Private</scope>
<incidents>abc1234</incidents> <incidents>abc1234</incidents>
<info> <info>
<category>Security</category> <category>Security</category>
<event>BURGLARY</event> <event>BURGLARY</event>
<urgency>Expected</urgency> <urgency>Expected</urgency>
<certainty>Likely</certainty> <certainty>Likely</certainty>
skipping to change at page 15, line 7 skipping to change at page 15, line 7
</parameter> </parameter>
<parameter> <parameter>
<valueName>SENSOR-DATA-NAMESPACE2</valueName> <valueName>SENSOR-DATA-NAMESPACE2</valueName>
<value>TRUE</value> <value>TRUE</value>
</parameter> </parameter>
</info> </info>
</alert> </alert>
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <abcdef2@domain.com> Content-ID: <abcdef2@example.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence <presence
xmlns="urn:ietf:params:xml:ns:pidf" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp= xmlns:gbp=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
skipping to change at page 16, line 33 skipping to change at page 16, line 33
used for this purpose: used for this purpose:
1. SIP itself provides security mechanisms that allow the 1. SIP itself provides security mechanisms that allow the
verification of the originator's identity. These mechanisms can verification of the originator's identity. These mechanisms can
be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity
[RFC8224]. The latter provides a cryptographic assurance while [RFC8224]. The latter provides a cryptographic assurance while
the former relies on a chain of trust model. the former relies on a chain of trust model.
2. CAP provides additional security mechanisms and the ability to 2. CAP provides additional security mechanisms and the ability to
carry further information about the sender's identity. carry further information about the sender's identity.
Section 3.3.2.1 of [cap] specifies the signing algorithms of CAP Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP
documents. documents.
In addition to the desire to perform identity-based access control, In addition to the desire to perform identity-based access control,
the classic communication security threats need to be considered, the classic communication security threats need to be considered,
including integrity protection to prevent forgery or replay of alert including integrity protection to prevent forgery or replay of alert
messages in transit. To deal with replay of alerts, a CAP document messages in transit. To deal with replay of alerts, a CAP document
contains the mandatory <identifier>, <sender>, <sent> elements and an contains the mandatory <identifier>, <sender>, <sent> elements and an
optional <expire> element. Together, these elements make the CAP optional <expire> element. Together, these elements make the CAP
document unique for a specific sender and provide time restrictions. document unique for a specific sender and provide time restrictions.
An entity that has already received a CAP message within the An entity that has already received a CAP message within the
skipping to change at page 17, line 31 skipping to change at page 17, line 31
MIME subtype name: cap+xml MIME subtype name: cap+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset; Indicates the character encoding of Optional parameters: charset; Indicates the character encoding of
enclosed XML. Default is UTF-8 [RFC3629]. enclosed XML. Default is UTF-8 [RFC3629].
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
[RFC3023], Section 3.2. [RFC7303], Section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
payloads of the Common Alerting Protocol (CAP). RFC XXX [Replace payloads of the Common Alerting Protocol (CAP). RFC XXX [Replace
by the RFC number of this specification] discusses security by the RFC number of this specification] discusses security
considerations for this. considerations for this.
Interoperability considerations: This content type provides a way to Interoperability considerations: This content type provides a way to
convey CAP payloads. convey CAP payloads.
Published specification: RFC XXX [Replace by the RFC number of this Published specification: RFC XXX [Replace by the RFC number of this
skipping to change at page 18, line 23 skipping to change at page 18, line 23
documents.php&wg_abbrev=emergency documents.php&wg_abbrev=emergency
Person and email address to contact for further information: Hannes Person and email address to contact for further information: Hannes
Tschofenig, hannes.tschofenig@gmx.net Tschofenig, hannes.tschofenig@gmx.net
Intended usage: Limited use Intended usage: Limited use
Author/Change controller: IETF ECRIT working group Author/Change controller: IETF ECRIT working group
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations application/xml [RFC7303], and many of the considerations
described there also apply to application/cap+xml. described there also apply to application/cap+xml.
10.2. IANA Registration of 'cap' Additional Data Block 10.2. IANA Registration of 'cap' Additional Data Block
This document registers a new block type in the sub-registry called This document registers a new block type in the sub-registry called
'Emergency Call Data Types' of the Emergency Call Additional Data 'Emergency Call Data Types' of the Emergency Call Additional Data
Registry defined in [RFC7852]. The token is "cap", the Data About is Registry defined in [RFC7852]. The token is "cap", the Data About is
"The Call" and the reference is this document. "The Call" and the reference is this document.
10.3. IANA Registration for 425 Response Code 10.3. IANA Registration for 425 Response Code
skipping to change at page 20, line 25 skipping to change at page 20, line 25
Details of these error codes are in Section 5. Details of these error codes are in Section 5.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank the participants of the Early Warning The authors would like to thank the participants of the Early Warning
adhoc meeting at IETF#69 for their feedback. Additionally, we would adhoc meeting at IETF#69 for their feedback. Additionally, we would
like to thank the members of the NENA Long Term Direction Working like to thank the members of the NENA Long Term Direction Working
Group for their feedback. Group for their feedback.
Additionally, we would like to thank Martin Thomson, James Additionally, we would like to thank Martin Thomson, James
Winterbottom, Shida Schubert, Bernard Aboba, and Marc Linsner for Winterbottom, Shida Schubert, Bernard Aboba, Marc Linsner, Christer
their review comments. Holmberg and Ivo Sedlacek for their review comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v.
1.1", October 2005. 1.2", October 2005, <https://docs.oasis-
open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>. <https://www.rfc-editor.org/info/rfc2392>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
skipping to change at page 21, line 16 skipping to change at page 21, line 16
Huitema, C., and D. Gurle, "Session Initiation Protocol Huitema, C., and D. Gurle, "Session Initiation Protocol
(SIP) Extension for Instant Messaging", RFC 3428, (SIP) Extension for Instant Messaging", RFC 3428,
DOI 10.17487/RFC3428, December 2002, DOI 10.17487/RFC3428, December 2002,
<https://www.rfc-editor.org/info/rfc3428>. <https://www.rfc-editor.org/info/rfc3428>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, DOI 10.17487/RFC7303, July 2014,
<https://www.rfc-editor.org/info/rfc3023>. <https://www.rfc-editor.org/info/rfc7303>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442, for the Session Initiation Protocol", RFC 6442,
DOI 10.17487/RFC6442, December 2011, DOI 10.17487/RFC6442, December 2011,
<https://www.rfc-editor.org/info/rfc6442>. <https://www.rfc-editor.org/info/rfc6442>.
 End of changes. 21 change blocks. 
26 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/