RFC 7852
Additional Data Related to an Emergency Call
9. Security Considerations
The data structures described in this document contain information usually considered private. When information is provided by value, entities that are a party to the SIP signaling (such as proxy servers and back-to-back user agents) will have access to it and need to protect it against inappropriate disclosure. An entity that is able to eavesdrop on the SIP signaling will also have access. Some Internet access types (such as in-the-clear Wi-Fi) are more vulnerable than others (such as 3G or 4G cellular data traffic) to eavesdropping. Mechanisms that protect against eavesdropping (such as TLS version 1.2 or later) SHOULD be preferentially used whenever feasible. (This requirement is not a "MUST" because there is an existing deployed base of clear-text SIP, and also because, as an emergency call, it is more important for the call to go through than for it to be protected; for example, the call MUST proceed even if the TLS negotiation or certificate verification fails for whatever reason.) When information is provided by reference, TLS mutual authentication is REQUIRED. That is, HTTPS is REQUIRED for dereferencing, the requester MUST use a client certificate to authenticate the HTTP request, and the provider of the information is REQUIRED to validate the credentials provided by the requester. While the creation of a public key infrastructure (PKI) that has global scope might be difficult, the alternatives to creating devices and services that can provide critical information securely are more daunting. The provider of the information MAY enforce any policy it wishes to use, but PSAPs and responder agencies are strongly advised to deploy a PKI so that providers of additional data can check the certificate of the client (the requester) and decide the appropriate policy to enforce based on that certificate.
TLS MUST be version 1.2 or later. It is RECOMMENDED to use only cipher suites that offer Perfect Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC) and to follow the recommendations in BCP 195 [RFC7525]. Ideally, the PSAP and emergency responders will be given credentials signed by an authority trusted by the data provider. In most circumstances, nationally recognized credentials are sufficient; the emergency services community within a country can arrange a PKI, data providers can be provisioned with the root Certification Authority (CA) public key for the country. Some nations are developing a PKI for this and related purposes. Since calls could be made from devices where the device and/or the service provider(s) is not local to the emergency services authorities, globally recognized credentials are useful. This might be accomplished by extending the notion of the "forest guide" described in [RFC5582] to allow the forest guide to provide the credential of the PKI root for areas for which it has coverage information, but standards for such a mechanism are not yet available. In its absence, the data provider needs to obtain by out-of-band means the root CA credentials for any areas to which it is willing to provide additional data. With the credential of the root CA for a national emergency services PKI, the data provider server can validate the credentials of an entity requesting additional data by reference. The data provider also needs a credential that can be verified by the emergency services to know that it is receiving data from an authorized server. The emergency services authorities could provide credentials, distinguishable from credentials provided to emergency responders and PSAPs, which could be used to validate data providers. Such credentials would have to be acceptable to any PSAP or responder that could receive a call with additional data supplied by that provider. This would be extensible to global credential validation using the forest guide as mentioned above. In the absence of such credentials, the emergency services authorities could maintain a list of local data providers' credentials as provided to them out of band. At a minimum, the emergency services authorities could obtain a credential from the DNS entry of the domain in the additional data URI (e.g., using DNS-Based Authentication of Named Entities (DANE) [RFC6698]) to at least validate that the server is known to the domain providing the URI. When devices provide data by reference, the credential validation issues are similar to when service providers do so, and while the solutions are the same, the challenges of doing so for every device are obviously more difficult, especially when considering root certificate updates, revocation lists, etc. However, in general, devices are not expected to provide data directly by reference, but
rather to either provide data by value or upload the data to a server that can more reliably make it available and more easily enforce security policy. Devices that do provide data directly by reference, which might include fixed-location sensors, will need to be capable of handling this. Neither service providers nor devices will supply private information unless the call is recognized as an emergency call. In cellular telephony systems (such as those using 3GPP IMS), there are different procedures for an originating device to place an emergency call versus a normal call. If a call that is really an emergency call is initiated as a normal call and the cellular service provider recognizes this, 3GPP IMS permits the service provider to either accept the call anyway or reject it with a specific code that instructs the device to retry the call as an emergency call. Service providers ought to choose the latter, otherwise the device will not include the information specified in this document (since the device didn't recognize the call as being an emergency call).10. Privacy Considerations
This document enables functionality for conveying additional information about the caller and the caller's device and service to the callee. Some of this information is personal data and therefore privacy concerns arise. An explicit privacy indicator for information directly relating to the caller's identity is defined and use is mandatory. However, observance of this request for privacy and which information it relates to is determined by the destination jurisdiction (which replicates functionality provided in some legacy emergency services systems). There are a number of privacy concerns with non-emergency real-time communication services that are also applicable to emergency calling. Data protection regulation worldwide has, however, decided to create exceptions for emergency services since the drawbacks of disclosing personal data are outweighed by the benefit for the emergency caller. Hence, the data protection rights of individuals are commonly waived for emergency situations. There are, however, still various countries that offer some degree of anonymity for the caller towards PSAP call takers. The functionality defined in this document far exceeds the amount of information sharing available in the legacy POTS system. For this reason, there are additional privacy threats to consider, which are described in more detail in [RFC6973].
Stored Data Compromise: There is an increased risk of stored data
compromise since additional data is collected and stored in
databases. Without adequate measures to secure stored data from
unauthorized or inappropriate access at access network providers,
service providers, end devices, as well as PSAPs, individuals are
exposed to potential financial, reputational, or physical harm.
Misattribution: If the personal data collected and conveyed is
incorrect or inaccurate, then this can lead to misattribution.
Misattribution occurs when data or communications related to one
individual are attributed to another.
Identification: By the nature of the additional data and its
capability to provide much richer information about the caller,
the call, and the location, the calling party is identified in a
much better way. Some users could feel uncomfortable with this
degree of information sharing even in emergency services
situations.
Secondary Use: There is a risk of secondary use, which is the use of
collected information about an individual without the individual's
consent for a purpose different from that for which the
information was collected. The stated purpose of the additional
data is for emergency services purposes, but theoretically the
same information could be used for any other call as well.
Additionally, parties involved in the emergency call could retain
the obtained information and reuse it for other, non-emergency
services purposes. While technical measures are not in place to
prevent such secondary reuse, policy, legal, regulatory, and other
non-technical approaches can be effective.
Disclosure: When the data defined in this document is not properly
protected (while in transit with traditional communication
security techniques and while stored using access control
mechanisms), there is the risk of disclosure, which is the
revelation of private information about an individual.
To mitigate these privacy risks, the following countermeasures can be
taken:
In regions where callers can elect to suppress certain personally
identifying information, network or PSAP functionality can inspect
privacy flags within the SIP headers to determine what information
can be passed, stored, or displayed to comply with local policy or
law. RFC 3325 [RFC3325] defines the 'id' priv-value token. The
presence of this privacy type in a Privacy header field indicates
that the user would like the network asserted identity to be kept private with respect to SIP entities outside the trust domain with which the user authenticated, including the PSAP. This document defines various data structures that contain privacy- sensitive data such as, for example, identifiers for the device (e.g., serial number and MAC address) or account/SIM (e.g., IMSI), contact information for the user, and location of the caller. Local regulations may govern which data is provided in emergency calls, but in general, the emergency call system is aided by the information described in this document. There is a trade-off between the privacy considerations and the utility of the data. For protection, this specification requires all retrieval of data passed by reference to be protected against eavesdropping and alteration via communication security techniques (namely TLS). Furthermore, security safeguards are required to prevent unauthorized access to stored data. Various security incidents over at least the past few decades have shown that data breaches are not uncommon and are often caused by lack of proper access control frameworks, software bugs (such as buffer overflows), or missing input parsing (such as SQL injection attacks). The risks of data breaches have increased with the obligation for emergency services to retain emergency-call-related data for extended periods (e.g., several years are the norm). Finally, it is also worth highlighting the nature of the SIP communication architecture, which introduces additional complications for privacy. Some forms of data can be sent by value in the SIP signaling or by reference (a URL in the SIP signaling). When data is sent by value, all intermediaries have access to the data. As such, these intermediaries could also introduce additional privacy risk. Therefore, in situations where the conveyed information is privacy sensitive and intermediaries are involved, transmitting by reference might be appropriate, assuming the source of the data can operate a sufficient dereferencing infrastructure and that proper access control policies are available for distinguishing the different entities dereferencing the reference. Without access control policies, any party in possession of the reference is able to resolve the reference and to obtain the data, including intermediaries.
11. IANA Considerations
11.1. Emergency Call Additional Data Registry
This document creates a new registry called 'Emergency Call Additional Data' with a number of sub-registries. For several of the sub-registries, "Expert Review" is the criteria for adding new entries. As discussed in Section 5, it can be counterproductive to register new types of data, and as discussed in Section 10, data sent as part of an emergency call can be very privacy sensitive. In some cases, it is anticipated that various standards bodies dealing with emergency services might need to register new values, and in those cases, text below advises the designed expert to verify that the entity requesting the registration is relevant (e.g., a recognized emergency-services-related Standards Development Organization (SDO)). In other cases, especially those where the trade-off between the potential benefit versus danger of new registrations is more conservative (such as Section 11.1.9), "Specification Required" is the criteria, which is a higher hurdle and also implicitly includes an "Expert Review". The following sub-registries are created for this registry.11.1.1. Provider ID Series Registry
This document creates a new sub-registry called "Provider ID Series". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the entity requesting a new value is a legitimate issuer of service provider IDs suitable for use in Additional Call Data. Private entities issuing or using internally generated IDs are encouraged to register here and to ensure that all IDs they issue or use are unique. This guarantees that IDs issued or used by the entity are globally unique and distinguishable from other IDs issued or used by the same or a different entity. (Some organizations, such as NENA, issue IDs that are unique among all IDs they issue, so an entity using a combination of its NENA ID and the fact that it is from NENA is globally unique. Other entities might not have an ID issued by an organization such as NENA, so they are permitted to use their domain name, but if so, it needs to be unique.) The content of this registry includes: Name: An identifier to be used in the 'ProviderIDSeries' element. Source: The full name of the organization issuing the identifiers.
URL: A URL to the organization for further information. The initial set of values is listed in Figure 1.11.1.2. Service Environment Registry
This document creates a new sub-registry called "Service Environment". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the entity requesting a new value is relevant for this service element (e.g., a recognized emergency-services-related SDO) and that the new value is distinct from existing values, and its use is unambiguous. The content of this registry includes: Token: The value to be used in the <ServiceEnvironment> element. Description: A short description of the value. The initial set of values is listed in Figure 4.11.1.3. Service Type Registry
This document creates a new sub-registry called "Service Type". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the entity requesting a new value is relevant for this service element (e.g., a recognized emergency-services-related SDO) and that the requested value is clearly distinct from other values so that there is no ambiguity as to when the value is to be used or which value is to be used. The content of this registry includes: Name: The value to be used in the <ServiceType> element. Description: A short description of the value. The initial set of values is listed in Figure 5.11.1.4. Service Mobility Registry
This document creates a new sub-registry called "Service Mobility". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the entity requesting a new value is relevant for this service element (e.g., a recognized emergency-services-related SDO) and that the requested value is clearly distinct from other values so that there is no ambiguity as to when the value is to be used or which value is to be used.
The content of this registry includes: Token: The value used in the <ServiceMobility> element. Description: A short description of the value. The initial set of values is listed in Figure 6.11.1.5. Type of Provider Registry
This document creates a new sub-registry called "Type of Provider". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the proposed new value is distinct from existing values and appropriate for use in the <TypeOfServicerProvider> element The content of this registry includes: Token: The value used in the <TypeOfProvider> element. Description: A short description of the type of service provider. The initial set of values is defined in Figure 2.11.1.6. Device Classification Registry
This document creates a new sub-registry called "Device Classification". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should consider whether the proposed class is unique from existing classes, and the definition of the class will be clear to implementors and PSAPs/responders. The content of this registry includes: Token: Value used in the <DeviceClassification> element. Description: Short description identifying the device type. The initial set of values is defined in Figure 8.11.1.7. Device ID Type Registry
This document creates a new sub-registry called "Device ID Type". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should ascertain that the proposed type is well understood and provides information that PSAPs and responders are able to use to uniquely identify a device. (For example, a biometric
fingerprint used to authenticate a device would not normally be used
by a PSAP or responder to identify a device.)
The content of this registry includes:
Token: The value to be placed in the <TypeOfDeviceID> element.
Description: Short description identifying the type of the device
ID.
The initial set of values is defined in Figure 9.
11.1.8. Device/Service Data Type Registry
This document creates a new sub-registry called "Device/Service Data
Type". As defined in [RFC5226], this registry operates under
"Specification Required" rules, which include an explicit "Expert
Review". The designated expert should ascertain that the proposed
type is well understood and provides information useful to PSAPs and
responders. The specification must contain a complete description of
the data and a precise format specification suitable to allow
interoperable implementations.
The content of this registry includes:
Token: The value to be placed in the <DeviceSpecificType> element.
Description: Short description identifying the data.
Specification: Citation for the specification of the data.
The initial set of values is listed in Figure 10.
11.1.9. Emergency Call Data Types Registry
This document creates a new sub-registry called "Emergency Call Data
Types". As defined in [RFC5226], this registry operates under
"Specification Required" rules, which include an explicit "Expert
Review". The expert is responsible for verifying that the document
contains a complete and clear specification, and the proposed
functionality does not obviously duplicate existing functionality.
The expert is also responsible for verifying that the block is
correctly categorized per the description of the categories in
Section 1.
The registry contains an entry for every data block that can be sent
with an emergency call using the mechanisms as specified in this
document. Each data block is identified by the 'root' of its MIME
media subtype (which is the part after 'EmergencyCallData.'). If the
MIME media subtype does not start with 'EmergencyCallData.', then it
cannot be registered here nor used in a Call-Info header field as
specified in this document. The subtype MAY exist under any MIME
media type (although most commonly under 'application/', this is NOT
REQUIRED); however, to be added to the registry, the 'root' needs to
be unique regardless of the MIME media type.
The content of this registry includes:
Token: The root of the data's MIME media subtype (not including the
'EmergencyCallData' prefix and any suffix such as '+xml').
Data About: A hint as to if the block is considered descriptive of
the call, the caller, or the location (or is applicable to more
than one), which can help PSAPs and other entities determine if
they wish to process the block. Note that this is only a hint;
entities need to consider the block's contents, not just this
field, when determining if they wish to process the block (which
is why the field only exists in the registry and is not contained
within the block). The value MUST be either 'The Call', 'The
Caller', 'The Location', or 'Multiple'. New values are created by
extending this registry in a subsequent RFC.
Reference: The document that describes the data object.
Note that the tokens in this registry are part of the
'EmergencyCallData' compound value; when used as a value of the
'purpose' parameter of a Call-Info header field, the values listed in
this registry are prefixed by 'EmergencyCallData.' per the
'EmergencyCallData' registration; see Section 11.2.
The initial set of values is listed in Figure 25.
+----------------+--------------+------------+
| Token | Data About | Reference |
+----------------+--------------+------------+
| ProviderInfo | The Call | RFC 7852 |
| ServiceInfo | The Call | RFC 7852 |
| DeviceInfo | The Call | RFC 7852 |
| SubscriberInfo | The Call | RFC 7852 |
| Comment | The Call | RFC 7852 |
+----------------+--------------+------------+
Figure 25: Additional Data Blocks Registry
11.2. 'EmergencyCallData' Purpose Parameter Value
This document defines the 'EmergencyCallData' value for the 'purpose' parameter of the Call-Info header field [RFC3261]. IANA has added this document to the list of references for the 'purpose' value of Call-Info in the "Header Field Parameters and Parameter Values" sub- registry of the "Session Initiation Protocol (SIP) Parameters" registry. Note that 'EmergencyCallData' is a compound value; when used as a value of the 'purpose' parameter of a Call-Info header field, 'EmergencyCallData' is immediately followed by a dot ('.') and a value from the "Emergency Call Data Types" registry; see Section 11.1.9.11.3. URN Sub-Namespace Registration for <provided-by> Registry Entry
This section registers the namespace specified in Section 11.5.1 in the provided-by registry established by RFC 4119, for usage within the <provided-by> element of a PIDF-LO. The schema for the <provided-by> element used by this document is specified in Section 8.6.11.4. MIME Registrations
11.4.1. MIME Content-Type Registration for 'application/ EmergencyCallData.ProviderInfo+xml'
This specification requests the registration of a new MIME media type according to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. Type name: application Subtype name: EmergencyCallData.ProviderInfo+xml Mandatory parameters: N/A Optional parameters: charset (indicates the character encoding of the contents) Encoding considerations: Uses XML, which can contain 8-bit characters, depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303]. Security considerations: This content type is designed to carry the data provider information, which is a sub-category of additional data about an emergency call. Since this data can contain personal information, appropriate precautions are needed
to limit unauthorized access, inappropriate disclosure, and
eavesdropping of personal information. Please refer to Sections 9
and 10 for more information.
Interoperability considerations: N/A
Published specification: RFC 7852
Applications that use this media type: Emergency Services
Additional information:
Magic Number: N/A
File Extension: .xml
Macintosh file type code: 'TEXT'
Person and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <iesg@ietf.org>
11.4.2. MIME Content-Type Registration for 'application/
EmergencyCallData.ServiceInfo+xml'
This specification requests the registration of a new MIME media type
according to the procedures of RFC 6838 [RFC6838] and guidelines in
RFC 7303 [RFC7303].
Type name: application
Subtype name: EmergencyCallData.ServiceInfo+xml
Mandatory parameters: N/A
Optional parameters: charset (indicates the character encoding of
the contents)
Encoding considerations: Uses XML, which can contain 8-bit
characters, depending on the character encoding. See Section 3.2
of RFC 7303 [RFC7303].
Security considerations: This content type is designed to carry
the service information, which is a sub-category of additional
data about an emergency call. Since this data can contain
personal information, appropriate precautions are needed to limit
unauthorized access, inappropriate disclosure, and eavesdropping
of personal information. Please refer to Sections 9 and 10 for
more information.
Interoperability considerations: N/A
Published specification: RFC 7852
Applications that use this media type: Emergency Services
Additional information:
Magic Number: N/A
File Extension: .xml
Macintosh file type code: 'TEXT'
Person and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <iesg@ietf.org>
11.4.3. MIME Content-Type Registration for 'application/
EmergencyCallData.DeviceInfo+xml'
This specification requests the registration of a new MIME media type
according to the procedures of RFC 6838 [RFC6838] and guidelines in
RFC 7303 [RFC7303].
Type name: application
Subtype name: EmergencyCallData.DeviceInfo+xml
Mandatory parameters: N/A
Optional parameters: charset (indicates the character encoding of
the contents)
Encoding considerations: Uses XML, which can contain 8-bit
characters, depending on the character encoding. See Section 3.2
of RFC 7303 [RFC7303].
Security considerations: This content type is designed to carry
device information, which is a sub-category of additional data
about an emergency call. Since this data contains personal
information, appropriate precautions need to be taken to limit
unauthorized access, inappropriate disclosure to third parties,
and eavesdropping of this information. Please refer to Sections 9
and 10 for more information.
Interoperability considerations: N/A
Published specification: RFC 7852
Applications that use this media type: Emergency Services
Additional information:
Magic Number: N/A
File Extension: .xml
Macintosh file type code: 'TEXT'
Person and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <iesg@ietf.org>
11.4.4. MIME Content-Type Registration for 'application/
EmergencyCallData.SubscriberInfo+xml'
This specification requests the registration of a new MIME media type
according to the procedures of RFC 6838 [RFC6838] and guidelines in
RFC 7303 [RFC7303].
Type name: application
Subtype name: EmergencyCallData.SubscriberInfo+xml
Mandatory parameters: N/A
Optional parameters: charset (indicates the character encoding of
the contents)
Encoding considerations: Uses XML, which can contain 8-bit
characters, depending on the character encoding. See Section 3.2
of RFC 7303 [RFC7303].
Security considerations: This content type is designed to carry
owner/subscriber information, which is a sub-category of
additional data about an emergency call. Since this data contains
personal information, appropriate precautions need to be taken to
limit unauthorized access, inappropriate disclosure to third
parties, and eavesdropping of this information. Please refer to
Sections 9 and 10 for more information.
Interoperability considerations: N/A
Published specification: RFC 7852
Applications that use this media type: Emergency Services
Additional information:
Magic Number: N/A
File Extension: .xml
Macintosh file type code: 'TEXT'
Person and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <iesg@ietf.org>
11.4.5. MIME Content-Type Registration for 'application/
EmergencyCallData.Comment+xml'
This specification requests the registration of a new MIME media type
according to the procedures of RFC 6838 [RFC6838] and guidelines in
RFC 7303 [RFC7303].
Type name: application
Subtype name: EmergencyCallData.Comment+xml
Mandatory parameters: N/A
Optional parameters: charset (indicates the character encoding of
the contents)
Encoding considerations: Uses XML, which can contain 8-bit
characters, depending on the character encoding. See Section 3.2
of RFC 7303 [RFC7303].
Security considerations: This content type is designed to carry a
comment, which is a sub-category of additional data about an
emergency call. This data can contain personal information.
Appropriate precautions are needed to limit unauthorized access,
inappropriate disclosure to third parties, and eavesdropping of
this information. Please refer to Sections 9 and 10 for more
information.
Interoperability considerations: N/A
Published specification: RFC 7852
Applications that use this media type: Emergency Services
Additional information:
Magic Number: N/A
File Extension: .xml
Macintosh file type code: 'TEXT'
Person and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <iesg@ietf.org>
11.5. URN Sub-Namespace Registration
11.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:EmergencyCallData Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>. XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Namespace for Additional Emergency Call Data</title> </head> <body> <h1>Namespace for Additional Data Related to an Emergency Call </h1> <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> RFC 7852</a>.</p> </body> </html> END11.5.2. Registration for urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:
Data Provider Information</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2>Data Provider Information</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.5.3. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo
This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
delegated by the IESG <iesg@ietf.org>.
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:
Service Information</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2>Service Information</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.5.4. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo
This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
delegated by the IESG <iesg@ietf.org>.
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:
Device Information</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2>Device Information</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.5.5. Registration for urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>. XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Namespace for Additional Emergency Call Data: Owner/Subscriber Information</title> </head> <body> <h1>Namespace for Additional Data Related to an Emergency Call </h1> <h2> Owner/Subscriber Information</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> RFC 7852</a>.</p> </body> </html> END11.5.6. Registration for urn:ietf:params:xml:ns:EmergencyCallData:Comment
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:Comment
</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2> Comment</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.6. Schema Registrations
This specification registers the following schemas, as per the
guidelines in RFC 3688 [RFC3688].
ID: EmergencyCallData
URI: urn:ietf:params:xml:schema:EmergencyCallData
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Section 8.6.
ID: EmergencyCallData:ProviderInfo
URI: urn:ietf:params:xml:schema:EmergencyCallData:ProviderInfo
Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Figure 19.
ID: EmergencyCallData:ServiceInfo
URI: urn:ietf:params:xml:schema:EmergencyCallData:ServiceInfo
Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Figure 20.
ID: EmergencyCallData:DeviceInfo
URI: urn:ietf:params:xml:schema:EmergencyCallData:DeviceInfo
Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Figure 21.
ID: EmergencyCallData:SubscriberInfo
URI: urn:ietf:params:xml:schema:EmergencyCallData:SubscriberInfo
Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Section 8.4.
ID: EmergencyCallData:Comment
URI: urn:ietf:params:xml:schema:EmergencyCallData:Comment
Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Section 8.5.
ID: vcard-4.0
URI: urn:ietf:params:xml:ns:vcard-4.0
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Appendix A.
11.7. vCard Parameter Value Registration
This document registers a new value in the "vCard Parameter Values"
registry as defined by [RFC6350] with the following template:
Value: main-number
Purpose: The main telephone number, typically of an enterprise, as
opposed to a direct-dial number of an individual employee
Conformance: This value can be used with the 'TYPE' parameter
applied on the 'TEL' property
Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90
00
(next page on part 5)
