Internet DRAFT - draft-bakker-sipping-3gpp-ims-xml-body-handling
draft-bakker-sipping-3gpp-ims-xml-body-handling
SIPPING Working Group J. Bakker, Ed.
Internet-Draft Research In Motion (RIM)
Intended status: Experimental March 27, 2012
Expires: September 28, 2012
Specification of 3GPP IM CN Subsystem XML body handling
draft-bakker-sipping-3gpp-ims-xml-body-handling-08
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. The applicability of these content-
disposition values are limited to 3GPP IMS. 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 September 28, 2012.
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 September 28, 2012 [Page 1]
Internet-Draft 3GPP IM CN Subsystem XML body handling March 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. 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. Example application/3gpp-ims+xml body (part) . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Revision Information . . . . . . . . . . . . . . . . . 7
A.1. version 00 . . . . . . . . . . . . . . . . . . . . . . . . 7
A.2. version 01 . . . . . . . . . . . . . . . . . . . . . . . . 7
A.3. version 02 . . . . . . . . . . . . . . . . . . . . . . . . 7
A.4. version 03 . . . . . . . . . . . . . . . . . . . . . . . . 7
A.5. version 04 . . . . . . . . . . . . . . . . . . . . . . . . 7
A.6. version 05 . . . . . . . . . . . . . . . . . . . . . . . . 7
A.7. version 06 . . . . . . . . . . . . . . . . . . . . . . . . 7
A.8. version 07 . . . . . . . . . . . . . . . . . . . . . . . . 7
A.9. version 08 . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Bakker Expires September 28, 2012 [Page 2]
Internet-Draft 3GPP IM CN Subsystem XML body handling March 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 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) 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 September 28, 2012 [Page 3]
Internet-Draft 3GPP IM CN Subsystem XML body handling March 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 to be 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 default content disposition has been defined for MIME type
"application/3gpp-ims+xml" MIME type. Sections 2.2 and 2.3 show how
a body (part) according to the MIME type is to be intepreted by
different entities (UE and AS) in 3GPP IMS. 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 to
be interpreted, implies that a single default content disposition
value does not cover both cases
4.2. The application/3gpp-ims+xml MIME type with content disposition
3gpp-alternative-service
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 detects the emergency call and can 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".
It is further possible that one or more UASes in the network
experience service interuptions, e.g. when forwarding a (non-
emergency) service request from a UAC. For example, 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 or the UAS) and the attempt to retrieve the user profile
fails. The UAS then responds with a 504 (Server Time-out), including
a MIME body (part) and a Content-Type header field set to
Bakker Expires September 28, 2012 [Page 4]
Internet-Draft 3GPP IM CN Subsystem XML body handling March 2012
"application/3gpp-ims+xml". Upon receiving the response, the UAC
then creates 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 and security issues with usage of this mechanism in
the general internet have not been evaluated.
4.2.1. Example application/3gpp-ims+xml MIME body (part) with type XML
element set to emergency
<ims-3gpp version="1">
<alternative-service>
<type>emergency</type>
<reason/>
</alternative-service>
</ims-3gpp>
4.3. The application/3gpp-ims+xml MIME type with content disposition
3gpp-service-info
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.1, an International Mobile Subscriber Identity (IMSI) is
transferred.
4.3.1. Example application/3gpp-ims+xml body (part)
<ims-3gpp version="1">
<service-info>
262013564857956
</service-info>
</ims-3gpp>
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
Bakker Expires September 28, 2012 [Page 5]
Internet-Draft 3GPP IM CN Subsystem XML body handling March 2012
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
and Paul Kyzivat for their guidance and comments that contributed to
the progression of this work.
8. References
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.
Bakker Expires September 28, 2012 [Page 6]
Internet-Draft 3GPP IM CN Subsystem XML body handling March 2012
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
8.2. Informative References
[5] 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.8.0, June 2009.
Appendix A. Revision Information
A.1. version 00
1. 2008-02-12, Initial version
A.2. version 01
1. 2008-07-02, Updated reference and further aligned 3GPP TS 24.229
and this document
A.3. version 02
1. 2009-03-01, Corrected "header" into "header field"
A.4. version 03
1. 2010-02-23, no changes
2. 2011-02-09, no changes
A.5. version 04
1. 2010-09-28, Introduces the case of addressing the MIME body's use
for indicating the need to re-register with the IMS
2. 2010-09-28, Updates the reference to 3GPP TS 24.229
3. 2010-09-28, Introduces a reference to
draft-patel-ecrit-sos-parameter-10
A.6. version 05
1. 2011-02-09, Editorially correct "registeration context" into
"registration context"
2. 2011-02-09, Removed the reference to
draft-patel-ecrit-sos-parameter-10
A.7. version 06
1. 2011-02-21, corrected, and changed, XML element name from "3gpp-
ims" to "ims-3gpp"
2. 2011-02-21, Updated address information of author
A.8. version 07
1. 2011-12-02, Updated address information of author
Bakker Expires September 28, 2012 [Page 7]
Internet-Draft 3GPP IM CN Subsystem XML body handling March 2012
A.9. version 08
1. 2012-27-03, Added a new background section 2.1 and renumbered
existing sections
2. 2012-27-03, Improved body handling text to not preclude multipart
bodies
3. 2012-27-03, Editorials
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 September 28, 2012 [Page 8]
