idnits 2.17.1
draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.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 :
----------------------------------------------------------------------------
** The abstract seems to contain references ([5]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 4, 2012) is 4214 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 4346 (ref. '4') (Obsoleted by RFC 5246)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 DISPATCH Working Group J. Bakker, Ed.
3 Internet-Draft Research In Motion (RIM)
4 Intended status: Standards Track September 4, 2012
5 Expires: March 8, 2013
7 Specification of 3GPP IM CN Subsystem XML body handling
8 draft-bakker-dispatch-3gpp-ims-xml-body-handling-00
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 [5]. The applicability of these content-
15 disposition values are limited to 3GPP IMS [5]. 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 March 8, 2013.
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. General . . . . . . . . . . . . . . . . . . . . . . . . 4
68 4.2.2. Example application/3gpp-ims+xml MIME body (part)
69 with type XML element set to emergency . . . . . . . . 5
70 4.3. The application/3gpp-ims+xml MIME type with content
71 disposition 3gpp-service-info . . . . . . . . . . . . . . . 5
72 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . . 5
73 4.3.2. Example application/3gpp-ims+xml body (part) . . . . . 6
75 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
83 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
85 Appendix A. Revision Information . . . . . . . . . . . . . . . . . 7
86 A.1. version 00 . . . . . . . . . . . . . . . . . . . . . . . . 7
88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
90 1. Overall Applicability
92 This document makes certain assumptions regarding network topology
93 and the existence of transitive trust. These assumptions are
94 generally NOT APPLICABLE in the Internet as a whole. The mechanism
95 specified here was designed to satisfy the requirements specified by
96 the 3rd Generation Partnership Project (3GPP) for IP multimedia
97 subsystem (IMS) for which either no general-purpose solution was
98 found, where insufficient operational experience was available to
99 understand if a general solution is needed, or where a more general
100 solution is not yet mature.
102 2. Introduction
104 New disposition-types for the Content-Disposition header field can
105 only be registered with IANA according to procedures defined in
106 Section 9 of [1].
108 The 3rd Generation Partnership Project (3GPP) (http://www.3gpp.org)
109 is specifying the IP multimedia subsystem (IMS) [6] where SIP is the
110 protocol used to establish media sessions across different
111 participants.
113 This document registers new disposition-types for the Content-
114 Disposition header field: 3gpp-alternative-service and 3gpp-service-
115 info, to address specific requirements of the IMS. The new
116 disposition-types may not be applicable to the general Internet. The
117 new disposition types are applicable to the "application/
118 3gpp-ims+xml" MIME type [5].
120 3. Terminology
122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
124 document are to be interpreted as described in [2].
126 The term "Application Server" (AS) is introduced in this document.
128 An "Application Server" as referred to here is a SIP network server
129 that performs network based functions. The AS can act as a SIP Proxy
130 as defined in [3] or a back-to-back UA (B2BUA) as defined in [3]
131 based on the functions it needs to perform. There can be one or more
132 ASes involved in a SIP session.
134 4. Background for the new disposition-types for the Content-Disposition
135 header field
137 4.1. Introduction
139 Section 20.11 of [3] specifies that the Content-Disposition header
140 field describes how the message body or, for multipart messages, a
141 message body part is interpreted by the UAC or UAS. In addition, [3]
142 specifies that if this header field is missing, the MIME type
143 determines the default content disposition. If there is none,
144 "render" is assumed.
146 No default content disposition has been defined for MIME type
147 "application/3gpp-ims+xml" MIME type [5]. Sections 4.2 and 4.3 below
148 show how a body (part) according to the MIME type is interpreted by
149 different entities (UE and AS) in 3GPP IMS (each entity having a
150 different content handler for the same MIME media type tag). The
151 difference in requirements for UE and AS, coupled with the fact that
152 the Content-Disposition header field describes how the message body
153 (part) is interpreted, implies that a single default content
154 disposition value does not cover both cases.
156 NOTE: An alternative with a more general applicable approach could
157 e.g. be unique MIME media type tags, each associated with a
158 content handler. However, having unique MIME media type tags
159 at this stage raises backwards compatibility concerns for the
160 IP multimedia subsystem (IMS) [6].
162 4.2. The application/3gpp-ims+xml MIME type with content disposition
163 3gpp-alternative-service
165 4.2.1. General
167 In the IMS it is possible that a UA attempts to place an emergency
168 call when the IMS network does not support emergency services. The
169 edge proxy can detect the emergency call and redirect the UE using a
170 SIP 380 (Alternative Service) to place the emergency call using
171 another domain (e.g. using a Circuit Switched network) or using
172 another registration context, if a type XML element in the MIME body
173 (part) is set to "emergency".
175 Section 21.3.5 of [3] specifies that, for the SIP 380 (Alternative
176 Service) response, alternative services are described in the message
177 body (part) of the response. In IMS, for the purpose of indicating
178 alternative domains, a SIP 380 (Alternative Service) response will
179 include a MIME body (part) and a Content-Type header field set to
180 "application/3gpp-ims+xml".
182 It is further possible that one or more UASes in the network
183 experience service interruptions, e.g. when forwarding a (non-
184 emergency) service request from a UAC. Examples of this are when
185 there is no response to the service request and its retransmissions,
186 a 3xx response or a 480 (Temporarily Unavailable) response is
187 received for the request, the UAS does not have a needed user profile
188 (e.g. due to restart of the UAS) and the attempt to retrieve the user
189 profile fails. In such situations the UAS responds with a 504
190 (Server Time-out), including a MIME body (part) and a Content-Type
191 header field set to "application/3gpp-ims+xml". Upon receiving this
192 response, the UAC can create another registration context in an
193 attempt to restore the services, if a type XML element in the MIME
194 body (part) is set to "restoration".
196 Such configurations are generally not applicable to the internet as a
197 whole where such trust relationships do not exist.
199 In addition, security issues have only been considered for networks
200 which are trusted and use hop by hop security mechanisms with
201 transitive trust. Security issues with usage of this mechanism in
202 the general internet have not been evaluated.
204 4.2.2. Example application/3gpp-ims+xml MIME body (part) with type XML
205 element set to emergency
207
208
209 emergency
210
211
212
214 4.3. The application/3gpp-ims+xml MIME type with content disposition
215 3gpp-service-info
217 4.3.1. General
219 In 3GPP IMS the SIP registrar (S-CSCF) can perform a third party
220 registration to an AS. The SIP registrar downloads User Profile
221 information and can transparently transfer User Profile specific
222 information to the AS using a body (part) of MIME type "application/
223 3gpp-ims+xml" in a SIP REGISTER request. In the example in Section
224 4.3.2, an International Mobile Subscriber Identity (IMSI) is
225 transferred.
227 4.3.2. Example application/3gpp-ims+xml body (part)
229
230
231 262013564857956
232
233
235 5. Security Considerations
237 It is necessary to protect the messages between proxies;
238 implementation SHOULD use a transport that provides integrity and
239 confidentially between the signaling hops. The Transport Layer
240 Security (TLS) [4] based signaling in SIP can be used to provide this
241 protection.
243 Security issues have only been considered for networks which are
244 trusted and use hop by hop security mechanisms with transitive trust
245 and security issues with usage of this mechanism in the general
246 internet have not been evaluated.
248 6. IANA Considerations
250 This document registers new disposition-types for the Content-
251 Disposition header field that apply to the "application/3gpp-ims+xml"
252 body (part) used by 3GPP and are to be registered in the IANA
253 registry for Mail Content Disposition Values and Parameters:
255 o 3gpp-alternative-service: the body (part) contains 3GPP IM CN
256 subsystem XML with the 'alternative-service' XML element as
257 described in Section 4.2; and
259 o 3gpp-service-info: the body (part) contains 3GPP IM CN subsystem
260 XML with the 'service-info' XML element as described in Section
261 4.3.
263 7. Acknowledgements
265 The author would like to thank Andrew Allen, Dean Willis, Cullen
266 Jennings, Victor Pascual Avila, Christopher Wong, Gonzalo Camarillo,
267 Paul Kyzivat, and Atle Monrad for their guidance and comments that
268 contributed to the progression of this work.
270 8. References
271 8.1. Normative References
273 [1] Troost, R., Dorner, S., and K. Moore, "Communicating
274 Presentation Information in Internet Messages: The Content-
275 Disposition Header Field", RFC 2183, August 1997.
277 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
278 Levels", BCP 14, RFC 2119, March 1997.
280 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
281 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
282 Session Initiation Protocol", RFC 3261, June 2002.
284 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
285 Protocol Version 1.1", RFC 4346, April 2006.
287 8.2. Informative References
289 [5] IANA, "Registry for Application Media Types".
291 [6] 3GPP, "IP Multimedia Call Control Protocol based on Session
292 Initiation Protocol (SIP) and Session Description Protocol
293 (SDP); Stage 3 (Release 8)", 3GPP TS 24.229 V8.20.0, June 2012.
295 Appendix A. Revision Information
297 A.1. version 00
298 1. Initial version for consideration by dispatch, based upon
299 draft-bakker-sipping-3gpp-ims-xml-body-handling-08
300 2. Changed references to section 2.2 and 2.3 into 4.2 and 4.3,
301 respectively.
302 3. Updated abstract and section 2 and section 4.1 to reflect
303 discussions on the list
304 4. Various editorial comments
306 Author's Address
308 John-Luc Bakker (editor)
309 Research In Motion (RIM)
310 5000 Riverside Drive, building 6, suite 100
311 Irving, Texas 75039
312 USA
314 Phone: unlisted
315 Fax: unlisted
316 Email: jbakker@rim.com