diff options
Diffstat (limited to 'doc/rfc/rfc7852.txt')
| -rw-r--r-- | doc/rfc/rfc7852.txt | 6331 |
1 files changed, 6331 insertions, 0 deletions
diff --git a/doc/rfc/rfc7852.txt b/doc/rfc/rfc7852.txt new file mode 100644 index 0000000..12aa4fd --- /dev/null +++ b/doc/rfc/rfc7852.txt @@ -0,0 +1,6331 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Gellens +Request for Comments: 7852 +Updates: 6443, 6881 B. Rosen +Category: Standards Track NeuStar +ISSN: 2070-1721 H. Tschofenig + + R. Marshall + TeleCommunication Systems, Inc. + J. Winterbottom + Winterb Consulting Services + July 2016 + + + Additional Data Related to an Emergency Call + +Abstract + + When an emergency call is sent to a Public Safety Answering Point + (PSAP), the originating device, the access network provider to which + the device is connected, and all service providers in the path of the + call have information about the call, the caller, or the location, + which is helpful for the PSAP to have in handling the emergency. + This document describes data structures and mechanisms to convey such + data to the PSAP. The intent is that every emergency call carry as + much of the information described here as possible using the + mechanisms described here. + + The mechanisms permit the data to be conveyed by reference (as an + external resource) or by value (within the body of a SIP message or a + location object). This follows the tradition of prior emergency + services standardization work where data can be conveyed by value + within the call signaling (i.e., in the body of the SIP message) or + by reference. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7852. + + + + +Gellens, et al. Standards Track [Page 1] + +RFC 7852 Additional Call Data July 2016 + + +Copyright Notice + + Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Data Provider Information. . . . . . . . . . . . . . . . . 9 + 4.1.1. Data Provider String . . . . . . . . . . . . . . . . . 9 + 4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . . 9 + 4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . . 10 + 4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . . 11 + 4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . . 12 + 4.1.6. Data Provider Language(s) Supported . . . . . . . . . . 13 + 4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . . 14 + 4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . . 14 + 4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . . 15 + 4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . . 15 + 4.2. Service Information . . . . . . . . . . . . . . . . . . . 18 + 4.2.1. Service Environment . . . . . . . . . . . . . . . . . . 18 + 4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . . 19 + 4.2.3. Service Mobility Environment . . . . . . . . . . . . . 21 + 4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . . 22 + 4.3. Device Information . . . . . . . . . . . . . . . . . . . . 22 + 4.3.1. Device Classification . . . . . . . . . . . . . . . . . 22 + 4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . . 23 + 4.3.3. Device Model Number . . . . . . . . . . . . . . . . . . 24 + 4.3.4. Unique Device Identifier . . . . . . . . . . . . . . . 24 + 4.3.5. Device/Service-Specific Additional Data Structure . . . 25 + 4.3.6. Device/Service-Specific Additional Data Structure Type 26 + 4.3.7. EmergencyCallData.DeviceInfo Example . . . . . . . . . 27 + 4.4. Owner/Subscriber Information . . . . . . . . . . . . . . . 27 + 4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . . 27 + 4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . . 28 + + + +Gellens, et al. Standards Track [Page 2] + +RFC 7852 Additional Call Data July 2016 + + + 4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . . 29 + 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . . 31 + 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . . 32 + 5. Issues with Getting New Types of Data into Use . . . . . . . 32 + 5.1. Choosing between Defining a New Type of Block or a New + Type of Device/Service-Specific Additional Data . . . . . 33 + 6. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33 + 6.1. Transmitting Blocks Using Call-Info . . . . . . . . . . . 36 + 6.2. Transmitting Blocks by Reference Using the <provided-by> + Element . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 6.3. Transmitting Blocks by Value Using the <provided-by> + Element . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 6.4. The Content-Disposition Parameter . . . . . . . . . . . . 39 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 + 8. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 53 + 8.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 54 + 8.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . . 56 + 8.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 57 + 8.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 59 + 8.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . . 60 + 8.6. provided-by XML Schema . . . . . . . . . . . . . . . . . . 61 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 62 + 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 64 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 + 11.1. Emergency Call Additional Data Registry . . . . . . . . . 67 + 11.1.1. Provider ID Series Registry . . . . . . . . . . . . . 67 + 11.1.2. Service Environment Registry . . . . . . . . . . . . . 68 + 11.1.3. Service Type Registry . . . . . . . . . . . . . . . . 68 + 11.1.4. Service Mobility Registry . . . . . . . . . . . . . . 68 + 11.1.5. Type of Provider Registry . . . . . . . . . . . . . . 69 + 11.1.6. Device Classification Registry . . . . . . . . . . . . 69 + 11.1.7. Device ID Type Registry . . . . . . . . . . . . . . . 69 + 11.1.8. Device/Service Data Type Registry . . . . . . . . . . 70 + 11.1.9. Emergency Call Data Types Registry . . . . . . . . . . 70 + 11.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . . 72 + 11.3. URN Sub-Namespace Registration for <provided-by> + Registry Entry . . . . . . . . . . . . . . . . . . . . . 72 + 11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 72 + 11.4.1. MIME Content-Type Registration for + 'application/EmergencyCallData.ProviderInfo+xml' . . . 72 + 11.4.2. MIME Content-Type Registration for + 'application/EmergencyCallData.ServiceInfo+xml' . . . 73 + 11.4.3. MIME Content-Type Registration for + 'application/EmergencyCallData.DeviceInfo+xml' . . . . 74 + 11.4.4. MIME Content-Type Registration for + 'application/EmergencyCallData.SubscriberInfo+xml' . . 75 + + + + +Gellens, et al. Standards Track [Page 3] + +RFC 7852 Additional Call Data July 2016 + + + 11.4.5. MIME Content-Type Registration for + 'application/EmergencyCallData.Comment+xml' . . . . . 76 + 11.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 78 + 11.5.1. Registration for + urn:ietf:params:xml:ns:EmergencyCallData . . . . . . . 78 + 11.5.2. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo . 78 + 11.5.3. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo . 79 + 11.5.4. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo . . 80 + 11.5.5. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 81 + 11.5.6. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:Comment . . . 81 + 11.6. Schema Registrations . . . . . . . . . . . . . . . . . . 82 + 11.7. vCard Parameter Value Registration . . . . . . . . . . . 83 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 84 + 12.2. Informative References . . . . . . . . . . . . . . . . . 85 + Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 89 + Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 111 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 112 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113 + +1. Introduction + + When an IP-based emergency call is initiated, a rich set of data from + multiple data sources is conveyed to the Public Safety Answering + Point (PSAP). This data includes information about the calling party + identity, the multimedia capabilities of the device, the request for + emergency services, location information, and metadata about the + sources of the data. In addition, the device, the access network + provider, and any service provider in the call path has even more + information that is useful for a PSAP when handling an emergency. + + This document extends the basic set of data communicated with an + emergency call based on the Session Initiation Protocol (SIP), as + described in RFC 6443 [RFC6443] and RFC 6881 [RFC6881], in order to + carry additional data that is useful to an entity or call taker + handling the call. This data is "additional" to the basic + information found in the emergency call signaling used. The intent + is that every emergency call carry as much of the information + described here as possible using the mechanisms described here. + + + + + + + +Gellens, et al. Standards Track [Page 4] + +RFC 7852 Additional Call Data July 2016 + + + This document defines three categories of this additional data that + can be transmitted with an emergency call: + + Data Associated with a Location: Primary location data is conveyed + in the Presence Information Data Format Location Object (PIDF-LO) + data structure as defined in RFC 4119 [RFC4119] and extended by + RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location + information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for + geodetic location information), and RFC 7035 [RFC7035] (for + relative location). This primary location data identifies the + location or estimated location of the caller. However, there + might exist additional, secondary data that is specific to the + location, such as floor plans, tenant and building owner contact + data, heating, ventilation, and air conditioning (HVAC) status, + etc. Such secondary location data is not included in the location + data structure but can be transmitted using the mechanisms defined + in this document. Although this document does not define any + structures for such data, future documents can do so following the + procedures defined here. + + Data Associated with a Call: While some information is carried in + the call setup procedure itself (as part of the SIP headers as + well as in the body of the SIP message), there is additional data + known by the device making the call, the access network to which + the device is connected, and service providers along the path of + the call. This information includes service provider contact + information, subscriber identity and contact information, the type + of service the service provider and the access network provide, + what type of device is being used, etc. Some data is broadly + applicable, while other data is dependent on the type of device or + service. For example, a medical monitoring device might have + sensor data. The data structures defined in this document (Data + Provider Information, Device Information, and Owner/Subscriber + Information) all fall into the category of "Data Associated with a + Call". Note that the owner/subscriber information includes the + subscriber's vCard, which might contain personal information such + as birthday, anniversary, etc., but the data block itself is still + considered to be about the call, not the caller. + + Data Associated with a Caller: This is personal data about a caller, + such as medical information and emergency contact data. Although + this document does not define any structures within this category, + future documents can do so following the procedures defined here. + + While this document defines data structures only within the category + of Data Associated with a Call, by establishing the overall framework + of Additional Data, along with general mechanisms for transport of + such data, extension points, and procedures for future extensions, it + + + +Gellens, et al. Standards Track [Page 5] + +RFC 7852 Additional Call Data July 2016 + + + minimizes the work needed to carry data in the other categories. + Other specifications can make use of the facilities provided here. + + For interoperability, there needs to be a common way for the + information conveyed to a PSAP to be encoded and identified. + Identification allows emergency services authorities to know during + call processing which types of data are present and to determine if + they wish to access it. A common encoding allows the data to be + successfully accessed. + + This document defines an extensible set of data structures, and + mechanisms to transmit this data either by value or by reference, + either in the SIP call signaling or in the PIDF-LO. The data + structures are usable by other communication systems and transports + as well. The data structures are defined in Section 4, and the + transport mechanisms (using SIP and HTTPS) are defined in Section 6. + + Each data structure described in this document is encoded as a + "block" of information. Each block is an XML structure with an + associated Multipurpose Internet Mail Extensions (MIME) media type + for identification within transport such as SIP and HTTPS. The set + of blocks is extensible. Registries are defined to identify the + block types that can be used and to allow blocks to be included in + emergency call signaling. + + Much of the information supplied by service providers and devices is + private and confidential. Service providers and devices generally go + to lengths to protect this information; disclosing it in the context + of an emergency call is a trade-off to protect the greater interest + of the customer in an emergency. + +2. Terminology + + 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]. + + This document also uses terminology from [RFC5012]. We use the term + "service provider" to refer to an Application Service Provider (ASP). + A Voice Service Provider (VSP) is a special type of ASP. With the + term "Access Network Provider", we refer to the Internet Access + Provider (IAP) and the Internet Service Provider (ISP) without + further distinguishing these two entities, since the difference + between the two is not relevant for this document. Note that the + roles of an ASP and access network provider might be provided by a + single company. An Emergency Services Provider is an entity directly + involved in providing emergency services. This includes PSAPs, + + + + +Gellens, et al. Standards Track [Page 6] + +RFC 7852 Additional Call Data July 2016 + + + dispatch, police, fire, emergency medical, other responders, and + other similar agencies. + + Within each data block definition (see Section 4), the values for the + 'Use:' label are specified as one of the following: + + 'Required': means it MUST be present in the data structure. + + 'Conditional': means it MUST be present if the specified + condition(s) is met. It MAY be present if the condition(s) is not + met. + + 'Optional': means it MAY be present. + + vCard [RFC6350] is a data format for representing and exchanging a + variety of information about individuals and other entities. For + applications that use XML, the format defined in vCard is not + immediately applicable. For this reason, an XML-based encoding of + the information elements defined in the vCard specification has been + defined, and the name of that specification is xCard [RFC6351]. + Since the term vCard is more familiar to most readers, we use the + terms xCard and vCard interchangeably. + +3. Document Scope + + The scope of this document is explicitly limited to emergency calls. + The data structures defined here are not appropriate to be conveyed + in non-emergency calls because they carry sensitive and private data. + However, in certain private-use situations between a specialized + service provider (such as a vehicle telematics service provider) and + dedicated equipment (such as in a vehicle) where the endpoints have a + preexisting relationship and privacy issues are addressed within the + relationship, the mechanisms and data structures defined here can be + used with communications within the limited context of the + preexisting relationship. + +4. Data Structures + + This section defines the following five data structures, each as a + data block. For each block, we define the MIME media type and the + XML encoding. The five data structures are: + + 'Data Provider': This block supplies name and contact information + for the entity that created the data. Section 4.1 provides the + details. + + 'Service Information': This block supplies information about the + service. The description can be found in Section 4.2. + + + +Gellens, et al. Standards Track [Page 7] + +RFC 7852 Additional Call Data July 2016 + + + 'Device Information': This block supplies information about the + device placing the call. Device information can be found in + Section 4.3. + + 'Owner/Subscriber': This block supplies information about the owner + of the device or about the subscriber. Details can be found in + Section 4.4. + + 'Comment': This block provides a way to supply free form human- + readable text to the PSAP or emergency responders. This simple + structure is defined in Section 4.5. + + Each block contains a mandatory <DataProviderReference> element. The + purpose of the <DataProviderReference> element is to associate all + blocks added by the same data provider as a unit. The + <DataProviderReference> element associates the data provider block to + each of the other blocks added as a unit. Consequently, when a data + provider adds additional data to an emergency call (such as device + information), it MUST add information about itself (via the data + provider block), and the blocks added contain the same value in the + <DataProviderReference> element. All blocks added by a single entity + at the same time MUST have the same <DataProviderReference> value. + (In certain situations, the same provider might process a call more + than once, likely in different roles, and in such cases, each time it + processes the call, it adds a new set of blocks with a new + <DataProviderReference> value.) The value of the + <DataProviderReference> element has the same syntax and properties + (specifically, world-uniqueness) as the value of the 'Message-ID' + message body header field specified in RFC 5322 [RFC5322] except that + the <DataProviderReference> element is not enclosed in brackets (the + '<' and '>' symbols are omitted). In other words, the value of a + <DataProviderReference> element is syntactically a msg-id as + specified in RFC 5322 [RFC5322]. + + Each block is added to the "Additional Data Blocks" registry created + in Section 11.1.9 and categorized as providing data about the caller. + New blocks added to the registry in the future MUST also be + categorized per the description of the three categories in Section 1. + See Sections 5 and 5.1 for additional considerations when adding new + blocks or types of data. + + Note that the xCard format is reused in some of the data structures + to provide contact information. In an xCard, there is no way to + specify a 'main' telephone number (that is, a primary or main contact + number, typically of an enterprise, as opposed to a direct-dial + number of an individual). These numbers are useful to emergency + responders who are called to a large enterprise. This document adds + a new parameter value called 'main-number' to the 'TYPE' parameter of + + + +Gellens, et al. Standards Track [Page 8] + +RFC 7852 Additional Call Data July 2016 + + + the 'tel' property. It can be used in any xCard in an emergency call + additional data block. + +4.1. Data Provider Information + + This block is intended to be supplied by any service provider in the + path of the call, or the access network provider, and the device. It + includes identification and contact information. This block MUST be + supplied by any entity that provides any other block; it SHOULD be + supplied by every service provider in the call path and by the access + network provider if those entities do not add any other blocks. + Devices SHOULD use this block to provide identifying information. + The MIME media type is 'application/ + EmergencyCallData.ProviderInfo+xml'. An access network provider + SHOULD provide this block either by value or by reference in the + <provided-by> element of a PIDF-LO. + +4.1.1. Data Provider String + + Data Element: Data Provider String + + Use: Conditional. Optional for blocks supplied by the originating + device; mandatory otherwise. + + XML Element: <DataProviderString> + + Description: This is a plaintext string suitable for displaying the + name of the service provider that supplied the data structure. If + the device creates the structure, it SHOULD use the value of the + contact header field in the SIP INVITE. + + Reason for Need: Inform the call taker of the identity of the entity + providing the data. + + How Used by Call Taker: Allows the call taker to interpret the data + in this structure. The source of the information often influences + how the information is used, believed, or verified. + +4.1.2. Data Provider ID + + Data Element: Data Provider ID + + Use: Conditional. Optional for blocks supplied by the originating + device; mandatory otherwise. This data MUST be provided by all + entities other than the originating device in order to uniquely + identify the service provider or access provider. + + XML Element: <ProviderID> + + + +Gellens, et al. Standards Track [Page 9] + +RFC 7852 Additional Call Data July 2016 + + + Description: A jurisdiction-specific code for, or the fully + qualified domain name of, the access network provider or service + provider shown in the <DataProvidedBy> element that created the + structure. NOTE: The value SHOULD be assigned by an organization + appropriate for the jurisdiction. In the United States, if the + provider is registered with NENA, the provider's NENA Company ID + MUST appear here. Additional information can be found at the + National Emergency Number Association (NENA) Company Identifier + Program <http://www.nena.org/?page=cid2014> or the NENA Company ID + <http://www.nena.org/?page=CompanyID>. The NENA Company ID MUST + be in the form of a URI in the following format: + urn:nena:companyid:<NENA Company ID>. If the organization does + not have an identifier registered with a jurisdiction-specific + emergency services registrar (such as NENA), then the value MAY be + the fully qualified domain name of the service provider or access + provider. The device MAY use its IP address or fully qualified + domain name (and set the 'Data Provider ID Series' element to + 'domain'). + + Reason for Need: Inform the call taker of the identity of the entity + providing the data. + + How Used by Call Taker: Where jurisdictions have lists of providers, + the Data Provider ID provides useful information about the data + source. The Data Provider ID uniquely identifies the source of + the data, which might be needed especially during unusual + circumstances and for routine logging. + +4.1.3. Data Provider ID Series + + Data Element: Data Provider ID Series + + Use: Conditional. Optional for blocks supplied by the originating + device; mandatory otherwise. + + XML Element: <ProviderIDSeries> + + Description: Identifies the issuer of the <ProviderID>. The + "Provider ID Series" registry created in Section 11.1.1 initially + contains the entries shown in Figure 1. + + Reason for Need: Identifies how to interpret the Data Provider ID. + The combination of ProviderIDSeries and ProviderID MUST be + globally unique. + + How Used by Call Taker: Determines which provider ID registry to + consult for more information. + + + + +Gellens, et al. Standards Track [Page 10] + +RFC 7852 Additional Call Data July 2016 + + + +-----------+--------------------------+----------------------+ + | Name | Source | URL | + +-----------+--------------------------+----------------------+ + | NENA | National Emergency | http://www.nena.org | + | | Number Association | | + | | | | + | EENA | European Emergency | http://www.eena.org | + | | Number Association | | + | | | | + | domain | (The ID is a fully | (not applicable) | + | | qualified domain name) | | + +-----------+--------------------------+----------------------+ + + Figure 1: Provider ID Series Registry + +4.1.4. Type of Data Provider + + Data Element: Type of Data Provider + + Use: Required + + XML Element: <TypeOfProvider> + + Description: Identifies the type of data provider supplying the + data. The registry containing all valid values is created in + Section 11.1.5, and the initial set of values is shown in + Figure 2. + + Reason for Need: Identifies the category of data provider. + + How Used by Call Taker: This information can be helpful when + deciding whom to contact when further information is needed. + + + + + + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 11] + +RFC 7852 Additional Call Data July 2016 + + + +------------------------------+------------------------------------+ + | Token | Description | + +------------------------------+------------------------------------+ + |Client | Originating client/device | + | | | + |Access Network Provider | Access network service provider | + | | | + |Telecom Provider | Telecom service provider (including| + | | native and over-the-top VoIP | + | | services) | + | | | + |Telematics Provider | A sensor-based service provider, | + | | especially vehicle based | + | | | + |Language Translation Provider | A spoken language translation | + | | service | + | | | + |Emergency Service Provider | An emergency service provider | + | | conveying information to another| + | | emergency service provider | + | | | + |Emergency Modality Translation| An emergency-call-specific | + | | modality translation service, | + | | e.g., for sign language | + | | | + |Relay Provider | An interpretation service, e.g., | + | | video relay for sign language | + | | interpretation | + | | | + |Other | Any other type of service provider | + +------------------------------+------------------------------------+ + + Figure 2: Type of Data Provider Registry + +4.1.5. Data Provider Contact URI + + Data Element: Data Provider Contact URI + + Use: Required + + XML Element: <ContactURI> + + Description: When provided by a service provider or an access + network provider, this information is expected to be a URI to a + 24/7 support organization tasked to provide PSAP support for this + emergency call. When provided by a device, this MUST be the + contact information of the user or owner of the device. (Ideally, + this is the contact information of the device user, but when the + + + +Gellens, et al. Standards Track [Page 12] + +RFC 7852 Additional Call Data July 2016 + + + owner and user are separate (e.g., the device owner is an + organization), this MAY be the contact information of the owner.) + The Data Provider Contact URI SHOULD be a tel URI [RFC3966] in + E.164 format and fully specified with a country code. If a tel + URI is not available, a generic SIP URI is acceptable. Note that + this contact information is not used by PSAPs for callbacks (a + call from a PSAP directly related to a recently terminated + emergency call, placed by the PSAP using a SIP Priority header + field set to 'psap-callback', as described in [RFC7090]). + + Reason for Need: Additional data providers might need to be + contacted in error cases or other unusual circumstances. + + How Used by Call Taker: To contact the supplier of the additional + data for assistance in handling the call. + +4.1.6. Data Provider Language(s) Supported + + Data Element: Data Provider Language(s) supported + + Use: Required + + XML Element: <Language> + + Description: This field encodes the language used by the entity at + the Data Provider Contact URI. The content of this field consists + of a single token from the Language Subtag Registry, which can be + found at [LanguageSubtagRegistry], and is defined in [RFC5646]. + Multiple instances of this element MAY occur, but the order is + significant and the preferred language SHOULD appear first. The + content MUST reflect the languages supported at the contact URI. + + (Note that this field informs the PSAP of the language(s) used by + the data provider. If the PSAP needs to contact the data + provider, it can be helpful to know in advance the language(s) + used by the data provider. If the PSAP uses a communication + protocol to reach the data provider, that protocol might have + language facilities of its own (such as the 'language' media + feature tag, defined in RFC 3840 [RFC3840], and the more extensive + language negotiation mechanism proposed in [HUMAN-LANG]), and if + so, those are independent of this field.) + + Reason for Need: This information indicates if the emergency service + authority can directly communicate with the service provider or if + an interpreter will be needed. + + + + + + +Gellens, et al. Standards Track [Page 13] + +RFC 7852 Additional Call Data July 2016 + + + How Used by Call Taker: If the call taker cannot speak any language + supported by the service provider, a translation service will need + to be added to the conversation. Alternatively, other persons at + the PSAP, besides the call taker, might be consulted for help + (depending on the urgency and the type of interaction). + +4.1.7. xCard of Data Provider + + Data Element: xCard of Data Provider + + Use: Optional + + XML Element: <DataProviderContact> + + Description: Per [RFC6351], the xCard structure is represented + within a <vcard> element. Although multiple <vcard> elements can + be contained in a structure, only one <vcard> element SHOULD be + provided. If more than one appears, the first SHOULD be used. + There are many fields in the xCard, and the creator of the data + structure is encouraged to provide all available information. N, + ORG, ADR, TEL, and EMAIL are suggested at a minimum. N SHOULD + contain the name of the support group or device owner as + appropriate. If more than one TEL property is provided, a + parameter from the "vCard Property Values" registry SHOULD be + specified for each TEL. For encoding of the vCard, this + specification uses the XML-based encoding specified in [RFC6351], + which is referred to in this document as 'xCard'. + + Reason for Need: Information needed to determine additional contact + information. + + How Used by Call Taker: Assists the call taker by providing + additional contact information aside from what is included in the + SIP INVITE or the PIDF-LO. + +4.1.8. Subcontractor Principal + + When the entity providing the data is a subcontractor, the Data + Provider Type is set to that of the primary service provider, and + this entry is supplied to provide information regarding the + subcontracting entity. + + Data Element: Subcontractor Principal + + Use: Conditional. This data is required if the entity providing the + data is a subcontractor. + + XML Element: <SubcontractorPrincipal> + + + +Gellens, et al. Standards Track [Page 14] + +RFC 7852 Additional Call Data July 2016 + + + Description: Some providers outsource their obligations to handle + aspects of emergency services to specialized providers. If the + data provider is a subcontractor to another provider, this element + contains the DataProviderString of the service provider to + indicate which provider the subcontractor is working for. + + Reason for Need: Identify the entity the subcontractor works for. + + How Used by Call Taker: Allows the call taker to understand what the + relationship is between data providers and the service providers + in the path of the call. + +4.1.9. Subcontractor Priority + + Data Element: Subcontractor Priority + + Use: Conditional. This data is required if the entity providing the + data is a subcontractor. + + XML Element: <SubcontractorPriority> + + Description: If the subcontractor is supposed to be contacted first, + then this element MUST have the value 'sub'. If the provider the + subcontractor is working for is supposed to be contacted first, + then this element MUST have the value 'main'. + + Reason for Need: Inform the call taker whom to contact first, if + support is needed. + + How Used by Call Taker: To decide which entity to contact first if + assistance is needed. + +4.1.10. ProviderInfo Example + + <?xml version="1.0" encoding="UTF-8"?> + <ad:EmergencyCallData.ProviderInfo + xmlns:ad="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> + <ad:DataProviderReference>string0987654321@example.org + </ad:DataProviderReference> + <ad:DataProviderString>Example VoIP Provider + </ad:DataProviderString> + <ad:ProviderID>urn:nena:companyid:ID123</ad:ProviderID> + <ad:ProviderIDSeries>NENA</ad:ProviderIDSeries> + <ad:TypeOfProvider>Telecom Provider</ad:TypeOfProvider> + <ad:ContactURI>tel:+1-201-555-0123</ad:ContactURI> + <ad:Language>en</ad:Language> + <ad:DataProviderContact + xmlns="urn:ietf:params:xml:ns:vcard-4.0"> + + + +Gellens, et al. Standards Track [Page 15] + +RFC 7852 Additional Call Data July 2016 + + + <vcard> + <fn><text>Hannes Tschofenig</text></fn> + <n> + <surname>Hannes</surname> + <given>Tschofenig</given> + <additional/> + <prefix/> + <suffix>Dipl. Ing.</suffix> + </n> + <bday><date>--0203</date></bday> + <anniversary> + <date-time>20090808T1430-0500</date-time> + </anniversary> + <gender><sex>M</sex></gender> + <lang> + <parameters><pref><integer>1</integer></pref> + </parameters> + <language-tag>de</language-tag> + </lang> + <lang> + <parameters><pref><integer>2</integer></pref> + </parameters> + <language-tag>en</language-tag> + </lang> + <org> + <parameters><type><text>work</text></type> + </parameters> + <text>Example VoIP Provider</text> + </org> + <adr> + <parameters> + <type><text>work</text></type> + <label><text>Hannes Tschofenig + Linnoitustie 6 + Espoo , Finland + 02600</text></label> + </parameters> + <pobox/> + <ext/> + <street>Linnoitustie 6</street> + <locality>Espoo</locality> + <region>Uusimaa</region> + <code>02600</code> + <country>Finland</country> + </adr> + <tel> + <parameters> + <type> + + + +Gellens, et al. Standards Track [Page 16] + +RFC 7852 Additional Call Data July 2016 + + + <text>work</text> + <text>voice</text> + </type> + </parameters> + <uri>tel:+358 50 4871445</uri> + </tel> + <tel> + <parameters> + <type> + <text>work</text> + <text>main-number</text> + <text>voice</text> + </type> + </parameters> + <uri>tel:+358 50 5050505</uri> + </tel> + <email> + <parameters><type><text>work</text></type> + </parameters> + <text>hannes.tschofenig@nsn.com</text> + </email> + <geo> + <parameters><type><text>work</text></type> + </parameters> + <uri>geo:60.210796,24.812924</uri> + </geo> + <key> + <parameters><type><text>home</text></type> + </parameters> + <uri> + http://www.example.com/key.asc + </uri> + </key> + <tz><text>Finland/Helsinki</text></tz> + <url> + <parameters><type><text>home</text></type> + </parameters> + <uri>http://www.tschofenig.priv.at</uri> + </url> + </vcard> + </ad:DataProviderContact> + </ad:EmergencyCallData.ProviderInfo> + + Figure 3: EmergencyCallData.ProviderInfo Example + + + + + + + +Gellens, et al. Standards Track [Page 17] + +RFC 7852 Additional Call Data July 2016 + + +4.2. Service Information + + This block describes the service that the service provider provides + to the caller. It SHOULD be included by all service providers in the + path of the call. The MIME media type is 'application/ + EmergencyCallData.ServiceInfo+xml'. + +4.2.1. Service Environment + + Data Element: Service Environment + + Use: Conditional. Required unless the 'ServiceType' value is + 'wireless'. + + XML Element: <ServiceEnvironment> + + Description: This element indicates whether a call is from a + business or residence. Currently, the only valid entries are + 'Business', 'Residence', and 'Unknown', as shown in Figure 4. New + values can be defined via the registry created in Section 11.1.2. + + Reason for Need: To provide context and a hint when determining + equipment and manpower requirements. + + How Used by Call Taker: Information can be used to provide context + and a hint to assist in determining equipment and manpower + requirements for emergency responders. This is non-authoritative; + there are situations where the service provider does not know the + type of service (e.g., anonymous prepaid service). The type of + service does not necessarily reflect the nature of the premises + (e.g., a business line installed in a residence or cellular + service). The registry does not contain all possible values for + all situations. Hence, this is at best advisory information, but + since it mimics a similar capability in some current emergency + calling systems (e.g., a field in the Automatic Location + Information (ALI) used with legacy North American wireline + systems), it is known to be valuable to PSAPs. The service + provider uses its best information (such as a rate plan, + facilities used to deliver service, or a service description) to + determine the information and is not responsible for determining + the actual characteristics of the location from which the call + originated. Because the usefulness is unknown (and less clear) + for cellular, this element is OPTIONAL for commercial mobile radio + services (e.g., cellular) and REQUIRED otherwise. + + + + + + + +Gellens, et al. Standards Track [Page 18] + +RFC 7852 Additional Call Data July 2016 + + + +-----------+--------------------------+ + | Token | Description | + +-----------+--------------------------+ + | Business | Business service | + | | | + | Residence | Residential service | + | | | + | Unknown | Type of service unknown | + | | (e.g., anonymous pre- | + | | paid service) | + +-----------+--------------------------+ + + Figure 4: Service Environment Registry + +4.2.2. Service Type + + Data Element: Service Delivered by Provider to End User + + Use: Required + + XML Element: <ServiceType> + + Description: This defines the type of service over which the call is + placed (similar to the Class of Service delivered with legacy + emergency calls in some regions). The implied mobility of this + service cannot be relied upon. A registry is created in + Section 11.1.3. The initial set of values is shown in Figure 5. + More than one value MAY be returned. For example, a VoIP inmate + telephone service is a reasonable combination. + + Reason for Need: Knowing the type of service can assist the PSAP in + the handling of the call. + + How Used by Call Taker: Call takers often use this information to + determine what kinds of questions to ask callers and how much to + rely on supportive information. As the information is not always + available, and the registry is not all encompassing, this is at + best advisory information, but since it mimics a similar + capability in some legacy emergency calling systems, it is known + to be valuable. + + +--------------+------------------------------------------+ + | Name | Description | + +--------------+------------------------------------------+ + | wireless | Wireless Telephone Service: Includes | + | | CDMA, GSM, Wi-Fi, WiMAX, and LTE | + | | (but not satellite) | + | | | + + + +Gellens, et al. Standards Track [Page 19] + +RFC 7852 Additional Call Data July 2016 + + + | coin | Fixed public pay/coin telephones: Any | + | | device operated by coin or credit card | + | | | + | one-way | One-way outbound service | + | | | + | temp | Soft dial tone/quick service/warm | + | | disconnect/suspended | + | | | + | MLTS-hosted | Hosted multi-line telephone system | + | | such as Centrex | + | | | + | MLTS-local | Local multi-line telephone system, | + | | including all PBXs, key systems, and | + | | Shared Tenant Services | + | | | + | sensor- | These are devices that generate DATA | + | unattended | ONLY. This is a one-way information | + | | transmit without interactive media. | + | | | + | sensor- | Devices that are supported by a | + | attended | monitoring service provider or that | + | | are capable of supporting interactive | + | | media | + | | | + | POTS | Wireline: Plain Old Telephone Service | + | | | + | OTT | An over-the-top service that provides | + | | communication over arbitrary Internet | + | | access (fixed, nomadic, mobile) | + | | | + | digital | Wireline non-OTT digital phone service | + | | | + | OPX | Off-premise extension | + | | | + | relay | A service where a human third-party | + | | agent provides additional assistance. | + | | This includes sign language relay/ | + | | interpretation, telematics services | + | | that provide a human on the call, | + | | and similar services. | + +--------------+------------------------------------------+ + + Figure 5: Service Delivered by Provider to End User Registry + + The initial set of values has been collected from sources of + currently used systems, including [NENA-02-010], [nc911], [NANP], and + [LERG]. + + + + +Gellens, et al. Standards Track [Page 20] + +RFC 7852 Additional Call Data July 2016 + + +4.2.3. Service Mobility Environment + + Data Element: Service Mobility Environment + + Use: Required + + XML Element: <ServiceMobility> + + Description: This provides the service provider's view of the + mobility of the caller's device. As the service provider might + not know the characteristics of the actual device or access + network used, the value should be treated as advisory and not be + relied upon. A registry is created in Section 11.1.4 with the + initial valid entries shown in Figure 6. + + Reason for Need: Knowing the service provider's belief of mobility + can assist the PSAP with the handling of the call. + + How Used by Call Taker: To determine whether to assume the location + of the caller might change. + + +-----------+----------------------------+ + | Token | Description | + +-----------+----------------------------+ + | Mobile | The device is able to move | + | | at any time | + | | | + | Fixed | The device is not expected | + | | to move unless the | + | | service is relocated | + | | | + | Nomadic | The device is not expected | + | | to change its point of | + | | attachment while on a | + | | call | + | | | + | Unknown | No information is known | + | | about the service | + | | mobility environment for | + | | the device | + +-----------+----------------------------+ + + Figure 6: Service Mobility Registry + + + + + + + + +Gellens, et al. Standards Track [Page 21] + +RFC 7852 Additional Call Data July 2016 + + +4.2.4. EmergencyCallData.ServiceInfo Example + + <?xml version="1.0" encoding="UTF-8"?> + <svc:EmergencyCallData.ServiceInfo + xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"> + <svc:DataProviderReference>2468.IBOC.MLTS.1359@example.org + </svc:DataProviderReference> + <svc:ServiceEnvironment>Business</svc:ServiceEnvironment> + <svc:ServiceType>MLTS-hosted</svc:ServiceType> + <svc:ServiceMobility>Fixed</svc:ServiceMobility> + </svc:EmergencyCallData.ServiceInfo> + + Figure 7: EmergencyCallData.ServiceInfo Example + +4.3. Device Information + + This block provides information about the device used to place the + call. It SHOULD be provided by any service provider that knows what + device is being used and by the device itself. The MIME media type + is 'application/EmergencyCallData.DeviceInfo+xml'. + +4.3.1. Device Classification + + Data Element: Device Classification + + Use: Optional + + XML Element: <DeviceClassification> + + Description: This data element defines the kind of device making the + emergency call. If the device provides the data structure, the + device information SHOULD be provided. If the service provider + provides the structure and it knows what the device is, the + service provider SHOULD provide the device information. Often the + carrier does not know what the device is. It is possible to + receive two Device Information blocks: one provided by the device + and one from the service provider. This information describes the + device, not how it is being used. This data element defines the + kind of device making the emergency call. A registry is created + in Section 11.1.6 with the initial set of values as shown in + Figure 8. + + Reason for Need: The device classification implies the capability of + the calling device and assists in identifying the meaning of the + emergency call location information that is being presented. For + example, does the device require human intervention to initiate a + call, or is this call the result of programmed instructions? Does + the calling device have the ability to update location or + + + +Gellens, et al. Standards Track [Page 22] + +RFC 7852 Additional Call Data July 2016 + + + condition changes? Is this device interactive or a one-way + reporting device? + + How Used by Call Taker: Can provide the call taker context regarding + the caller, the capabilities of the calling device, or the + environment in which the device is being used and can assist in + understanding the location information and capabilities of the + calling device. For example, a cordless handset might be outside + or next door. + + +---------------+----------------------------------------+ + | Token | Description | + +---------------+----------------------------------------+ + |cordless | Cordless handset | + |fixed | Fixed phone | + |satellite | Satellite phone | + |sensor-fixed | Fixed (non-mobile) sensor/alarm device | + |desktop | Soft client on desktop PC | + |laptop | Soft client on laptop-type device | + |tablet | Soft client on tablet-type device | + |alarm-monitored| Alarm system | + |sensor-mobile | Mobile sensor device | + |aircraft | Aircraft telematics device | + |automobile | Automobile/cycle/off-road telematics | + |truck | Truck/construction telematics | + |farm | Farm equipment telematics | + |marine | Marine telematics | + |personal | Personal telematics device | + |feature-phone | Cellular feature phone (not smartphone)| + |smart-phone | Cellular smartphone (native) | + |smart-phone-app| Soft client app on smartphone | + |unknown-device | Soft client on unknown device type | + |game | Gaming console | + |text-only | Other text device | + |NA | Not Available | + +---------------+----------------------------------------+ + + Figure 8: Device Classification Registry Initial Values + +4.3.2. Device Manufacturer + + Data Element: Device Manufacturer + + Use: Optional + + XML Element: <DeviceMfgr> + + + + + +Gellens, et al. Standards Track [Page 23] + +RFC 7852 Additional Call Data July 2016 + + + Description: The plain language name of the manufacturer of the + device. + + Reason for Need: Used by PSAP management for post-mortem + investigation/resolution. + + How Used by Call Taker: Probably not used by the call taker but by + PSAP management. + +4.3.3. Device Model Number + + Data Element: Device Model Number + + Use: Optional + + XML Element: <DeviceModelNr> + + Description: Model number of the device. + + Reason for Need: Used by PSAP management for after-action + investigation/resolution. + + How Used by Call Taker: Probably not used by the call taker but by + PSAP management. + +4.3.4. Unique Device Identifier + + Data Element: Unique Device Identifier + + Use: Optional + + XML Element: <UniqueDeviceID> + + XML Attribute: <TypeOfDeviceID> + + Description: A string that identifies the specific device (or the + device's current Subscriber Identification Module (SIM)) making + the call or creating an event. Note that more than one + <UniqueDeviceID> can be present to supply more than one of the + identifying values. + + The <TypeOfDeviceID> attribute identifies the type of device + identifier. A registry is created in Section 11.1.7 with an + initial set of values shown in Figure 9. + + + + + + + +Gellens, et al. Standards Track [Page 24] + +RFC 7852 Additional Call Data July 2016 + + + Reason for Need: Uniquely identifies the device (or, in the case of + International Mobile Subscriber Identity (IMSI), a SIM), + independent of any signaling identifiers present in the call + signaling stream. + + How Used by Call Taker: Probably not used by the call taker; might + be used by PSAP management during an investigation. (For example, + if a PSAP experiences repeated false/accidental calls and there is + no callback number or it isn't usable, the PSAP might need to try + to track down the device using various means, e.g., contacting + service providers in the area.) In the case of handsets without + current service, it might be possible to determine who last had + service. Another example might be a disconnected call where the + call taker believes there is a need for assistance but was not + able to obtain a location or other information. + + Example: <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID> + + +--------+------------------------------------------+ + | Token | Description | + +--------+------------------------------------------+ + | MEID | Mobile Equipment Identifier (CDMA) | + | ESN | Electronic Serial Number (GSM) | + | MAC | Media Access Control Address (IEEE) | + | WiMAX | Device Certificate Unique ID | + | IMEI | International Mobile Equipment ID (GSM) | + | IMSI | International Mobile Subscriber ID (GSM) | + | UDI | Unique Device Identifier | + | RFID | Radio Frequency Identification | + | SN | Manufacturer Serial Number | + +--------+------------------------------------------+ + + Figure 9: Registry of Device Identifier Types + +4.3.5. Device/Service-Specific Additional Data Structure + + Data Element: Device/service-specific additional data structure + + Use: Optional + + XML Element: <DeviceSpecificData> + + Description: A URI representing additional data whose schema is + specific to the device or service that created it. (For example, + a medical device or medical device monitoring service might have a + defined set of medical data.) The URI, when dereferenced, MUST + yield a data structure defined by the device/service-specific + + + + +Gellens, et al. Standards Track [Page 25] + +RFC 7852 Additional Call Data July 2016 + + + additional data type value. Different data can be created by each + classification, e.g., a data set created by a medical device. + + Reason for Need: Provides device/service-specific data that can be + used by the call taker and/or responders. + + How Used by Call Taker: Provide information to guide call takers to + select appropriate responders, give appropriate pre-arrival + instructions to callers, and advise responders of what to be + prepared for. May be used by responders to guide assistance + provided. + +4.3.6. Device/Service-Specific Additional Data Structure Type + + Data Element: Type of device/service-specific additional data + structure + + Use: Conditional. MUST be provided when a device/service-specific + additional data URI is provided. + + XML Element: <DeviceSpecificType> + + Description: A value from the registry defined in Section 11.1.8 to + describe the type of data located at the device/service-specific + additional data structure. The initial values shown in Figure 10 + currently only include IEEE 1512, which is the United States + Department of Transportation (USDoT) model for traffic incidents. + + Reason for Need: This data element allows identification of + externally defined schemas, which might have additional data that + can assist in emergency response. + + How Used by Call Taker: This data element allows the end user (call + taker or first responder) to know what type of additional data is + available to aid in providing the needed emergency services. + + Note: This mechanism is not appropriate for information specific to + a location or a caller (person). + + +---------+---------------------------+--------------------------+ + | Token | Description | Specification | + +---------+---------------------------+--------------------------+ + |IEEE1512 |Common Incident Management | IEEE 1512-2006 | + | | Message Set (USDoT model | | + | | for traffic incidents) | | + +---------+---------------------------+--------------------------+ + + Figure 10: Device/Service Data Type Registry + + + +Gellens, et al. Standards Track [Page 26] + +RFC 7852 Additional Call Data July 2016 + + + The IEEE 1512-2006 specifications can be found at [IEEE-1512-2006]. + +4.3.7. EmergencyCallData.DeviceInfo Example + + <?xml version="1.0" encoding="UTF-8"?> + <dev:EmergencyCallData.DeviceInfo + xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> + <dev:DataProviderReference>d4b3072df.201409182208075@example.org + </dev:DataProviderReference> + <dev:DeviceClassification>fixed</dev:DeviceClassification> + <dev:DeviceMfgr>Nokia</dev:DeviceMfgr> + <dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr> + <dev:UniqueDeviceID TypeOfDeviceID="IMEI">35788104 + </dev:UniqueDeviceID> + </dev:EmergencyCallData.DeviceInfo> + + Figure 11: EmergencyCallData.DeviceInfo Example + +4.4. Owner/Subscriber Information + + This block describes the owner of the device (if provided by the + device) or the subscriber information (if provided by a service + provider). The contact location is not necessarily the location of + the caller or incident but is rather the nominal contact address. + The MIME media type is 'application/ + EmergencyCallData.SubscriberInfo+xml'. + + In some jurisdictions, some or all parts of the subscriber-specific + information are subject to privacy constraints. These constraints + vary but dictate which information can be displayed and logged. A + general privacy indicator expressing a desire for privacy by the + subscriber is provided. The interpretation of how this is applied is + left to the receiving jurisdiction as the custodians of the local + regulatory requirements. This matches an equivalent privacy flag + provided in some legacy emergency call systems. + +4.4.1. Subscriber Data Privacy Indicator + + Attribute: 'privacyRequested', Boolean. + + Use: Conditional. This attribute MUST be provided if the owner/ + subscriber information block is not empty. + + Description: The subscriber data privacy indicator specifically + expresses the subscriber's desire for privacy. In some + jurisdictions, subscriber services can have a specific "Type of + Service" that prohibits information, such as the name of the + subscriber, from being displayed. This attribute is provided to + + + +Gellens, et al. Standards Track [Page 27] + +RFC 7852 Additional Call Data July 2016 + + + explicitly indicate whether the subscriber service includes such + constraints. The interpretation of this indicator is left to each + jurisdiction (in keeping with the semantics of the privacy + indicator provided in some legacy emergency call systems). + Because the interpretation of this indicator varies based on local + regulations, this document cannot describe the exact semantics nor + indicate which fields are affected (the application of this + indicator might affect the display of data contained in any of the + blocks). + + Reason for Need: Some jurisdictions require subscriber privacy to be + observed when processing emergency calls. + + How Used by Call Taker: Where privacy is indicated, the call taker + might not have access to some aspects of the subscriber + information. + +4.4.2. xCard for Subscriber's Data + + Data Element: xCard for Subscriber's Data + + Use: Conditional. Subscriber data MUST be provided unless it is not + available. Some services, such as prepaid phones, non-initialized + phones, etc., do not have information about the subscriber. + + XML Element: <SubscriberData> + + Description: Information known by the service provider or device + about the subscriber, e.g., Name, Address, Individual Telephone + Number, Main Telephone Number, and any other data. <n>, <org> (if + appropriate), <adr>, <tel>, and <email> are suggested at a + minimum. If more than one <tel> property is provided, a parameter + from the "vCard Property Values" registry MUST be specified on + each <tel>. While some data (such as <anniversary>) might not + seem obviously relevant for emergency services, any data is + potentially useful in some emergency circumstances. + + Reason for Need: When the caller is unable to provide information, + this data can be used to obtain it. + + How Used by Call Taker: Obtaining critical information about the + caller and possibly the location when it is not able to be + obtained otherwise. While the location here is not necessarily + that of a caller, in some circumstances it can be helpful in + locating the caller when other means have failed. + + + + + + +Gellens, et al. Standards Track [Page 28] + +RFC 7852 Additional Call Data July 2016 + + +4.4.3. EmergencyCallData.SubscriberInfo Example + + <?xml version="1.0" encoding="UTF-8"?> + <sub:EmergencyCallData.SubscriberInfo + xmlns:sub= + "urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo" + privacyRequested="false"> + <sub:DataProviderReference>FEABFECD901@example.org + </sub:DataProviderReference> + <sub:SubscriberData xmlns="urn:ietf:params:xml:ns:vcard-4.0"> + <vcard> + <fn><text>Simon Perreault</text></fn> + <n> + <surname>Perreault</surname> + <given>Simon</given> + <additional/> + <prefix/> + <suffix>ing. jr</suffix> + <suffix>M.Sc.</suffix> + </n> + <bday><date>--0203</date></bday> + <anniversary> + <date-time>20090808T1430-0500</date-time> + </anniversary> + <gender><sex>M</sex></gender> + <lang> + <parameters><pref><integer>1</integer></pref> + </parameters> + <language-tag>fr</language-tag> + </lang> + <lang> + <parameters><pref><integer>2</integer></pref> + </parameters> + <language-tag>en</language-tag> + </lang> + <org> + <parameters><type><text>work</text></type> + </parameters> + <text>Viagenie</text> + </org> + <adr> + <parameters> + <type><text>work</text></type> + <label><text>Simon Perreault + 2875 boul. Laurier, suite D2-630 + Quebec, QC, Canada + G1V 2M2</text></label> + </parameters> + + + +Gellens, et al. Standards Track [Page 29] + +RFC 7852 Additional Call Data July 2016 + + + <pobox/> + <ext/> + <street>2875 boul. Laurier, + suite D2-630</street> + <locality>Quebec</locality> + <region>QC</region> + <code>G1V 2M2</code> + <country>Canada</country> + </adr> + <tel> + <parameters> + <type> + <text>work</text> + <text>voice</text> + </type> + </parameters> + <uri>tel:+1-418-656-9254;ext=102</uri> + </tel> + <tel> + <parameters> + <type> + <text>work</text> + <text>voice</text> + <text>main-number</text> + </type> + </parameters> + <uri>tel:+1-418-555-0000</uri> + </tel> + <tel> + <parameters> + <type> + <text>work</text> + <text>text</text> + <text>voice</text> + <text>cell</text> + <text>video</text> + </type> + </parameters> + <uri>tel:+1-418-262-6501</uri> + </tel> + <email> + <parameters><type><text>work</text></type> + </parameters> + <text>simon.perreault@viagenie.ca</text> + </email> + <geo> + <parameters><type><text>work</text></type> + </parameters> + + + +Gellens, et al. Standards Track [Page 30] + +RFC 7852 Additional Call Data July 2016 + + + <uri>geo:46.766336,-71.28955</uri> + </geo> + <key> + <parameters><type><text>work</text></type> + </parameters> + <uri> + http://www.viagenie.ca/simon.perreault/simon.asc + </uri> + </key> + <tz><text>America/Montreal</text></tz> + <url> + <parameters><type><text>home</text></type> + </parameters> + <uri>http://nomis80.org</uri> + </url> + </vcard> + </sub:SubscriberData> + </sub:EmergencyCallData.SubscriberInfo> + + Figure 12: EmergencyCallData.SubscriberInfo Example + +4.5. Comment + + This block provides a mechanism for the data provider to supply + extra, human-readable information to the PSAP. It is not intended + for a general purpose extension mechanism nor does it aim to provide + machine-readable content. The MIME media type is 'application/ + EmergencyCallData.Comment+xml'. + +4.5.1. Comment + + Data Element: EmergencyCallData.Comment + + Use: Optional + + XML Element: <Comment> + + Description: Human-readable text providing additional information to + the PSAP staff. + + Reason for Need: Explanatory information for values in the data + structure. + + How Used by Call Taker: To interpret the data provided. + + + + + + + +Gellens, et al. Standards Track [Page 31] + +RFC 7852 Additional Call Data July 2016 + + +4.5.2. EmergencyCallData.Comment Example + + <?xml version="1.0" encoding="UTF-8"?> + <com:EmergencyCallData.Comment + xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment"> + <com:DataProviderReference>string0987654321@example.org + </com:DataProviderReference> + <com:Comment xml:lang="en">This is an example text.</com:Comment> + </com:EmergencyCallData.Comment> + + Figure 13: EmergencyCallData.Comment Example + +5. Issues with Getting New Types of Data into Use + + This document describes two mechanisms that allow extension of the + kind of data provided with an emergency call: define a new block or + define a new device/service-specific additional data URL for the + DeviceInfo block (Section 4.3.5). While defining new data types and + getting a new device or application to send the new data might be + easy, getting PSAPs and responders to actually retrieve the data and + use it will be difficult. New mechanism providers should understand + that acquiring and using new forms of data usually require software + upgrades at the PSAP and/or responders, as well as training of call + takers and responders in how to interpret and use the information. + Legal and operational review might also be needed. Overwhelming a + call taker or responder with too much information is highly + discouraged. Thus, the barrier to supporting new data is quite high. + + The mechanisms this document describes are meant to encourage + development of widely supported, common data formats for classes of + devices. If all manufacturers of a class of device use the same + format, and the data can be shown to improve outcomes, then PSAPs and + responders can be encouraged to upgrade their systems and train their + staff to use the data. Variations, however well intentioned, are + unlikely to be supported. + + Implementors should consider that data from sensor-based devices in + some cases might not be useful to call takers or PSAPs (and privacy, + liability, or other considerations might preclude the PSAP from + accessing or handling the data) but might be of use to responders. + Each data item provided with the call in conformance with this + document can be accessed by responders or other entities in the + emergency services, whether or not the data is accessed by the PSAP. + + + + + + + + +Gellens, et al. Standards Track [Page 32] + +RFC 7852 Additional Call Data July 2016 + + +5.1. Choosing between Defining a New Type of Block or a New Type of + Device/Service-Specific Additional Data + + For devices that have device- or service-specific data, there are two + choices to carry it. A new block can be defined, or the device/ + service-specific additional data URL in the DeviceInfo block can be + used and a new type defined for it. The data passed would likely be + the same in either case. Considerations for choosing the mechanism + under which to register include: + + Applicability: Information that will be supported by many kinds of + devices or services are more appropriately defined as separate + blocks. + + Privacy: Information sent as a device/service-specific additional + data URL in the DeviceInfo block is by reference (not by value), + which inherently provides some additional privacy protection + (since the requester needs to supply a certificate which is + verified by the supplier). + + Size: Information that can be very large might be better sent in the + DeviceInfo block, rather than in a new block, so that + implementations are unable to send the data by value. Conversely, + data that is small might best be sent in a separate block so that + it can be sent by value. + + Availability of a server: Providing the data via the DeviceInfo + block requires that a server be available from which to retrieve + the data. Providing the data via a new block allows it to be sent + by value. + +6. Data Transport Mechanisms + + This section defines how to convey additional data to an emergency + service provider. Two different means are specified: the first uses + call signaling; the second uses the <provided-by> element of a PIDF- + LO [RFC4119]. + + 1. First, the ability to embed a Uniform Resource Identifier (URI) + in an existing SIP header field, the Call-Info header field, is + defined. The URI points to the additional data structure. The + Call-Info header field is specified in Section 20.9 of [RFC3261]. + + This document adds a new compound token starting with the value + 'EmergencyCallData' for the Call-Info 'purpose' parameter. If + the 'purpose' parameter is set to a value starting with + 'EmergencyCallData', then the Call-Info header field contains + either an HTTPS URL pointing to an external resource or a Content + + + +Gellens, et al. Standards Track [Page 33] + +RFC 7852 Additional Call Data July 2016 + + + Indirection (CID) URI that allows the data structure to be placed + in the body of the SIP message. The 'purpose' parameter also + indicates the kind of data (by its MIME media subtype) that is + available at the URI. + + As the data is conveyed using a URI in the SIP signaling, the + data itself can reside on an external resource or can be + contained within the body of the SIP message. When the URI + refers to data at an external resource, the data is said to be + passed by reference. When the URI refers to data contained + within the body of the SIP message, the data is said to be passed + by value. A PSAP or emergency responder is able to examine the + type of data provided and selectively access the data it is + interested in, while forwarding all of it (the values or + references) to downstream entities. + + To be conveyed in a SIP body, additional data about a call is + defined as a series of MIME objects (also referred to as a + "block" of data). Each block defined in this document is an XML + data structure identified by its MIME media type. (Blocks + defined by others can be encoded in XML or not, as identified by + their MIME registration.) As usual, whenever more than one MIME + part is included in the body of a message, MIME multipart (i.e., + 'multipart/mixed') encloses them all. + + This document defines a set of XML schemas and MIME media types + used for each block defined here. When additional data is passed + by value in the SIP signaling, each CID URL points to one block + in the body. Multiple URIs are used within a Call-Info header + field (or multiple Call-Info header fields) to point to multiple + blocks. When additional data is provided by reference (in SIP + signaling or the <provided-by> element of a PIDF-LO), each HTTPS + URL references one block; the data is retrieved with an HTTPS GET + operation, which returns the block as an object (the blocks + defined here are returned as XML objects). + + 2. Second, the ability to embed additional data structures in the + <provided-by> element of a PIDF-LO [RFC4119] is defined. + + In addition to service providers in the call path, the access + network provider generally has similar information that can be + valuable to the PSAP. When the access network provider and + service provider are separate entities, the access network does + not participate in the application-layer signaling (and hence + cannot add a Call-Info header field to the SIP message) but can + provide location information in a PIDF-LO. When the access + network provider supplies location information in the form of a + PIDF-LO from a location server via a location configuration + + + +Gellens, et al. Standards Track [Page 34] + +RFC 7852 Additional Call Data July 2016 + + + protocol, it has the ability to add the data structures defined + in this document (or references to them) within the PIDF-LO. + + The data in these data structures is not specific to the location + itself, but rather provides descriptive information having to do + with the immediate circumstances about the provider's provision + of the location (e.g., the identity of the access network + provider, how to contact that entity, what kind of service the + access network provides, subscriber information, etc.). This + data is similar in nearly every respect to the data known by + service providers in the path of the call. The <provided-by> + element of the PIDF-LO is a mechanism for the access network + provider to supply the information. This document describes a + namespace per [RFC4119] for inclusion in the <provided-by> + element of a PIDF-LO for adding information known to the access + network provider. The access network provider SHOULD provide + additional data within a <provided-by> element of a PIDF-LO it + returns for emergency use (e.g., if requested with an HTTP- + Enabled Location Delivery (HELD) 'responseTime' attribute of + 'emergencyRouting' or 'emergencyDispatch' [RFC5985]). + + One or more blocks of data registered in the "Emergency Call + Additional Data" registry, as defined in Section 11.1.9, can be + included or referenced in the SIP signaling (using the Call-Info + header field) or in the <provided-by> element of a PIDF-LO. For + interoperability, only blocks in the registry are permitted to be + sent using the mechanisms specified in this document. Since multiple + entities are expected to provide sets of data, the data itself needs + information describing the source. Consequently, each entity adding + additional data MUST supply a 'Data Provider' block. All other + blocks are optional, but each entity SHOULD supply all blocks where + it has at least some of the information in the block. + + Note that, as with any mechanism, failures are possible. For + example, a block (provided by value or by reference) might not be the + type indicated by the 'purpose' parameter, or might be badly formed, + etc. The general principle that applies to emergency calls is that + it is more important for the call to go through than for everything + to be correct. Thus, most PSAPs will process a call if at all + possible, even if data is missing or other failures occur. + + + + + + + + + + + +Gellens, et al. Standards Track [Page 35] + +RFC 7852 Additional Call Data July 2016 + + +6.1. Transmitting Blocks Using Call-Info + + A URI to a block MAY be inserted in any SIP request or response + method (most often INVITE or MESSAGE), using a Call-Info header field + containing a 'purpose' value starting with 'EmergencyCallData', a dot + ('.'), and the type of data available at the URI. The type of data + is denoted by including the root of the MIME media subtype (the + 'EmergencyCallData' prefix is not repeated), omitting any suffix such + as '+xml'. For example, when referencing a block with MIME media + type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' + parameter is set to 'EmergencyCallData.ProviderInfo'. An example + Call-Info header field for this would be: + + Call-Info: https://www.example.com/23sedde3; + purpose="EmergencyCallData.ProviderInfo" + + A Call-Info header field with a 'purpose' value starting with + 'EmergencyCallData' only has meaning in the context of an emergency + call (as ascertained by the presence of an emergency service URN in a + Request-URI header field of a SIP message), test emergency calls + (using an appropriate service URN), and some private-use calls where + the endpoints have a preexisting relationship and privacy concerns do + not apply because of the relationship; use in other contexts is + undefined and is likely to unnecessarily expose confidential data. + + If the data is provided by reference, an HTTPS URI MUST be included, + and consequently, Transport Layer Security (TLS) protection is used + during the retrieval of the information. + + The data can also be supplied by value in any SIP request or response + method that is permitted to contain a body (i.e., not a BYE request) + [RFC3261]. In this case, CID [RFC2392] is used, with the CID URL + referencing the MIME body part containing the data. Note that + [RFC3261] forbids proxies from altering message bodies, so entities + in the call path that add blocks by value need to do so using an + appropriate SIP entity (e.g., a back-to-back user agent). + + Transmitting data by value is especially useful in certain cases, + such as when the data exists in or is generated by the originating + device but is not intended for very large data blocks. Additional + security and privacy considerations apply to data transmitted by + value, as discussed in Sections 9 and 10, respectively. + + More than one Call-Info header field with a 'purpose' value starting + with 'EmergencyCallData' can be expected, but at least one MUST be + provided. The device MUST provide one unless it knows that a service + provider is in the path of the call. The device MAY insert one if it + uses a service provider. Each service provider in the path of an + + + +Gellens, et al. Standards Track [Page 36] + +RFC 7852 Additional Call Data July 2016 + + + emergency call MUST insert its own. For example, a device, a + telematics service provider in the call path, as well as the mobile + carrier handling the call will each provide one. There might be + circumstances where there is a service provider who is unaware that + the call is an emergency call and cannot reasonably be expected to + determine that it is an emergency call. In that case, that service + provider is not expected to provide EmergencyCallData. + + When blocks are transmitted by value, the 'purpose' parameter in a + Call-Info header field identifies the data, and the CID URL points to + the data block in the body (which has a matching Content-ID body part + header field). When a data block is carried in a signed or encrypted + body part, the enclosing multipart (e.g., 'multipart/signed' or + 'multipart/encrypted') has the same Content-ID as the data part. + This allows an entity to identify and access the data blocks it is + interested in without having to dive deeply into the message + structure or decrypt parts it is not interested in. + +6.2. Transmitting Blocks by Reference Using the <provided-by> Element + + The <EmergencyCallDataReference> element is used to transmit an + additional data block by reference within a <provided-by> element of + a PIDF-LO. The <EmergencyCallDataReference> element has two + attributes: 'ref' to specify the URL and 'purpose' to indicate the + type of data block referenced. The value of 'ref' is an HTTPS URL + that resolves to a data structure with information about the call. + The value of 'purpose' is the same as used in a Call-Info header + field (as specified in Section 6.1). + + For example, to reference a block with MIME media type 'application/ + EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set + to 'EmergencyCallData.ProviderInfo'. An example + <EmergencyCallDataReference> element for this would be: + + <EmergencyCallDataReference ref="https://www.example.com/23sedde3" + purpose="EmergencyCallData.ProviderInfo"/> + + The <EmergencyCallDataReference> element transmits one data block; + multiple data blocks are transmitted by using multiple + <EmergencyCallDataReference> elements. Multiple + <EmergencyCallDataReference> elements MAY be included as child + elements inside the <provided-by> element. + + + + + + + + + +Gellens, et al. Standards Track [Page 37] + +RFC 7852 Additional Call Data July 2016 + + + The following is a simplified example: + + <provided-by> + <EmergencyCallDataReference + purpose="EmergencyCallData.ServiceInfo" + ref="https://example.com/ref2" /> + + <EmergencyCallDataReference + purpose="EmergencyCallData.ProviderInfo" + ref="https://example.com/ref3" /> + + <EmergencyCallDataReference + purpose="EmergencyCallData.Comment" + ref="https://example.com/ref4" /> + </provided-by> + + Example <provided-by> by Reference + + For an example in context, Figure 18 shows a PIDF-LO example with an + <EmergencyCallDataReference> element pointing to an + EmergencyCallData.ServiceInfo data block with the URL in the 'ref' + attribute and the 'purpose' attribute set to + 'EmergencyCallData.ServiceInfo'. + +6.3. Transmitting Blocks by Value Using the <provided-by> Element + + It is RECOMMENDED that access networks supply the data specified in + this document by reference, because PIDF-LOs can be fetched by a + client or other entity and stored locally, so providing the data by + value risks exposing private information to a larger audience. + + The <EmergencyCallDataValue> element is used to transmit one or more + additional data blocks by value within a <provided-by> element of a + PIDF-LO. Each block being transmitted is placed (as a child element) + inside the <EmergencyCallDataValue> element. (The same XML structure + as would be contained in the corresponding MIME media type body part + is placed inside the <EmergencyCallDataValue> element.) Multiple + <EmergencyCallDataValue> elements MAY be included as child elements + in the <provided-by> element. + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 38] + +RFC 7852 Additional Call Data July 2016 + + + The following is a simplified example: + + <provided-by> + + <EmergencyCallDataValue> + + <EmergencyCallData.ProviderInfo + xmlns= + "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> + <DataProviderReference>flurbit735@es.example.com + </DataProviderReference> + <DataProviderString>Access Network Examples, Inc. + </DataProviderString> + <ProviderID>urn:nena:companyid:Test</ProviderID> + <ProviderIDSeries>NENA</ProviderIDSeries> + <TypeOfProvider>Access Network Provider + </TypeOfProvider> + <ContactURI>tel:+1-555-555-0897</ContactURI> + <Language>en</Language> + </EmergencyCallData.ProviderInfo> + + <EmergencyCallData.Comment + xmlns= + "urn:ietf:params:xml:ns:EmergencyCallData:Comment"> + <DataProviderReference>flurbit735@es.example.com + </DataProviderReference> + <Comment xml:lang="en">This is an example text. + </Comment> + </EmergencyCallData.Comment> + + </EmergencyCallDataValue> + + </provided-by> + + Example <provided-by> by Value + + For an example in context, Figure 18 shows a PIDF-LO example that + contains a <provided-by> element with the + <EmergencyCallData.ProviderInfo> and the <EmergencyCallData.Comment> + elements as child elements of an <EmergencyCallDataValue> element. + +6.4. The Content-Disposition Parameter + + RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. + It updates and clarifies handling originally defined in RFC 3261 + [RFC3261] based on implementation experience. While RFC 3261 did not + mandate support for 'multipart' message bodies, 'multipart/mixed' + MIME bodies are used by many extensions (including this document) + + + +Gellens, et al. Standards Track [Page 39] + +RFC 7852 Additional Call Data July 2016 + + + today. For example, adding a PIDF-LO, a Session Description Protocol + (SDP), and additional data in the body of a SIP message requires a + 'multipart' message body. + + RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' + parameter for the Content-Disposition header field. These RFCs + describe how a User Agent Server (UAS) reacts if it receives a + message body whose content type or disposition type it does not + understand. If the 'handling' parameter has the value 'optional', + the UAS ignores the message body. If the 'handling' parameter has + the value 'required', the UAS returns a 415 (Unsupported Media Type) + response. The 'by-reference' disposition type of RFC 5621 [RFC5621] + allows a SIP message to contain a reference to the body part, and the + SIP User Agent (UA) processes the body part according to the + reference. This is the case for a Call-Info header field containing + a CID URL. + + As an example, a SIP message indicates the 'Content-Disposition' + parameter in the body of the SIP message as shown in Figure 14. + + Content-Type: application/sdp + ...Omit Content-Disposition here; defaults are ok + + ...SDP goes in here + + --boundary1 + Content-Type: application/pidf+xml + Content-ID: <target123@atlanta.example.com> + Content-Disposition: by-reference;handling=optional + + ...PIDF-LO goes in here + + --boundary1 + Content-Type: application/EmergencyCallData.ProviderInfo+xml + Content-ID: <1234567890@atlanta.example.com> + Content-Disposition: by-reference; handling=optional + + ...Data provider information data goes in here + + --boundary1-- + + Figure 14: Example for Use of the Content-Disposition Parameter + in SIP + + + + + + + + +Gellens, et al. Standards Track [Page 40] + +RFC 7852 Additional Call Data July 2016 + + +7. Examples + + This section illustrates a longer and more complex example, as shown + in Figure 15. In this example, additional data is added by the end + device, included by the VoIP provider, and provided by the access + network provider (via the PIDF-LO). + + O +----+ [============] [=============] + /|\ | UA | [ Access ] [ VoIP ] + | +----+ [ Network ] [ Provider ] + / \ [ Provider ] [ example.org ] + [ ] [ ] + (1) [ ] (2) [ ] + Emergency Call [ ] Emergency Call [ ] + ------------------------------------------------------> ] + +Device Info [ ] +Device Info [ ] + +Data Prov. Info [ ^ ] +Data Provider Info [ | ] + +Location URI [=======.====] +Location URI [====|========] + . | + . | + +Location . [==============] | + +Owner/Subscriber Info . [ ] (3) | + +Device Info . (4) [ <------------+ + +Data Provider Info #3 ..........> ] Emergency Call + [ ] +Device Info + [ PSAP ] +Data Prov. Info #2 + [ ] +Location URI + [==============] + + + Legend: + + --- Emergency Call Setup Procedure + ... Location Retrieval/Response + + Figure 15: Additional Data Example Flow + + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 41] + +RFC 7852 Additional Call Data July 2016 + + + The example scenario starts with the end device itself adding device + information, owner/subscriber information, a location URI, and data + provider information to the outgoing emergency call setup message + (see step #1 in Figure 15). The SIP INVITE example is shown in + Figure 16. + + INVITE urn:service:sos SIP/2.0 + Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 + Max-Forwards: 70 + To: <urn:service:sos> + From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl + Call-ID: 3848276298220188511@example.com + Call-Info: <http://wwww.example.com/hannes/photo.jpg> + ;purpose=icon, + <http://www.example.com/hannes/> ;purpose=info, + <cid:1234567890@atlanta.example.com> + ;purpose=EmergencyCallData.ProviderInfo, + <cid:0123456789@atlanta.example.com> + ;purpose=EmergencyCallData.DeviceInfo + Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o> + Geolocation-Routing: yes + Accept: application/sdp, application/pidf+xml, + application/EmergencyCallData.ProviderInfo+xml + CSeq: 31862 INVITE + Contact: <sips:hannes@example.com> + Content-Type: multipart/mixed; boundary=boundary1 + Content-Length: ... + + --boundary1 + Content-Type: application/sdp + + ...SDP goes here + + --boundary1 + Content-Type: application/EmergencyCallData.DeviceInfo+xml + Content-ID: <0123456789@atlanta.example.com> + Content-Disposition: by-reference;handling=optional + + <?xml version="1.0" encoding="UTF-8"?> + <dev:EmergencyCallData.DeviceInfo + xmlns:dev= + "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> + <dev:DataProviderReference> + d4b3072df09876543@[93.184.216.119] + </dev:DataProviderReference> + <dev:DeviceClassification>laptop</dev:DeviceClassification> + <dev:UniqueDeviceID + TypeOfDeviceID="MAC">00-0d-4b-30-72-df + + + +Gellens, et al. Standards Track [Page 42] + +RFC 7852 Additional Call Data July 2016 + + + </dev:UniqueDeviceID> + </dev:EmergencyCallData.DeviceInfo> + + --boundary1 + Content-Type: application/EmergencyCallData.ProviderInfo+xml + Content-ID: <1234567890@atlanta.example.com> + Content-Disposition: by-reference;handling=optional + + <?xml version="1.0" encoding="UTF-8"?> + <pi:EmergencyCallData.ProviderInfo + xmlns:pi= + "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> + <pi:DataProviderReference>d4b3072df09876543@[93.184.216.119] + </pi:DataProviderReference> + <pi:DataProviderString>Hannes Tschofenig</pi:DataProviderString> + <pi:TypeOfProvider>Client</pi:TypeOfProvider> + <pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI> + <pi:Language>en</pi:Language> + <pi:DataProviderContact + xmlns="urn:ietf:params:xml:ns:vcard-4.0"> + <vcard> + <fn><text>Hannes Tschofenig</text></fn> + <n> + <surname>Hannes</surname> + <given>Tschofenig</given> + <additional/> + <prefix/> + <suffix>Dipl. Ing.</suffix> + </n> + <bday><date>--0203</date></bday> + <anniversary> + <date-time>20090808T1430-0500</date-time> + </anniversary> + <gender><sex>M</sex></gender> + <lang> + <parameters><pref><integer>1</integer></pref> + </parameters> + <language-tag>de</language-tag> + </lang> + <lang> + <parameters><pref><integer>2</integer></pref> + </parameters> + <language-tag>en</language-tag> + </lang> + <adr> + <parameters> + <type><text>work</text></type> + <label><text>Hannes Tschofenig + + + +Gellens, et al. Standards Track [Page 43] + +RFC 7852 Additional Call Data July 2016 + + + Linnoitustie 6 + Espoo, Finland + 02600</text></label> + </parameters> + <pobox/> + <ext/> + <street>Linnoitustie 6</street> + <locality>Espoo</locality> + <region>Uusimaa</region> + <code>02600</code> + <country>Finland</country> + </adr> + <adr> + <parameters> + <type><text>home</text></type> + <label><text>Hannes Tschofenig + c/o Hotel DuPont + 42 W 11th St + Wilmington, DE 19801 + USA</text></label> + </parameters> + <pobox/> + <ext/> + <street>42 W 11th St</street> + <locality>Wilmington</locality> + <region>DE</region> + <code>19801</code> + <country>USA</country> + </adr> + <tel> + <parameters> + <type> + <text>work</text> + <text>voice</text> + </type> + </parameters> + <uri>tel:+358 50 4871445</uri> + </tel> + <tel> + <parameters> + <type> + <text>home</text> + <text>voice</text> + </type> + </parameters> + <uri>tel:+1-555-555-0123</uri> + </tel> + <tel> + + + +Gellens, et al. Standards Track [Page 44] + +RFC 7852 Additional Call Data July 2016 + + + <parameters> + <type> + <text>work</text> + <text>voice</text> + <text>main-number</text> + </type> + </parameters> + <uri>tel:+1-302-594-3100</uri> + </tel> + <email> + <parameters><type><text>work</text></type> + </parameters> + <text>hannes.tschofenig@nsn.com</text> + </email> + <geo> + <parameters><type><text>work</text></type> + </parameters> + <uri>geo:60.210796,24.812924</uri> + </geo> + <geo> + <parameters><type><text>home</text></type> + </parameters> + <uri>geo:39.746537,-75.548027</uri> + </geo> + <key> + <parameters> + <type><text>home</text></type> + </parameters> + <uri>https://www.example.com/key.asc</uri> + </key> + <tz><text>Finland/Helsinki</text></tz> + <url> + <parameters><type><text>home</text></type> + </parameters> + <uri>http://example.com/hannes.tschofenig + </uri> + </url> + </vcard> + </pi:DataProviderContact> + </pi:EmergencyCallData.ProviderInfo> + --boundary1-- + + Figure 16: End Device Sending SIP INVITE with Additional Data + + In this example, information available to the access network provider + is included in the call setup message only indirectly via the use of + the location reference. The PSAP has to retrieve it via a separate + lookup step. Since the access network provider and the VoIP service + + + +Gellens, et al. Standards Track [Page 45] + +RFC 7852 Additional Call Data July 2016 + + + provider are two independent entities in this scenario, the access + network provider is not involved in application-layer exchanges; the + SIP INVITE transits the access network transparently, as illustrated + in steps #1 and #2 (the access network does not alter the SIP + INVITE). + + The VoIP service provider receives the message and determines, based + on the service URN, that the incoming request is an emergency call. + It performs typical emergency-services-related tasks (such as + location-based routing) and adds additional data, namely service and + subscriber information as well as data provider information #2, to + the outgoing message. For the example, we assume a VoIP service + provider deploys a back-to-back user agent allowing additional data + to be included in the body of the SIP message (rather than by + reference), which allows us to illustrate the use of multiple data + provider info blocks. The resulting message is shown in Figure 17. + The SIP INVITE is sent to the PSAP in step #3. + + INVITE sips:psap@example.org SIP/2.0 + Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 + Max-Forwards: 70 + To: <urn:service:sos> + From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl + Call-ID: 3848276298220188511@example.com + Call-Info: <http://wwww.example.com/hannes/photo.jpg>; + purpose=icon, + <http://www.example.com/hannes/>; purpose=info, + <cid:1234567890@atlanta.example.com>; + purpose=EmergencyCallData.ProviderInfo + <cid:0123456789@atlanta.example.com>; + purpose=EmergencyCallData.DeviceInfo + Call-Info: <cid:bloorpyhex@atlanta.example.com>; + purpose=EmergencyCallData.ServiceInfo + Call-Info: <cid:aaabbb@atlanta.example.com>; + purpose=EmergencyCallData.ProviderInfo + Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o> + Geolocation-Routing: yes + Accept: application/sdp, application/pidf+xml, + application/EmergencyCallData.ProviderInfo+xml + CSeq: 31862 INVITE + Contact: <sips:hannes@example.com> + Content-Type: multipart/mixed; boundary=boundary1 + Content-Length: ... + + --boundary1 + Content-Type: application/sdp + + ...SDP goes here + + + +Gellens, et al. Standards Track [Page 46] + +RFC 7852 Additional Call Data July 2016 + + + --boundary1 + Content-Type: application/EmergencyCallData.DeviceInfo+xml + Content-ID: <0123456789@atlanta.example.com> + Content-Disposition: by-reference;handling=optional + + <?xml version="1.0" encoding="UTF-8"?> + <dev:EmergencyCallData.DeviceInfo + xmlns:dev= + "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> + <dev:DataProviderReference>d4b3072df09876543@[93.184.216.119] + </dev:DataProviderReference> + <dev:DeviceClassification>laptop</dev:DeviceClassification> + <dev:UniqueDeviceID + TypeOfDeviceID="MAC">00-0d-4b-30-72-df</dev:UniqueDeviceID> + </dev:EmergencyCallData.DeviceInfo> + + --boundary1 + Content-Type: application/EmergencyCallData.ProviderInfo+xml + Content-ID: <1234567890@atlanta.example.com> + Content-Disposition: by-reference;handling=optional + + <?xml version="1.0" encoding="UTF-8"?> + <pi:EmergencyCallData.ProviderInfo + xmlns:pi= + "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> + <pi:DataProviderReference>d4b3072df09876543@[93.184.216.119] + </pi:DataProviderReference> + <pi:DataProviderString>Hannes Tschofenig + </pi:DataProviderString> + <pi:TypeOfProvider>Client</pi:TypeOfProvider> + <pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI> + <pi:Language>en</pi:Language> + <pi:DataProviderContact + xmlns="urn:ietf:params:xml:ns:vcard-4.0"> + <vcard> + <fn><text>Hannes Tschofenig</text></fn> + <n> + <surname>Hannes</surname> + <given>Tschofenig</given> + <additional/> + <prefix/> + <suffix>Dipl. Ing.</suffix> + </n> + <bday><date>--0203</date></bday> + <anniversary> + <date-time>20090808T1430-0500</date-time> + </anniversary> + <gender><sex>M</sex></gender> + + + +Gellens, et al. Standards Track [Page 47] + +RFC 7852 Additional Call Data July 2016 + + + <lang> + <parameters><pref><integer>1</integer></pref> + </parameters> + <language-tag>de</language-tag> + </lang> + <lang> + <parameters><pref><integer>2</integer></pref> + </parameters> + <language-tag>en</language-tag> + </lang> + <adr> + <parameters> + <type><text>work</text></type> + <label><text>Hannes Tschofenig + Linnoitustie 6 + Espoo, Finland + 02600</text></label> + </parameters> + <pobox/> + <ext/> + <street>Linnoitustie 6</street> + <locality>Espoo</locality> + <region>Uusimaa</region> + <code>02600</code> + <country>Finland</country> + </adr> + <adr> + <parameters> + <type><text>home</text></type> + <label><text>Hannes Tschofenig + c/o Hotel DuPont + 42 W 11th St + Wilmington, DE 19801 + USA</text></label> + </parameters> + <pobox/> + <ext/> + <street>42 W 11th St</street> + <locality>Wilmington</locality> + <region>DE</region> + <code>19801</code> + <country>USA</country> + </adr> + <tel> + <parameters> + <type> + <text>work</text> + <text>voice</text> + + + +Gellens, et al. Standards Track [Page 48] + +RFC 7852 Additional Call Data July 2016 + + + </type> + </parameters> + <uri>tel:+358 50 4871445</uri> + </tel> + <tel> + <parameters> + <type> + <text>home</text> + <text>voice</text> + </type> + </parameters> + <uri>tel:+1-555-555-0123</uri> + </tel> + <email> + <parameters><type><text>work</text></type> + </parameters> + <text>hannes.tschofenig@nsn.com</text> + </email> + <geo> + <parameters><type><text>work</text></type> + </parameters> + <uri>geo:60.210796,24.812924</uri> + </geo> + <geo> + <parameters><type><text>home</text></type> + </parameters> + <uri>geo:39.746537,-75.548027</uri> + </geo> + <key> + <parameters> + <type><text>home</text></type> + </parameters> + <uri>https://www.example.com/key.asc</uri> + </key> + <tz><text>Finland/Helsinki</text></tz> + <url> + <parameters><type><text>home</text></type> + </parameters> + <uri>http://example.com/hannes.tschofenig</uri> + </url> + </vcard> + </pi:DataProviderContact> + </pi:EmergencyCallData.ProviderInfo> + + --boundary1 + Content-Type: application/EmergencyCallData.ServiceInfo+xml + Content-ID: <bloorpyhex@atlanta.example.com> + Content-Disposition: by-reference;handling=optional + + + +Gellens, et al. Standards Track [Page 49] + +RFC 7852 Additional Call Data July 2016 + + + <?xml version="1.0" encoding="UTF-8"?> + <svc:EmergencyCallData.ServiceInfo + xmlns:svc= + "urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"> + <svc:DataProviderReference>string0987654321@example.org + </svc:DataProviderReference> + <svc:ServiceEnvironment>Residence</svc:ServiceEnvironment> + <svc:ServiceType>VOIP</svc:ServiceType> + <svc:ServiceMobility>Unknown</svc:ServiceMobility> + </svc:EmergencyCallData.ServiceInfo> + + --boundary1 + Content-Type: application/EmergencyCallData.ProviderInfo+xml + Content-ID: <aaabbb@atlanta.example.com> + Content-Disposition: by-reference;handling=optional + + <?xml version="1.0" encoding="UTF-8"?> + <pi:EmergencyCallData.ProviderInfo + xmlns:pi= + "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> + <pi:DataProviderReference>string0987654321@example.org + </pi:DataProviderReference> + <pi:DataProviderString>Exemplar VoIP Provider + </pi:DataProviderString> + <pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID> + <pi:ProviderIDSeries>NENA</pi:ProviderIDSeries> + <pi:TypeOfProvider>Service Provider</pi:TypeOfProvider> + <pi:ContactURI>sip:voip-provider@example.com</pi:ContactURI> + <pi:Language>en</pi:Language> + <pi:DataProviderContact + xmlns="urn:ietf:params:xml:ns:vcard-4.0"> + <vcard> + <fn><text>John Doe</text></fn> + <n> + <surname>John</surname> + <given>Doe</given> + <additional/> + <prefix/> + <suffix/> + </n> + <bday><date>--0203</date></bday> + <anniversary> + <date-time>20090808T1430-0500</date-time> + </anniversary> + <gender><sex>M</sex></gender> + <lang> + <parameters><pref><integer>1</integer></pref> + </parameters> + + + +Gellens, et al. Standards Track [Page 50] + +RFC 7852 Additional Call Data July 2016 + + + <language-tag>en</language-tag> + </lang> + <org> + <parameters><type><text>work</text></type> + </parameters> + <text>Exemplar VoIP Provider</text> + </org> + <adr> + <parameters> + <type><text>work</text></type> + <label><text>John Doe + 123 Middle Street + The Sticks, IA 50055</text></label> + </parameters> + <pobox/> + <ext/> + <street>123 Middle Street</street> + <locality>The Sticks</locality> + <region>IA</region> + <code>50055</code> + <country>USA</country> + </adr> + <tel> + <parameters> + <type> + <text>work</text> + <text>voice</text> + <text>main-number</text> + </type> + </parameters> + <uri>sips:john.doe@example.com</uri> + </tel> + <email> + <parameters><type><text>work</text></type> + </parameters> + <text>john.doe@example.com</text> + </email> + <geo> + <parameters><type><text>work</text></type> + </parameters> + <uri>geo:41.761838,-92.963268</uri> + </geo> + <tz><text>America/Chicago</text></tz> + <url> + <parameters><type><text>home</text></type> + </parameters> + <uri>http://www.example.com/john.doe</uri> + </url> + + + +Gellens, et al. Standards Track [Page 51] + +RFC 7852 Additional Call Data July 2016 + + + </vcard> + </pi:DataProviderContact> + </pi:EmergencyCallData.ProviderInfo> + --boundary1-- + + Figure 17: VoIP Provider Sending SIP INVITE with Additional Data + + Finally, the PSAP requests location information from the access + network provider. The response is shown in Figure 18. Along with + the location information, additional data is provided in the + <provided-by> element of the PIDF-LO. This request and response is + step #4. + + <?xml version="1.0" encoding="UTF-8"?> + <presence xmlns="urn:ietf:params:xml:ns:pidf" + xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" + xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" + xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" + entity="pres:alice@atlanta.example.com"> + <dm:device id="target123-1"> + <gp:geopriv> + <gp:location-info> + <civicAddress + xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> + <country>US</country> + <A1>DE</A1> + <A3>Wilmington</A3> + <PRD>W</PRD> + <RD>11th</RD> + <STS>Street</STS> + <HNO>42</HNO> + <NAM>The Hotel DuPont</NAM> + <PC>19801</PC> + </civicAddress> + </gp:location-info> + <gp:usage-rules> + <gbp:retransmission-allowed>true + </gbp:retransmission-allowed> + <gbp:retention-expiry>2013-12-10T20:00:00Z + </gbp:retention-expiry> + </gp:usage-rules> + <gp:method>802.11</gp:method> + + <gp:provided-by + xmlns="urn:ietf:params:xml:ns:EmergencyCallData"> + + + + + + +Gellens, et al. Standards Track [Page 52] + +RFC 7852 Additional Call Data July 2016 + + + <EmergencyCallDataReference + purpose="EmergencyCallData.ServiceInfo" + ref="https://example.com/ref2" /> + + <EmergencyCallDataValue> + <EmergencyCallData.ProviderInfo + xmlns= + "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> + <DataProviderReference>88QV4FpfZ976T@example.com + </DataProviderReference> + <DataProviderString>Diamond State Exemplar + </DataProviderString> + <ProviderID>urn:nena:companyid:diamond</ProviderID> + <ProviderIDSeries>NENA</ProviderIDSeries> + <TypeOfProvider>Access Network Provider</TypeOfProvider> + <ContactURI>tel:+1-302-555-0000</ContactURI> + <Language>en</Language> + </EmergencyCallData.ProviderInfo> + + <EmergencyCallData.Comment + xmlns="urn:ietf:params:xml:ns:EmergencyCallData:Comment"> + <DataProviderReference>88QV4FpfZ976T@example.com + </DataProviderReference> + <Comment xml:lang="en">This is an example text.</Comment> + </EmergencyCallData.Comment> + + </EmergencyCallDataValue> + </gp:provided-by> + + </gp:geopriv> + <dm:deviceID>mac:00-0d-4b-30-72-df</dm:deviceID> + <dm:timestamp>2013-07-09T20:57:29Z</dm:timestamp> + </dm:device> + </presence> + + Figure 18: Access Network Provider Returning PIDF-LO + with Additional Data + +8. XML Schemas + + This section defines the XML schemas of the five data blocks. + Additionally, the provided-by schema is specified. + + + + + + + + + +Gellens, et al. Standards Track [Page 53] + +RFC 7852 Additional Call Data July 2016 + + +8.1. EmergencyCallData.ProviderInfo XML Schema + + <?xml version="1.0"?> + <xs:schema + targetNamespace= + "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo" + xmlns:xml="http://www.w3.org/XML/1998/namespace" + xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2009/01/xml.xsd"/> + + <xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0" + schemaLocation="vcard.xsd"/> + + <xs:element + name="EmergencyCallData.ProviderInfo" + type="pi:ProviderInfoType"/> + + <xs:simpleType name="SubcontractorPriorityType"> + <xs:restriction base="xs:string"> + <xs:enumeration value="sub"/> + <xs:enumeration value="main"/> + </xs:restriction> + </xs:simpleType> + + <xs:complexType name="ProviderInfoType"> + <xs:sequence> + <xs:element name="DataProviderReference" + type="xs:token" minOccurs="1" maxOccurs="1"/> + + <xs:element name="DataProviderString" + type="xs:string" minOccurs="1" maxOccurs="1"/> + + <xs:element name="ProviderID" + type="xs:string" minOccurs="0" maxOccurs="1"/> + + <xs:element name="ProviderIDSeries" + type="xs:string" minOccurs="0" maxOccurs="1"/> + + <xs:element name="TypeOfProvider" + type="xs:token" minOccurs="1" maxOccurs="1"/> + + + + + +Gellens, et al. Standards Track [Page 54] + +RFC 7852 Additional Call Data July 2016 + + + <xs:element name="ContactURI" type="xs:anyURI" + minOccurs="1" maxOccurs="1"/> + + <xs:element name="Language" minOccurs="1" maxOccurs="unbounded"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:pattern + value="([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8}) + (-[a-z]{4})?(-([a-z]{2}|\d{3}))?(-([0-9a-z]{5,8}| + \d[0-9a-z]{3}))*(-[0-9a-wyz](-[0-9a-z]{2,8})+)* + (-x(-[0-9a-z]{1,8})+)?|x(-[0-9a-z]{1,8})+|[a-z]{1,3} + (-[0-9a-z]{2,8}){1,2}"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + + <xs:element name="DataProviderContact" + minOccurs="0" maxOccurs="1"> + <xs:complexType> + <xs:sequence> + <xs:element minOccurs="0" + maxOccurs="unbounded" ref="xc:vcard"/> + </xs:sequence> + </xs:complexType> + </xs:element> + + <xs:element name="SubcontractorPrincipal" + type="xs:string" minOccurs="0" maxOccurs="1"/> + + <xs:element name="SubcontractorPriority" + type="pi:SubcontractorPriorityType" + minOccurs="0" maxOccurs="1"/> + + <xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + </xs:schema> + + Figure 19: EmergencyCallData.ProviderInfo XML Schema + + + + + + + + + + +Gellens, et al. Standards Track [Page 55] + +RFC 7852 Additional Call Data July 2016 + + +8.2. EmergencyCallData.ServiceInfo XML Schema + + <?xml version="1.0"?> + <xs:schema + targetNamespace= + "urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo" + xmlns:xml="http://www.w3.org/XML/1998/namespace" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2001/xml.xsd"/> + + <xs:element name="EmergencyCallData.ServiceInfo" + type="svc:ServiceInfoType"/> + + <xs:complexType name="ServiceInfoType"> + <xs:sequence> + <xs:element name="DataProviderReference" + type="xs:token" minOccurs="1" maxOccurs="1"/> + + <xs:element name="ServiceEnvironment" + type="xs:string" minOccurs="0" maxOccurs="1"/> + + <xs:element name="ServiceType" + type="xs:string" minOccurs="1" + maxOccurs="unbounded"/> + + <xs:element name="ServiceMobility" + type="xs:string" minOccurs="1" maxOccurs="1"/> + + <xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + </xs:schema> + + Figure 20: EmergencyCallData.ServiceInfo XML Schema + + + + + + + + + + +Gellens, et al. Standards Track [Page 56] + +RFC 7852 Additional Call Data July 2016 + + +8.3. EmergencyCallData.DeviceInfo XML Schema + + <?xml version="1.0"?> + <xs:schema + targetNamespace= + "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo" + xmlns:xml="http://www.w3.org/XML/1998/namespace" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2001/xml.xsd"/> + + <xs:element name="EmergencyCallData.DeviceInfo" + type="dev:DeviceInfoType"/> + + <xs:complexType name="DeviceInfoType"> + <xs:sequence> + <xs:element name="DataProviderReference" + type="xs:token" minOccurs="1" maxOccurs="1"/> + + <xs:element name="DeviceClassification" + type="xs:string" minOccurs="0" maxOccurs="1"/> + + <xs:element name="DeviceMfgr" + type="xs:string" minOccurs="0" maxOccurs="1"/> + + <xs:element name="DeviceModelNr" + type="xs:string" minOccurs="0" maxOccurs="1"/> + + <xs:element name="UniqueDeviceID" minOccurs="0" + maxOccurs="unbounded"> + <xs:complexType> + <xs:simpleContent> + <xs:extension base="xs:string"> + <xs:attribute name="TypeOfDeviceID" + type="xs:string" + use="required"/> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + + <xs:element name="DeviceSpecificData" + type="xs:anyURI" minOccurs="0" maxOccurs="1"/> + + + + +Gellens, et al. Standards Track [Page 57] + +RFC 7852 Additional Call Data July 2016 + + + <xs:element name="DeviceSpecificType" + type="xs:string" minOccurs="0" maxOccurs="1"/> + + <xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + </xs:schema> + + Figure 21: EmergencyCallData.DeviceInfo XML Schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 58] + +RFC 7852 Additional Call Data July 2016 + + +8.4. EmergencyCallData.SubscriberInfo XML Schema + + <?xml version="1.0"?> + <xs:schema + targetNamespace= + "urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:sub= + "urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo" + xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0" + xmlns:xml="http://www.w3.org/XML/1998/namespace" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2001/xml.xsd"/> + + <xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0" + schemaLocation="vcard.xsd"/> + + <xs:element name="EmergencyCallData.SubscriberInfo" + type="sub:SubscriberInfoType"/> + + <xs:complexType name="SubscriberInfoType"> + <xs:sequence> + <xs:element name="DataProviderReference" type="xs:token" + minOccurs="1" maxOccurs="1"/> + <xs:element name="SubscriberData"> + <xs:complexType> + <xs:sequence> + <xs:element ref="xc:vcard" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + </xs:element> + + <xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + + </xs:sequence> + <xs:attribute name="privacyRequested" + type="xs:boolean" use="required"/> + + </xs:complexType> + </xs:schema> + + Figure 22: EmergencyCallData.SubscriberInfo XML Schema + + + + +Gellens, et al. Standards Track [Page 59] + +RFC 7852 Additional Call Data July 2016 + + +8.5. EmergencyCallData.Comment XML Schema + + <?xml version="1.0"?> + <xs:schema + targetNamespace= + "urn:ietf:params:xml:ns:EmergencyCallData:Comment" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment" + xmlns:xml="http://www.w3.org/XML/1998/namespace" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2001/xml.xsd"/> + + <xs:element name="EmergencyCallData.Comment" + type="com:CommentType"/> + + <xs:complexType name="CommentType"> + <xs:sequence> + <xs:element name="DataProviderReference" + type="xs:token" minOccurs="1" maxOccurs="1"/> + + <xs:element name="Comment" + type="com:CommentSubType" minOccurs="0" + maxOccurs="unbounded"/> + + <xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + <xs:complexType name="CommentSubType"> + <xs:simpleContent> + <xs:extension base="xs:string"> + <xs:attribute ref="xml:lang"/> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + + </xs:schema> + + Figure 23: EmergencyCallData.Comment XML Schema + + + + + + + + +Gellens, et al. Standards Track [Page 60] + +RFC 7852 Additional Call Data July 2016 + + +8.6. provided-by XML Schema + + This section defines the provided-by schema. + +<?xml version="1.0"?> +<xs:schema + targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:ad="urn:ietf:params:xml:ns:EmergencyCallData" + xmlns:xml="http://www.w3.org/XML/1998/namespace" + xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo" + xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo" + xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo" + xmlns:sub="urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo" + xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:import + namespace="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo" + schemaLocation="ProviderInfo.xsd"/> + <xs:import + namespace="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo" + schemaLocation="ServiceInfo.xsd"/> + <xs:import + namespace="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo" + schemaLocation="DeviceInfo.xsd"/> + <xs:import + namespace="urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo" + schemaLocation="SubscriberInfo.xsd"/> + <xs:import + namespace="urn:ietf:params:xml:ns:EmergencyCallData:Comment" + schemaLocation="Comment.xsd"/> + <xs:element name="EmergencyCallDataReference" type="ad:ByRefType"/> + <xs:element name="EmergencyCallDataValue" + type="ad:EmergencyCallDataValueType"/> + <!-- Additional Data By Reference --> + <xs:complexType name="ByRefType"> + <xs:sequence> + <xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + <xs:attribute name="purpose" type="xs:token" use="required"/> + <xs:attribute name="ref" type="xs:anyURI" use="required"/> + </xs:complexType> + <!-- Additional Data By Value --> + <xs:complexType name="EmergencyCallDataValueType"> + <xs:sequence> + + + +Gellens, et al. Standards Track [Page 61] + +RFC 7852 Additional Call Data July 2016 + + + <xs:element ref="pi:EmergencyCallData.ProviderInfo" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="svc:EmergencyCallData.ServiceInfo" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="dev:EmergencyCallData.DeviceInfo" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="sub:EmergencyCallData.SubscriberInfo" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="com:EmergencyCallData.Comment" + minOccurs="0" maxOccurs="unbounded"/> + <xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> +</xs:schema> + + Figure 24: provided-by XML Schema + +9. Security Considerations + + The data structures described in this document contain information + usually considered private. When information is provided by value, + entities that are a party to the SIP signaling (such as proxy servers + and back-to-back user agents) will have access to it and need to + protect it against inappropriate disclosure. An entity that is able + to eavesdrop on the SIP signaling will also have access. Some + Internet access types (such as in-the-clear Wi-Fi) are more + vulnerable than others (such as 3G or 4G cellular data traffic) to + eavesdropping. Mechanisms that protect against eavesdropping (such + as TLS version 1.2 or later) SHOULD be preferentially used whenever + feasible. (This requirement is not a "MUST" because there is an + existing deployed base of clear-text SIP, and also because, as an + emergency call, it is more important for the call to go through than + for it to be protected; for example, the call MUST proceed even if + the TLS negotiation or certificate verification fails for whatever + reason.) When information is provided by reference, TLS mutual + authentication is REQUIRED. That is, HTTPS is REQUIRED for + dereferencing, the requester MUST use a client certificate to + authenticate the HTTP request, and the provider of the information is + REQUIRED to validate the credentials provided by the requester. + While the creation of a public key infrastructure (PKI) that has + global scope might be difficult, the alternatives to creating devices + and services that can provide critical information securely are more + daunting. The provider of the information MAY enforce any policy it + wishes to use, but PSAPs and responder agencies are strongly advised + to deploy a PKI so that providers of additional data can check the + certificate of the client (the requester) and decide the appropriate + policy to enforce based on that certificate. + + + +Gellens, et al. Standards Track [Page 62] + +RFC 7852 Additional Call Data July 2016 + + + TLS MUST be version 1.2 or later. It is RECOMMENDED to use only + cipher suites that offer Perfect Forward Secrecy (PFS) and avoid + Cipher Block Chaining (CBC) and to follow the recommendations in BCP + 195 [RFC7525]. + + Ideally, the PSAP and emergency responders will be given credentials + signed by an authority trusted by the data provider. In most + circumstances, nationally recognized credentials are sufficient; the + emergency services community within a country can arrange a PKI, data + providers can be provisioned with the root Certification Authority + (CA) public key for the country. Some nations are developing a PKI + for this and related purposes. Since calls could be made from + devices where the device and/or the service provider(s) is not local + to the emergency services authorities, globally recognized + credentials are useful. This might be accomplished by extending the + notion of the "forest guide" described in [RFC5582] to allow the + forest guide to provide the credential of the PKI root for areas for + which it has coverage information, but standards for such a mechanism + are not yet available. In its absence, the data provider needs to + obtain by out-of-band means the root CA credentials for any areas to + which it is willing to provide additional data. With the credential + of the root CA for a national emergency services PKI, the data + provider server can validate the credentials of an entity requesting + additional data by reference. + + The data provider also needs a credential that can be verified by the + emergency services to know that it is receiving data from an + authorized server. The emergency services authorities could provide + credentials, distinguishable from credentials provided to emergency + responders and PSAPs, which could be used to validate data providers. + Such credentials would have to be acceptable to any PSAP or responder + that could receive a call with additional data supplied by that + provider. This would be extensible to global credential validation + using the forest guide as mentioned above. In the absence of such + credentials, the emergency services authorities could maintain a list + of local data providers' credentials as provided to them out of band. + At a minimum, the emergency services authorities could obtain a + credential from the DNS entry of the domain in the additional data + URI (e.g., using DNS-Based Authentication of Named Entities (DANE) + [RFC6698]) to at least validate that the server is known to the + domain providing the URI. + + When devices provide data by reference, the credential validation + issues are similar to when service providers do so, and while the + solutions are the same, the challenges of doing so for every device + are obviously more difficult, especially when considering root + certificate updates, revocation lists, etc. However, in general, + devices are not expected to provide data directly by reference, but + + + +Gellens, et al. Standards Track [Page 63] + +RFC 7852 Additional Call Data July 2016 + + + rather to either provide data by value or upload the data to a server + that can more reliably make it available and more easily enforce + security policy. Devices that do provide data directly by reference, + which might include fixed-location sensors, will need to be capable + of handling this. + + Neither service providers nor devices will supply private information + unless the call is recognized as an emergency call. In cellular + telephony systems (such as those using 3GPP IMS), there are different + procedures for an originating device to place an emergency call + versus a normal call. If a call that is really an emergency call is + initiated as a normal call and the cellular service provider + recognizes this, 3GPP IMS permits the service provider to either + accept the call anyway or reject it with a specific code that + instructs the device to retry the call as an emergency call. Service + providers ought to choose the latter, otherwise the device will not + include the information specified in this document (since the device + didn't recognize the call as being an emergency call). + +10. Privacy Considerations + + This document enables functionality for conveying additional + information about the caller and the caller's device and service to + the callee. Some of this information is personal data and therefore + privacy concerns arise. An explicit privacy indicator for + information directly relating to the caller's identity is defined and + use is mandatory. However, observance of this request for privacy + and which information it relates to is determined by the destination + jurisdiction (which replicates functionality provided in some legacy + emergency services systems). + + There are a number of privacy concerns with non-emergency real-time + communication services that are also applicable to emergency calling. + Data protection regulation worldwide has, however, decided to create + exceptions for emergency services since the drawbacks of disclosing + personal data are outweighed by the benefit for the emergency caller. + Hence, the data protection rights of individuals are commonly waived + for emergency situations. There are, however, still various + countries that offer some degree of anonymity for the caller towards + PSAP call takers. + + The functionality defined in this document far exceeds the amount of + information sharing available in the legacy POTS system. For this + reason, there are additional privacy threats to consider, which are + described in more detail in [RFC6973]. + + + + + + +Gellens, et al. Standards Track [Page 64] + +RFC 7852 Additional Call Data July 2016 + + + Stored Data Compromise: There is an increased risk of stored data + compromise since additional data is collected and stored in + databases. Without adequate measures to secure stored data from + unauthorized or inappropriate access at access network providers, + service providers, end devices, as well as PSAPs, individuals are + exposed to potential financial, reputational, or physical harm. + + Misattribution: If the personal data collected and conveyed is + incorrect or inaccurate, then this can lead to misattribution. + Misattribution occurs when data or communications related to one + individual are attributed to another. + + Identification: By the nature of the additional data and its + capability to provide much richer information about the caller, + the call, and the location, the calling party is identified in a + much better way. Some users could feel uncomfortable with this + degree of information sharing even in emergency services + situations. + + Secondary Use: There is a risk of secondary use, which is the use of + collected information about an individual without the individual's + consent for a purpose different from that for which the + information was collected. The stated purpose of the additional + data is for emergency services purposes, but theoretically the + same information could be used for any other call as well. + Additionally, parties involved in the emergency call could retain + the obtained information and reuse it for other, non-emergency + services purposes. While technical measures are not in place to + prevent such secondary reuse, policy, legal, regulatory, and other + non-technical approaches can be effective. + + Disclosure: When the data defined in this document is not properly + protected (while in transit with traditional communication + security techniques and while stored using access control + mechanisms), there is the risk of disclosure, which is the + revelation of private information about an individual. + + To mitigate these privacy risks, the following countermeasures can be + taken: + + In regions where callers can elect to suppress certain personally + identifying information, network or PSAP functionality can inspect + privacy flags within the SIP headers to determine what information + can be passed, stored, or displayed to comply with local policy or + law. RFC 3325 [RFC3325] defines the 'id' priv-value token. The + presence of this privacy type in a Privacy header field indicates + + + + + +Gellens, et al. Standards Track [Page 65] + +RFC 7852 Additional Call Data July 2016 + + + that the user would like the network asserted identity to be kept + private with respect to SIP entities outside the trust domain with + which the user authenticated, including the PSAP. + + This document defines various data structures that contain privacy- + sensitive data such as, for example, identifiers for the device + (e.g., serial number and MAC address) or account/SIM (e.g., IMSI), + contact information for the user, and location of the caller. Local + regulations may govern which data is provided in emergency calls, but + in general, the emergency call system is aided by the information + described in this document. There is a trade-off between the privacy + considerations and the utility of the data. For protection, this + specification requires all retrieval of data passed by reference to + be protected against eavesdropping and alteration via communication + security techniques (namely TLS). Furthermore, security safeguards + are required to prevent unauthorized access to stored data. Various + security incidents over at least the past few decades have shown that + data breaches are not uncommon and are often caused by lack of proper + access control frameworks, software bugs (such as buffer overflows), + or missing input parsing (such as SQL injection attacks). The risks + of data breaches have increased with the obligation for emergency + services to retain emergency-call-related data for extended periods + (e.g., several years are the norm). + + Finally, it is also worth highlighting the nature of the SIP + communication architecture, which introduces additional complications + for privacy. Some forms of data can be sent by value in the SIP + signaling or by reference (a URL in the SIP signaling). When data is + sent by value, all intermediaries have access to the data. As such, + these intermediaries could also introduce additional privacy risk. + Therefore, in situations where the conveyed information is privacy + sensitive and intermediaries are involved, transmitting by reference + might be appropriate, assuming the source of the data can operate a + sufficient dereferencing infrastructure and that proper access + control policies are available for distinguishing the different + entities dereferencing the reference. Without access control + policies, any party in possession of the reference is able to resolve + the reference and to obtain the data, including intermediaries. + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 66] + +RFC 7852 Additional Call Data July 2016 + + +11. IANA Considerations + +11.1. Emergency Call Additional Data Registry + + This document creates a new registry called 'Emergency Call + Additional Data' with a number of sub-registries. + + For several of the sub-registries, "Expert Review" is the criteria + for adding new entries. As discussed in Section 5, it can be + counterproductive to register new types of data, and as discussed in + Section 10, data sent as part of an emergency call can be very + privacy sensitive. In some cases, it is anticipated that various + standards bodies dealing with emergency services might need to + register new values, and in those cases, text below advises the + designed expert to verify that the entity requesting the registration + is relevant (e.g., a recognized emergency-services-related Standards + Development Organization (SDO)). In other cases, especially those + where the trade-off between the potential benefit versus danger of + new registrations is more conservative (such as Section 11.1.9), + "Specification Required" is the criteria, which is a higher hurdle + and also implicitly includes an "Expert Review". + + The following sub-registries are created for this registry. + +11.1.1. Provider ID Series Registry + + This document creates a new sub-registry called "Provider ID Series". + As defined in [RFC5226], this registry operates under "Expert Review" + rules. The expert should determine that the entity requesting a new + value is a legitimate issuer of service provider IDs suitable for use + in Additional Call Data. + + Private entities issuing or using internally generated IDs are + encouraged to register here and to ensure that all IDs they issue or + use are unique. This guarantees that IDs issued or used by the + entity are globally unique and distinguishable from other IDs issued + or used by the same or a different entity. (Some organizations, such + as NENA, issue IDs that are unique among all IDs they issue, so an + entity using a combination of its NENA ID and the fact that it is + from NENA is globally unique. Other entities might not have an ID + issued by an organization such as NENA, so they are permitted to use + their domain name, but if so, it needs to be unique.) + + The content of this registry includes: + + Name: An identifier to be used in the 'ProviderIDSeries' element. + + Source: The full name of the organization issuing the identifiers. + + + +Gellens, et al. Standards Track [Page 67] + +RFC 7852 Additional Call Data July 2016 + + + URL: A URL to the organization for further information. + + The initial set of values is listed in Figure 1. + +11.1.2. Service Environment Registry + + This document creates a new sub-registry called "Service + Environment". As defined in [RFC5226], this registry operates under + "Expert Review" rules. The expert should determine that the entity + requesting a new value is relevant for this service element (e.g., a + recognized emergency-services-related SDO) and that the new value is + distinct from existing values, and its use is unambiguous. + + The content of this registry includes: + + Token: The value to be used in the <ServiceEnvironment> element. + + Description: A short description of the value. + + The initial set of values is listed in Figure 4. + +11.1.3. Service Type Registry + + This document creates a new sub-registry called "Service Type". As + defined in [RFC5226], this registry operates under "Expert Review" + rules. The expert should determine that the entity requesting a new + value is relevant for this service element (e.g., a recognized + emergency-services-related SDO) and that the requested value is + clearly distinct from other values so that there is no ambiguity as + to when the value is to be used or which value is to be used. + + The content of this registry includes: + + Name: The value to be used in the <ServiceType> element. + + Description: A short description of the value. + + The initial set of values is listed in Figure 5. + +11.1.4. Service Mobility Registry + + This document creates a new sub-registry called "Service Mobility". + As defined in [RFC5226], this registry operates under "Expert Review" + rules. The expert should determine that the entity requesting a new + value is relevant for this service element (e.g., a recognized + emergency-services-related SDO) and that the requested value is + clearly distinct from other values so that there is no ambiguity as + to when the value is to be used or which value is to be used. + + + +Gellens, et al. Standards Track [Page 68] + +RFC 7852 Additional Call Data July 2016 + + + The content of this registry includes: + + Token: The value used in the <ServiceMobility> element. + + Description: A short description of the value. + + The initial set of values is listed in Figure 6. + +11.1.5. Type of Provider Registry + + This document creates a new sub-registry called "Type of Provider". + As defined in [RFC5226], this registry operates under "Expert Review" + rules. The expert should determine that the proposed new value is + distinct from existing values and appropriate for use in the + <TypeOfServicerProvider> element + + The content of this registry includes: + + Token: The value used in the <TypeOfProvider> element. + + Description: A short description of the type of service provider. + + The initial set of values is defined in Figure 2. + +11.1.6. Device Classification Registry + + This document creates a new sub-registry called "Device + Classification". As defined in [RFC5226], this registry operates + under "Expert Review" rules. The expert should consider whether the + proposed class is unique from existing classes, and the definition of + the class will be clear to implementors and PSAPs/responders. + + The content of this registry includes: + + Token: Value used in the <DeviceClassification> element. + + Description: Short description identifying the device type. + + The initial set of values is defined in Figure 8. + +11.1.7. Device ID Type Registry + + This document creates a new sub-registry called "Device ID Type". As + defined in [RFC5226], this registry operates under "Expert Review" + rules. The expert should ascertain that the proposed type is well + understood and provides information that PSAPs and responders are + able to use to uniquely identify a device. (For example, a biometric + + + + +Gellens, et al. Standards Track [Page 69] + +RFC 7852 Additional Call Data July 2016 + + + fingerprint used to authenticate a device would not normally be used + by a PSAP or responder to identify a device.) + + The content of this registry includes: + + Token: The value to be placed in the <TypeOfDeviceID> element. + + Description: Short description identifying the type of the device + ID. + + The initial set of values is defined in Figure 9. + +11.1.8. Device/Service Data Type Registry + + This document creates a new sub-registry called "Device/Service Data + Type". As defined in [RFC5226], this registry operates under + "Specification Required" rules, which include an explicit "Expert + Review". The designated expert should ascertain that the proposed + type is well understood and provides information useful to PSAPs and + responders. The specification must contain a complete description of + the data and a precise format specification suitable to allow + interoperable implementations. + + The content of this registry includes: + + Token: The value to be placed in the <DeviceSpecificType> element. + + Description: Short description identifying the data. + + Specification: Citation for the specification of the data. + + The initial set of values is listed in Figure 10. + +11.1.9. Emergency Call Data Types Registry + + This document creates a new sub-registry called "Emergency Call Data + Types". As defined in [RFC5226], this registry operates under + "Specification Required" rules, which include an explicit "Expert + Review". The expert is responsible for verifying that the document + contains a complete and clear specification, and the proposed + functionality does not obviously duplicate existing functionality. + The expert is also responsible for verifying that the block is + correctly categorized per the description of the categories in + Section 1. + + The registry contains an entry for every data block that can be sent + with an emergency call using the mechanisms as specified in this + document. Each data block is identified by the 'root' of its MIME + + + +Gellens, et al. Standards Track [Page 70] + +RFC 7852 Additional Call Data July 2016 + + + media subtype (which is the part after 'EmergencyCallData.'). If the + MIME media subtype does not start with 'EmergencyCallData.', then it + cannot be registered here nor used in a Call-Info header field as + specified in this document. The subtype MAY exist under any MIME + media type (although most commonly under 'application/', this is NOT + REQUIRED); however, to be added to the registry, the 'root' needs to + be unique regardless of the MIME media type. + + The content of this registry includes: + + Token: The root of the data's MIME media subtype (not including the + 'EmergencyCallData' prefix and any suffix such as '+xml'). + + Data About: A hint as to if the block is considered descriptive of + the call, the caller, or the location (or is applicable to more + than one), which can help PSAPs and other entities determine if + they wish to process the block. Note that this is only a hint; + entities need to consider the block's contents, not just this + field, when determining if they wish to process the block (which + is why the field only exists in the registry and is not contained + within the block). The value MUST be either 'The Call', 'The + Caller', 'The Location', or 'Multiple'. New values are created by + extending this registry in a subsequent RFC. + + Reference: The document that describes the data object. + + Note that the tokens in this registry are part of the + 'EmergencyCallData' compound value; when used as a value of the + 'purpose' parameter of a Call-Info header field, the values listed in + this registry are prefixed by 'EmergencyCallData.' per the + 'EmergencyCallData' registration; see Section 11.2. + + The initial set of values is listed in Figure 25. + + +----------------+--------------+------------+ + | Token | Data About | Reference | + +----------------+--------------+------------+ + | ProviderInfo | The Call | RFC 7852 | + | ServiceInfo | The Call | RFC 7852 | + | DeviceInfo | The Call | RFC 7852 | + | SubscriberInfo | The Call | RFC 7852 | + | Comment | The Call | RFC 7852 | + +----------------+--------------+------------+ + + Figure 25: Additional Data Blocks Registry + + + + + + +Gellens, et al. Standards Track [Page 71] + +RFC 7852 Additional Call Data July 2016 + + +11.2. 'EmergencyCallData' Purpose Parameter Value + + This document defines the 'EmergencyCallData' value for the 'purpose' + parameter of the Call-Info header field [RFC3261]. IANA has added + this document to the list of references for the 'purpose' value of + Call-Info in the "Header Field Parameters and Parameter Values" sub- + registry of the "Session Initiation Protocol (SIP) Parameters" + registry. Note that 'EmergencyCallData' is a compound value; when + used as a value of the 'purpose' parameter of a Call-Info header + field, 'EmergencyCallData' is immediately followed by a dot ('.') and + a value from the "Emergency Call Data Types" registry; see + Section 11.1.9. + +11.3. URN Sub-Namespace Registration for <provided-by> Registry Entry + + This section registers the namespace specified in Section 11.5.1 in + the provided-by registry established by RFC 4119, for usage within + the <provided-by> element of a PIDF-LO. + + The schema for the <provided-by> element used by this document is + specified in Section 8.6. + +11.4. MIME Registrations + +11.4.1. MIME Content-Type Registration for 'application/ + EmergencyCallData.ProviderInfo+xml' + + This specification requests the registration of a new MIME media type + according to the procedures of RFC 6838 [RFC6838] and guidelines in + RFC 7303 [RFC7303]. + + Type name: application + + Subtype name: EmergencyCallData.ProviderInfo+xml + + Mandatory parameters: N/A + + Optional parameters: charset (indicates the character encoding of + the contents) + + Encoding considerations: Uses XML, which can contain 8-bit + characters, depending on the character encoding. See Section 3.2 + of RFC 7303 [RFC7303]. + + Security considerations: This content type is designed to carry + the data provider information, which is a sub-category of + additional data about an emergency call. Since this data can + contain personal information, appropriate precautions are needed + + + +Gellens, et al. Standards Track [Page 72] + +RFC 7852 Additional Call Data July 2016 + + + to limit unauthorized access, inappropriate disclosure, and + eavesdropping of personal information. Please refer to Sections 9 + and 10 for more information. + + Interoperability considerations: N/A + + Published specification: RFC 7852 + + Applications that use this media type: Emergency Services + + Additional information: + + Magic Number: N/A + + File Extension: .xml + + Macintosh file type code: 'TEXT' + + Person and email address for further information: + Hannes Tschofenig, Hannes.Tschofenig@gmx.net + + Intended usage: LIMITED USE + + Author: This specification is a work item of the IETF ECRIT + working group, with mailing list address <ecrit@ietf.org>. + + Change controller: The IESG <iesg@ietf.org> + +11.4.2. MIME Content-Type Registration for 'application/ + EmergencyCallData.ServiceInfo+xml' + + This specification requests the registration of a new MIME media type + according to the procedures of RFC 6838 [RFC6838] and guidelines in + RFC 7303 [RFC7303]. + + Type name: application + + Subtype name: EmergencyCallData.ServiceInfo+xml + + Mandatory parameters: N/A + + Optional parameters: charset (indicates the character encoding of + the contents) + + Encoding considerations: Uses XML, which can contain 8-bit + characters, depending on the character encoding. See Section 3.2 + of RFC 7303 [RFC7303]. + + + + +Gellens, et al. Standards Track [Page 73] + +RFC 7852 Additional Call Data July 2016 + + + Security considerations: This content type is designed to carry + the service information, which is a sub-category of additional + data about an emergency call. Since this data can contain + personal information, appropriate precautions are needed to limit + unauthorized access, inappropriate disclosure, and eavesdropping + of personal information. Please refer to Sections 9 and 10 for + more information. + + Interoperability considerations: N/A + + Published specification: RFC 7852 + + Applications that use this media type: Emergency Services + + Additional information: + + Magic Number: N/A + + File Extension: .xml + + Macintosh file type code: 'TEXT' + + Person and email address for further information: + Hannes Tschofenig, Hannes.Tschofenig@gmx.net + + Intended usage: LIMITED USE + + Author: This specification is a work item of the IETF ECRIT + working group, with mailing list address <ecrit@ietf.org>. + + Change controller: The IESG <iesg@ietf.org> + +11.4.3. MIME Content-Type Registration for 'application/ + EmergencyCallData.DeviceInfo+xml' + + This specification requests the registration of a new MIME media type + according to the procedures of RFC 6838 [RFC6838] and guidelines in + RFC 7303 [RFC7303]. + + Type name: application + + Subtype name: EmergencyCallData.DeviceInfo+xml + + Mandatory parameters: N/A + + Optional parameters: charset (indicates the character encoding of + the contents) + + + + +Gellens, et al. Standards Track [Page 74] + +RFC 7852 Additional Call Data July 2016 + + + Encoding considerations: Uses XML, which can contain 8-bit + characters, depending on the character encoding. See Section 3.2 + of RFC 7303 [RFC7303]. + + Security considerations: This content type is designed to carry + device information, which is a sub-category of additional data + about an emergency call. Since this data contains personal + information, appropriate precautions need to be taken to limit + unauthorized access, inappropriate disclosure to third parties, + and eavesdropping of this information. Please refer to Sections 9 + and 10 for more information. + + Interoperability considerations: N/A + + Published specification: RFC 7852 + + Applications that use this media type: Emergency Services + + Additional information: + + Magic Number: N/A + + File Extension: .xml + + Macintosh file type code: 'TEXT' + + Person and email address for further information: + Hannes Tschofenig, Hannes.Tschofenig@gmx.net + + Intended usage: LIMITED USE + + Author: This specification is a work item of the IETF ECRIT + working group, with mailing list address <ecrit@ietf.org>. + + Change controller: The IESG <iesg@ietf.org> + +11.4.4. MIME Content-Type Registration for 'application/ + EmergencyCallData.SubscriberInfo+xml' + + This specification requests the registration of a new MIME media type + according to the procedures of RFC 6838 [RFC6838] and guidelines in + RFC 7303 [RFC7303]. + + Type name: application + + Subtype name: EmergencyCallData.SubscriberInfo+xml + + Mandatory parameters: N/A + + + +Gellens, et al. Standards Track [Page 75] + +RFC 7852 Additional Call Data July 2016 + + + Optional parameters: charset (indicates the character encoding of + the contents) + + Encoding considerations: Uses XML, which can contain 8-bit + characters, depending on the character encoding. See Section 3.2 + of RFC 7303 [RFC7303]. + + Security considerations: This content type is designed to carry + owner/subscriber information, which is a sub-category of + additional data about an emergency call. Since this data contains + personal information, appropriate precautions need to be taken to + limit unauthorized access, inappropriate disclosure to third + parties, and eavesdropping of this information. Please refer to + Sections 9 and 10 for more information. + + Interoperability considerations: N/A + + Published specification: RFC 7852 + + Applications that use this media type: Emergency Services + + Additional information: + + Magic Number: N/A + + File Extension: .xml + + Macintosh file type code: 'TEXT' + + Person and email address for further information: + Hannes Tschofenig, Hannes.Tschofenig@gmx.net + + Intended usage: LIMITED USE + + Author: This specification is a work item of the IETF ECRIT + working group, with mailing list address <ecrit@ietf.org>. + + Change controller: The IESG <iesg@ietf.org> + +11.4.5. MIME Content-Type Registration for 'application/ + EmergencyCallData.Comment+xml' + + This specification requests the registration of a new MIME media type + according to the procedures of RFC 6838 [RFC6838] and guidelines in + RFC 7303 [RFC7303]. + + Type name: application + + + + +Gellens, et al. Standards Track [Page 76] + +RFC 7852 Additional Call Data July 2016 + + + Subtype name: EmergencyCallData.Comment+xml + + Mandatory parameters: N/A + + Optional parameters: charset (indicates the character encoding of + the contents) + + Encoding considerations: Uses XML, which can contain 8-bit + characters, depending on the character encoding. See Section 3.2 + of RFC 7303 [RFC7303]. + + Security considerations: This content type is designed to carry a + comment, which is a sub-category of additional data about an + emergency call. This data can contain personal information. + Appropriate precautions are needed to limit unauthorized access, + inappropriate disclosure to third parties, and eavesdropping of + this information. Please refer to Sections 9 and 10 for more + information. + + Interoperability considerations: N/A + + Published specification: RFC 7852 + + Applications that use this media type: Emergency Services + + Additional information: + + Magic Number: N/A + + File Extension: .xml + + Macintosh file type code: 'TEXT' + + Person and email address for further information: + Hannes Tschofenig, Hannes.Tschofenig@gmx.net + + Intended usage: LIMITED USE + + Author: This specification is a work item of the IETF ECRIT + working group, with mailing list address <ecrit@ietf.org>. + + Change controller: The IESG <iesg@ietf.org> + + + + + + + + + +Gellens, et al. Standards Track [Page 77] + +RFC 7852 Additional Call Data July 2016 + + +11.5. URN Sub-Namespace Registration + +11.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData + + This section registers a new XML namespace, as per the guidelines in + RFC 3688 [RFC3688]. + + URI: urn:ietf:params:xml:ns:EmergencyCallData + + Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as + delegated by the IESG <iesg@ietf.org>. + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Namespace for Additional Emergency Call Data</title> + </head> + <body> + <h1>Namespace for Additional Data Related to an Emergency Call + </h1> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> + RFC 7852</a>.</p> + </body> + </html> + END + +11.5.2. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo + + This section registers a new XML namespace, as per the guidelines in + RFC 3688 [RFC3688]. + + URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo + + Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as + delegated by the IESG <iesg@ietf.org>. + + + + + + + + +Gellens, et al. Standards Track [Page 78] + +RFC 7852 Additional Call Data July 2016 + + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Namespace for Additional Emergency Call Data: + Data Provider Information</title> + </head> + <body> + <h1>Namespace for Additional Data Related to an Emergency Call + </h1> + <h2>Data Provider Information</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> + RFC 7852</a>.</p> + </body> + </html> + END + +11.5.3. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo + + This section registers a new XML namespace, as per the guidelines in + RFC 3688 [RFC3688]. + + URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo + + Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as + delegated by the IESG <iesg@ietf.org>. + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Namespace for Additional Emergency Call Data: + Service Information</title> + </head> + <body> + + + +Gellens, et al. Standards Track [Page 79] + +RFC 7852 Additional Call Data July 2016 + + + <h1>Namespace for Additional Data Related to an Emergency Call + </h1> + <h2>Service Information</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> + RFC 7852</a>.</p> + </body> + </html> + END + +11.5.4. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo + + This section registers a new XML namespace, as per the guidelines in + RFC 3688 [RFC3688]. + + URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo + + Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as + delegated by the IESG <iesg@ietf.org>. + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Namespace for Additional Emergency Call Data: + Device Information</title> + </head> + <body> + <h1>Namespace for Additional Data Related to an Emergency Call + </h1> + <h2>Device Information</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> + RFC 7852</a>.</p> + </body> + </html> + END + + + + + + + + + +Gellens, et al. Standards Track [Page 80] + +RFC 7852 Additional Call Data July 2016 + + +11.5.5. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo + + This section registers a new XML namespace, as per the guidelines in + RFC 3688 [RFC3688]. + + URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo + + Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as + delegated by the IESG <iesg@ietf.org>. + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Namespace for Additional Emergency Call Data: + Owner/Subscriber Information</title> + </head> + <body> + <h1>Namespace for Additional Data Related to an Emergency Call + </h1> + <h2> Owner/Subscriber Information</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> + RFC 7852</a>.</p> + </body> + </html> + END + +11.5.6. Registration for + urn:ietf:params:xml:ns:EmergencyCallData:Comment + + This section registers a new XML namespace, as per the guidelines in + RFC 3688 [RFC3688]. + + URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment + + Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as + delegated by the IESG <iesg@ietf.org>. + + + + + + + +Gellens, et al. Standards Track [Page 81] + +RFC 7852 Additional Call Data July 2016 + + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Namespace for Additional Emergency Call Data:Comment + </title> + </head> + <body> + <h1>Namespace for Additional Data Related to an Emergency Call + </h1> + <h2> Comment</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> + RFC 7852</a>.</p> + </body> + </html> + END + +11.6. Schema Registrations + + This specification registers the following schemas, as per the + guidelines in RFC 3688 [RFC3688]. + + ID: EmergencyCallData + URI: urn:ietf:params:xml:schema:EmergencyCallData + Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as + delegated by the IESG (iesg@ietf.org). + XML: The XML schema can be found in Section 8.6. + + ID: EmergencyCallData:ProviderInfo + URI: urn:ietf:params:xml:schema:EmergencyCallData:ProviderInfo + Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as + delegated by the IESG (iesg@ietf.org). + XML: The XML schema can be found in Figure 19. + + ID: EmergencyCallData:ServiceInfo + URI: urn:ietf:params:xml:schema:EmergencyCallData:ServiceInfo + Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as + delegated by the IESG (iesg@ietf.org). + XML: The XML schema can be found in Figure 20. + + + + + + +Gellens, et al. Standards Track [Page 82] + +RFC 7852 Additional Call Data July 2016 + + + ID: EmergencyCallData:DeviceInfo + URI: urn:ietf:params:xml:schema:EmergencyCallData:DeviceInfo + Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as + delegated by the IESG (iesg@ietf.org). + + XML: The XML schema can be found in Figure 21. + + ID: EmergencyCallData:SubscriberInfo + URI: urn:ietf:params:xml:schema:EmergencyCallData:SubscriberInfo + Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as + delegated by the IESG (iesg@ietf.org). + XML: The XML schema can be found in Section 8.4. + + ID: EmergencyCallData:Comment + URI: urn:ietf:params:xml:schema:EmergencyCallData:Comment + Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as + delegated by the IESG (iesg@ietf.org). + XML: The XML schema can be found in Section 8.5. + + ID: vcard-4.0 + URI: urn:ietf:params:xml:ns:vcard-4.0 + Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as + delegated by the IESG (iesg@ietf.org). + XML: The XML schema can be found in Appendix A. + +11.7. vCard Parameter Value Registration + + This document registers a new value in the "vCard Parameter Values" + registry as defined by [RFC6350] with the following template: + + Value: main-number + + Purpose: The main telephone number, typically of an enterprise, as + opposed to a direct-dial number of an individual employee + + Conformance: This value can be used with the 'TYPE' parameter + applied on the 'TEL' property + + Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 + 00 + + + + + + + + + + + +Gellens, et al. Standards Track [Page 83] + +RFC 7852 Additional Call Data July 2016 + + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource + Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, + <http://www.rfc-editor.org/info/rfc2392>. + + [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, + F., Watson, M., and M. Zonoun, "MIME media types for ISUP + and QSIG Objects", RFC 3204, DOI 10.17487/RFC3204, + December 2001, <http://www.rfc-editor.org/info/rfc3204>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <http://www.rfc-editor.org/info/rfc3261>. + + [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail + Extensions (MIME) Parameter", RFC 3459, + DOI 10.17487/RFC3459, January 2003, + <http://www.rfc-editor.org/info/rfc3459>. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + <http://www.rfc-editor.org/info/rfc3688>. + + [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", + RFC 3966, DOI 10.17487/RFC3966, December 2004, + <http://www.rfc-editor.org/info/rfc3966>. + + [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object + Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, + <http://www.rfc-editor.org/info/rfc4119>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + + + + + +Gellens, et al. Standards Track [Page 84] + +RFC 7852 Additional Call Data July 2016 + + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + <http://www.rfc-editor.org/info/rfc5322>. + + [RFC5621] Camarillo, G., "Message Body Handling in the Session + Initiation Protocol (SIP)", RFC 5621, + DOI 10.17487/RFC5621, September 2009, + <http://www.rfc-editor.org/info/rfc5621>. + + [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying + Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, + September 2009, <http://www.rfc-editor.org/info/rfc5646>. + + [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, + DOI 10.17487/RFC6350, August 2011, + <http://www.rfc-editor.org/info/rfc6350>. + + [RFC6351] Perreault, S., "xCard: vCard XML Representation", + RFC 6351, DOI 10.17487/RFC6351, August 2011, + <http://www.rfc-editor.org/info/rfc6351>. + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + <http://www.rfc-editor.org/info/rfc6838>. + + [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, + DOI 10.17487/RFC7303, July 2014, + <http://www.rfc-editor.org/info/rfc7303>. + +12.2. Informative References + + [ECRIT-WG-wiki] + IETF ECRIT WG Wiki, "Additional Data Examples", July 2015, + <http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/ + WikiStart/additional-data-examples.zip>. + + [Err3047] RFC Errata, Erratum ID 3047, RFC 6351. + + [HUMAN-LANG] + Gellens, R., "Negotiating Human Language in Real-Time + Communications", Work in Progress, draft-ietf-slim- + negotiating-human-language-04, July 2016. + + [IANA-XML-Schemas] + IANA, "IETF XML Registry", + <http://www.iana.org/assignments/xml-registry>. + + + + +Gellens, et al. Standards Track [Page 85] + +RFC 7852 Additional Call Data July 2016 + + + [IEEE-1512-2006] + IEEE, "IEEE Standard for Common Incident Management + Message Sets for Use by Emergency Management Centers", + IEEE Std 1512-2006, DOI 10.1109/IEEESTD.2006.224678, + August 2006, <https://standards.ieee.org/findstds/ + standard/1512-2006.html>. + + [LanguageSubtagRegistry] + IANA, "Language Subtag Registry", + <http://www.iana.org/assignments/ + language-subtag-registry>. + + [LERG] Telcordia Technologies, Inc., "LERG Routing Guide", ANI + II Digits Definitions, June 2015. + + [NANP] North American Numbering Plan Administration (NANPA), "ANI + II Digits Assignments", September 2015, + <http://nanpa.com/number_resource_info/ + ani_ii_assignments.html>. + + [nc911] North Carolina 911 Board, "Wireless 911 for + Telecommunicators", January 2009, + <https://www.nc911.nc.gov/pdf/ + A_TelecommunicatorReference.pdf>. + + [NENA-02-010] + National Emergency Number Association (NENA), "NENA + Standard Data Formats for 9-1-1 Data Exchange & GIS + Mapping", NENA-02-010, Version 9, December 2010, + <http://www.nena.org>. + + [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private + Extensions to the Session Initiation Protocol (SIP) for + Asserted Identity within Trusted Networks", RFC 3325, + DOI 10.17487/RFC3325, November 2002, + <http://www.rfc-editor.org/info/rfc3325>. + + [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Indicating User Agent Capabilities in the Session + Initiation Protocol (SIP)", RFC 3840, + DOI 10.17487/RFC3840, August 2004, + <http://www.rfc-editor.org/info/rfc3840>. + + [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for + Emergency Context Resolution with Internet Technologies", + RFC 5012, DOI 10.17487/RFC5012, January 2008, + <http://www.rfc-editor.org/info/rfc5012>. + + + + +Gellens, et al. Standards Track [Page 86] + +RFC 7852 Additional Call Data July 2016 + + + [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location + Format for Presence Information Data Format Location + Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, + February 2008, <http://www.rfc-editor.org/info/rfc5139>. + + [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV + Presence Information Data Format Location Object (PIDF-LO) + Usage Clarification, Considerations, and Recommendations", + RFC 5491, DOI 10.17487/RFC5491, March 2009, + <http://www.rfc-editor.org/info/rfc5491>. + + [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and + Framework", RFC 5582, DOI 10.17487/RFC5582, September + 2009, <http://www.rfc-editor.org/info/rfc5582>. + + [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. + Thomson, "Dynamic Extensions to the Presence Information + Data Format Location Object (PIDF-LO)", RFC 5962, + DOI 10.17487/RFC5962, September 2010, + <http://www.rfc-editor.org/info/rfc5962>. + + [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", + RFC 5985, DOI 10.17487/RFC5985, September 2010, + <http://www.rfc-editor.org/info/rfc5985>. + + [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, + "Framework for Emergency Calling Using Internet + Multimedia", RFC 6443, DOI 10.17487/RFC6443, December + 2011, <http://www.rfc-editor.org/info/rfc6443>. + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August + 2012, <http://www.rfc-editor.org/info/rfc6698>. + + [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and + R. George, "Specifying Civic Address Extensions in the + Presence Information Data Format Location Object (PIDF- + LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013, + <http://www.rfc-editor.org/info/rfc6848>. + + [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for + Communications Services in Support of Emergency Calling", + BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, + <http://www.rfc-editor.org/info/rfc6881>. + + + + + + +Gellens, et al. Standards Track [Page 87] + +RFC 7852 Additional Call Data July 2016 + + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <http://www.rfc-editor.org/info/rfc6973>. + + [RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. + Thomson, "Relative Location Representation", RFC 7035, + DOI 10.17487/RFC7035, October 2013, + <http://www.rfc-editor.org/info/rfc7035>. + + [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. + Patel, "Public Safety Answering Point (PSAP) Callback", + RFC 7090, DOI 10.17487/RFC7090, April 2014, + <http://www.rfc-editor.org/info/rfc7090>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <http://www.rfc-editor.org/info/rfc7525>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 88] + +RFC 7852 Additional Call Data July 2016 + + +Appendix A. XML Schema for vCard/xCard + + This section contains the vCard/xCard XML schema version of the Relax + NG schema defined in RFC 6351 [RFC6351] for use with the XML schemas + defined in this document. In addition to mapping the Relax NG schema + to an XML schema, this specification applies an erratum raised for + RFC 6351 regarding the type definition; see RFC Erratum ID 3047 + [Err3047]. + + <?xml version="1.0" encoding="UTF-8"?> + <xs:schema + targetNamespace="urn:ietf:params:xml:ns:vcard-4.0" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:ns1="urn:ietf:params:xml:ns:vcard-4.0" + elementFormDefault="qualified"> + <!-- + 3.3 + iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" } + x-name = xsd:string { pattern = "x-[a-zA-Z0-9-]+" } + --> + <xs:simpleType name="iana-token"> + <xs:annotation> + <xs:documentation>Section 3.3: vCard Format Specification + </xs:documentation> + </xs:annotation> + <xs:restriction base="xs:string"/> + </xs:simpleType> + <xs:simpleType name="x-name"> + <xs:restriction base="xs:string"/> + </xs:simpleType> + <!-- + 4.1 + --> + <xs:element name="text" type="xs:string"/> + <xs:group name="value-text-list"> + <xs:sequence> + <xs:element ref="ns1:text" maxOccurs="unbounded"/> + </xs:sequence> + </xs:group> + <!-- 4.2 --> + <xs:element name="uri" type="xs:anyURI"/> + <!-- 4.3.1 --> + <xs:element name="date" + substitutionGroup="ns1:value-date-and-or-time"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:pattern + value="\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d"/> + + + +Gellens, et al. Standards Track [Page 89] + +RFC 7852 Additional Call Data July 2016 + + + </xs:restriction> + </xs:simpleType> + </xs:element> + <!-- 4.3.2 --> + <xs:element name="time" + substitutionGroup="ns1:value-date-and-or-time"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:pattern value= + "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)(Z|[+\-]\d\d(\d\d)?)?"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + <!-- 4.3.3 --> + <xs:element name="date-time" + substitutionGroup="ns1:value-date-and-or-time"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:pattern value= + "(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?(Z|[+\-]\d\d(\d\d)?)?"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + <!-- 4.3.4 --> + <xs:element name="value-date-and-or-time" abstract="true"/> + <!-- 4.3.5 --> + <xs:complexType name="value-timestamp"> + <xs:sequence> + <xs:element ref="ns1:timestamp"/> + </xs:sequence> + </xs:complexType> + <xs:element name="timestamp"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:pattern value="\d{8}T\d{6}(Z|[+\-]\d\d(\d\d)?)?"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + <!-- 4.4 --> + <xs:element name="boolean" type="xs:boolean"/> + <!-- 4.5 --> + <xs:element name="integer" type="xs:integer"/> + <!-- 4.6 --> + <xs:element name="float" type="xs:float"/> + <!-- 4.7 --> + <xs:element name="utc-offset"> + <xs:simpleType> + <xs:restriction base="xs:string"> + + + +Gellens, et al. Standards Track [Page 90] + +RFC 7852 Additional Call Data July 2016 + + + <xs:pattern value="[+\-]\d\d(\d\d)?"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + <!-- 4.8 --> + <xs:element name="language-tag"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:pattern value= + "([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8})(-[a-z]{4})? + (-([a-z]{2}|\d{3}))?(-([0-9a-z]{5,8}|\d[0-9a-z]{3}))* + (-[0-9a-wyz](-[0-9a-z]{2,8})+)*(-x(-[0-9a-z]{1,8})+)? + |x(-[0-9a-z]{1,8})+|[a-z]{1,3}(-[0-9a-z]{2,8}){1,2}"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + <!-- + 5.1 + --> + <xs:group name="param-language"> + <xs:annotation> + <xs:documentation>Section 5: Parameters</xs:documentation> + </xs:annotation> + <xs:sequence> + <xs:element ref="ns1:language" minOccurs="0"/> + </xs:sequence> + </xs:group> + <xs:element name="language"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:language-tag"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 5.2 --> + <xs:group name="param-pref"> + <xs:sequence> + <xs:element ref="ns1:pref" minOccurs="0"/> + </xs:sequence> + </xs:group> + <xs:element name="pref"> + <xs:complexType> + <xs:sequence> + <xs:element name="integer"> + <xs:simpleType> + <xs:restriction base="xs:integer"> + <xs:minInclusive value="1"/> + <xs:maxInclusive value="100"/> + + + +Gellens, et al. Standards Track [Page 91] + +RFC 7852 Additional Call Data July 2016 + + + </xs:restriction> + </xs:simpleType> + </xs:element> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 5.4 --> + <xs:group name="param-altid"> + <xs:sequence> + <xs:element ref="ns1:altid" minOccurs="0"/> + </xs:sequence> + </xs:group> + <xs:element name="altid"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 5.5 --> + <xs:group name="param-pid"> + <xs:sequence> + <xs:element ref="ns1:pid" minOccurs="0"/> + </xs:sequence> + </xs:group> + <xs:element name="pid"> + <xs:complexType> + <xs:sequence> + <xs:element name="text" maxOccurs="unbounded"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:pattern value="\d+(\.\d+)?"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 5.6 --> + <xs:group name="param-type"> + <xs:sequence> + <xs:element ref="ns1:type" minOccurs="0"/> + </xs:sequence> + </xs:group> + <xs:element name="type"> + <xs:complexType> + <xs:sequence> + <xs:element name="text" maxOccurs="unbounded"> + + + +Gellens, et al. Standards Track [Page 92] + +RFC 7852 Additional Call Data July 2016 + + + <xs:simpleType> + <xs:restriction base="xs:token"> + <xs:enumeration value="work"/> + <xs:enumeration value="home"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 5.7 --> + <xs:group name="param-mediatype"> + <xs:sequence> + <xs:element ref="ns1:mediatype" minOccurs="0"/> + </xs:sequence> + </xs:group> + <xs:element name="mediatype"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 5.8 --> + <xs:group name="param-calscale"> + <xs:sequence> + <xs:element ref="ns1:calscale" minOccurs="0"/> + </xs:sequence> + </xs:group> + <xs:element name="calscale"> + <xs:complexType> + <xs:sequence> + <xs:element name="text"> + <xs:simpleType> + <xs:restriction base="xs:token"> + <xs:enumeration value="gregorian"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 5.9 --> + <xs:group name="param-sort-as"> + <xs:sequence> + <xs:element ref="ns1:sort-as" minOccurs="0"/> + </xs:sequence> + </xs:group> + + + +Gellens, et al. Standards Track [Page 93] + +RFC 7852 Additional Call Data July 2016 + + + <xs:element name="sort-as"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:text" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 5.10 --> + <xs:group name="param-geo"> + <xs:sequence> + <xs:element name="geo" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + </xs:sequence> + </xs:group> + <!-- 5.11 --> + <xs:group name="param-tz"> + <xs:sequence> + <xs:element name="tz" minOccurs="0"> + <xs:complexType> + <xs:choice> + <xs:element ref="ns1:text"/> + <xs:element ref="ns1:uri"/> + </xs:choice> + </xs:complexType> + </xs:element> + </xs:sequence> + </xs:group> + <!-- + 6.1.3 + --> + <xs:element name="source"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + + + +Gellens, et al. Standards Track [Page 94] + +RFC 7852 Additional Call Data July 2016 + + + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.1.4 --> + <xs:element name="kind"> + <xs:complexType> + <xs:sequence> + <xs:annotation> + <xs:documentation> + The text value must be one of: individual, group, org, + location or a ns1:x-name or a ns1:iana-token value + </xs:documentation> + </xs:annotation> + <xs:element name="text" type="xs:token" + minOccurs="1" maxOccurs="1"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.2.1 --> + <xs:element name="fn"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.2.2 --> + <xs:element name="n"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-sort-as"/> + <xs:group ref="ns1:param-altid"/> + + + +Gellens, et al. Standards Track [Page 95] + +RFC 7852 Additional Call Data July 2016 + + + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:surname" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:given" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:additional" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:prefix" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:suffix" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element name="surname" type="xs:string"/> + <xs:element name="given" type="xs:string"/> + <xs:element name="additional" type="xs:string"/> + <xs:element name="prefix" type="xs:string"/> + <xs:element name="suffix" type="xs:string"/> + <!-- 6.2.3 --> + <xs:element name="nickname"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:group ref="ns1:value-text-list"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.2.4 --> + <xs:element name="photo"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + + + +Gellens, et al. Standards Track [Page 96] + +RFC 7852 Additional Call Data July 2016 + + + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.2.5 --> + <xs:element name="bday"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-calscale"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:choice> + <xs:element ref="ns1:value-date-and-or-time"/> + <xs:element ref="ns1:text"/> + </xs:choice> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.2.6 --> + <xs:element name="anniversary"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-calscale"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:choice> + <xs:element ref="ns1:value-date-and-or-time"/> + <xs:element ref="ns1:text"/> + </xs:choice> + </xs:sequence> + </xs:complexType> + + + +Gellens, et al. Standards Track [Page 97] + +RFC 7852 Additional Call Data July 2016 + + + </xs:element> + <!-- 6.2.7 --> + <xs:element name="gender"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:sex"/> + <xs:element ref="ns1:identity" minOccurs="0"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element name="sex"> + <xs:simpleType> + <xs:restriction base="xs:token"> + <xs:enumeration value=""/> + <xs:enumeration value="M"/> + <xs:enumeration value="F"/> + <xs:enumeration value="O"/> + <xs:enumeration value="N"/> + <xs:enumeration value="U"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + <xs:element name="identity" type="xs:string"/> + <!-- 6.3.1 --> + <xs:group name="param-label"> + <xs:sequence> + <xs:element ref="ns1:label" minOccurs="0"/> + </xs:sequence> + </xs:group> + <xs:element name="label"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element name="adr"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-geo"/> + + + +Gellens, et al. Standards Track [Page 98] + +RFC 7852 Additional Call Data July 2016 + + + <xs:group ref="ns1:param-tz"/> + <xs:group ref="ns1:param-label"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:pobox" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:ext" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:street" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:locality" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:region" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:code" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element ref="ns1:country" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element name="pobox" type="xs:string"/> + <xs:element name="ext" type="xs:string"/> + <xs:element name="street" type="xs:string"/> + <xs:element name="locality" type="xs:string"/> + <xs:element name="region" type="xs:string"/> + <xs:element name="code" type="xs:string"/> + <xs:element name="country" type="xs:string"/> + <!-- 6.4.1 --> + <xs:element name="tel"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid" + minOccurs="0"/> + <xs:group ref="ns1:param-pid" + minOccurs="0"/> + <xs:group ref="ns1:param-pref" + minOccurs="0"/> + <xs:element name="type" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:element name="text" + type="xs:string" + maxOccurs="unbounded"> + + + +Gellens, et al. Standards Track [Page 99] + +RFC 7852 Additional Call Data July 2016 + + + </xs:element> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:choice> + <xs:element ref="ns1:text"/> + <xs:element ref="ns1:uri"/> + </xs:choice> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.4.2 --> + <xs:element name="email"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.4.3 --> + <xs:element name="impp"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + + + +Gellens, et al. Standards Track [Page 100] + +RFC 7852 Additional Call Data July 2016 + + + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.4.4 --> + <xs:element name="lang"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:language-tag"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.5.1 --> + <xs:group name="property-tz"> + <xs:sequence> + <xs:element name="tz"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group + ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:choice> + <xs:element ref="ns1:text"/> + <xs:element ref="ns1:uri"/> + <xs:element ref="ns1:utc-offset"/> + </xs:choice> + </xs:sequence> + </xs:complexType> + </xs:element> + + + +Gellens, et al. Standards Track [Page 101] + +RFC 7852 Additional Call Data July 2016 + + + </xs:sequence> + </xs:group> + <!-- 6.5.2 --> + <xs:group name="property-geo"> + <xs:sequence> + <xs:element name="geo"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group + ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + </xs:sequence> + </xs:group> + <!-- 6.6.1 --> + <xs:element name="title"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.6.2 --> + <xs:element name="role"> + <xs:complexType> + + + +Gellens, et al. Standards Track [Page 102] + +RFC 7852 Additional Call Data July 2016 + + + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.6.3 --> + <xs:element name="logo"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.6.4 --> + <xs:element name="org"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + + + +Gellens, et al. Standards Track [Page 103] + +RFC 7852 Additional Call Data July 2016 + + + <xs:group ref="ns1:param-sort-as"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:group ref="ns1:value-text-list"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.6.5 --> + <xs:element name="member"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.6.6 --> + <xs:element name="related"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:element name="type" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:element name="text" maxOccurs="unbounded"> + <xs:simpleType> + <xs:restriction base="xs:token"> + <xs:enumeration value="work"/> + <xs:enumeration value="home"/> + <xs:enumeration value="contact"/> + <xs:enumeration value="acquaintance"/> + <xs:enumeration value="friend"/> + <xs:enumeration value="met"/> + + + +Gellens, et al. Standards Track [Page 104] + +RFC 7852 Additional Call Data July 2016 + + + <xs:enumeration value="co-worker"/> + <xs:enumeration value="colleague"/> + <xs:enumeration value="co-resident"/> + <xs:enumeration value="neighbor"/> + <xs:enumeration value="child"/> + <xs:enumeration value="parent"/> + <xs:enumeration value="sibling"/> + <xs:enumeration value="spouse"/> + <xs:enumeration value="kin"/> + <xs:enumeration value="muse"/> + <xs:enumeration value="crush"/> + <xs:enumeration value="date"/> + <xs:enumeration value="sweetheart"/> + <xs:enumeration value="me"/> + <xs:enumeration value="agent"/> + <xs:enumeration value="emergency"/> + </xs:restriction> + </xs:simpleType> + </xs:element> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:choice> + <xs:element ref="ns1:uri"/> + <xs:element ref="ns1:text"/> + </xs:choice> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.7.1 --> + <xs:element name="categories"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:group ref="ns1:value-text-list"/> + + + +Gellens, et al. Standards Track [Page 105] + +RFC 7852 Additional Call Data July 2016 + + + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.7.2 --> + <xs:element name="note"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.7.3 --> + <xs:element name="prodid"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:text"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.7.4 --> + <xs:element name="rev" type="ns1:value-timestamp"/> + <!-- 6.7.5 --> + <xs:element name="sound"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-language"/> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + + + +Gellens, et al. Standards Track [Page 106] + +RFC 7852 Additional Call Data July 2016 + + + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.7.6 --> + <xs:element name="uid"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.7.7 --> + <xs:element name="clientpidmap"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:sourceid"/> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element name="sourceid" type="xs:positiveInteger"/> + <!-- 6.7.8 --> + <xs:element name="url"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.8.1 --> + <xs:element name="key"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + + + +Gellens, et al. Standards Track [Page 107] + +RFC 7852 Additional Call Data July 2016 + + + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:choice> + <xs:element ref="ns1:uri"/> + <xs:element ref="ns1:text"/> + </xs:choice> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.9.1 --> + <xs:element name="fburl"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.9.2 --> + <xs:element name="caladruri"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + + + +Gellens, et al. Standards Track [Page 108] + +RFC 7852 Additional Call Data July 2016 + + + </xs:element> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- 6.9.3 --> + <xs:element name="caluri"> + <xs:complexType> + <xs:sequence> + <xs:element name="parameters" minOccurs="0"> + <xs:complexType> + <xs:sequence> + <xs:group ref="ns1:param-altid"/> + <xs:group ref="ns1:param-pid"/> + <xs:group ref="ns1:param-pref"/> + <xs:group ref="ns1:param-type"/> + <xs:group ref="ns1:param-mediatype"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:element ref="ns1:uri"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <!-- Top-level grammar --> + <xs:group name="property"> + <xs:sequence> + <xs:element ref="ns1:adr" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:anniversary" minOccurs="0" + maxOccurs="1"/> + <xs:element ref="ns1:bday" minOccurs="0" + maxOccurs="1"/> + <xs:element ref="ns1:caladruri" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:caluri" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:categories" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:clientpidmap" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:email" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:fburl" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:fn" minOccurs="1" + maxOccurs="unbounded"/> + <xs:group ref="ns1:property-geo" minOccurs="0" + + + +Gellens, et al. Standards Track [Page 109] + +RFC 7852 Additional Call Data July 2016 + + + maxOccurs="unbounded"/> + <xs:element ref="ns1:impp" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:key" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:kind" minOccurs="0" + maxOccurs="1"/> + <xs:element ref="ns1:lang" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:logo" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:member" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:n" minOccurs="0" + maxOccurs="1"/> + <xs:element ref="ns1:nickname" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:note" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:org" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:photo" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:prodid" minOccurs="0" + maxOccurs="1"/> + <xs:element ref="ns1:related" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:rev" minOccurs="0" + maxOccurs="1"/> + <xs:element ref="ns1:role" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:gender" minOccurs="0" + maxOccurs="1"/> + <xs:element ref="ns1:sound" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:source" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:tel" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:title" minOccurs="0" + maxOccurs="unbounded"/> + <xs:group ref="ns1:property-tz" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="ns1:uid" minOccurs="0" + maxOccurs="1"/> + <xs:element ref="ns1:url" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + + + +Gellens, et al. Standards Track [Page 110] + +RFC 7852 Additional Call Data July 2016 + + + </xs:group> + <xs:element name="vcards"> + <xs:complexType> + <xs:sequence> + <xs:element ref="ns1:vcard" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:complexType name="vcardType"> + <xs:sequence> + <xs:group ref="ns1:property"/> + <xs:element ref="ns1:group" minOccurs="0" + maxOccurs="unbounded"/> + <xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + <xs:element name="vcard" type="ns1:vcardType"/> + <xs:element name="group"> + <xs:complexType> + <xs:group ref="ns1:property"/> + <xs:attribute name="name" use="required"/> + </xs:complexType> + </xs:element> + </xs:schema> + +Appendix B. XML Validation + + This document defines a number of XML schemas and contains various + examples. Extracting the XML and validating the examples against the + schemas can be challenging, especially due to the formatting + limitations introduced by IETF RFCs. For those readers who copy the + XML schemas and examples directly from this document, please consider + that errors might be introduced due to line breaks and extra + whitespaces in the regular expressions contained in the vCard schema + in Appendix A. To validate the PIDF-LO from Figure 18, it is also + necessary to consult the referenced RFCs and copy the schemas + necessary for successful validation. + + The XML schemas found in this document include a 'SchemaLocation' + attribute. Depending on the location of the downloaded schema files, + you may need to adjust this schema location or configure your XML + editor to point to the location. + + For the convenience of the reader, the schemas are available at + [IANA-XML-Schemas], and the XML examples are available at the IETF + ECRIT working group wiki page [ECRIT-WG-wiki]. + + + + +Gellens, et al. Standards Track [Page 111] + +RFC 7852 Additional Call Data July 2016 + + +Acknowledgments + + This work was originally started in NENA and has benefited from a + large number of participants involved in NENA standardization + efforts, originally in the Long Term Definition working group, the + Data Technical Committee, and most recently in the Additional Data + working group. The authors are grateful for the initial work and + extended comments provided by many NENA participants, including + Delaine Arnold, Marc Berryman, Guy Caron, Brian Dupras, Mark + Fletcher, James Leyerle, Kathy McMahon, Christian Militeau, Ira + Pyles, Matt Serra, and Robert (Bob) Sherry. Amursana Khiyod, Robert + Sherry, Frank Rahoi, Scott Ross, and Tom Klepetka provided valuable + feedback regarding the vCard/xCard use in this specification. + + We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin + Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris + Santer, Archie Cobbs, Magnus Nystrom, Stephen Farrell, Amanda Baber, + Dan Banks, Andrew Newton, Philip Reichl, and Francis Dupont for their + review comments. Alissa Cooper, Guy Caron, Ben Campbell, and Barry + Leiba deserve special mention for their detailed and extensive review + comments, which were very helpful and appreciated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 112] + +RFC 7852 Additional Call Data July 2016 + + +Authors' Addresses + + Randall Gellens + San Diego, CA 92121 + United States + + Email: rg+ietf@randy.pensive.org + + + Brian Rosen + NeuStar + 470 Conrad Dr. + Mars, PA 16046 + United States + + Phone: +1 724 382 1051 + Email: br@brianrosen.net + + + Hannes Tschofenig + Hall in Tirol 6060 + Austria + + Email: Hannes.tschofenig@gmx.net + URI: http://www.tschofenig.priv.at + + + Roger Marshall + TeleCommunication Systems, Inc. + 2401 Elliott Avenue + Seattle, WA 98121 + United States + + Phone: +1 206 792 2424 + Email: rmarshall@telecomsys.com + URI: http://www.telecomsys.com + + + James Winterbottom + Winterb Consulting Services + Gwynneville, NSW 2500 + Australia + + Phone: +61 448 266004 + Email: a.james.winterbottom@gmail.com + + + + + + +Gellens, et al. Standards Track [Page 113] + |