idnits 2.17.1 draft-montemurro-gsma-imei-urn-14.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (May 6, 2013) is 4002 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 530, 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-09 Summary: 3 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: November 7, 2013 D. McDonald 6 unaffiliated 7 P. Gosden 8 GSM Association 9 May 6, 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-14 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 associated parameter for the 20 IMEISV (International Mobile station Equipment Identity and Software 21 Version number). The IMEI is 15 decimal digits long and the IMEISV 22 is 16 decimal digits long and both are encoded using Binary Encoded 23 Decimal (BCD). The IMEI and IMEISV were introduced as part of the 24 specification for Global System for Mobile communications(GSM) and 25 are also now incorporated by the 3rd Generation Partnership Project 26 (3GPP) as part of the 3GPP specification for GSM, the Universal 27 Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term 28 Evolution). The IMEI and IMEISV are used to uniquely identify Mobile 29 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 November 7, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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) . . . . . . . . . . . . . . . . . 9 87 4.1.3. Spare . . . . . . . . . . . . . . . . . . . . . . . . 9 88 4.2. IMEISV Format . . . . . . . . . . . . . . . . . . . . . . 10 89 4.2.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 10 90 4.2.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 10 91 4.2.3. Software Version Number (SVN) . . . . . . . . . . . . 10 93 5. Community considerations . . . . . . . . . . . . . . . . . . . 10 95 6. Namespace considerations . . . . . . . . . . . . . . . . . . . 11 97 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 99 8. Security considerations . . . . . . . . . . . . . . . . . . . 11 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 104 10.1. Normative references . . . . . . . . . . . . . . . . . . . 12 105 10.2. Informative references . . . . . . . . . . . . . . . . . . 13 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 109 1. Introduction 111 This specification defines a Uniform Resource Name namespace for the 112 GSMA (GSM Association) and a sub-namespace for the IMEI 113 (International Mobile station Equipment Identity), and associated 114 parameter for the Software Version number from the IMEISV 115 (International Mobile station Equipment Identity and Software Version 116 number) as per the namespace registration requirement found in [1]. 117 The namespace gsma is a namespace for identities used by Mobile 118 Equipment used in GSM, UMTS and LTE networks. The IMEI and the 119 IMEISV are managed by the GSMA, so this namespace would be managed by 120 the GSMA. Whilst this specification currently specifies only the 121 IMEI sub-namespace under the GSMA URN namespace additional sub- 122 namespaces under the GSMA namespace may be specified in the future by 123 the GSMA through the publication of future informational RFCs. 125 The IMEI is 15 decimal digits long and includes a Type Allocation 126 Code (TAC) of 8 decimal digits and the Serial Number (SNR) of 6 127 decimal digits plus a Spare decimal digit. The TAC identifies the 128 type of the Mobile Equipment and is chosen from a range of values 129 allocated to the Mobile Equipment manufacturer in order to uniquely 130 identify the model of the Mobile Equipment. The SNR is an individual 131 serial number that uniquely identifies each Mobile Equipment within 132 the TAC. The Spare digit is used as a check digit to validate the 133 IMEI and is always set to the value 0 when transmitted by the Mobile 134 Equipment. 136 The IMEISV is 16 decimal digits long and includes the TAC and SNR 137 same as for the IMEI but also a 2 decimal digit Software Version 138 Number (SVN) which is allocated by the Mobile Equipment manufacturer 139 to identify the software version of the Mobile Equipment. 141 The information here is meant to be a concise guide for those wishing 142 to use the IMEI and IMEISV as URNs. Nothing in this document should 143 be construed to override 3GPP TS 23.003 [2] that defines the IMEI and 144 IMEISV. 146 The GSM Association (GSMA) is a global trade association representing 147 more than 750 GSM mobile phone operators across 220 territories and 148 countries of the world. The primary goals of the GSMA are to ensure 149 mobile phones and wireless services work globally and are easily 150 accessible. Further details about the GSMA role in allocating the 151 IMEI and the IMEISV and the IMEI and IMEISV allocation guidelines can 152 be found in GSMA TS 06 [3] 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [4]. 160 3. Namespace Registration Template 162 3.1. GSMA 164 Namespace ID: "gsma" requested 166 Registration Information: 168 Registration version number: 1 170 Registration date: 2011-07-08 172 Declared registrant of the namespace: GSM Association, 1st Floor, 173 Mid City Place, 71 High Holborn, London, England 175 Declaration of syntactic structure: 176 The identifier is expressed in ASCII characters and has a 177 hierarchical structure expressed using the augmented Backus-Naur 178 Form (ABNF) defined in [8] as follows: 180 gsma-urn = "urn:gsma:" gsma-specifier 181 *(":" gsma-specifier-defined-substring) 182 *(";" gsma-specifier-param) 184 gsma-specifier = "imei" / gsma-specifier-defined-string 185 gsma-specifier-defined-string = gsma-approved-nonempty-string 186 gsma-specifier-defined-substring = gsma-approved-nonempty-string 187 gsma-specifier-defined-param-name = gsma-approved-nonempty-string 188 gsma-specifier-defined-param-val = gsma-approved-string 189 gsma-specifier-param = 190 "svn" "=" software-version-string / 191 "vers" "=" gsma-format-version-string / 192 gsma-specifier-defined-param-name "=" 193 gsma-specifier-defined-param-val 194 software-version-string = 2DIGIT 195 gsma-format-version-string = DIGIT 196 gsma-approved-string = *unreserved 197 gsma-approved-nonempty-string = 1*unreserved 198 unreserved = ALPHA / DIGIT / "-" / "." / "_" 200 The GSMA namespace includes a predefined namespace for IMEI and 201 may be in the future extended to include other identifiers used by 202 Mobile Equipment used in GSM, UMTS or LTE networks or future 203 networks deployed by members of the GSMA. 205 An IMEI is an identifier under the GSMA namespace that uniquely 206 identifies Mobile Equipment used in GSM, UMTS and LTE networks. 208 The internal representation of a IMEI is a specific sequence of 209 bits in memory, as described in 3GPP TS 23.003 [2]. To accurately 210 represent a IMEI as a URN, it is necessary to convert the BCD bit 211 sequence to a string representation. Each field BCD bit sequence 212 has its value printed as a decimal digit string with the most 213 significant digit first. 215 The following augmented Backus-Naur Form (ABNF) includes the set 216 of core rules in RFC 5234 [8], and are not repeated here. 218 A URN with the "imei" gsma-specifier contains exactly one gsma- 219 specifier-defined-substring, and its formal definition is provided 220 by the following ABNF [8]: 222 IMEI = tac "-" snr "-" spare 223 tac = 8DIGIT 224 snr = 6DIGIT 225 spare = 1DIGIT 226 For example: 227 urn:gsma:imei:90420156-025763-0;vers=0 229 The optional "vers" parameter is included for extensibility of the 230 namespace, for example if the IMEI format is extended in the 231 future (such as with additional digits or using hex digits). A 232 value of "vers" equal to 0 or the absence of the "vers" parameter 233 means the URN format is compliant with the format specified here. 234 Any change to the format specified here requires the publication 235 of a future informational RFC. 236 draft-allen-dispatch-imei-urn-as-instanceid-09 [9] defines how the 237 IMEI URN can be used as an instance ID as specified in RFC 5626 238 [10]. Any future value of the "vers" parameter other than equal 239 to 0 or the definition of additional parameters that are intended 240 to be used as part of an instance ID will require an update to 241 draft-allen-dispatch-imei-urn-as-instanceid-09 [9]. 243 The IMEISV is an identifier that uniquely identifies Mobile 244 Equipment and associated software versions used in GSM and UMTS 245 networks. The internal representation of a IMEISV is a specific 246 sequence of bits in memory, as described in 3GPP TS 23.003 [2] 247 To represent the IMEISV the URN parameter "svn" is appended to the 248 IMEI URN and set equal to the decimal string representation of the 249 two software version number (svn) bits in the IMEISV and the spare 250 digit in the IMEI gsma-specifier-defined-substring is set to zero. 251 For example: 252 urn:gsma:imei:90420156-025763-0;svn=42 254 The , , , 256 and can comprise any ASCII 257 characters compliant with the above ABNF. The exclusion of the 258 colon from the list of other characters means that the colon can 259 only occur as a delimiter between string values. The exclusion of 260 the semicolon from the list of other characters means that the 261 semicolon can only occur as a delimiter for parameter values. The 262 exclusion of the "=" character from the list of other characters 263 means that the "=" character can only occur as an operator for 264 parameter values. 266 The GSMA will take responsibility for the gsma-specifier "imei" 267 and manage the URNs in its sub-namespace. 269 Additional gsma-specifiers may be added in the future through 270 informational RFCs. 272 Relevant ancillary documentation: 273 See IMEI Allocation and Approval Guidelines [3] and 3GPP TS 23.003 274 [2]. 276 Identifier uniqueness considerations: 277 Identifiers in the "gsma" namespace are defined and assigned in 278 the requested namespace by the GSMA after ensuring that the URNs 279 to be assigned are unique. Uniqueness is achieved by checking 280 against the registry of previously assigned names. 282 Procedures are in place to ensure that each IMEI is uniquely 283 assigned by the Mobile Equipment manufacturer so that it is 284 guaranteed to uniquely identify that particular Mobile Equipment. 285 Procedures are in place to ensure that each IMEISV is uniquely 286 assigned by the Mobile Equipment manufacturer so that it is 287 guaranteed to uniquely identify that particular Mobile Equipment 288 and the specific software version installed. 290 Identifier persistence considerations: 291 The GSMA is committed to maintaining uniqueness and persistence of 292 all resources identified by assigned URNs. 294 As the NID sought is "gsma" and GSMA is the long standing acronym 295 for the trade association that represents the mobile phone 296 operators the URN should also persist indefinitely (at least as 297 long as there is a need for its use). The assignment process 298 guarantees that names are not reassigned. The binding between the 299 name and its resource is permanent. 301 The TAC and SNR portions of IMEISVs are stored in the Mobile 302 Equipment so they remain persistent. The SVN may be modified by 303 software when new versions are installed but should be persistent 304 for the duration of the installation of that specific version of 305 software. 307 Process of identifier assignment: 308 GSMA will manage the (including "imei"), , , , and identifier resources to maintain 312 uniqueness. 314 The process for IMEI and IMEISV assignment is documented in GSMA 315 TS 06[3] 317 Process for identifier resolution: 318 Since the GSMA namespace is not globally resolvable, this is not 319 applicable. 321 Rules for Lexical Equivalence: 322 Two IMEI URNs are equivalent if the single gsma-defined-substrings 323 in the two URNs are the same, and the sequences of gsma-specifier- 324 params are the same and in the same order, with the exception that 325 the gsma-specifier-param "vers=0" is to be ignored for purposes of 326 comparison. All of these comparisons are to be case-insensitive. 328 Any identifier in GSMA namespaces can be compared using the normal 329 mechanisms for percent-encoded UTF-8 strings. 331 Conformance with URN Syntax: 332 The string representation of the GSMA URN and of the IMEI sub- 333 namespace is fully compatible with the URN syntax. 335 Validation Mechanism: 336 The IMEI can be validated using the mechanism defined in Annex B 337 of 3GPP TS 23.003 [2]. There is no mechanism defined to validate 338 the SVN field of the IMEISV. 340 Scope: GSMA URN is global in scope. 342 4. Specification 344 4.1. IMEI Format 346 The IMEI format is 15 decimal digits encoded in 8 octets using BCD as 347 defined in 3GPP TS 24.008 [5]. The most significant digit is coded 348 in the most significant bits of octet 1. The least significant digit 349 is coded in the least significant bits of octet 8. 351 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 352 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 353 | | | S| 354 | T | S | p| 355 | A | N | a| 356 | C | R | r| 357 | | | e| 358 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 359 1 2 3 4 5 6 7 8 Octets 361 4.1.1. Type Allocation Code (TAC) 363 The TAC is a 8 decimal digit value. The TAC identifies the type of 364 the Mobile Equipment and is chosen from a range of values allocated 365 to the Mobile Equipment manufacturer in order to uniquely identify 366 the model of the Mobile Equipment. 368 4.1.2. Serial Number (SNR) 370 The SNR is a 6 decimal digit value. The SNR is an individual serial 371 number that uniquely identifies each Mobile Equipment within the TAC. 373 4.1.3. Spare 375 The Spare is a single decimal digit. When the IMEI is stored on the 376 Mobile Equipment and network equipment it contains a value that is 377 used as a Check Digit and is intended to avoid manual reporting 378 errors, (e.g. when customers register stolen mobiles at the 379 operator's customer care desk) and also to help guard against the 380 possibility of incorrect entries being provisioned in the network 381 equipment. The Spare is always set to zero when transmitted by the 382 Mobile Equipment, (including when in the IMEI URN format). Annex B 383 of 3GPP TS 23.003 [2] defines a mechanism for computing the actual 384 check digit in order to validate the TAC and SNR. 386 4.2. IMEISV Format 388 The IMEISV format is 16 decimal digits encoded in 8 octets using BCD 389 as defined in 3GPP TS 24.008 [5]. The most significant digit is 390 coded in the most significant bits of octet 1. The least significant 391 digit is coded in the least significant bits of octet 8. 393 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 394 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 395 | | | | 396 | T | S | S | 397 | A | N | V | 398 | C | R | N | 399 | | | | 400 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 401 1 2 3 4 5 6 7 8 Octets 403 4.2.1. Type Allocation Code (TAC) 405 The TAC is the same as for the IMEI in Section 5.1.1. 407 4.2.2. Serial Number (SNR) 409 The SNR is the same as for the IMEI in Section 5.1.2. 411 4.2.3. Software Version Number (SVN) 413 The Software Version Number is allocated by the Mobile Equipment 414 manufacturer to identify the software version of the Mobile 415 Equipment. 417 5. Community considerations 419 GSM, UMTS and LTE mobile devices will be interoperating with Internet 420 devices for a variety of voice and data services. To do this, they 421 need to make use of Internet protocols that will operate end to end 422 between devices in GSM/UMTS/LTE networks and those in the general 423 internet. Some of these protocols require the use of URN's as 424 identifiers. Within the GSM/UMTS/LTE networks, mobile devices are 425 identified by their IMEI and IMEISV. Internet users will need to be 426 able to receive and include the GSMA URN in various Internet protocol 427 elements to facilitate communication between pure internet based 428 devices and GSM/UMTS/LTE mobile devices. Thus the existence and 429 syntax of these namespaces needs to be available to the general 430 internet community and the namespace needs to be reserved with IANA 431 in order to guarantee uniqueness and prevent potential namespace 432 conflicts both within the internet and within GSM/UMTS/LTE networks. 433 Conversely, Internet implementations will not generally possess IMEI 434 identifiers. The identifiers generated by such implementations will 435 typically be URNs within namespaces other than "gsma," and may, 436 depending on context, even be non-URN URIs. Implementations are 437 advised to be ready to process URIs other than "gsma"-namespaced 438 URNs, so as to aid in interoperability. 440 6. Namespace considerations 442 A URN was considered the most appropriate URI to represent the IMEI 443 and IMEISV as these identifiers may be used and transported similarly 444 to the Universally Unique Identifier (UUID)which is defined as a URN 445 in [11]. Since specifications for protocols that are used to 446 transport device identifiers often require the device identifier to 447 be globally unique and in the URN format it is necessary that the URN 448 formats are defined to represent the IMEI and IMEISV. 450 7. IANA considerations 452 In accordance with BCP 66 [1], IANA is asked to register the Formal 453 URN Namespace 'GSMA' in the Registry of URN Namespaces, using the 454 registration template presented in Section 3 of this document. 456 8. Security considerations 458 IMEIs (but with the Spare value set to the value of the Check Digit) 459 are displayable on most Mobile Equipment and in many cases is printed 460 on the case within the battery compartment. Anyone with brief 461 physical access to the Mobile Equipment can therefore easily obtain 462 the IMEI. Therefore the IMEI MUST NOT be used as security 463 capabilities (identifiers whose mere possession grants access). 464 Unfortuantely there are currently examples of some applications which 465 are using the IMEI for authorisation. Also some service providers 466 customer service departments have been known to use knowledge of the 467 IMEI as proof that the caller is the legitimate owner of the Mobile 468 Equipment. Both of these are inappropriate uses of the IMEI. 470 Whilst the specific software version of the Mobile Equipment only 471 identifies the lower layer software that has undegone and passed 472 certification testing and not the operating system or application 473 software there is still a possibility that the Software version could 474 identify software that is vulnerable to attacks or is known to 475 contain security holes. Therfore care SHOULD be taken regarding use 476 of the IMEISV as it could help a malicious device identify Mobile 477 Equipment running software that is known to be vulnerable to certain 478 attacks. This is a similar concern to the use of the User-Agent 479 header in SIP as specified in RFC 3261 [12]. Therefore the IMEISV 480 (that is, the IMEI URN with svn parameter) MUST NOT be delivered to 481 devices that are not trusted. Further, because IMEIs can be loosely 482 correlated to a user, they need to be treated as any other personally 483 identifiable information. In particular, the IMEI URN MUST NOT be 484 included in messages intended to convey any level of anonymity. 486 Additional security considerations are specified in 3GPP TS 22.016 487 [6]. Specifically the IMEI is to be incorporated in a module which 488 is contained within the terminal. The IMEI SHALL NOT be changed 489 after the terminal's production process. It SHALL resist tampering, 490 i.e. manipulation and change, by any means (e.g. physical, electrical 491 and software). 493 9. Acknowledgements 495 This document draws heavily on the 3GPP work on Numbering, Addressing 496 and Identification in 3GPP TS 23.003 [2] and also on the style and 497 structure used in RFC 4122 [11]. The authors would like to thank 498 Cullen Jennings, Lisa Dusseault, Dale Worley, and Ivo Sedlacek for 499 their help and comments. 501 10. References 503 10.1. Normative references 505 [1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 506 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 507 BCP 66, RFC 3406, October 2002. 509 [2] 3GPP, "TS 23.003: Numbering, addressing and identification 510 (Release 8)", 3GPP 23.003, December 2012, 511 . 513 [3] GSMA Association, "IMEI Allocation and Approval Guidelines", 514 PRD TS.06 (DG06) version 6.0, July 2011, . 518 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 519 Levels", BCP 14, RFC 2119, March 1997. 521 [5] 3GPP, "TS 24.008: Mobile radio interface Layer 3 specification; 522 Core network protocols; Stage 3 (Release 8)", 3GPP 24.008, 523 December 2012, 524 . 526 [6] 3GPP, "TS 22.016: International Mobile station Equipment 527 Identities (IMEI)(Release 7)", 3GPP 22.016, May 2007, 528 . 530 [7] Moats, R., "URN Syntax", RFC 2141, May 1997. 532 10.2. Informative references 534 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 535 Specifications: ABNF", STD 68, RFC 5234, January 2008. 537 [9] Allen, A., "Using the International Mobile station Equipment 538 Identity(IMEI)URN as an Instance ID, work in progress", 539 Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-09, 540 May 2013. 542 [10] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 543 Initiated Connections in the Session Initiation Protocol 544 (SIP)", RFC 5626, October 2009. 546 [11] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 547 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 549 [12] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 550 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 551 Session Initiation Protocol", RFC 3261, June 2002. 553 Authors' Addresses 555 Michael Montemurro (editor) 556 Blackberry 557 4701 Tahoe Dr 558 Mississauga, Ontario L4W 0B4 559 Canada 561 Phone: unlisted 562 Fax: unlisted 563 Email: mmontemurro@blackberry.com 564 Andrew Allen 565 Blackberry 566 1200 Sawgrass Corporate Parkway 567 Sunrise, Florida 33323 568 USA 570 Phone: unlisted 571 Fax: unlisted 572 Email: aallen@blackberry.com 574 David McDonald 575 unaffiliated 577 Phone: unlisted 578 Fax: unlisted 579 Email: mcdonalddm@hotmail.com 581 Paul Gosden 582 GSM Association 583 1st Floor, Mid City Place, 71 High Holborn, 584 London 585 England 587 Phone: unlisted 588 Fax: unlisted 589 Email: pgosden@gsm.org