DISPATCH Working Group J. Bakker, Ed. Internet-Draft Research In Motion (RIM) Intended status: Standards Track September 4, 2012 Expires: March 8, 2013 Specification of 3GPP IM CN Subsystem XML body handling draft-bakker-dispatch-3gpp-ims-xml-body-handling-00 Abstract This document registers new disposition-types for the Content- Disposition header field that apply to the application/3gpp-ims+xml body (part) used by 3GPP [5]. The applicability of these content- disposition values are limited to 3GPP IMS [5]. The application/ 3gpp-ims+xml body (part) has the following three distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), (2) for delivering user profile specific information from the SIP registrar to an Application Server, and (3) for causing a UAC to attempt to re-register with the IMS. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 8, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Bakker Expires March 8, 2013 [Page 1] Internet-Draft 3GPP IM CN Subsystem XML body handling September 2012 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overall Applicability . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Background for the new disposition-types for the Content-Disposition header field . . . . . . . . . . . . . . . 4 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. The application/3gpp-ims+xml MIME type with content disposition 3gpp-alternative-service . . . . . . . . . . . 4 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2.2. Example application/3gpp-ims+xml MIME body (part) with type XML element set to emergency . . . . . . . . 5 4.3. The application/3gpp-ims+xml MIME type with content disposition 3gpp-service-info . . . . . . . . . . . . . . . 5 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3.2. Example application/3gpp-ims+xml body (part) . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Revision Information . . . . . . . . . . . . . . . . . 7 A.1. version 00 . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Bakker Expires March 8, 2013 [Page 2] Internet-Draft 3GPP IM CN Subsystem XML body handling September 2012 1. Overall Applicability This document makes certain assumptions regarding network topology and the existence of transitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. The mechanism specified here was designed to satisfy the requirements specified by the 3rd Generation Partnership Project (3GPP) for IP multimedia subsystem (IMS) for which either no general-purpose solution was found, where insufficient operational experience was available to understand if a general solution is needed, or where a more general solution is not yet mature. 2. Introduction New disposition-types for the Content-Disposition header field can only be registered with IANA according to procedures defined in Section 9 of [1]. The 3rd Generation Partnership Project (3GPP) (http://www.3gpp.org) is specifying the IP multimedia subsystem (IMS) [6] where SIP is the protocol used to establish media sessions across different participants. This document registers new disposition-types for the Content- Disposition header field: 3gpp-alternative-service and 3gpp-service- info, to address specific requirements of the IMS. The new disposition-types may not be applicable to the general Internet. The new disposition types are applicable to the "application/ 3gpp-ims+xml" MIME type [5]. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. The term "Application Server" (AS) is introduced in this document. An "Application Server" as referred to here is a SIP network server that performs network based functions. The AS can act as a SIP Proxy as defined in [3] or a back-to-back UA (B2BUA) as defined in [3] based on the functions it needs to perform. There can be one or more ASes involved in a SIP session. Bakker Expires March 8, 2013 [Page 3] Internet-Draft 3GPP IM CN Subsystem XML body handling September 2012 4. Background for the new disposition-types for the Content-Disposition header field 4.1. Introduction Section 20.11 of [3] specifies that the Content-Disposition header field describes how the message body or, for multipart messages, a message body part is interpreted by the UAC or UAS. In addition, [3] specifies that if this header field is missing, the MIME type determines the default content disposition. If there is none, "render" is assumed. No default content disposition has been defined for MIME type "application/3gpp-ims+xml" MIME type [5]. Sections 4.2 and 4.3 below show how a body (part) according to the MIME type is interpreted by different entities (UE and AS) in 3GPP IMS (each entity having a different content handler for the same MIME media type tag). The difference in requirements for UE and AS, coupled with the fact that the Content-Disposition header field describes how the message body (part) is interpreted, implies that a single default content disposition value does not cover both cases. NOTE: An alternative with a more general applicable approach could e.g. be unique MIME media type tags, each associated with a content handler. However, having unique MIME media type tags at this stage raises backwards compatibility concerns for the IP multimedia subsystem (IMS) [6]. 4.2. The application/3gpp-ims+xml MIME type with content disposition 3gpp-alternative-service 4.2.1. General In the IMS it is possible that a UA attempts to place an emergency call when the IMS network does not support emergency services. The edge proxy can detect the emergency call and redirect the UE using a SIP 380 (Alternative Service) to place the emergency call using another domain (e.g. using a Circuit Switched network) or using another registration context, if a type XML element in the MIME body (part) is set to "emergency". Section 21.3.5 of [3] specifies that, for the SIP 380 (Alternative Service) response, alternative services are described in the message body (part) of the response. In IMS, for the purpose of indicating alternative domains, a SIP 380 (Alternative Service) response will include a MIME body (part) and a Content-Type header field set to "application/3gpp-ims+xml". Bakker Expires March 8, 2013 [Page 4] Internet-Draft 3GPP IM CN Subsystem XML body handling September 2012 It is further possible that one or more UASes in the network experience service interruptions, e.g. when forwarding a (non- emergency) service request from a UAC. Examples of this are when there is no response to the service request and its retransmissions, a 3xx response or a 480 (Temporarily Unavailable) response is received for the request, the UAS does not have a needed user profile (e.g. due to restart of the UAS) and the attempt to retrieve the user profile fails. In such situations the UAS responds with a 504 (Server Time-out), including a MIME body (part) and a Content-Type header field set to "application/3gpp-ims+xml". Upon receiving this response, the UAC can create another registration context in an attempt to restore the services, if a type XML element in the MIME body (part) is set to "restoration". Such configurations are generally not applicable to the internet as a whole where such trust relationships do not exist. In addition, security issues have only been considered for networks which are trusted and use hop by hop security mechanisms with transitive trust. Security issues with usage of this mechanism in the general internet have not been evaluated. 4.2.2. Example application/3gpp-ims+xml MIME body (part) with type XML element set to emergency emergency 4.3. The application/3gpp-ims+xml MIME type with content disposition 3gpp-service-info 4.3.1. General In 3GPP IMS the SIP registrar (S-CSCF) can perform a third party registration to an AS. The SIP registrar downloads User Profile information and can transparently transfer User Profile specific information to the AS using a body (part) of MIME type "application/ 3gpp-ims+xml" in a SIP REGISTER request. In the example in Section 4.3.2, an International Mobile Subscriber Identity (IMSI) is transferred. Bakker Expires March 8, 2013 [Page 5] Internet-Draft 3GPP IM CN Subsystem XML body handling September 2012 4.3.2. Example application/3gpp-ims+xml body (part) 262013564857956 5. Security Considerations It is necessary to protect the messages between proxies; implementation SHOULD use a transport that provides integrity and confidentially between the signaling hops. The Transport Layer Security (TLS) [4] based signaling in SIP can be used to provide this protection. Security issues have only been considered for networks which are trusted and use hop by hop security mechanisms with transitive trust and security issues with usage of this mechanism in the general internet have not been evaluated. 6. IANA Considerations This document registers new disposition-types for the Content- Disposition header field that apply to the "application/3gpp-ims+xml" body (part) used by 3GPP and are to be registered in the IANA registry for Mail Content Disposition Values and Parameters: o 3gpp-alternative-service: the body (part) contains 3GPP IM CN subsystem XML with the 'alternative-service' XML element as described in Section 4.2; and o 3gpp-service-info: the body (part) contains 3GPP IM CN subsystem XML with the 'service-info' XML element as described in Section 4.3. 7. Acknowledgements The author would like to thank Andrew Allen, Dean Willis, Cullen Jennings, Victor Pascual Avila, Christopher Wong, Gonzalo Camarillo, Paul Kyzivat, and Atle Monrad for their guidance and comments that contributed to the progression of this work. 8. References Bakker Expires March 8, 2013 [Page 6] Internet-Draft 3GPP IM CN Subsystem XML body handling September 2012 8.1. Normative References [1] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content- Disposition Header Field", RFC 2183, August 1997. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 8.2. Informative References [5] IANA, "Registry for Application Media Types". [6] 3GPP, "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 8)", 3GPP TS 24.229 V8.20.0, June 2012. Appendix A. Revision Information A.1. version 00 1. Initial version for consideration by dispatch, based upon draft-bakker-sipping-3gpp-ims-xml-body-handling-08 2. Changed references to section 2.2 and 2.3 into 4.2 and 4.3, respectively. 3. Updated abstract and section 2 and section 4.1 to reflect discussions on the list 4. Various editorial comments Bakker Expires March 8, 2013 [Page 7] Internet-Draft 3GPP IM CN Subsystem XML body handling September 2012 Author's Address John-Luc Bakker (editor) Research In Motion (RIM) 5000 Riverside Drive, building 6, suite 100 Irving, Texas 75039 USA Phone: unlisted Fax: unlisted Email: jbakker@rim.com Bakker Expires March 8, 2013 [Page 8]