RFC 7852
Additional Data Related to an Emergency Call
RFC 7852: Additional Data Related to an Emergency Call ✨
Okay bestie, welcome to RFC 7852! 💖 This is part 1 of 21, so the front matter comes first. Let's get into it 🎀
The Title Block 📋
This RFC is a Standards Track document, so it's a real spec that implementers are supposed to follow 💅 It's from July 2016, and its ISSN is 2070-1721 🦋
- Number: RFC 7852
- Title: Additional Data Related to an Emergency Call
- Updates: RFC 6443 and RFC 6881 🔥 This document updates them, so you need to read it alongside those two.
- Obsoletes: nothing is listed here.
- Authors: R. Gellens, B. Rosen, H. Tschofenig, R. Marshall, and J. Winterbottom 👑
- Affiliations: B. Rosen is with NeuStar, R. Marshall is with TeleCommunication Systems, Inc., and J. Winterbottom is with Winterb Consulting Services 🌈
Abstract 🌸
So when an emergency call goes to a Public Safety Answering Point (PSAP), a bunch of people already know stuff that could help the PSAP handle it. The originating device knows things, the access network provider knows things, and every service provider along the path knows things too. That's info about the call, the caller, or the location 😭
This document defines data structures and mechanisms for getting that info to the PSAP. The goal is that every emergency call carries as much of it as possible, using these mechanisms ✨
The data can travel by reference, meaning as an external resource, or by value, meaning inside the body of a SIP message or a location object. This copies the vibe of older emergency services work, where data could go by value inside the call signaling (that's the body of the SIP message) or by reference 🧚
Status of This Memo 💜
This is an Internet Standards Track document 💅
It's a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🫶
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7852 🔗
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, which you can find at http://trustee.ietf.org/license-info. Those rules were in effect on the date this document was published. Please read them carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come 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
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
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 . . . . . . . . . . . . . . . . . . . . . . . 113Part 1 is done, bestie! 🎉 Next up in part 2 is Section 1, Introduction 💖 Stay tuned for the rest of the spec ✨
1. Introduction ✨
okay so when an IP-based emergency call goes out, a whole bunch of data rides along to the PSAP (Public Safety Answering Point) 🚨. That includes who's calling, what the device can do, why they're reaching out for emergency services, where they are, and metadata about where all of that info came from. And the device, the access network provider, and any service provider in the call path know even MORE stuff that's super useful for a PSAP handling an emergency 💅
This doc levels up the basic emergency call data that rides on SIP (as laid out in RFC 6443 [RFC6443] and RFC 6881 [RFC6881]) by adding extra "Additional Data" that helps whoever is handling the call 🫶. It's "additional" because it sits on top of the basic info in the emergency call signaling. The goal is for every emergency call to carry as much of this as possible, using the mechanisms described here 🎀
This doc defines three categories of this additional data that can be sent with an emergency call:
- Data Associated with a Location: Primary location data goes in the Presence Information Data Format Location Object (PIDF-LO) data structure, defined in RFC 4119 [RFC4119] and extended by RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location info), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for geodetic location info), and RFC 7035 [RFC7035] (for relative location). This primary location data tells you where the caller is, or where they're estimated to be 📍. But there can be extra, secondary data that's specific to the location, like floor plans, tenant and building owner contact info, heating, ventilation, and air conditioning (HVAC) status, etc. 🏢 That secondary stuff isn't in the location data structure, but it can be sent using the mechanisms in this doc. This doc doesn't define any structures for it yet, but future docs can, following the procedures set out here ✨
- Data Associated with a Call: Some info is carried in the call setup itself (in the SIP headers and the body of the SIP message), but there's also extra data known by the device making the call, the access network it's connected to, and the service providers along the call path 🛰️. That includes service provider contact info, subscriber identity and contact info, the type of service the service provider and access network provide, what kind of device is being used, etc. Some of it applies broadly, and some depends on the device or service. For example, a medical monitoring device might have sensor data 🩺. The data structures defined in this doc (Data Provider Information, Device Information, and Owner/Subscriber Information) all fall into the "Data Associated with a Call" bucket. Heads up: the owner/subscriber info includes the subscriber's vCard, which might have personal stuff like a birthday or anniversary 🎂, but the data block is still considered to be about the call, not the caller 💜
- Data Associated with a Caller: This is personal data about a caller, like medical info and emergency contact data 🌸. This doc doesn't define any structures in this category, but future docs can do so following the procedures set out here
This doc only defines data structures within the Data Associated with a Call category. But by setting up the overall framework for Additional Data, along with general transport mechanisms, extension points, and procedures for future extensions, it cuts down the work needed to carry data in the other categories 🧚. Other specs can make use of what's provided here 🌈
For interoperability, the info sent to a PSAP needs a common way to be encoded and identified 🤝. Identification lets emergency services authorities know, during call processing, which types of data are present and decide whether they want to access it. A common encoding means the data can actually be accessed successfully 🔑
This doc defines an extensible set of data structures and mechanisms to transmit this data either by value or by reference, and either in the SIP call signaling or in the PIDF-LO 💖. The data structures can be used by other communication systems and transports too 🦋. The data structures are defined in Section 4, and the transport mechanisms (using SIP and HTTPS) are defined in Section 6 ⭐
Each data structure in this doc is encoded as a "block" of information 📦. Each block is an XML structure with an associated Multipurpose Internet Mail Extensions (MIME) media type so it can be identified within transports like SIP and HTTPS. The set of blocks is extensible. Registries are defined to identify which block types can be used and to allow blocks to be included in emergency call signaling 📋
Real talk though: a lot of the info supplied by service providers and devices is private and confidential 🙈. They usually go to great lengths to protect it. Disclosing it in an emergency call is a trade-off, made 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 doc also uses terminology from [RFC5012] 💅. We use the term "service provider" to mean an Application Service Provider (ASP). A Voice Service Provider (VSP) is a special type of ASP 📞. With the term "Access Network Provider," we mean the Internet Access Provider (IAP) and the Internet Service Provider (ISP), without splitting hairs between the two, since the difference doesn't matter for this doc 🌐. Note that one company might play both the ASP and access network provider roles at once 🫶. An Emergency Services Provider is an entity directly involved in providing emergency services. That includes PSAPs, 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 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 all kinds of info about individuals and other entities 👯. But for apps that use XML, the vCard format isn't immediately applicable. So there's an XML-based encoding of the info elements defined in the vCard spec, and that's called xCard [RFC6351] 🧩. Since most readers are more familiar with the term vCard, we use the terms xCard and vCard interchangeably 🌸
3. Document Scope 🚧
The scope of this doc is explicitly limited to emergency calls 🚨. The data structures defined here are not appropriate to send in non-emergency calls, because they carry sensitive and private data 🙅♀️. But there's an exception: in certain private-use situations, like between a specialized service provider (such as a vehicle telematics service provider) and dedicated equipment (such as the stuff inside a vehicle), the endpoints might already have a relationship, and privacy is handled within that relationship. In that case, the mechanisms and data structures defined here can be used for communications within the limited context of that preexisting relationship 🚗💕
4. Data Structures 🧱
This section defines 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': supplies name and contact info for the entity that created the data. Section 4.1 has the details 🧑💼'Service Information': supplies info about the service. The description is in Section 4.2 📶'Device Information': supplies info about the device placing the call. You'll find it in Section 4.3 📱'Owner/Subscriber': supplies info about the owner of the device or about the subscriber. Details are in Section 4.4 👑'Comment': gives 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 point of the <DataProviderReference> element is to tie together all blocks added by the same data provider as a unit. It links the data provider block to each of the other blocks added as a unit. So when a data provider adds more data to an emergency call (like device information), it MUST add info about itself (via the data provider block), and the blocks it adds 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 💖. (Sometimes the same provider processes a call more than once, probably in different roles. In those 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]. The one difference is that the <DataProviderReference> element isn't wrapped in brackets, so the '<' and '>' symbols are left out. In other words, a <DataProviderReference> value 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 it's 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 🔍
Here's a tricky bit: the xCard format gets reused in some of the data structures to provide contact info 📇. But xCard has no way to specify a 'main' telephone number, meaning a primary or main contact number (typically for an enterprise, as opposed to someone's direct-dial number) 🏬. Those main numbers are super useful to emergency responders who get called to a large enterprise 🚒. So this doc adds a new parameter value called 'main-number' to the 'TYPE' parameter of the 'tel' property 🎉. It can be used in any xCard in an emergency call additional data block 💅
4.1. Data Provider Information ✨
okay so this block is the "who gave us this info" block 🫶 It's meant to be filled in by any service provider in the path of the call, the access network provider, and the device. It holds identification and contact info. 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 too if those entities don't add any other blocks. Devices SHOULD use this block to share their identifying info 💖
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 that's good 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: So the call taker knows who is providing the data 👑
How Used by Call Taker: It lets the call taker interpret the data in this structure. The source of the info often changes how it gets used, believed, or verified. Main character energy for the source 💅
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, so the service provider or access provider can be uniquely identified 🔥
XML Element: <ProviderID>
Description: This is 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 that's appropriate for the jurisdiction. In the United States, if the provider is registered with NENA, the provider's NENA Company ID MUST appear here. More info is 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 this format: urn:nena:companyid:<NENA Company ID>. If the organization doesn't 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: So the call taker knows who's providing the data 🫶
How Used by Call Taker: Where jurisdictions have lists of providers, the Data Provider ID gives useful info about where the data came from. It uniquely identifies the data source, which can be really needed in unusual circumstances and for routine logging. Lowkey the most important ID in the whole block 🦋
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: This identifies the issuer of the <ProviderID>. The "Provider ID Series" registry created in Section 11.1.1 starts out with the entries shown in Figure 1 📚
Reason for Need: It tells you how to read the Data Provider ID. The combination of ProviderIDSeries and ProviderID MUST be globally unique. No duplicates allowed, bestie 🙅♀️
How Used by Call Taker: It decides which provider ID registry to check for more info 🔍
+-----------+--------------------------+----------------------+
| 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: This identifies the type of data provider that's supplying the data. The registry holding all the valid values is created in Section 11.1.5, and the starting set of values is shown in Figure 2 🌷
Reason for Need: It identifies the category of data provider 🍓
How Used by Call Taker: This info can be super helpful when deciding who to contact if more info is needed 📞
+------------------------------+------------------------------------+
| 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 a service provider or an access network provider provides this, it's expected to be a URI for a 24/7 support organization that's set up to give PSAP support for this emergency call 🌙 When a device provides it, this MUST be the contact info of the user or owner of the device. (Ideally that's the device user, but when the owner and user are different, like if the device owner is an organization, this MAY be the owner's contact info.) The Data Provider Contact URI SHOULD be a tel URI [RFC3966] in E.164 format, fully specified with a country code. If a tel URI isn't available, a generic SIP URI is fine 📱 Note that this contact info is NOT used by PSAPs for callbacks. (A callback is a call from a PSAP that's directly related to a recently ended emergency call, placed by the PSAP using a SIP Priority header field set to 'psap-callback', as described in [RFC7090].) 🙈
Reason for Need: Extra data providers might need to be contacted in error cases or other unusual circumstances 🚨
How Used by Call Taker: To reach the supplier of the additional data for help 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 is a single token from the Language Subtag Registry, which you can find at [LanguageSubtagRegistry] and which is defined in [RFC5646] 🌍 Multiple instances of this element MAY occur, but the order matters, and the preferred language SHOULD appear first. The content MUST reflect the languages supported at the contact URI 💜
(Quick aside: this field tells the PSAP what language(s) the data provider uses. If the PSAP needs to contact the data provider, it helps to know the language(s) ahead of time. If the PSAP uses a communication protocol to reach the data provider, that protocol might have its own language stuff, like the 'language' media feature tag defined in RFC 3840 [RFC3840], and the more extensive language negotiation mechanism proposed in [HUMAN-LANG]. If so, those work independently of this field 🧚)
Reason for Need: It shows whether the emergency service authority can talk directly with the service provider, or whether an interpreter will be needed 🗣️
How Used by Call Taker: If the call taker can't speak any language the service provider supports, a translation service will need to be added to the conversation. Or other people at the PSAP, besides the call taker, might be consulted for help, depending on how urgent things are and what kind of interaction it is 🎀
4.1.7. xCard of Data Provider
Data Element: xCard of Data Provider
Use: Optional
XML Element: <DataProviderContact>
Description: Okay bestie, so per [RFC6351] the xCard lives inside a <vcard> element 💌 A structure can hold more than one <vcard> element, but you SHOULD provide just one 💅. If more than one shows up anyway, the first one SHOULD be used 🫶. There are SO many fields in an xCard, and the creator is encouraged to fill in all the info they have 🌈. N, ORG, ADR, TEL, and EMAIL are suggested as the bare minimum ✨. N SHOULD contain the name of the support group or device owner, as appropriate 🎀. If there's more than one TEL property, a parameter from the "vCard Property Values" registry SHOULD be specified for each TEL 🍓. For encoding, this spec uses the XML-based encoding from [RFC6351], which it calls 'xCard' throughout the doc 🦋.
Reason for Need: Information needed to determine additional contact information 📞
How Used by Call Taker: The call taker gets extra contact info beyond what's already in the SIP INVITE or the PIDF-LO, so it's giving helpful backup 💖
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>
Description: Some providers outsource parts of their emergency services duties to specialized providers 🙈. If the data provider is a subcontractor to another provider, this element contains the DataProviderString of the service provider, so everyone knows who the subcontractor is working for 💜.
Reason for Need: Identify the entity the subcontractor works for.
How Used by Call Taker: The call taker can see the relationship between the data providers and the service providers along the path of the call. Main character energy for the whole chain 👑.
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 the one to call first 📞, then this element MUST have the value 'sub'. If the provider the subcontractor is working for is the one to call first, then this element MUST have the value 'main'.
Reason for Need: Tells the call taker who to contact first if support is needed 🫶.
How Used by Call Taker: Helps the call taker 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">
<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>
<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 🎀
4.2. Service Information
This block describes the service that the service provider gives 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 tells you whether a call is coming from a business or a residence 🏢🏠. Right now, the only valid entries are 'Business', 'Residence', and 'Unknown', as shown in Figure 4 💖. New values can be defined through the registry created in Section 11.1.2 🌸.
Reason for Need: To give context and a hint when figuring out equipment and manpower needs 🧠.
How Used by Call Taker: The info gives context and a hint that helps responders figure out how much equipment and manpower they'll need 🚒. It's non-authoritative, though 🙈. The service provider doesn't always know the type of service, like with an anonymous prepaid plan. The service type also doesn't always match the premises, like a business line installed in a home, or cellular service. The registry doesn't have every possible value for every situation either. So it's really only advisory, BUT it copies a similar feature in some current emergency calling systems (like a field in the Automatic Location Information (ALI) used with legacy North American wireline systems), and PSAPs find it super valuable 👑. The service provider uses its best info (like a rate plan, the facilities used to deliver service, or a service description) to work this out. It isn't responsible for determining the actual characteristics of the location where the call started 🫶. Since the usefulness is unknown (and less clear) for cellular, this element is OPTIONAL for commercial mobile radio services (e.g., cellular) and REQUIRED otherwise 💅.
+-----------+--------------------------+
| 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>
okay so this one tells everyone what kind of service the call was placed over 🎀 (kinda like the Class of Service that legacy emergency calls had in some regions 📞). The implied mobility of this service cannot be relied upon 🙈. There's a registry for it in Section 11.1.3 💅, and the starter values are in Figure 5. More than one value MAY be returned 💖, like a VoIP inmate telephone service, which is a totally reasonable combo 😭.
Reason for Need: knowing the type of service helps the PSAP handle the call 🫶.
How Used by Call Taker: call takers use this to figure out what questions to ask and how much to trust the supporting info 🧚. It's not always there, and the registry isn't all-encompassing, so it's basically advisory info 🦋. But it copies something legacy 911 systems already did, so it's known to be valuable ✨.
+--------------+------------------------------------------+
| Name | Description |
+--------------+------------------------------------------+
| wireless | Wireless Telephone Service: Includes |
| | CDMA, GSM, Wi-Fi, WiMAX, and LTE |
| | (but not satellite) |
| | |
| 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 starter values were gathered from systems people are actually using right now, including [NENA-02-010], [nc911], [NANP], and [LERG] 🌸.
4.2.3. Service Mobility Environment
Data Element: Service Mobility Environment Use: Required XML Element: <ServiceMobility>
This is the service provider's take on how mobile the caller's device is 📱. Since the provider might not know the real device or access network, the value should be treated as advisory and not be relied upon 🦋. The registry lives in Section 11.1.4, and the starting entries are in Figure 6 💜.
Reason for Need: the provider's belief about mobility helps the PSAP handle the call 🧚.
How Used by Call Taker: it helps decide whether the caller's location 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
4.2.4. EmergencyCallData.ServiceInfo Example
Here's a full example so you can see the vibe 👀✨:
<?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 is all about the device that placed 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 one defines the kind of device making the emergency call 📞. If the device gives us the data structure, the device information SHOULD be provided 💖. If the service provider gives us the structure and knows what the device is, the service provider SHOULD provide the device information 🧚. Often the carrier doesn't know what the device is 🙈. It's possible to get two Device Information blocks: one from the device and one from the service provider 👯. This info describes the device, not how it's being used 🦋. There's a registry for this in Section 11.1.6, with the starting values in Figure 8 ✨.
Reason for Need: the device classification tells us what the calling device can do and helps make sense of the location info coming in 🗺️. For example, does the device need a human to start the call, or is it running programmed instructions 🤖? Can the device update its location or condition changes 📍? Is it interactive, or is it just a one-way reporting device 📡?
How Used by Call Taker: this gives the call taker context about the caller, what the device can do, and where it's being used 🌸. It helps them understand the location info and the device's abilities 💅. 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>
Description: the plain-language name of the device's manufacturer 🏭.
Reason for Need: PSAP management uses this for post-mortem investigation and 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: the model number of the device 🔢.
Reason for Need: PSAP management uses this for after-action investigation and resolution 🧐.
How Used by Call Taker: probably not used by the call taker, but by PSAP management 🫶.
4.3.4. Unique Device Identifier 🪪✨
Okay bestie, this one is the device's own ID card 💅. It's a string that identifies the specific device, or the device's current Subscriber Identification Module (SIM), that's making the call or creating an event. You can have more than one <UniqueDeviceID> in the same block if you want to supply more than one of the identifying values 🫶.
The TypeOfDeviceID attribute tells you what kind of identifier you're looking at. There's a registry for this in Section 11.1.7, and it starts with the set of values shown in Figure 9 🌸.
- Use: Optional
- XML Element:
<UniqueDeviceID> - XML Attribute:
<TypeOfDeviceID>
Here's the whole vibe: it uniquely identifies the device (or, for an International Mobile Subscriber Identity (IMSI), the SIM) no matter what signaling identifiers show up in the call signaling stream 🦋.
Reason for Need: It gives you a unique identity for the device, separate from any signaling identifiers 🔐.
How Used by Call Taker: Honestly, the call taker probably won't use this one 🙈. PSAP management might pull it up during an investigation 🕵️♀️. For example, if a PSAP keeps getting repeated false or accidental calls and there's no callback number (or it isn't usable), the PSAP might need to track down the device by other means, like contacting service providers in the area 📞. For handsets without current service, it might be possible to work out who last had service 📱. Another example: a disconnected call where the call taker thinks someone needs help but couldn't get a location or any other info 😭.
<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: This is a URI that points to extra data whose schema belongs to the device or service that made it 💜. For example, a medical device or a medical device monitoring service might have its own defined set of medical data 🏥. The URI, when dereferenced, MUST yield a data structure defined by the device/service-specific additional data type value. Each classification can create different data, like a data set made by a medical device ✨.
Reason for Need: It gives device- or service-specific data that the call taker and/or responders can use 🚑.
How Used by Call Taker: This helps call takers pick the right responders, give good pre-arrival instructions to callers, and tell responders what to be ready for 🙌. Responders might use it to guide the help they give 💪.
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: This is a value from the registry defined in Section 11.1.8 that describes the type of data at the device/service-specific additional data structure 📋. The initial values 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 lets you identify externally defined schemas, which might have extra data that helps with emergency response 🧠.
How Used by Call Taker: This lets the end user (call taker or first responder) know what kind of additional data is available to help provide 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
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 👑
Okay, this block describes the owner of the device (if the device provides that) or the subscriber information (if a service provider provides it) 🧾. The contact location isn't necessarily where the caller or the incident is. It's more like the nominal contact address 📬. The MIME media type is application/EmergencyCallData.SubscriberInfo+xml 💌.
Some jurisdictions have privacy rules for some or all of the subscriber-specific info 🤫. These rules vary, but they decide what can be displayed and logged 🙈. There's a general privacy indicator that shows the subscriber wants privacy 🔒. How that gets applied is up to the receiving jurisdiction, since they're the ones who know their local rules 🌍. This matches an equivalent privacy flag found 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 shows that the subscriber wants privacy 💜. In some jurisdictions, subscriber services can have a specific "Type of Service" that stops information, like the subscriber's name, from being displayed 🚫. This attribute says whether the subscriber service includes those kinds of constraints 🔐. How this indicator gets interpreted is left to each jurisdiction, matching the semantics of the privacy indicator in some legacy emergency call systems 📞. Since local regulations change how this indicator is read, this document can't describe the exact semantics or say which fields are affected. Applying the indicator might change how data in any of the blocks gets displayed 🌈.
Reason for Need: Some jurisdictions require subscriber privacy to be respected when emergency calls are handled 🛡️.
How Used by Call Taker: When privacy is indicated, the call taker might not have access to some parts 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., don't have info about the subscriber 📵.
XML Element: <SubscriberData>
Description: This is information the service provider or device knows about the subscriber, like Name, Address, Individual Telephone Number, Main Telephone Number, and any other data 🗂️. <n>, <org> (if appropriate), <adr>, <tel>, and <email> are suggested as a minimum 💅. If more than one <tel> property is provided, a parameter from the "vCard Property Values" registry MUST be specified on each <tel> 📇. Some data (like <anniversary>) might not seem obviously relevant for emergency services, but any data could be useful in some emergency situations 🎂.
Reason for Need: When the caller can't provide information, this data can be used to get it 🆘.
How Used by Call Taker: This helps get critical info about the caller, and possibly the location, when it can't be obtained another way 🧩. The location here isn't necessarily the caller's, but in some situations it can help find the caller when other methods have failed 🔍✨.
4.4.3. EmergencyCallData.SubscriberInfo Example 🎀
Here's a full example of a subscriber block, so you can see how all the pieces click together 💖
<?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>
<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>
<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 is the sweet little side channel for the data provider to slip extra, human-readable notes to the PSAP ✨ It is not meant to be a general-purpose extension mechanism, and it doesn't try to be machine-readable either. 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 giving the PSAP staff additional information.
Reason for Need: Explanatory information for the values in the data structure.
How Used by Call Taker: To interpret the data provided.
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 🚧
Okay so this part is about the two ways you can extend the kind of data that rides along with an emergency call 🦋 You can either define a new block, or define a new device/service-specific additional data URL for the DeviceInfo block (Section 4.3.5). Defining new data types and getting a new device or app to send them might be the easy part, ngl 💅 The hard part is getting PSAPs and responders to actually fetch the data and use it 😭
New mechanism providers should get that acquiring and using new forms of data usually means software upgrades at the PSAP and/or responders, plus training call takers and responders on how to read and use the info. Legal and operational review might also be needed. Drowning a call taker or responder in too much information is highly discouraged 🙈 So yeah, the barrier to supporting new data is pretty high, bestie.
The whole point of these mechanisms is to encourage widely supported, common data formats for classes of devices 🧚 If every manufacturer of a class of device uses 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 it. Well-intentioned variations are unlikely to get supported, sadly 💔
Implementors should consider that data from sensor-based devices might not be useful to call takers or PSAPs in some cases. Privacy, liability, or other considerations might stop the PSAP from accessing or handling the data, but it could still be useful 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 PSAP accesses it.
5.1. Choosing between Defining a New Type of Block or a New Type of Device/Service-Specific Additional Data
Okay, so for devices that have device- or service-specific data, there are two ways to carry it 👑 You can define a new block, or you can use the device/service-specific additional data URL in the DeviceInfo block and define a new type for it. The data passed would likely be the same either way ✨ When you're picking which mechanism to register under, here's what to think about:
Applicability: Information that will be supported by many kinds of devices or services is more appropriately defined as separate blocks. That's main character energy for a shared block 🌈
Privacy: Information sent as a device/service-specific additional data URL in the DeviceInfo block is sent by reference (not by value). That inherently gives some extra privacy protection, because the requester needs to supply a certificate that the supplier verifies 🔥
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, small data might be best 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 to retrieve the data from. Providing the data via a new block lets it be sent by value 💜
6. Data Transport Mechanisms 🚚✨
Okay bestie, this section is all about HOW the extra info actually gets to the emergency service provider 🫶 There are two ways to send it. The first uses call signaling, and the second uses the <provided-by> element of a PIDF-LO [RFC4119] 💌
- First, a URI goes inside an existing SIP header. The Call-Info header field 📎 is where we embed a Uniform Resource Identifier (URI), and that URI points to the additional data structure. The Call-Info header field is specified in Section 20.9 of [RFC3261] 💅
This doc 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 Indirection (CID) URI that lets the data structure live right in the body of the SIP message 🧚 The purpose parameter also tells you the kind of data (by its MIME media subtype) that's sitting at the URI ✨
Since the data is conveyed using a URI in the SIP signaling, the data itself can be on an external resource or inside the body of the SIP message 📦 When the URI points to data at an external resource, we say the data is passed by reference 🔗 When the URI points to data inside the SIP message body, we say it's passed by value 💜 A PSAP or emergency responder can check out the type of data provided, pick out the bits they care about, and still forward 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 called 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') wraps them all up together 🎁
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 get 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 hands back the block as an object (the blocks defined here come back as XML objects) 🧁
- Second, extra data can go inside the
<provided-by>element of a PIDF-LO [RFC4119] 🌈
Honestly, service providers in the call path aren't the only ones with useful info 🙈 The access network provider generally has similar information that can be super valuable to the PSAP 💖 When the access network provider and the service provider are separate entities, the access network doesn't take part in the application-layer signaling (so it can't add a Call-Info header field to the SIP message), but it CAN provide location information in a PIDF-LO 🗺️ When the access network provider supplies location information as a PIDF-LO from a location server via a location configuration protocol, it has the ability to add the data structures defined in this document (or references to them) right inside the PIDF-LO ✨
The data in these structures isn't about the location itself. It's descriptive info about the immediate circumstances of 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 pretty much the same as the data known by service providers in the path of the call 🫶 The <provided-by> element of the PIDF-LO is the mechanism the access network provider uses 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 🕵️♀️ So 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 for emergency calls is that it is more important for the call to go through than for everything to be correct 📞💖 So most PSAPs will process a call if at all possible, even if data is missing or other failures occur 🫶
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) 💌 It goes in a Call-Info header field containing a 'purpose' value that starts with 'EmergencyCallData', then a dot ('.'), then 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), and you leave off 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) 🚨 It also works for test emergency calls (using an appropriate service URN) and for some private-use calls where the endpoints have a preexisting relationship and privacy concerns don't apply because of that 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 while the information is retrieved 🔐✨
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 that holds 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 it 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 isn't meant 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 emergency call MUST insert its own 🫶 For example, a device, a telematics service provider in the call path, and the mobile carrier handling the call will each provide one 🚗📡 There might be circumstances where a service provider is unaware that the call is an emergency call and cannot reasonably be expected to determine that it is one. 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 lets an entity find and access the data blocks it cares about without diving deep into the message structure or decrypting parts it isn't interested in 🥳💜
6.2. Transmitting Blocks by Reference Using the <provided-by> Element ✨
Okay bestie, this is the "send a link instead of the whole thing" move 🔗💖. The <EmergencyCallDataReference> element carries one additional data block by reference inside a <provided-by> element of a PIDF-LO. It has two attributes: ref gives the URL, and purpose says what type of block is being 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 one used in a Call-Info header field (see Section 6.1), so it's giving consistency 🎀.
For example, to reference a block with MIME media type application/EmergencyCallData.ProviderInfo+xml, you set the purpose parameter to EmergencyCallData.ProviderInfo. Here's what that element looks like 👀:
<EmergencyCallDataReference ref="https://www.example.com/23sedde3"
purpose="EmergencyCallData.ProviderInfo"/>Each <EmergencyCallDataReference> element transmits one data block, so if you want several blocks, you use several elements. Multiple <EmergencyCallDataReference> elements MAY be included as child elements inside the <provided-by> element. Here's 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. The URL sits in the ref attribute and the purpose attribute is set to EmergencyCallData.ServiceInfo 🧚.
6.3. Transmitting Blocks by Value Using the <provided-by> Element 💜
Real talk, this one needs a little care 🫶. It is RECOMMENDED that access networks supply the data specified in this document by reference. The reason is that 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 carries one or more additional data blocks by value inside 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 that would be contained in the corresponding MIME media type body part goes inside the <EmergencyCallDataValue> element. Multiple <EmergencyCallDataValue> elements MAY be included as child elements in the <provided-by> element. Here's 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 how message bodies are handled in SIP. It updates and clarifies handling that was originally defined in RFC 3261 [RFC3261], based on implementation experience. RFC 3261 did not mandate support for 'multipart' message bodies, but 'multipart/mixed' MIME bodies are used by lots of extensions today, this document included 🙈. For example, if you're adding a PIDF-LO, a Session Description Protocol (SDP), and additional data to the body of a SIP message, you need a 'multipart' message body.
RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' parameter for the Content-Disposition header field. They describe how a User Agent Server (UAS) reacts when 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] lets a SIP message contain a reference to the body part, and the SIP User Agent (UA) processes the body part according to that 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
7. Examples 🦋
This section illustrates a longer and more complex example, shown in Figure 15. In this scenario, 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 FlowThe 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
</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
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>
<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
Okay so the big thing to notice here is that the access network provider's info isn't actually in the INVITE itself 🦋 It only shows up indirectly through the location reference, so the PSAP has to go fetch it in a separate lookup step 📚 which is lowkey extra homework 🙈
Since the access network provider and the VoIP service provider are two totally separate entities in this scenario, the access network provider is not involved in application-layer exchanges 💅 The SIP INVITE just passes right through the access network like it's not even there. Steps #1 and #2 show this, and the access network does not alter the SIP INVITE ✨
The VoIP service provider gets the message and clocks the service URN, so it knows this is an emergency call 🚨 It does its usual emergency-services stuff (like location-based routing 🗺️) and then adds more data: service and subscriber information, plus data provider information #2 🌸 For the example, we assume the VoIP service provider runs a back-to-back user agent that lets extra data go in the body of the SIP message (rather than by reference) 🧚 This lets us show off multiple data provider info blocks, which is so iconic 👑 The resulting message is in Figure 17, and 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
--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>
<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>
</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
<?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>
<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>
</vcard>
</pi:DataProviderContact>
</pi:EmergencyCallData.ProviderInfo>
--boundary1--Figure 17: VoIP Provider Sending SIP INVITE with Additional Data 💖
Okay so finally 🎀 the PSAP asks the access network provider for location information. 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">
<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 ✨
Okay bestie, this section is where the schemas live 🧚 It defines the XML schemas of the five data blocks 💅 and, on top of that, the provided-by schema gets specified too 👑
8.1. EmergencyCallData.ProviderInfo XML Schema ✨
okay so this one is the schema for the ProviderInfo block, aka all the deets about who's providing the data 💁♀️ it's giving organized, honestly. the Language pattern is lowkey intense but it's just checking the language tags 🌈
<?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"/>
<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
8.2. EmergencyCallData.ServiceInfo XML Schema 🎀
this is the ServiceInfo one, and it's giving the "what kind of service is this" energy 🧚
<?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
8.3. EmergencyCallData.DeviceInfo XML Schema 📱
now the DeviceInfo schema, which is all about the device itself. the UniqueDeviceID bit is so specific it's kind of iconic 💖
<?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"/>
<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
8.4. EmergencyCallData.SubscriberInfo XML Schema 💜
this one covers the subscriber info, including the privacyRequested attribute, which is required and is a boolean. main character energy 👑
<?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
8.5. EmergencyCallData.Comment XML Schema 🦋
last of the EmergencyCallData ones, and this is the Comment schema. the xml:lang attribute is on the comment text itself, so you can tag what language each comment is in 🌸
<?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
8.6. provided-by XML Schema 🌈
this section is where the provided-by schema lives, so here it comes, bestie 🫶
<?xml version="1.0"?> <xs:import
namespace="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
schemaLocation="ProviderInfo.xsd"/>Okay, the schema keeps going, and it's giving organized ✨ Each of the five helper XSDs gets imported on its own namespace, so nothing gets mixed up 💅
<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>
<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 🔒
Okay bestie, security time, and this part is SO important, no cap 🫣 The data structures in this document hold information that's usually considered private. When the info is provided by value, every entity that's part of the SIP signaling (like proxy servers and back-to-back user agents) can see it, so they have to protect it against inappropriate disclosure 🙈 Anyone who can eavesdrop on the SIP signaling gets access too. Some Internet access types (like in-the-clear Wi-Fi) are more vulnerable to eavesdropping than others (like 3G or 4G cellular data traffic), so protection is a whole vibe 🧚 Mechanisms that guard against eavesdropping (such as TLS version 1.2 or later) SHOULD be preferentially used whenever feasible 💜 (This one isn't a "MUST" 🙃 because there's already a deployed base of clear-text SIP, and also because it's an emergency call, so getting the call through matters more than keeping it protected. For example, the call MUST proceed even if the TLS negotiation or certificate verification fails for whatever reason 😭)
When info is provided by reference, TLS mutual authentication is REQUIRED 🔐 That means 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 the requester gives. Making a public key infrastructure (PKI) with global scope might be difficult, but the alternatives for building devices and services that can give critical information securely are even 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 right policy to enforce based on that certificate 👑
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 get credentials signed by an authority the data provider trusts 💖 In most circumstances, nationally recognized credentials are enough. The emergency services community within a country can set up a PKI, and data providers can be provisioned with the root Certification Authority (CA) public key for that country. Some nations are building a PKI for this and related purposes 🌍 Calls can come from devices where the device and/or the service provider(s) isn't local to the emergency services authorities, so globally recognized credentials are useful ✨ This might be done by extending the notion of the "forest guide" described in [RFC5582], so the forest guide can provide the credential of the PKI root for areas it has coverage information for. Standards for that mechanism aren't available yet, though 🥲 Without it, the data provider needs to get the root CA credentials for any areas where it's willing to provide additional data through out-of-band means. With the root CA credential 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 the emergency services can verify, so they know they're getting data from an authorized server 🫶 The emergency services authorities could provide credentials that are distinguishable from the ones given to emergency responders and PSAPs, and those 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 from that provider. This could extend to global credential validation using the forest guide, as mentioned above 🌸 Without such credentials, the emergency services authorities could keep a list of local data providers' credentials, given to them out of band. At a minimum, the emergency services authorities could get a credential from the DNS entry of the domain in the additional data URI (for example, 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 it. The solutions are the same, but the challenges of doing this for every device are obviously harder, especially when you think about root certificate updates, revocation lists, and so on 🙃 Still, devices aren't generally expected to provide data directly by reference. They're more likely to either provide data by value or upload the data to a server that can make it available more reliably and enforce security policy more easily 💅 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's really an emergency call is started as a normal call and the cellular service provider recognizes it, 3GPP IMS lets the service provider either accept the call anyway or reject it with a specific code that tells the device to retry as an emergency call. Service providers ought to choose the latter, because otherwise the device won't include the information specified in this document (since the device didn't recognize the call as an emergency call) 😭💜
10. Privacy Considerations 🔒
bestie, this section is about privacy, and it's serious 🫶. This document lets the caller's extra info (about them, their device, and their service) reach the callee. A lot of that is personal data, so privacy concerns come with it. There's an explicit privacy indicator for info that directly relates to the caller's identity, and using it is mandatory 🔥. Whether anyone actually honors that privacy request, and which info it covers, is up to the destination jurisdiction. Some legacy emergency services systems worked the same way ✨.
Non-emergency real-time comms have plenty of privacy issues, and those apply to emergency calls too 💅. Data protection law around the world has still made exceptions for emergency services. The reasoning is that the risks of sharing personal data are outweighed by what the emergency caller gets out of it. So the data protection rights individuals usually have are commonly waived in emergencies 🚨. That said, some countries still give callers a degree of anonymity toward PSAP call takers 🎀.
This document goes way beyond what the legacy POTS system shared, so there are extra privacy threats to think about. They're covered in more detail in [RFC6973] 👀.
- Stored Data Compromise: Stored data is more at risk because more data is being collected and kept in databases 😭. If access network providers, service providers, end devices, and PSAPs don't protect stored data from unauthorized or inappropriate access, people could face financial, reputational, or physical harm 💀.
- Misattribution: If the personal data collected and shared is incorrect or inaccurate, it can lead to misattribution. That's when data or communications about one person get attached to someone else 🙈.
- Identification: The extra data gives much richer info about the caller, the call, and the location, so the caller gets identified way more precisely 👀. Some users could be uncomfortable with that much sharing, even in an emergency 🌸.
- Secondary Use: This is when info collected about someone gets used, without their consent, for a purpose other than the one it was collected for 🫠. The stated purpose here is emergency services, but in theory the same info could be used for any other call. Parties involved in the emergency call could also keep the info and reuse it for non-emergency services purposes 😤. No technical measures stop that kind of reuse, but policy, legal, regulatory, and other non-technical approaches can work well 💜.
- Disclosure: If the data defined here isn't properly protected, it can be disclosed. That means it's revealed to others, both while in transit (with traditional communication security techniques) and while stored (with access control mechanisms) 🚨.
To lower these privacy risks, the following countermeasures can be taken 🛡️:
In regions where callers can choose to hide certain personally identifying info, network or PSAP functionality can inspect privacy flags in the SIP headers. That tells them what info can be passed on, stored, or displayed, so they follow local policy or law 🎀. RFC 3325 [RFC3325] defines the 'id' priv-value token. When that privacy type shows up in a Privacy header field, it means the user wants the network asserted identity kept private from SIP entities outside the trust domain they authenticated with, including the PSAP 🤫.
This document defines data structures that hold privacy-sensitive data 🫣. Examples include identifiers for the device (like serial number and MAC address), account or SIM identifiers (like IMSI), contact info for the user, and the caller's location. Local regulations may decide which data goes into emergency calls, but in general the emergency call system is helped by the info described here ✨. There's a trade-off between privacy and how useful the data is 💅. To protect it, this specification requires all retrieval of data passed by reference to be protected against eavesdropping and alteration with communication security techniques (namely TLS) 🔐. Security safeguards are also required to stop unauthorized access to stored data 🚫. Over at least the past few decades, lots of security incidents have shown that data breaches aren't rare. They're often caused by weak access control frameworks, software bugs (like buffer overflows), or missing input parsing (like SQL injection attacks) 😱. The risk of breaches has also grown, because emergency services are obligated to keep emergency-call-related data for long stretches (several years is the norm) 📆.
Last but not least, the SIP communication architecture adds its own privacy complications 🧩. Some 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, every intermediary can see it, and those intermediaries could add privacy risk of their own 👀. So when the info is privacy sensitive and intermediaries are involved, sending it by reference might be appropriate 🦋. That assumes the data source can run a sufficient dereferencing infrastructure, and that proper access control policies exist to tell apart the different entities dereferencing the reference 🔑. Without access control policies, anyone holding the reference can resolve it and get the data, intermediaries included 😬.
11. IANA Considerations 🧾
11.1. Emergency Call Additional Data Registry 📚
This document creates a new registry called 'Emergency Call Additional Data' 🎉, and it has a bunch of sub-registries.
For several of the sub-registries, "Expert Review" is the criteria for adding new entries 🧐. As Section 5 discusses, registering new types of data can backfire, and as Section 10 discusses, data sent during an emergency call can be super privacy sensitive 🙈. Some standards bodies that focus on emergency services might need to register new values, so in those cases the text below tells the designed expert to check that the requesting entity is relevant (for example, a recognized emergency-services-related Standards Development Organization (SDO)) 🫶. In other cases, where the trade-off between potential benefit and danger of new registrations is more conservative (like Section 11.1.9), "Specification Required" is the criteria instead 🚧. That's a higher hurdle, and it 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 confirm that the entity asking for a new value is a legit issuer of service provider IDs that work in Additional Call Data 🔍.
Private entities that issue or use internally generated IDs are encouraged to register here, and to make sure every ID they issue or use is unique 🌈. That guarantees the IDs are globally unique and can be told apart from IDs issued or used by the same or a different entity 💖. (Some organizations, like NENA, issue IDs that are unique among all the IDs they issue. So an entity using a combination of its NENA ID plus the fact that it's from NENA is globally unique 🙌. Other entities might not have an ID from an organization like NENA, so they're allowed to use their domain name, but if they do, it needs to be unique 🌸.)
The content of this registry includes:
- Name: An identifier used in the
ProviderIDSerieselement 🧸. - Source: The full name of the organization issuing the identifiers 🏢.
- URL: A URL to the organization for more info 🔗.
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 confirm that the entity asking for a new value is relevant for this service element (for example, a recognized emergency-services-related SDO), that the new value is distinct from existing values, and that its use is unambiguous 🧐.
The content of this registry includes:
- Token: The value 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 confirm that the entity asking for a new value is relevant for this service element (for example, a recognized emergency-services-related SDO), and that the requested value is clearly distinct from other values, so there's zero ambiguity about when to use it or which value to use 🎯.
The content of this registry includes:
- Name: The value 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 confirm that the entity asking for a new value is relevant for this service element (for example, a recognized emergency-services-related SDO), and that the requested value is clearly distinct from other values, so there's no ambiguity about when to use it or which value to use 🦋.
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 confirm 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 🎀
Okay bestie, this section creates a brand new sub-registry called "Device Classification" 💅. Under [RFC5226] it runs on "Expert Review" rules. The expert checks whether the proposed class is unique compared to the existing classes, and whether the class definition will be clear to implementors and PSAPs/responders ✨.
Here's what lives in this registry:
- Token: the value used in the
<DeviceClassification>element. - Description: a short description identifying the device type.
The initial set of values is defined in Figure 8 🦋.
11.1.7. Device ID Type Registry 🧚
This one creates a new sub-registry called "Device ID Type" 💖. Under [RFC5226] it also uses "Expert Review", and the expert needs to make sure the proposed type is well understood and gives PSAPs and responders something they can use to uniquely identify a device. For example, a biometric fingerprint used to authenticate a device wouldn't normally be used by a PSAP or responder to identify a device 🙈.
What's inside:
- Token: the value to be placed in the
<TypeOfDeviceID>element. - Description: a 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 🌈
Now we're making a sub-registry called "Device/Service Data Type" 🫶. This one runs under [RFC5226]'s "Specification Required" rules, which include an explicit "Expert Review". The designated expert should make sure the proposed type is well understood and useful to PSAPs and responders. The specification must contain a complete description of the data and a precise format specification, so that interoperable implementations are possible 🔥.
Contents:
- Token: the value to be placed in the
<DeviceSpecificType>element. - Description: a short description identifying the data.
- Specification: a 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 sub-registry is called "Emergency Call Data Types" 👑. It also follows [RFC5226]'s "Specification Required" rules, including an explicit "Expert Review". The expert checks that the document has a complete and clear specification, and that the proposed functionality doesn't obviously duplicate something that already exists. The expert also verifies that the block is categorised correctly, following the category descriptions in Section 1 🧐.
Every data block that can be sent with an emergency call, using the mechanisms in this document, gets an entry here. Each block is identified by the 'root' of its MIME media subtype, which is the part after 'EmergencyCallData.'. If the MIME media subtype doesn't start with 'EmergencyCallData.', it can't be registered here, and it can't be used in a Call-Info header field as specified in this document 🙅♀️.
The subtype MAY exist under any MIME media type. Most commonly it's under 'application/', but that is NOT REQUIRED. To be added to the registry, though, the 'root' has to be unique regardless of the MIME media type.
What's inside:
- Token: the root of the data's MIME media subtype. Leave out the 'EmergencyCallData' prefix and any suffix such as '+xml'.
- Data About: a hint about whether the block describes the call, the caller, or the location, or applies to more than one of those. This helps PSAPs and other entities decide if they want to process the block. It's only a hint though, so entities also need to look at the block's contents and not just this field 👀. That's exactly why this field only lives in the registry and isn't included inside the block. The value MUST be either 'The Call', 'The Caller', 'The Location', or 'Multiple'. New values get created by extending this registry in a later RFC 💜.
- Reference: the document that describes the data object.
Quick note: the tokens here are part of the 'EmergencyCallData' compound value. When one is used as the value of the 'purpose' parameter of a Call-Info header field, it gets prefixed with 'EmergencyCallData.', as set out in that registration. See Section 11.2 for the details 🦋.
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 Registry11.2. 'EmergencyCallData' Purpose Parameter Value 🎀
This document defines the 'EmergencyCallData' value for the 'purpose' parameter of the Call-Info header field [RFC3261] ✨. IANA 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 📚.
'EmergencyCallData' is a compound value. When it's used as the 'purpose' value of a Call-Info header field, it's immediately followed by a dot ('.') and then a value from the "Emergency Call Data Types" registry. Check out Section 11.1.9 for that list 🌸.
11.3. URN Sub-Namespace Registration for <provided-by> Registry Entry 🌷
This section registers the namespace from Section 11.5.1 in the provided-by registry set up by RFC 4119 🧚. It's for use within the <provided-by> element of a PIDF-LO. The schema for the <provided-by> element used by this document is in Section 8.6 💜.
11.4. MIME Registrations 💌
11.4.1. MIME Content-Type Registration for 'application/EmergencyCallData.ProviderInfo+xml' 🍓
This specification asks for a new MIME media type to be registered, following the procedures in RFC 6838 [RFC6838] and the 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: It 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 carries the data provider information, which is a sub-category of additional data about an emergency call 🔐. This data can include personal information, so you need proper precautions to stop unauthorised access, inappropriate disclosure, and eavesdropping of that personal info. Check out Sections 9 and 10 for more 😭.
- 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' 🌈
Same deal here: a new MIME media type gets registered under RFC 6838 [RFC6838], with the guidelines from 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: It 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 carries the service information, which is a sub-category of additional data about an emergency call 🛡️. This data can contain personal information, so precautions are needed to limit unauthorised access, inappropriate disclosure, and eavesdropping of that personal information. Check out Sections 9 and 10 for more 🙈.
- 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' 📱
Last one in this batch! A new MIME media type gets registered under RFC 6838 [RFC6838] and the RFC 7303 [RFC7303] guidelines 🎉.
- Type name: application
- Subtype name: EmergencyCallData.DeviceInfo+xml
- Mandatory parameters: N/A
- Optional parameters: charset (indicates the character encoding of the contents)
- Encoding considerations: It 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 carries device information, which is a sub-category of additional data about an emergency call 🚨. This data contains personal information, so you need to take appropriate precautions to limit unauthorised access, inappropriate disclosure to third parties, and eavesdropping of this information. Check out Sections 9 and 10 for more 😭.
- 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' ✨
okay so this section registers a brand new MIME media type 💅 and it does it totally by the book, following the procedures in RFC 6838 [RFC6838] and the guidelines in RFC 7303 [RFC7303] 🎀
- Type name:
application - Subtype name:
EmergencyCallData.SubscriberInfo+xml - Mandatory parameters:
N/A - Optional parameters:
charset, which is the character encoding of the contents 🌸 - Encoding considerations: it's XML, and XML can contain 8-bit characters depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303] 💜
- Security considerations:
😭 bestie, this one is SERIOUS. This content type carries owner/subscriber information, which is a sub-category of additional data about an emergency call. Since it's personal info, you absolutely need precautions to limit unauthorized access, inappropriate disclosure to third parties, and eavesdropping of this information. Go check Sections 9 and 10 for more 🔒
- 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' 🦋
same energy here, bestie 💖 this one also registers a new MIME media type using RFC 6838 [RFC6838] and the guidelines in RFC 7303 [RFC7303] ✨
- Type name:
application - Subtype name:
EmergencyCallData.Comment+xml - Mandatory parameters:
N/A - Optional parameters:
charset, which is the character encoding of the contents 🌈 - Encoding considerations: it's XML, and XML can contain 8-bit characters depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303] 🫶
- Security considerations:
🙈 this content type is for a comment, which is a sub-category of additional data about an emergency call. A comment can contain personal information, so 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>
11.5. URN Sub-Namespace Registration 🌸
11.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData 🎀
this bit registers a new XML namespace, following 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>
END11.5.2. Registration for urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 🧚
same vibe: a new XML namespace, following 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>.
- 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>
END11.5.3. Registration for urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 🌈
a new XML namespace again, via 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>
<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>
END11.5.4. Registration for urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 📱
you know the drill, a new XML namespace under 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>
END11.5.5. Registration for urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 🔒
this one's the personal-info namespace, so handle it with care 🫶 it's registered under RFC 3688 [RFC3688] like the others.
- 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>
END11.5.6. Registration for urn:ietf:params:xml:ns:EmergencyCallData:Comment 💬
last one in this batch, another XML namespace via 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>.
- 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>
END11.6. Schema Registrations 🧚
this spec registers the following schemas, following 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.
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 ✨
okay so this section is literally a little registry request, and I'm obsessed 🎀 It adds a new value to the "vCard Parameter Values" registry, which lives in [RFC6350]. The registration follows this 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
00So basically main-number is the main line for a company, not the direct-dial number of one specific employee 📞💖 You can use it with the TYPE parameter on the TEL property, and the example shows it as main,voice with PREF=1 🌸
12. References 📚🦋
12.1. Normative References 💅
These are the must-read ones, bestie 🫶
[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>.
[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 🌈
These are the extra-credit reads, the ones that give you the full picture 🧚✨
[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>.
[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>.
[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>.
[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>.
Appendix A. XML Schema for vCard/xCard 🎀
This section has the vCard/xCard XML schema, which is the version of the Relax NG schema from RFC 6351 [RFC6351] written for the XML schemas defined in this document. Besides mapping the Relax NG schema over to an XML schema, this specification also applies an erratum that was raised for RFC 6351 about the type definition. You can check it out in 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"/>
</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">
<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"/>
</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">
<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> <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> <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"/>
okay the schema is getting spicy now 💅 here's the next chunk, bestie 🫶
</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"/>
<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>
</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"/>
<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">
</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>
<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>
</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>okay bestie, we're picking up right where we left off 💖 this part is all about the vCard element definitions for the ns1 namespace, and it's giving very organized schema energy 🎀 every element has its own little parameters block and the comments tell you which section it comes from, so you can always find your way back 🗺️
<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"/>
<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"/>
<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"/>
</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>
<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>
<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>that's where this chunk ends, and the schema keeps going in the next part, so stay tuned 🦋 the elements pick up right here with the rest of the caladruri definition ✨
</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"
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>
</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 ✨
Okay bestie, this is the part where we talk about actually checking the XML examples and schemas 🧚 This document defines a bunch of XML schemas and has loads of examples, and pulling the XML out and validating everything can be genuinely tricky, mostly because of the formatting limits that come with IETF RFCs. 😭 If you're copying the XML schemas and examples straight out of this doc, just know that line breaks and extra whitespace can sneak in and cause errors, especially inside the regular expressions in the vCard schema from Appendix A. 💀 And if you want to validate the PIDF-LO from Figure 18, you'll also need to check out the referenced RFCs and grab the schemas you need for it to pass. 🎀
The XML schemas in this document include a SchemaLocation attribute. Depending on where you end up saving the schema files, you might need to tweak that schema location, or point your XML editor at the right spot. 🌸
For your convenience, the schemas live at [IANA-XML-Schemas], and the XML examples are on the IETF ECRIT working group wiki page at [ECRIT-WG-wiki]. 🫶
Acknowledgments
Okay, shoutout time! 💖 This work actually started out in NENA, and it's been shaped by a ton of people who joined in on NENA standardization efforts. That includes the Long Term Definition working group, the Data Technical Committee, and most recently the Additional Data working group. The authors are super grateful for the early work and the extended comments from loads of NENA folks, 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 also gave really valuable feedback on how vCard/xCard gets used in this spec. 💅
And we also have 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. 🦋 Then there are Alissa Cooper, Guy Caron, Ben Campbell, and Barry Leiba, who totally deserve special mention. 👑 Their reviews were detailed and extensive, and honestly they were so helpful and so appreciated. 🥹✨
Authors' Addresses 🎀
Here's where you can find the authors 💜
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📦 where this page comes from
- ietf: rfc7852 2016-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms