idnits 2.17.1 draft-montemurro-gsma-imei-urn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 13, 2006) is 6377 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Montemurro, Ed. 3 Internet-Draft A. Allen 4 Intended status: Experimental Research in Motion (RIM) 5 Expires: April 16, 2007 D. McDonald 6 GSM Association 7 October 13, 2006 9 A Uniform Resource Name Namespace For The GSM Association (GSMA) and the 10 International Mobile station Equipment Identity(IMEI) 11 draft-montemurro-gsma-imei-urn-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 16, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This specification defines a Uniform Resource Name namespace for the 45 GSMA and sub namespaces for the IMEI (International Mobile station 46 Equipment Identity), and for the IMEISV (International Mobile station 47 Equipment Identity and Software Version number). The IMEI is 15 48 decimal digits long and the IMEISV is 16 decimal digits long and are 49 both encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV 50 were introduced as part of the specification for Global System for 51 Mobile (GSM) and are also now incorporated by the 3rd Generation 52 Partnership Project (3GPP) as part of the 3GPP specification for GSM, 53 and the Universal Mobile Telecommunications System (UMTS). The IMEI 54 and IMEISV are used to uniquely identify Mobile Equipment within 55 these systems and are managed by the GSMA (GSM Association). 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Namespace Registration Templates . . . . . . . . . . . . . . . 5 66 4.1. GSMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. IMEI . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3. IMEISV . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.1. IMEI Format . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.1.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 11 73 5.1.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 11 74 5.1.3. Spare . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.2. IMEISV Format . . . . . . . . . . . . . . . . . . . . . . 11 76 5.2.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 12 77 5.2.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 12 78 5.2.3. Software Version Number (SVN) . . . . . . . . . . . . 12 80 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 8.1. Normative references . . . . . . . . . . . . . . . . . . . 13 86 8.2. Informative references . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 Intellectual Property and Copyright Statements . . . . . . . . . . 15 91 1. Introduction 93 This specification defines a Uniform Resource Name namespace for the 94 IMEI (International Mobile station Equipment Identity), and for the 95 IMEISV (International Mobile station Equipment Identity and Software 96 Version number. The IMEI and the IMEISV are managed by the GSMA, so 97 the namespaces would be managed by the GSMA. Whilst this 98 specification currently specifies only the IMEI and IMEISV sub 99 namespaces under the GSMA URN namespace additional sub namespaces 100 under the GSMA namespace may be specified in the future by the GSMA. 102 The IMEI is 15 decimal digits long and includes a Type Allocation 103 Code (TAC) of 8 decimal digits and the Serial Number (SNR) of 6 104 decimal digits plus a Spare decimal digit. The TAC identifies the 105 type of the Mobile Equipment and is chosen from a range of values 106 allocated to the Mobile Equipment manufacturer in order to uniquely 107 identify the model of the Mobile Equipment. The SNR is an individual 108 serial number that uniquely identifies each Mobile Equipment within 109 the TAC. The Spare digit is used as a security check to combat 110 potential spoofing and is always set to the value 0 when transmitted 111 by the Mobile Equipment. 113 The IMEISV is 16 decimal digits long and includes the TAC and SNR 114 same as for the IMEI but also a 2 decimal digit Software Version 115 Number (SVN) which is allocated by the Mobile Equipment manufacturer 116 to identify the software version of the Mobile Equipment. 118 The IMEI is specified to be stored in a tamper proof fashion so that 119 it cannot be overwritten or otherwise reprogrammed by software. 121 The information here is meant to be a concise guide for those wishing 122 to use the IMEI and IMEISV as URNs. Nothing in this document should 123 be construed to override 3GPP TS 23.003 [1] that defines the IMEI and 124 IMEISV. 126 The GSM Association (GSMA) is a global trade association representing 127 more than 690 GSM mobile phone operators across 214 territories and 128 countries of the world. The primary goals of the GSMA are to ensure 129 mobile phones and wireless services work globally and are easily 130 accessible. Further details about the GSMA role in allocating the 131 IMEI and the IMEISV and the IMEI and IMEISV allocation guidelines can 132 be found in GSMA PRD TW.06 [2] 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [3]. 140 3. Motivation 142 One of the main reasons for the IMEI is to be able to take measures 143 against the use of stolen equipment or against equipment that is 144 malfunctioning and causing operational problems for the network. 146 The theft of mobile phones has become a significant problem in many 147 countries and often involves the use of violence and intimidation 148 which is frequently perpetrated against children. The ability of the 149 network to identify that a stolen mobile is being used and identify 150 the subscription that is using it or to prevent its use should help 151 to reduce these problems. 153 The potential for damage by malfunctioning mobiles is also of 154 increasing concern. In earlier times when there was a limited well 155 specified set of features and services that were defined for Mobile 156 Equipment it was possible to define and conduct rigorous conformance 157 testing of the Mobile Equipment to ensure its appropriateness for use 158 on the Cellular network. Now however as the networks and services 159 are becoming much more complex, varied and feature rich with the 160 associated drive for rapid deployment of new services leveraging the 161 great flexibility provided by Internet Protocols this kind of 162 rigourous conformance testing of every service, application and 163 capability is becoming no longer viable. As a result it is more 164 likely that Mobile Equipment commercially deployed in the networks in 165 future will not always exhibit the correct behaviors under all 166 circumstances. Sometimes this may result in more than just 167 dissatisfaction for a particular mobile user but could potentially 168 result in an unintended Denial of Service (DoS) attack on the network 169 that could potentially impact thousands of other users. The use of 170 the IMEISV is additionally helpful in this respect as it allows 171 specific problematic software versions of Mobile Equipment to be 172 identified so that appropriate defensive or corrective action can be 173 taken. 175 There is also increasing concern that the increasingly disturbing 176 phenomenon of malware such as viruses and other trojans will rapidly 177 spread to Mobile Equipment. This equipment has become more computer 178 like through the increasing use of smartphones and PDAs with 179 standardized Operating Systems. Such devices support for 180 downloadable installable applications and the communication potential 181 through peer to peer IP to deliver these programs from one Mobile 182 Phone to another. There is a real concern that once the appearance 183 of malware viruses on Mobile Equipment becomes common that 184 coordinated DoS attacks could be conducted against Mobile Networks by 185 possibly millions of mobile phones. Since the bandwidth capabilities 186 of Cellular Networks are an order of magnitude lower than those of 187 broadband access networks it is potentially much easier to congest a 188 cellular network through a coordinated attack than the fixed network. 189 These networks are also already relied upon for Emergency Services so 190 the consequences of widespread network failure through coordinated 191 Mobile Phone virus DoS attack are potentially much more severe. The 192 IMEI can play a significant role in identifying Mobile Equipment that 193 is known to be infected with viruses and to prevent its use and limit 194 potential damage to the operation of the network and the Mobile 195 Equipment of other users. Likewise the IMEISV can help identify 196 Mobile Equipment running software versions vulnerable to attack by 197 such malware. 199 Currently GSM and UMTS network lower layers provide the ability to 200 transport the IMEI and IMEISV between the Mobile Equipment and the 201 network. However these networks are now transitioning to IP Core 202 Networks such as the 3GPP IP Multimedia Subssytem (IMS) where the 203 cellular access network signaling is becoming decoupled from the IP 204 based network and applications such that it is becoming more 205 difficult for the session and application layers to obtain the IMEI 206 and IMEISV of the Mobile Equipment involved in the session or 207 accessing the application or server. Also access for Mobile 208 Equipment to these networks is now being extended via non cellular 209 access technologies such as WLAN and Bluetooth and various broadband 210 technologies that do not provide any transport layer support for the 211 IMEI or IMEISV. It is therefore necessary that support for transport 212 of these identifiers by IP protocols be provided by defining URNs for 213 them. 215 4. Namespace Registration Templates 217 4.1. GSMA 219 Namespace ID: "urn:gsma" requested 221 Registration Information: 223 Registration date: 2006-10-11 225 Declared registrant of the namespace: GSMA. 227 Declaration of syntactic structure: 229 GSMA is an identifier for a namespace for identifiers used by Mobile 230 Equipment used in GSM and UMTS networks. 232 The identifier has a hierarchical structure as follows: 233 urn:gsma:imei/imeisv/ [: ]+ 235 + denotes one or more occurrences of gsma-specifier defined 236 strings all delimited by a colon." 238 The GSMA namespace includes two predefined namespaces IMEI and IMEISV 239 and may be in the future extended to include other identifiers used 240 by Mobile Equipment used in GSM and UMTS networks or future networks 241 deployed by members of the GSMA. 243 For example: 244 urn:gsma:imei:90420156-025763-0 245 urn:gsma:imeisv:90420156-025763-42 247 The and defined string can comprise 248 any UTF-8 characters compliant with URI syntax and must not contain 249 the ":" character (see STD 66, RFC 3986 [xref target="RFC3986"]). 250 The exclusion of the colon from the list of other characters means 251 that the colon can only occur as a delimiter between string values. 253 The GSMA will take responsibility for the gsma-specifier "imei" and 254 "imeisv". 256 The GSMA will take responsibility to assign other gsma-specifiers and 257 manage the sub level and its applicable gsma-specifier defined 258 string(s). 260 Relevant ancillary documentation: None. 262 Identifier uniqueness considerations: Identifiers in the "gsma" 263 namespace are defined and assigned in the requested namespace by 264 the GSMA after ensuring that the URNs to be assigned are unique. 265 Uniqueness is achieved by checking against the registry of 266 previously assigned names. 268 Identifier persistence considerations: 270 The GSMA is committed to maintaining uniqueness and persistence of 271 all resources identified by assigned URNs. 273 As the URN sought is "gsma" and GSMA is the long standing acronym for 274 the trade association that represents the mobile phone operators the 275 URN should also persist indefinitely, (at least as long as there is a 276 need for its use).The assignment process guarantees that names are 277 not reassigned. The binding between the name and its resource is 278 permanent. 280 Process of identifier assignment: 282 GSMA will manage the and 283 including "imei" and "imeisv" identifier resources to maintain 284 uniqueness. 286 The process of assigning additional URNs at the sub- 287 level will be managed by the GSMA. 289 Process for identifier resolution: Since the GSMA namespace is not 290 globally resolvable, this is not applicable. 292 Rules for Lexical Equivalence: 294 The lexical equivalence of the GSMA namespace-specific strings (NSSs) 295 is defined as an exact, but not case-sensitive, string match. 297 Any identifier in GSMA namespaces can be compared using the normal 298 mechanisms for percent-encoded UTF-8 strings. 300 Conformance with URN Syntax: The string representation of a IMEI is 301 fully compatible with the URN syntax. 303 Validation Mechanism: None 305 Scope: GSMA URN is global in scope. 307 4.2. IMEI 309 Namespace ID: "urn:gsma:imei" requested. 311 Registration Information: 313 Registration date: 2006-10-11 315 Declared registrant of the namespace: GSMA. 317 Declaration of syntactic structure: . 319 A IMEI is an identifier under the GSMA namespace that uniquely 320 identifies Mobile Equipment used in GSM and UMTS networks. 322 The internal representation of a IMEI is a specific sequence of bits 323 in memory, as described in 3GPP TS 23.003 [1]. To accurately 324 represent a IMEI as a URN, it is necessary to convert the BCD bit 325 sequence to a string representation. 327 Each field BCD bit sequence has its value printed as a decimal digit 328 string with the most significant digit first. 330 The formal definition of the IMEISV string representation is provided 331 by the following ABNF [4] 333 IMEI = tac "-" snr "-" svn 334 tac = 8decDigit 335 snr = 6decDigit 336 spare = 1decDigit 337 decDigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 339 The following is an example of the string representation of a IMEI as 340 a URN: 342 urn:gsma:imei:90420156-025763-0 344 Relevant ancillary documentation: 3GPP TS 23.003 [1] and GSMA PRD 345 TW.06 [2] 347 Identifier uniqueness considerations: Procedures are in place to 348 ensure that each IMEI is uniquely assigned by the Mobile Equipment 349 manufacturer so that it is guaranteed to uniquely identify that 350 particular Mobile Equipment. 352 Identifier persistence considerations: IMEIs are stored in the 353 Mobile Equipment in a tamper proof non modifiable fashion so they 354 remain persistent 356 Process of identifier assignment: The process for IMEI assignment is 357 documented in GSMA PRD TW.06 [2]. 359 Process for identifier resolution: Since IMEIs are not globally 360 resolvable, this is not applicable. 362 Rules for Lexical Equivalence: Consider each field of the IMEISV to 363 be a sequence of decimal digits. Then, to compare a pair of 364 IMEIs, arithmetically compare the corresponding fields from each 365 IMEI in order of significance and according to their data type. 366 Two IMEIs are equal if and only if all the corresponding fields 367 are equal 369 Conformance with URN Syntax: The string representation of a IMEI is 370 fully compatible with the URN syntax. 372 Validation mechanism: The IMEI can be validated using the mechanism 373 defined in Annex B of 3GPP TS 23.003 [1] 375 Scope: IMEIs are global in scope. 377 4.3. IMEISV 379 Namespace ID: "urn:gsma:imeisv" requested 381 Registration Information: 383 Registration date: 2006-10-11 385 Declared registrant of the namespace: GSMA. 387 Declaration of syntactic structure: 389 A IMEISV is an identifier under the GSMA namespace that uniquely 390 identifies Mobile Equipment and associated software versions used in 391 GSM and UMTS networks. 393 The internal representation of a IMEISV is a specific sequence of 394 bits in memory, as described in 3GPP TS 23.003 [1]. To accurately 395 represent a IMEISV as a URN, it is necessary to convert the BCD bit 396 sequence to a string representation. 398 Each field BCD bit sequence has its value printed as a decimal digit 399 string with the most significant digit first. 401 The formal definition of the IMEISV string representation is provided 402 by the following ABNF [4] 404 IMEISV = tac "-" snr "-" svn 405 tac = 8decDigit 406 snr = 6decDigit 407 svn = 2decDigit 408 decDigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 410 The following is an example of the string representation of a IMEISV 411 as a URN: 413 urn:gsma:imeisv:90420156-025763-42 415 Relevant ancillary documentation: 3GPP TS 23.003 [1] and GSMA PRD 416 TW.06 [2] 418 Identifier uniqueness considerations: Procedures are in place to 419 ensure that each IMEISV is uniquely assigned by the Mobile 420 Equipment manufacturer so that it is guaranteed to uniquely 421 identify that particular Mobile Equipment and the specific 422 software version installed. 424 Identifier persistence considerations: The TAC and SNR portions of 425 IMEISVs are stored in the Mobile Equipment in a tamper proof non 426 modifiable fashion so they remain persistent. The SVN may be 427 modified by software when new versions are installed but should be 428 persistent for the duration of the installation of that specific 429 version of software. 431 Process of identifier assignment: The process for IMEISV assignment 432 is documented in GSMA PRD TW.06 [2]. 434 Process for identifier resolution: Since IMEISVs are not globally 435 resolvable, this is not applicable. 437 Rules for Lexical Equivalence: Consider each field of the IMEISV to 438 be a sequence of decimal digits. Then, to compare a pair of 439 IMEISVs, arithmetically compare the corresponding fields from each 440 IMEISV in order of significance and according to their data type. 441 Two IMEISVs are equal if and only if all the corresponding fields 442 are equal 444 Conformance with URN Syntax: The string representation of a IMEISV 445 is fully compatible with the URN syntax. 447 Validation mechanism: The TAC and SNR fields of the IMEISV can be 448 validated using the mechanism defined in Annex B of 3GPP TS 23.003 449 [1]. There is no mechanism defined to validate the SVN field of 450 the IMEISV. 452 Scope: IMEISVs are global in scope. 454 5. Specification 455 5.1. IMEI Format 457 The IMEI format is 15 decimal digits encoded in 8 octets using BCD as 458 defined in 3GPP TS 24.008 [5]. The least significant digit is coded 459 in the 1st 3 bits of octet 1. The most significant digit is coded in 460 the least significant bits of octet 8. Last 4 digits of octet 8 are 461 all 1's. 463 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Decimal Digits 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | |S| 466 | T | S |p| 467 | A | N |a| 468 | C | R |r| 469 | | |e| 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 1 2 3 4 5 6 7 8 Octets 473 5.1.1. Type Allocation Code (TAC) 475 The TAC is a 8 decimal digit value. The TAC identifies the type of 476 the Mobile Equipment and is chosen from a range of values allocated 477 to the Mobile Equipment manufacturer in order to uniquely identify 478 the model of the Mobile Equipment. 480 5.1.2. Serial Number (SNR) 482 The SNR is a 6 decimal digit value. The SNR is an individual serial 483 number that uniquely identifies each Mobile Equipment within the TAC 485 5.1.3. Spare 487 The Spare is a single decimal digit that is used as a security check 488 digit to combat potential spoofing. The Spare is always set to zero 489 when transmitted by the Mobile Equipment. Annex B of 3GPP TS 23.003 490 [1] defines a mechanism for computing the actual check digit in order 491 to validate the TAC and SNR. 493 5.2. IMEISV Format 495 The IMEISV format is 16 decimal digits encoded in 8 octets using BCD 496 as defined in 3GPP TS 24.008 [5]. The least significant digit is 497 coded in the 1st 3 bits of octet 1. The most significant digit is 498 coded in the least significant bits of octet 8. 500 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 Decimal Digits 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | | | | 503 | T | S | S | 504 | A | N | V | 505 | C | R | N | 506 | | | | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 1 2 3 4 5 6 7 8 Octets 510 5.2.1. Type Allocation Code (TAC) 512 The TAC is the same as for the IMEI in Section 5.1.1. 514 5.2.2. Serial Number (SNR) 516 The SNR is the same as for the IMEI in Section 5.1.2. 518 5.2.3. Software Version Number (SVN) 520 The Software Version Number is allocated by the Mobile Equipment 521 manufacturer to identify the software version of the Mobile 522 Equipment. 524 6. Security considerations 526 IMEIs (with the Spare value set to zero) are displayable on most 527 Mobile Equipment therefore they must not be used as security 528 capabilities (identifiers whose mere possession grants access), for 529 example. 531 Care should be taken regarding use of the IMEISV as it could help a 532 malicious device identify Mobile Equipment running software that is 533 known to be vulnerable to certain attacks. This is a similar concern 534 to the use of the User-Agent header in SIP as specified in RFC 3261 535 [6]. 537 Additional security considerations are specified in 3GPP TS 22.016 538 [7]. 540 7. Acknowledgements 542 This document draws heavily on the 3GPP work on Numbering, Addressing 543 and Identification in 3GPP TS 23.003 [1] and also on the style and 544 structure used in RFC 4122 [8]. 546 8. References 548 8.1. Normative references 550 [1] 3GPP, "TS 23.003: Numbering, addressing and identification 551 (Release 7)", 3GPP 23.003, June 2006, 552 . 554 [2] GSMA Assocaition, "IMEI Allocation and Approval Guidelines", 555 PRD TW.06 version 3.3.0, December 2004, 556 . 558 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 559 Levels", BCP 14, RFC 2119, March 1997. 561 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 562 Specifications: ABNF", RFC 4234, October 2005. 564 [5] 3GPP, "TS 24.008: Mobile radio interface Layer 3 specification; 565 Core network protocols; Stage 3 (Release 7)", 3GPP 24.008, 566 June 2006, . 568 8.2. Informative references 570 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 571 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 572 Session Initiation Protocol", RFC 3261, June 2002. 574 [7] 3GPP, "TS 22.016: International Mobile station Equipment 575 Identities (IMEI)(Release 6)", 3GPP 22.016, January 2005, 576 . 578 [8] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 579 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 581 Authors' Addresses 583 Michael Montemurro (editor) 584 Research in Motion (RIM) 585 5090 Commerce Blvd 586 Mississauga, Ontario L4W 5W4 587 Canada 589 Phone: unlisted 590 Fax: unlisted 591 Email: mmontemurro@rim.com 592 Andrew Allen 593 Research in Motion (RIM) 594 102 Decker Court, Suite 100 595 Irving, Texas 75062 596 USA 598 Phone: unlisted 599 Fax: unlisted 600 Email: aallen@rim.com 602 David McDonald 603 GSM Association 604 Block 2, Deansgrange Business Park 605 Deansgrange, Co. Dublin 606 Ireland 608 Phone: unlisted 609 Fax: unlisted 610 Email: DMcDonald@gsm.org 612 Full Copyright Statement 614 Copyright (C) The Internet Society (2006). 616 This document is subject to the rights, licenses and restrictions 617 contained in BCP 78, and except as set forth therein, the authors 618 retain all their rights. 620 This document and the information contained herein are provided on an 621 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 622 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 623 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 624 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 625 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 628 Intellectual Property 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org. 652 Acknowledgment 654 Funding for the RFC Editor function is provided by the IETF 655 Administrative Support Activity (IASA).