Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7852

Additional Data Related to an Emergency Call

Pages: 113
Proposed Standard
Errata
Updates:  64436881
Part 4 of 5 – Pages 62 to 83
First   Prev   Next

Top   ToC   RFC7852 - Page 62   prevText

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.
Top   ToC   RFC7852 - Page 63
   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
Top   ToC   RFC7852 - Page 64
   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].
Top   ToC   RFC7852 - Page 65
   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
Top   ToC   RFC7852 - Page 66
   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.
Top   ToC   RFC7852 - Page 67

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.
Top   ToC   RFC7852 - Page 68
   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.
Top   ToC   RFC7852 - Page 69
   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
Top   ToC   RFC7852 - Page 70
   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
Top   ToC   RFC7852 - Page 71
   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
Top   ToC   RFC7852 - Page 72

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
Top   ToC   RFC7852 - Page 73
      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].
Top   ToC   RFC7852 - Page 74
      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)
Top   ToC   RFC7852 - Page 75
      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
Top   ToC   RFC7852 - Page 76
      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
Top   ToC   RFC7852 - Page 77
      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>
Top   ToC   RFC7852 - Page 78

11.5. URN Sub-Namespace Registration

11.5.1. Registration for urn:ietf:params:xml:ns:EmergencyCallData

This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:EmergencyCallData Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>. XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Namespace for Additional Emergency Call Data</title> </head> <body> <h1>Namespace for Additional Data Related to an Emergency Call </h1> <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> RFC 7852</a>.</p> </body> </html> END

11.5.2. Registration for urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo

This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
Top   ToC   RFC7852 - Page 79
   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>
Top   ToC   RFC7852 - Page 80
        <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
Top   ToC   RFC7852 - Page 81

11.5.5. Registration for urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo

This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>. XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Namespace for Additional Emergency Call Data: Owner/Subscriber Information</title> </head> <body> <h1>Namespace for Additional Data Related to an Emergency Call </h1> <h2> Owner/Subscriber Information</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt"> RFC 7852</a>.</p> </body> </html> END

11.5.6. Registration for urn:ietf:params:xml:ns:EmergencyCallData:Comment

This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
Top   ToC   RFC7852 - Page 82
   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.
Top   ToC   RFC7852 - Page 83
      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)

Next Section