tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7852

 
 
 

Additional Data Related to an Emergency Call

Part 4 of 5, p. 62 to 83
Prev Section       Next Section

 


prevText      Top      ToC       Page 62 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 Section