idnits 2.17.1
draft-bakker-sipping-3gpp-ims-xml-body-handling-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 27, 2012) is 4412 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 4346 (ref. '4') (Obsoleted by RFC 5246)
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIPPING Working Group J. Bakker, Ed.
3 Internet-Draft Research In Motion (RIM)
4 Intended status: Experimental March 27, 2012
5 Expires: September 28, 2012
7 Specification of 3GPP IM CN Subsystem XML body handling
8 draft-bakker-sipping-3gpp-ims-xml-body-handling-08
10 Abstract
12 This document registers new disposition-types for the Content-
13 Disposition header field that apply to the application/3gpp-ims+xml
14 body (part) used by 3GPP. The applicability of these content-
15 disposition values are limited to 3GPP IMS. The application/
16 3gpp-ims+xml body (part) has the following three distinct uses: (1)
17 for redirecting the emergency session to use a different domain (e.g.
18 using a Circuit Switched call), (2) for delivering user profile
19 specific information from the SIP registrar to an Application Server,
20 and (3) for causing a UAC to attempt to re-register with the IMS.
22 Status of this Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on September 28, 2012.
39 Copyright Notice
41 Copyright (c) 2012 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Overall Applicability . . . . . . . . . . . . . . . . . . . . . 3
58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 4. Background for the new disposition-types for the
63 Content-Disposition header field . . . . . . . . . . . . . . . 4
64 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
65 4.2. The application/3gpp-ims+xml MIME type with content
66 disposition 3gpp-alternative-service . . . . . . . . . . . 4
67 4.2.1. Example application/3gpp-ims+xml MIME body (part)
68 with type XML element set to emergency . . . . . . . . 5
69 4.3. The application/3gpp-ims+xml MIME type with content
70 disposition 3gpp-service-info . . . . . . . . . . . . . . . 5
71 4.3.1. Example application/3gpp-ims+xml body (part) . . . . . 5
73 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
81 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
83 Appendix A. Revision Information . . . . . . . . . . . . . . . . . 7
84 A.1. version 00 . . . . . . . . . . . . . . . . . . . . . . . . 7
85 A.2. version 01 . . . . . . . . . . . . . . . . . . . . . . . . 7
86 A.3. version 02 . . . . . . . . . . . . . . . . . . . . . . . . 7
87 A.4. version 03 . . . . . . . . . . . . . . . . . . . . . . . . 7
88 A.5. version 04 . . . . . . . . . . . . . . . . . . . . . . . . 7
89 A.6. version 05 . . . . . . . . . . . . . . . . . . . . . . . . 7
90 A.7. version 06 . . . . . . . . . . . . . . . . . . . . . . . . 7
91 A.8. version 07 . . . . . . . . . . . . . . . . . . . . . . . . 7
92 A.9. version 08 . . . . . . . . . . . . . . . . . . . . . . . . 8
94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
96 1. Overall Applicability
98 This document makes certain assumptions regarding network topology
99 and the existence of transitive trust. These assumptions are
100 generally NOT APPLICABLE in the Internet as a whole. The mechanism
101 specified here was designed to satisfy the requirements specified by
102 the 3rd Generation Partnership Project for IP multimedia subsystem
103 (IMS) for which either no general-purpose solution was found, where
104 insufficient operational experience was available to understand if a
105 general solution is needed, or where a more general solution is not
106 yet mature.
108 2. Introduction
110 New disposition-types for the Content-Disposition header field can
111 only be registered with IANA according to procedures defined in
112 Section 9 of [1].
114 The 3rd Generation Partnership Project (3GPP) (http://www.3gpp.org)
115 is specifying the IP multimedia subsystem (IMS) where SIP is the
116 protocol used to establish media sessions across different
117 participants.
119 This document registers new disposition-types for the Content-
120 Disposition header field: 3gpp-alternative-service and 3gpp-service-
121 info, to address specific requirements of the IMS. The new
122 disposition-types may not be applicable to the general Internet. The
123 new disposition types are applicable to the "application/
124 3gpp-ims+xml" MIME type [5].
126 3. Terminology
128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
130 document are to be interpreted as described in [2].
132 The term "Application Server" (AS) is introduced in this document.
134 An "Application Server" as referred to here is a SIP network server
135 that performs network based functions. The AS can act as a SIP Proxy
136 as defined in [3] or a back-to-back UA (B2BUA) as defined in [3]
137 based on the functions it needs to perform. There can be one or more
138 ASes involved in a SIP session.
140 4. Background for the new disposition-types for the Content-Disposition
141 header field
143 4.1. Introduction
145 Section 20.11 of [3] specifies that the Content-Disposition header
146 field describes how the message body or, for multipart messages, a
147 message body part is to be interpreted by the UAC or UAS. In
148 addition, [3] specifies that if this header field is missing, the
149 MIME type determines the default content disposition. If there is
150 none, "render" is assumed.
152 No default default content disposition has been defined for MIME type
153 "application/3gpp-ims+xml" MIME type. Sections 2.2 and 2.3 show how
154 a body (part) according to the MIME type is to be intepreted by
155 different entities (UE and AS) in 3GPP IMS. The difference in
156 requirements for UE and AS, coupled with the fact that the Content-
157 Disposition header field describes how the message body (part) is to
158 be interpreted, implies that a single default content disposition
159 value does not cover both cases
161 4.2. The application/3gpp-ims+xml MIME type with content disposition
162 3gpp-alternative-service
164 In the IMS it is possible that a UA attempts to place an emergency
165 call when the IMS network does not support emergency services. The
166 edge proxy detects the emergency call and can redirect the UE using a
167 SIP 380 (Alternative Service) to place the emergency call using
168 another domain (e.g. using a Circuit Switched network) or using
169 another registration context, if a type XML element in the MIME body
170 (part) is set to "emergency".
172 Section 21.3.5 of [3] specifies that, for the SIP 380 (Alternative
173 Service) response, alternative services are described in the message
174 body (part) of the response. In IMS, for the purpose of indicating
175 alternative domains, a SIP 380 (Alternative Service) response will
176 include a MIME body (part) and a Content-Type header field set to
177 "application/3gpp-ims+xml".
179 It is further possible that one or more UASes in the network
180 experience service interuptions, e.g. when forwarding a (non-
181 emergency) service request from a UAC. For example, there is no
182 response to the service request and its retransmissions, a 3xx
183 response or a 480 (Temporarily Unavailable) response is received for
184 the request, the UAS does not have a needed user profile (e.g. due to
185 restart or the UAS) and the attempt to retrieve the user profile
186 fails. The UAS then responds with a 504 (Server Time-out), including
187 a MIME body (part) and a Content-Type header field set to
188 "application/3gpp-ims+xml". Upon receiving the response, the UAC
189 then creates another registration context in an attempt to restore
190 the services, if a type XML element in the MIME body (part) is set to
191 "restoration".
193 Such configurations are generally not applicable to the internet as a
194 whole where such trust relationships do not exist.
196 In addition security issues have only been considered for networks
197 which are trusted and use hop by hop security mechanisms with
198 transitive trust and security issues with usage of this mechanism in
199 the general internet have not been evaluated.
201 4.2.1. Example application/3gpp-ims+xml MIME body (part) with type XML
202 element set to emergency
204
205
206 emergency
207
208
209
211 4.3. The application/3gpp-ims+xml MIME type with content disposition
212 3gpp-service-info
214 In 3GPP IMS the SIP registrar (S-CSCF) can perform a third party
215 registration to an AS. The SIP registrar downloads User Profile
216 information and can transparently transfer User Profile specific
217 information to the AS using a body (part) of MIME type "application/
218 3gpp-ims+xml" in a SIP REGISTER request. In the example in Section
219 4.3.1, an International Mobile Subscriber Identity (IMSI) is
220 transferred.
222 4.3.1. Example application/3gpp-ims+xml body (part)
224
225
226 262013564857956
227
228
230 5. Security Considerations
232 It is necessary to protect the messages between proxies;
233 implementation SHOULD use a transport that provides integrity and
234 confidentially between the signaling hops. The Transport Layer
235 Security (TLS) [4] based signaling in SIP can be used to provide this
236 protection.
238 Security issues have only been considered for networks which are
239 trusted and use hop by hop security mechanisms with transitive trust
240 and security issues with usage of this mechanism in the general
241 internet have not been evaluated.
243 6. IANA Considerations
245 This document registers new disposition-types for the Content-
246 Disposition header field that apply to the "application/3gpp-ims+xml"
247 body (part) used by 3GPP and are to be registered in the IANA
248 registry for Mail Content Disposition Values and Parameters:
250 o 3gpp-alternative-service: the body (part) contains 3GPP IM CN
251 subsystem XML with the 'alternative-service' XML element as
252 described in Section 4.2; and
254 o 3gpp-service-info: the body (part) contains 3GPP IM CN subsystem
255 XML with the 'service-info' XML element as described in Section
256 4.3.
258 7. Acknowledgements
260 The author would like to thank Andrew Allen, Dean Willis, Cullen
261 Jennings, Victor Pascual Avila, Christopher Wong, Gonzalo Camarillo
262 and Paul Kyzivat for their guidance and comments that contributed to
263 the progression of this work.
265 8. References
267 8.1. Normative References
269 [1] Troost, R., Dorner, S., and K. Moore, "Communicating
270 Presentation Information in Internet Messages: The Content-
271 Disposition Header Field", RFC 2183, August 1997.
273 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
274 Levels", BCP 14, RFC 2119, March 1997.
276 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
277 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
278 Session Initiation Protocol", RFC 3261, June 2002.
280 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
281 Protocol Version 1.1", RFC 4346, April 2006.
283 8.2. Informative References
285 [5] 3GPP, "IP Multimedia Call Control Protocol based on Session
286 Initiation Protocol (SIP) and Session Description Protocol
287 (SDP); Stage 3 (Release 8)", 3GPP TS 24.229 V8.8.0, June 2009.
289 Appendix A. Revision Information
291 A.1. version 00
292 1. 2008-02-12, Initial version
294 A.2. version 01
295 1. 2008-07-02, Updated reference and further aligned 3GPP TS 24.229
296 and this document
298 A.3. version 02
299 1. 2009-03-01, Corrected "header" into "header field"
301 A.4. version 03
302 1. 2010-02-23, no changes
303 2. 2011-02-09, no changes
305 A.5. version 04
306 1. 2010-09-28, Introduces the case of addressing the MIME body's use
307 for indicating the need to re-register with the IMS
308 2. 2010-09-28, Updates the reference to 3GPP TS 24.229
309 3. 2010-09-28, Introduces a reference to
310 draft-patel-ecrit-sos-parameter-10
312 A.6. version 05
313 1. 2011-02-09, Editorially correct "registeration context" into
314 "registration context"
315 2. 2011-02-09, Removed the reference to
316 draft-patel-ecrit-sos-parameter-10
318 A.7. version 06
319 1. 2011-02-21, corrected, and changed, XML element name from "3gpp-
320 ims" to "ims-3gpp"
321 2. 2011-02-21, Updated address information of author
323 A.8. version 07
324 1. 2011-12-02, Updated address information of author
326 A.9. version 08
327 1. 2012-27-03, Added a new background section 2.1 and renumbered
328 existing sections
329 2. 2012-27-03, Improved body handling text to not preclude multipart
330 bodies
331 3. 2012-27-03, Editorials
333 Author's Address
335 John-Luc Bakker (editor)
336 Research In Motion (RIM)
337 5000 Riverside Drive, building 6, suite 100
338 Irving, Texas 75039
339 USA
341 Phone: unlisted
342 Fax: unlisted
343 Email: jbakker@rim.com