idnits 2.17.1 draft-montemurro-gsma-imei-urn-16.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2013) is 3942 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 565, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3406 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2141 (ref. '7') (Obsoleted by RFC 8141) == Outdated reference: A later version (-13) exists of draft-allen-dispatch-imei-urn-as-instanceid-10 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: Informational Blackberry 5 Expires: January 12, 2014 D. McDonald 6 Eircom 7 P. Gosden 8 GSM Association 9 July 11, 2013 11 A Uniform Resource Name Namespace for the GSM Association (GSMA) and the 12 International Mobile station Equipment Identity (IMEI) 13 draft-montemurro-gsma-imei-urn-16 15 Abstract 17 This specification defines a Uniform Resource Name namespace for the 18 GSMA (GSM Association)and a sub-namespace for the IMEI (International 19 Mobile station Equipment Identity), and an associated parameter for 20 the IMEISV (International Mobile station Equipment Identity and 21 Software Version number). The IMEI is 15 decimal digits long and the 22 IMEISV is 16 decimal digits long and both are encoded using Binary 23 Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part 24 of the specification for Global System for Mobile communications(GSM) 25 and are also now incorporated by the 3rd Generation Partnership 26 Project (3GPP) as part of the 3GPP specification for GSM, the 27 Universal Mobile Telecommunications System (UMTS) and 3GPP LTE (Long 28 Term Evolution). The IMEI and IMEISV are used to uniquely identify 29 Mobile Equipment within these systems and are managed by the GSMA. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 12, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Namespace Registration Template . . . . . . . . . . . . . . . 5 81 3.1. GSMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.1. IMEI Format . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.1.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 9 86 4.1.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 10 87 4.1.3. Spare . . . . . . . . . . . . . . . . . . . . . . . . 10 88 4.1.4. Binary Encoding . . . . . . . . . . . . . . . . . . . 10 89 4.2. IMEISV Format . . . . . . . . . . . . . . . . . . . . . . 11 90 4.2.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 11 91 4.2.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 11 92 4.2.3. Software Version Number (SVN) . . . . . . . . . . . . 11 93 4.2.4. Binary Encoding . . . . . . . . . . . . . . . . . . . 11 95 5. Community considerations . . . . . . . . . . . . . . . . . . . 11 97 6. Namespace considerations . . . . . . . . . . . . . . . . . . . 12 99 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 101 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 106 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 107 10.2. Informative references . . . . . . . . . . . . . . . . . . 14 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 111 1. Introduction 113 This specification defines a Uniform Resource Name namespace for the 114 GSMA (GSM Association) and a sub-namespace for the IMEI 115 (International Mobile station Equipment Identity), and associated 116 parameter for the Software Version number from the IMEISV 117 (International Mobile station Equipment Identity and Software Version 118 number) as per the namespace registration requirement found in [1]. 119 The namespace gsma is a namespace for identities used in GSM, UMTS 120 and LTE networks. The IMEI and the IMEISV are managed by the GSMA, 121 so this namespace would be managed by the GSMA. Whilst this 122 specification currently specifies only the IMEI sub-namespace under 123 the GSMA URN namespace additional sub-namespaces under the GSMA 124 namespace may be specified in the future by the GSMA through the 125 publication of future Informational RFCs. 127 The IMEI is 15 decimal digits long and includes a Type Allocation 128 Code (TAC) of 8 decimal digits and a Serial Number (SNR) of 6 decimal 129 digits plus a Spare decimal digit. The TAC identifies the type of 130 the Mobile Equipment and is chosen from a range of values allocated 131 to the Mobile Equipment manufacturer in order to uniquely identify 132 the model of the Mobile Equipment. The SNR is an individual serial 133 number that uniquely identifies each Mobile Equipment within the TAC. 134 The Spare digit is used as a check digit to validate the IMEI and is 135 always set to the value 0 when transmitted by the Mobile Equipment. 137 The IMEISV is 16 decimal digits long and includes the TAC and SNR 138 same as for the IMEI but also a 2 decimal digit Software Version 139 Number (SVN) which is allocated by the Mobile Equipment manufacturer 140 to identify the software version of the Mobile Equipment. 142 The information here is meant to be a concise guide for those wishing 143 to use the IMEI and IMEISV as URNs. Nothing in this document should 144 be construed to override 3GPP TS 23.003 [2] that defines the IMEI and 145 IMEISV. 147 The GSM Association (GSMA) is a global trade association representing 148 nearly 800 mobile phone operators across 220 territories and 149 countries of the world. The primary goals of the GSMA are to ensure 150 mobile phones and wireless services work globally and are easily 151 accessible. Further details about the GSMA role in allocating the 152 IMEI and the IMEISV and the IMEI and IMEISV allocation guidelines can 153 be found in GSMA PRD TS.06 [3]. 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [4]. 161 3. Namespace Registration Template 163 3.1. GSMA 165 Namespace ID: "gsma" requested 167 Registration Information: 169 Registration version number: 1 171 Registration date: 2013-07-02 173 Declared registrant of the namespace: 174 Registering organization: 175 Name: GSM Association 176 Address: 1st Floor, Mid City Place, 177 71 High Holborn, London, England 179 Designated contact person: 180 Name: Paul Gosden 181 Coordinates: pgosden@gsma.com 183 Declaration of syntactic structure: 184 The identifier is expressed in ASCII characters and has a 185 hierarchical structure expressed using the augmented Backus-Naur 186 Form (ABNF) defined in [8] as follows: 188 gsma-urn = "urn:gsma:" gsma-specifier 189 *(":" gsma-specifier-defined-substring) 190 *(";" gsma-specifier-param) 192 gsma-specifier = "imei" / gsma-specifier-defined-string 193 gsma-specifier-defined-string = gsma-approved-nonempty-string 194 gsma-specifier-defined-substring = imeival / 195 gsma-approved-nonempty-string 196 gsma-specifier-defined-param-name = 197 gsma-approved-nonempty-string 198 gsma-specifier-defined-param-val = gsma-approved-nonempty-string 199 gsma-specifier-param = 200 "svn=" software-version-string / 201 "vers=" gsma-format-version-string / 202 gsma-specifier-defined-param-name 203 ["=" gsma-specifier-defined-param-val] 204 software-version-string = 2DIGIT 205 gsma-format-version-string = DIGIT 206 gsma-approved-nonempty-string = 1*unreserved 207 unreserved = ALPHA / DIGIT / "-" / "." / "_" 209 A sub-namespace for the IMEI is defined under the GSMA namespace. 210 Other sub-namespaces may be defined in the future to include other 211 identifiers in the GSM, UMTS or LTE networks or future networks 212 deployed by members of the GSMA. 214 An IMEI is an identifier under the GSMA namespace that uniquely 215 identifies the mobile devices used in the GSM, UMTS and LTE 216 networks. 218 The representation of the IMEI is defined in 3GPP TS 23.003 [2]. 219 To accurately represent an IMEI received in a cellular signaling 220 message (see 3GPP TS 24.008 [5]) as a URN, it is necessary to 221 convert the received binary (Binary Coded Decimal (BCD)encoded) 222 bit sequence to a decimal digit string representation. Each field 223 has its value printed as a decimal digit string with the most 224 significant digit first. 226 The following augmented Backus-Naur Form (ABNF) includes the set 227 of core rules in RFC 5234 [8], and are not repeated here. 229 A URN with the "imei" gsma-specifier contains exactly one gsma- 230 specifier-defined-substring, and its formal definition is provided 231 by the following ABNF [8]: 233 imeival = tac "-" snr "-" spare 234 tac = 8DIGIT 235 snr = 6DIGIT 236 spare = DIGIT 237 For example: 238 urn:gsma:imei:90420156-025763-0;vers=0 240 The optional "vers" parameter is included for extensibility of the 241 namespace, for example if the IMEI format is extended in the 242 future (such as with additional digits or using hex digits). A 243 value of "vers" equal to 0 or the absence of the "vers" parameter 244 means the URN format is compliant with the format specified here. 245 Any change to the format specified here requires the publication 246 of a future Informational RFC. 247 draft-allen-dispatch-imei-urn-as-instanceid-10 [9] defines how the 248 GSMA IMEI URN can be used as an instance ID as specified in RFC 249 5626 [10]. Any future value of the "vers" parameter other than 250 equal to 0 or the definition of additional parameters that are 251 intended to be used as part of an instance ID will require an 252 update to draft-allen-dispatch-imei-urn-as-instanceid-10 [9]. 254 The IMEISV is an identifier that uniquely identifies mobile 255 devices and their associated software versions used in the GSM, 256 UMTS and LTE networks. The representation of the IMEISV is 257 defined in 3GPP TS 23.003 [2]. 259 To represent the IMEISV the URN parameter "svn" is appended to the 260 GSMA IMEI URN and set equal to the decimal string representation 261 of the two software version number (svn) digits in the IMEISV and 262 the spare digit in the IMEI gsma-specifier-defined-substring is 263 set to zero. 264 For example: 265 urn:gsma:imei:90420156-025763-0;svn=42 267 The , , , 269 and can comprise any ASCII 270 characters compliant with the above ABNF. The exclusion of the 271 colon from the list of other characters means that the colon can 272 only occur as a delimiter between string values. The exclusion of 273 the semicolon from the list of other characters means that the 274 semicolon can only occur as a delimiter for parameter values. The 275 exclusion of the "=" character from the list of other characters 276 means that the "=" character can only occur as an operator for 277 parameter values. 279 The GSMA will take responsibility for the gsma-specifier "imei" 280 and manage the URNs in its sub-namespace. 282 Additional gsma-specifiers may be added in the future through 283 Informational RFCs. 285 Relevant ancillary documentation: 286 See IMEI Allocation and Approval Guidelines [3] and 3GPP TS 23.003 287 [2]. 289 Identifier uniqueness considerations: 290 Identifiers in the "gsma" namespace are defined and assigned in 291 the requested namespace by the GSMA after ensuring that the URNs 292 to be assigned are unique. Uniqueness is achieved by checking 293 against the registry of previously assigned names. 295 Procedures are in place to ensure that each IMEI is uniquely 296 assigned by the Mobile Equipment manufacturer so that it is 297 guaranteed to uniquely identify that particular Mobile Equipment. 298 Procedures are in place to ensure that each IMEISV is uniquely 299 assigned by the Mobile Equipment manufacturer so that it is 300 guaranteed to uniquely identify that particular Mobile Equipment 301 and the specific software version installed. 303 Identifier persistence considerations: 304 The GSMA is committed to maintaining uniqueness and persistence of 305 all resources identified by assigned URNs. 307 As the NID sought is "gsma" and GSMA is the long standing acronym 308 for the trade association that represents the mobile phone 309 operators the URN should also persist indefinitely (at least as 310 long as there is a need for its use). The assignment process 311 guarantees that names are not reassigned. The binding between the 312 name and its resource is permanent. 314 The TAC and SNR portions of IMEISVs are stored in the Mobile 315 Equipment so they remain persistent. The SVN may be modified by 316 software when new versions are installed but should be persistent 317 for the duration of the installation of that specific version of 318 software. 320 Process of identifier assignment: 322 GSMA will manage the (including "imei"), , , , and identifier resources to maintain 326 uniqueness. 328 The process for IMEI and IMEISV assignment is documented in GSMA 329 TS 06[3] 331 Process for identifier resolution: 332 Since the GSMA namespace is not currently globally resolvable, 333 this is not applicable. 335 Rules for Lexical Equivalence: 336 Two GSMA IMEI URNs are equivalent if they have the same "imeival" 337 value, and the same gsma-specifier-params values in the same 338 sequential order, with the exception that the gsma-specifier-param 339 "vers=0" is to be ignored for the purposes of comparison. All of 340 these comparisons are to be case-insensitive. 342 Any identifier in GSMA namespaces can be compared using the normal 343 mechanisms for percent-encoded UTF-8 strings. 345 Conformance with URN Syntax: 346 The string representation of the GSMA URN and of the IMEI sub- 347 namespace is fully compatible with the URN syntax. 349 Validation Mechanism: 350 The IMEI can be validated using the mechanism defined in Annex B 351 of 3GPP TS 23.003 [2]. There is no mechanism defined to validate 352 the SVN field of the IMEISV. 354 Scope: GSMA URN is global in scope. 356 4. Specification 358 4.1. IMEI Format 360 4.1.1. Type Allocation Code (TAC) 362 The TAC is an 8 decimal digit value. The TAC identifies the type of 363 the Mobile Equipment and is chosen from a range of values allocated 364 to the Mobile Equipment manufacturer in order to uniquely identify 365 the model of the Mobile Equipment. 367 4.1.2. Serial Number (SNR) 369 The SNR is a 6 decimal digit value. The SNR is an individual serial 370 number that uniquely identifies each Mobile Equipment within the TAC. 372 4.1.3. Spare 374 The Spare is a single decimal digit. When the IMEI is stored on the 375 Mobile Equipment and network equipment it contains a value that is 376 used as a Check Digit and is intended to avoid manual reporting 377 errors, (e.g. when customers register stolen mobiles at the 378 operator's customer care desk) and also to help guard against the 379 possibility of incorrect entries being provisioned in the network 380 equipment. The Spare is always set to zero when transmitted by the 381 Mobile Equipment, (including when in the IMEI URN format). Annex B 382 of 3GPP TS 23.003 [2] defines a mechanism for computing the actual 383 check digit in order to validate the TAC and SNR. 385 4.1.4. Binary Encoding 387 When included in a cellular signaling message the IMEI format is 15 388 decimal digits encoded in 8 octets using BCD as defined in 3GPP TS 389 24.008 [5]. Figure 1 is an abstract representation of a BCD encoded 390 IMEI stored in memory (the actual storage format in memory is 391 implementation specific). In Figire 1 the most significant digit of 392 the TAC is coded in the least significant bits of octet 1. The most 393 significant digit of the SNR is coded in the least significant bits 394 of octet 5. The Spare digit is coded in the least significant bits 395 of octet 8. When included in an identity element in a cellular 396 signaling message the most significant digit of the TAC is included 397 in digit 1 of the identity element in Figure 10.5.4 of 3GPP TS 24.008 398 [5]. 400 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 401 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 402 | | | S| 403 | T | S | p| 404 | A | N | a| 405 | C | R | r| 406 | | | e| 407 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 408 1 2 3 4 5 6 7 8 Octets 409 Figure 1. IMEI Format 411 4.2. IMEISV Format 413 4.2.1. Type Allocation Code (TAC) 415 The TAC is the same as the TAC in the IMEI in Section 4.1.1. 417 4.2.2. Serial Number (SNR) 419 The SNR is the same as the SNR in the IMEI in Section 4.1.2. 421 4.2.3. Software Version Number (SVN) 423 The Software Version Number is allocated by the mobile device 424 manufacturer to identify the software version of the mobile device. 426 4.2.4. Binary Encoding 428 When included in a cellular signaling message the IMEISV format is 16 429 decimal digits encoded in 8 octets using BCD as defined in 3GPP TS 430 24.008 [5]. Figure 2 is an abstract representation of a BCD encoded 431 IMEISV stored in memory (the actual storage format in memory is 432 implementation specific). In Figire 2 the most significant digit of 433 the TAC is coded in the most significant bits of octet 1. The most 434 significant digit of the SNR is coded in the most significant bits of 435 octet 5. The most significant digit of the SVN is coded in the most 436 significant bits of octet 8. When included in an identity element in 437 a cellular signaling message the most significant digit of the TAC is 438 included in digit 1 of the identity element in Figure 10.5.4 of 3GPP 439 TS 24.008 [5]. 441 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 442 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 443 | | | | 444 | T | S | S | 445 | A | N | V | 446 | C | R | N | 447 | | | | 448 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 449 1 2 3 4 5 6 7 8 Octets 450 Figure 2. IMEISV Format 452 5. Community considerations 454 GSM, UMTS and LTE mobile devices will be interoperating with Internet 455 devices for a variety of voice and data services. To do this, they 456 need to make use of Internet protocols that will operate end to end 457 between devices in GSM/UMTS/LTE networks and those in the general 458 internet. Some of these protocols require the use of URN's as 459 identifiers. Within the GSM/UMTS/LTE networks, mobile devices are 460 identified by their IMEI or IMEISV. Internet users will need to be 461 able to receive and include the GSMA URN in various Internet protocol 462 elements to facilitate communication between pure internet based 463 devices and GSM/UMTS/LTE mobile devices. Thus the existence and 464 syntax of these namespaces needs to be available to the general 465 internet community and the namespace needs to be reserved with IANA 466 in order to guarantee uniqueness and prevent potential namespace 467 conflicts both within the internet and within GSM/UMTS/LTE networks. 468 Conversely, Internet implementations will not generally possess IMEI 469 identifiers. The identifiers generated by such implementations will 470 typically be URNs within namespaces other than "gsma," and may, 471 depending on context, even be non-URN URIs. Implementations are 472 advised to be ready to process URIs other than "gsma"-namespaced 473 URNs, so as to aid in interoperability. 475 6. Namespace considerations 477 A URN was considered the most appropriate URI to represent the IMEI 478 and IMEISV as these identifiers may be used and transported similarly 479 to the Universally Unique Identifier (UUID)which is defined as a URN 480 in [11]. Since specifications for protocols that are used to 481 transport device identifiers often require the device identifier to 482 be globally unique and in the URN format it is necessary that the URN 483 formats are defined to represent the IMEI and IMEISV. 485 7. IANA considerations 487 In accordance with BCP 66 [1], IANA is asked to register the Formal 488 URN Namespace 'GSMA' in the Registry of URN Namespaces, using the 489 registration template presented in Section 3 of this document. 491 8. Security considerations 493 IMEIs (but with the Spare value set to the value of the Check Digit) 494 are displayable on most mobile devices and in many cases is printed 495 on the case within the battery compartment. Anyone with brief 496 physical access to the mobile device can therefore easily obtain the 497 IMEI. Therefore the IMEI MUST NOT be used as security capabilities 498 (identifiers whose mere possession grants access). Unfortuantely 499 there are currently examples of some applications which are using the 500 IMEI for authorisation. Also some service providers customer service 501 departments have been known to use knowledge of the IMEI as proof 502 that the caller is the legitimate owner of the mobile device. Both 503 of these are inappropriate uses of the IMEI. 505 Whilst the specific software version of the mobile device only 506 identifies the lower layer software that has undergone and passed 507 certification testing and not the operating system or application 508 software there is still a possibility that the software version could 509 identify software that is vulnerable to attacks or is known to 510 contain security holes. Therfore care SHOULD be taken regarding use 511 of the IMEISV as it could help a malicious device identify mobile 512 device running software that is known to be vulnerable to certain 513 attacks. This is a similar concern to the use of the User-Agent 514 header in SIP as specified in RFC 3261 [12]. Therefore the IMEISV 515 (that is, the IMEI URN with svn parameter) MUST NOT be delivered to 516 devices that are not trusted. Further, because IMEIs can be loosely 517 correlated to a user, they need to be treated as any other personally 518 identifiable information. In particular, the IMEI URN MUST NOT be 519 included in messages intended to convey any level of anonymity. 521 Additional security considerations are specified in 3GPP TS 22.016 522 [6]. Specifically the IMEI is to be incorporated in a module which 523 is contained within the terminal. The IMEI SHALL NOT be changed 524 after the terminal's production process. It SHALL resist tampering, 525 i.e. manipulation and change, by any means (e.g. physical, electrical 526 and software). 528 9. Acknowledgements 530 This document draws heavily on the 3GPP work on Numbering, Addressing 531 and Identification in 3GPP TS 23.003 [2] and also on the style and 532 structure used in RFC 4122 [11]. The authors would like to thank 533 Cullen Jennings, Lisa Dusseault, Dale Worley, Ivo Sedlacek, Atle 534 Monrad, James Yu and Mary Barnes for their help and comments. 536 10. References 538 10.1. Normative references 540 [1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 541 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 542 BCP 66, RFC 3406, October 2002. 544 [2] 3GPP, "TS 23.003: Numbering, addressing and identification 545 (Release 8)", 3GPP 23.003, December 2012, 546 . 548 [3] GSMA Association, "IMEI Allocation and Approval Guidelines", 549 PRD TS.06 (DG06) version 6.0, July 2011, . 553 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 554 Levels", BCP 14, RFC 2119, March 1997. 556 [5] 3GPP, "TS 24.008: Mobile radio interface Layer 3 specification; 557 Core network protocols; Stage 3 (Release 8)", 3GPP 24.008, 558 June 2013, 559 . 561 [6] 3GPP, "TS 22.016: International Mobile station Equipment 562 Identities (IMEI)(Release 8)", 3GPP 22.016, December 2009, 563 . 565 [7] Moats, R., "URN Syntax", RFC 2141, May 1997. 567 10.2. Informative references 569 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 570 Specifications: ABNF", STD 68, RFC 5234, January 2008. 572 [9] Allen, A., "Using the International Mobile station Equipment 573 Identity(IMEI)URN as an Instance ID, work in progress", 574 Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-10, 575 July 2013. 577 [10] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 578 Initiated Connections in the Session Initiation Protocol 579 (SIP)", RFC 5626, October 2009. 581 [11] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 582 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 584 [12] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 585 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 586 Session Initiation Protocol", RFC 3261, June 2002. 588 Authors' Addresses 590 Michael Montemurro (editor) 591 Blackberry 592 4701 Tahoe Dr 593 Mississauga, Ontario L4W 0B4 594 Canada 596 Phone: unlisted 597 Fax: unlisted 598 Email: mmontemurro@blackberry.com 600 Andrew Allen 601 Blackberry 602 1200 Sawgrass Corporate Parkway 603 Sunrise, Florida 33323 604 USA 606 Phone: unlisted 607 Fax: unlisted 608 Email: aallen@blackberry.com 610 David McDonald 611 Eircom 613 Phone: unlisted 614 Fax: unlisted 615 Email: David.McDonald@meteor.ie 617 Paul Gosden 618 GSM Association 619 1st Floor, Mid City Place, 71 High Holborn, 620 London 621 England 623 Phone: unlisted 624 Fax: unlisted 625 Email: pgosden@gsma.com