diff options
Diffstat (limited to 'doc/rfc/rfc7254.txt')
| -rw-r--r-- | doc/rfc/rfc7254.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc7254.txt b/doc/rfc/rfc7254.txt new file mode 100644 index 0000000..5ad9b8c --- /dev/null +++ b/doc/rfc/rfc7254.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Montemurro, Ed. +Request for Comments: 7254 A. Allen +Category: Informational Blackberry +ISSN: 2070-1721 D. McDonald + Eircom + P. Gosden + GSM Association + May 2014 + + + A Uniform Resource Name Namespace + for the Global System for Mobile Communications Association (GSMA) + and the International Mobile station Equipment Identity (IMEI) + +Abstract + + This specification defines a Uniform Resource Name (URN) namespace + for the Global System for Mobile Communications Association (GSMA) + and a Namespace Specific String (NSS) for the International Mobile + station Equipment Identity (IMEI), as well as an associated parameter + for the International Mobile station Equipment Identity and Software + Version number (IMEISV). The IMEI and IMEISV were introduced as part + of the specification for the GSM and are also now incorporated by the + 3rd Generation Partnership Project (3GPP) as part of the 3GPP + specification for GSM, Universal Mobile Telecommunications System + (UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI and + IMEISV are used to uniquely identify Mobile Equipment within these + systems and are managed by the GSMA. URNs from this namespace almost + always contain personally identifiable information and need to be + treated accordingly. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7254. + + + + + +Montemurro, et al. Informational [Page 1] + +RFC 7254 The GSMA and IMEI URN May 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Montemurro, et al. Informational [Page 2] + +RFC 7254 The GSMA and IMEI URN May 2014 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................4 + 3. Namespace Registration Template .................................4 + 4. Specification ...................................................8 + 4.1. IMEI Parameters ............................................8 + 4.2. IMEI Format ................................................9 + 4.2.1. Type Allocation Code (TAC) ..........................9 + 4.2.2. Serial Number (SNR) .................................9 + 4.2.3. Spare ..............................................10 + 4.2.4. Binary Encoding ....................................10 + 4.3. IMEISV Format .............................................10 + 4.3.1. Type Allocation Code (TAC) .........................10 + 4.3.2. Serial Number (SNR) ................................11 + 4.3.3. Software Version Number (SVN) ......................11 + 4.3.4. Binary Encoding ....................................11 + 5. Community Considerations .......................................11 + 6. Namespace Considerations .......................................12 + 7. IANA Considerations ............................................12 + 8. Security and Privacy Considerations ............................12 + 9. Acknowledgements ...............................................14 + 10. References ....................................................14 + 10.1. Normative References .....................................14 + 10.2. Informative References ...................................15 + +1. Introduction + + This specification defines a Uniform Resource Name (URN) namespace + for the Global System for Mobile Communications Association (GSMA) + and a Namespace Specific String (NSS) for the International Mobile + station Equipment Identity (IMEI), as well as an associated parameter + for the International Mobile station Equipment Identity and Software + Version number (IMEISV) as per the namespace registration requirement + found in RFC 3406 [1]. The Namespace Identifier (NID) 'gsma' is for + identities used in GSM, Universal Mobile Telecommunications System + (UMTS), and Long Term Evolution (LTE) networks. The IMEI and the + IMEISV are managed by the GSMA, so this NID is managed by the GSMA. + While this specification currently defines only the 'imei' NSS under + the 'gsma' NID, additional NSS under the 'gsma' NID may be specified + in the future by the GSMA, using the procedure for URN NSS changes + and additions (currently through the publication of future + Informational RFCs approved by IETF consensus). + + + + + + + + +Montemurro, et al. Informational [Page 3] + +RFC 7254 The GSMA and IMEI URN May 2014 + + + The IMEI is 15 decimal digits long and includes a Type Allocation + Code (TAC) of 8 decimal digits and a Serial Number (SNR) of 6 decimal + digits plus a Spare decimal digit. The TAC identifies the type of + the Mobile Equipment and is chosen from a range of values allocated + to the Mobile Equipment manufacturer in order to uniquely identify + the model of the Mobile Equipment. The SNR is an individual serial + number that uniquely identifies each Mobile Equipment device within + the TAC. The Spare digit is used as a Check digit to validate the + IMEI and is always set to the value 0 when transmitted by the Mobile + Equipment. + + The IMEISV is 16 decimal digits long and includes the TAC and SNR, + same as for the IMEI, but also includes a 2 decimal digit Software + Version Number (SVN), which is allocated by the Mobile Equipment + manufacturer to identify the software version of the Mobile + Equipment. + + The information here is meant to be a concise guide for those wishing + to use the IMEI and IMEISV as URNs. Nothing in this document should + be construed to override 3GPP Technical Specification (TS) 23.003 + [2], which specifies the IMEI and IMEISV. + + The GSMA is a global trade association representing nearly 800 mobile + phone operators across 220 territories and countries of the world. + The primary goals of the GSMA are to ensure that mobile phones and + wireless services work globally and are easily accessible. Further + details about the GSMA's role in allocating the IMEI and the IMEISV, + as well as the IMEI and IMEISV allocation guidelines, can be found in + GSMA Permanent Reference Document (PRD) TS.06 [3]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + +3. Namespace Registration Template + + Namespace ID: 'gsma' + + Registration Information: + + Registration version number: 1 + + Registration date: 2014-01-12 + + + + + + +Montemurro, et al. Informational [Page 4] + +RFC 7254 The GSMA and IMEI URN May 2014 + + + Declared registrant of the namespace: + + Registering organization: + + Name: GSM Association + + Address: 1st Floor, Mid City Place, + + 71 High Holborn, London, England + + Designated contact person: + + Name: Paul Gosden + + Coordinates: pgosden@gsma.com + + Declaration of syntactic structure: + + The identifier is expressed in American Standard Code for + Information Interchange (ASCII) characters and has a hierarchical + structure expressed using the Augmented Backus-Naur Form (ABNF) + defined in RFC 5234 [5], as follows: + + gsma-urn = "urn:" gsma-NID ":" gsma-NSS + gsma-NID = "gsma" + gsma-NSS = imei-specifier / future-gsma-specifier + imei-specifier = "imei:" ( imeival / ext-imei ) + [ ";" sw-version-param ] + [ ";" imei-version-param ] + ext-imei = gsma-defined-nonempty ;GSMA defined and + ;IETF consensus + ;required + sw-version-param = "svn=" software-version + imei-version-param = "vers=" imei-version-val + software-version = 2DIGIT + imei-version-val = DIGIT + future-gsma-specifier = future-specifier + *( ";" future-param ) + future-specifier = gsma-defined-nonempty ;GSMA defined + + future-param = par-name [ EQUAL par-value ] + par-name = gsma-defined-nonempty + par-value = gsma-defined-nonempty + EQUAL = "=" + gsma-defined-nonempty = 1*gsma-urn-char + gsma-urn-char = ALPHA / DIGIT + / "-" / "." / "_" / "%" / ":" + + + + +Montemurro, et al. Informational [Page 5] + +RFC 7254 The GSMA and IMEI URN May 2014 + + + An NSS for the IMEI is defined under the 'gsma' NID. + + An IMEI is an identifier under the 'gsma' NID that uniquely + identifies the mobile devices used in the GSM, UMTS, and LTE + networks. + + The representation of the IMEI is defined in 3GPP TS 23.003 [2]. + To accurately represent an IMEI received in a cellular signaling + message (see 3GPP TS 24.008 [6]) as a URN, it is necessary to + convert the received binary (Binary Coded Decimal (BCD)) encoded + bit sequence to a decimal digit string representation. Each field + has its representation for humans as a decimal digit string with + the most significant digit first. + + The following ABNF includes the set of core rules in RFC 5234 [5]; + the core rules are not repeated here. + + A URN with the 'imei' NSS contains one 'imeival', and its formal + definition is provided by the following ABNF (RFC 5234) [5]: + + imeival = tac "-" snr "-" spare + + tac = 8DIGIT + + snr = 6DIGIT + + spare = DIGIT + + <future-gsma-specifier> and <gsma-defined-nonempty> can comprise + any ASCII characters compliant with the above ABNF. + + The GSMA will take responsibility for the 'gsma' namespace, + including the 'imei' NSS. + + Additional NSS may be added for future identifiers needed by the + GSMA, at their discretion. Only URNs with the 'imei' NSS are + considered to be "GSMA IMEI URNs", and use in IETF protocols of + other NSS that might be defined in the future will require IETF + consensus. + + Relevant ancillary documentation: + + See IMEI Allocation and Approval Guidelines (GSMA PRD TS.06) [3] + and 3GPP TS 23.003 [2]. + + + + + + + +Montemurro, et al. Informational [Page 6] + +RFC 7254 The GSMA and IMEI URN May 2014 + + + Identifier uniqueness considerations: + + Identifiers under the 'gsma' NID are defined and assigned by the + GSMA after ensuring that the URNs to be assigned are unique. + Uniqueness is achieved by checking against the IANA registry of + previously assigned names. + + Procedures are in place to ensure that each IMEI is uniquely + assigned by the Mobile Equipment manufacturer so that it is + guaranteed to uniquely identify that particular Mobile Equipment + device. + + Procedures are in place to ensure that each IMEISV is uniquely + assigned by the Mobile Equipment manufacturer so that it is + guaranteed to uniquely identify that particular Mobile Equipment + device and the specific software version installed. + + Identifier persistence considerations: + + The GSMA is committed to maintaining uniqueness and persistence of + all resources identified by assigned URNs. + + As the NID sought is 'gsma' and "GSMA" is the long-standing + acronym for the trade association that represents the mobile phone + operators, the URN should also persist indefinitely (at least as + long as there is a need for its use). The assignment process + guarantees that names are not reassigned. The binding between the + name and its resource is permanent. + + The TAC and SNR portions of the IMEI and IMEISV are permanently + stored in the Mobile Equipment, so they remain persistent as long + as the Mobile Equipment exists. The process for TAC and SNR + assignment is documented in GSMA PRD TS.06 [3], and once assigned, + the TAC and SNR values are not reassigned to other Mobile + Equipment devices. The SVN portion of the IMEISV may be modified + by software when new versions are installed but should be + persistent for the duration of the installation of that specific + version of software. + + Process of identifier assignment: + + The GSMA will manage the <NSS> (including 'imei') and + <future-gsma-specifier> identifier resources to maintain + uniqueness. + + The process for IMEI and IMEISV assignment is documented in GSMA + PRD TS.06 [3]. + + + + +Montemurro, et al. Informational [Page 7] + +RFC 7254 The GSMA and IMEI URN May 2014 + + + Process for identifier resolution: + + Since the 'gsma' NSS is not currently globally resolvable, this is + not applicable. + + Rules for Lexical Equivalence: + + Two GSMA IMEI URNs are equivalent if they have the same 'imeival' + value, and the same parameter values in the same sequential order, + with the exception that the 'vers=0' parameter is to be ignored + for the purposes of comparison. All of these comparisons are to + be case insensitive. + + Any identifier in the 'gsma' NSS can be compared using the normal + mechanisms for percent-encoded UTF-8 strings (see RFC 3629 [7]). + + Conformance with URN Syntax: + + The string representation of the 'gsma' NID and of the 'imei' NSS + is fully compatible with the URN syntax (see RFC 2141 [8]). + + Validation mechanism: + + The IMEI can be validated using the mechanism defined in Annex B + of 3GPP TS 23.003 [2]. There is no mechanism defined to validate + the SVN field of the IMEISV. + + Scope: The GSMA URN is global in scope. + +4. Specification + +4.1. IMEI Parameters + + The optional 'vers' parameter and the 'ext-imei' field in the ABNF + are included for extensibility of the 'imei' NSS -- for example, if + the IMEI format is extended in the future (such as with additional + digits or using hex digits). In this case, the 'vers' parameter + would contain a non-zero value and the 'ext-imei' would be further + defined to represent the syntax of the extended IMEI format. A value + of the 'vers' parameter equal to 0 or the absence of the 'vers' + parameter means the URN format is compliant with the format specified + here. + + Any change to the format of the 'imei' NSS requires the use of the + procedure for URN NSS changes and additions (currently through the + publication of future Informational RFCs approved by IETF consensus). + The use of the 'vers' parameter was chosen for extensibility instead + of defining a new NSS (e.g., 'imei2') because it is likely that many + + + +Montemurro, et al. Informational [Page 8] + +RFC 7254 The GSMA and IMEI URN May 2014 + + + applications will only need to perform string compares of the + 'imeival'. So, even if the format or length of the 'imeival' changes + in the future, such applications should continue to work without + having to be updated to understand a new NSS. + + RFC 7255 [10] specifies how the GSMA IMEI URN can be used as an + instance ID as specified in RFC 5626 [11]. Any future value of the + 'vers' parameter other than 0, or the definition of additional + parameters that are intended to be used as part of an instance ID, + will require an update to RFC 7255 [10]. + + For example: + + urn:gsma:imei:90420156-025763-0;vers=0 + + The IMEISV is an identifier that uniquely identifies mobile devices + and their associated software versions used in the GSM, UMTS, and LTE + networks. The representation of the IMEISV is defined in 3GPP TS + 23.003 [2]. + + To represent the IMEISV, the URN parameter 'svn' is appended to the + GSMA IMEI URN and set equal to the decimal string representation of + the two software version number (svn) digits in the IMEISV, and the + Spare digit in the IMEI 'imeival' is set to zero. + + For example: + + urn:gsma:imei:90420156-025763-0;svn=42 + +4.2. IMEI Format + +4.2.1. Type Allocation Code (TAC) + + The TAC is an 8 decimal digit value. The TAC identifies the type of + the Mobile Equipment and is chosen from a range of values allocated + to the Mobile Equipment manufacturer in order to uniquely identify + the model of the Mobile Equipment. + +4.2.2. Serial Number (SNR) + + The SNR is a 6 decimal digit value. The SNR is an individual serial + number that uniquely identifies each Mobile Equipment device within + the TAC. + + + + + + + + +Montemurro, et al. Informational [Page 9] + +RFC 7254 The GSMA and IMEI URN May 2014 + + +4.2.3. Spare + + The Spare is a single decimal digit. When the IMEI is stored on the + Mobile Equipment and network equipment, it contains a value that is + used as a Check digit and is intended to avoid manual reporting + errors (e.g., when customers register stolen mobiles at the + operator's customer care desk) and also to help guard against the + possibility of incorrect entries being provisioned in the network + equipment. The Spare is always set to zero when transmitted by the + Mobile Equipment (including when in the IMEI URN format). Annex B of + 3GPP TS 23.003 [2] specifies a mechanism for computing the actual + Check digit in order to validate the TAC and SNR. + +4.2.4. Binary Encoding + + When included in a cellular signaling message, the IMEI format is 15 + decimal digits encoded in 8 octets, using BCD as defined in 3GPP TS + 24.008 [6]. Figure 1 is an abstract representation of a BCD-encoded + IMEI stored in memory (the actual storage format in memory is + implementation specific). In Figure 1, the most significant digit of + the TAC is coded in the least significant bits of octet 1. The most + significant digit of the SNR is coded in the least significant bits + of octet 5. The Spare digit is coded in the least significant bits + of octet 8. When included in an identity element in a cellular + signaling message, the most significant digit of the TAC is + included in digit 1 of the identity element in Figure 10.5.4 of + 3GPP TS 24.008 [6]. + + 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | | S| + | T | S | p| + | A | N | a| + | C | R | r| + | | | e| + +--+-----+-----+-----+--+--+-----+-----+--+--+ + 1 2 3 4 5 6 7 8 Octets + + Figure 1: IMEI Format + +4.3. IMEISV Format + +4.3.1. Type Allocation Code (TAC) + + The TAC is the same as the TAC in the IMEI (see Section 4.2.1). + + + + + + +Montemurro, et al. Informational [Page 10] + +RFC 7254 The GSMA and IMEI URN May 2014 + + +4.3.2. Serial Number (SNR) + + The SNR is the same as the SNR in the IMEI (see Section 4.2.2). + +4.3.3. Software Version Number (SVN) + + The Software Version Number is allocated by the mobile device + manufacturer to identify the software version of the mobile device. + +4.3.4. Binary Encoding + + When included in a cellular signaling message, the IMEISV format is + 16 decimal digits encoded in 8 octets using BCD as defined in 3GPP TS + 24.008 [6]. Figure 2 is an abstract representation of a BCD-encoded + IMEISV stored in memory (the actual storage format in memory is + implementation specific). In Figure 2, the most significant digit of + the TAC is coded in the most significant bits of octet 1. The most + significant digit of the SNR is coded in the most significant bits of + octet 5. The most significant digit of the SVN is coded in the most + significant bits of octet 8. When included in an identity element in + a cellular signaling message, the most significant digit of the TAC + is included in digit 1 of the identity element in Figure 10.5.4 of + 3GPP TS 24.008 [6]. + + 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | | | + | T | S | S | + | A | N | V | + | C | R | N | + | | | | + +-----+-----+-----+-----+-----+-----+-----+-----+ + 1 2 3 4 5 6 7 8 Octets + + Figure 2: IMEISV Format + +5. Community Considerations + + GSM, UMTS, and LTE mobile devices will be interoperating with + Internet devices for a variety of voice and data services. To do + this, they need to make use of Internet protocols that will operate + end to end between devices in GSM/UMTS/LTE networks and those in the + general Internet. Some of these protocols require the use of URNs as + identifiers. Within the GSM/UMTS/LTE networks, mobile devices are + identified by their IMEI or IMEISV. Internet users will need to be + able to receive and include the GSMA URN in various Internet protocol + elements to facilitate communication between pure Internet-based + devices and GSM/UMTS/LTE mobile devices. Thus, the existence and + + + +Montemurro, et al. Informational [Page 11] + +RFC 7254 The GSMA and IMEI URN May 2014 + + + syntax of these namespaces need to be available to the general + Internet community, and the namespace needs to be reserved with IANA + in order to guarantee uniqueness and prevent potential namespace + conflicts both within the Internet and within GSM/UMTS/LTE networks. + Conversely, Internet implementations will not generally possess IMEI + identifiers. The identifiers generated by such implementations will + typically be URNs within namespaces other than 'gsma' and may, + depending on context, even be non-URN URIs. Implementations are + advised to be ready to process URIs other than 'gsma' namespaced + URNs, so as to aid in interoperability. + +6. Namespace Considerations + + A URN was considered the most appropriate URI to represent the IMEI + and IMEISV, as these identifiers may be used and transported + similarly to the Universally Unique Identifier (UUID), which is + defined as a URN in RFC 4122 [12]. Since specifications for + protocols that are used to transport device identifiers often require + the device identifier to be globally unique and in the URN format, it + is necessary that the URN formats are defined to represent the IMEI + and IMEISV. + +7. IANA Considerations + + In accordance with BCP 66 (RFC 3406) [1], IANA has registered the + Formal URN Namespace 'gsma' in the "Uniform Resource Names (URN) + Namespaces" registry, using the registration template presented in + Section 3 of this document. + +8. Security and Privacy Considerations + + IMEIs (but with the Spare value set to the value of the Check digit) + are displayable on most mobile devices and in many cases are printed + on the case within the battery compartment. Anyone with brief + physical access to the mobile device can therefore easily obtain the + IMEI. Therefore, IMEIs MUST NOT be used as security capabilities + (identifiers whose mere possession grants access). Unfortunately, + there are currently examples of some applications that are using the + IMEI for authorization. Also, some service provider's customer + service departments have been known to use knowledge of the IMEI as + "proof" that the caller is the legitimate owner of the mobile device. + Both of these are inappropriate uses of the IMEI. + + While the specific software version of the mobile device only + identifies the lower-layer software that has undergone and passed + certification testing, and not the operating system or application + software, the software version could identify software that is + vulnerable to attacks or is known to contain security holes. + + + +Montemurro, et al. Informational [Page 12] + +RFC 7254 The GSMA and IMEI URN May 2014 + + + Therefore, the IMEISV MUST only be delivered to trusted entities + within carrier networks and not provided to the Internet at large, as + it could help a malicious device identify that the mobile device is + running software that is known to be vulnerable to certain attacks. + This concern is similar to concerns regarding the use of the + User-Agent header in the Session Initiation Protocol (SIP) as + specified in RFC 3261 [13]. Therefore, the IMEISV (that is, the IMEI + URN with a 'svn' parameter) MUST NOT be delivered to devices that are + not trusted. IMEIs are almost always personally identifiable + information, and so these URNs MUST be treated as personally + identifiable information in all cases. In order to prevent violating + a user's privacy, the IMEI URN MUST NOT be included in messages + intended to convey any level of anonymity. + + Since the IMEI is permanently assigned to the mobile device and is + not modified when the ownership of the mobile device changes (even + upon a complete software reload of the device), the IMEI URN MUST NOT + be used as a user identifier or user address by an application. + Using the IMEI to identify a user or as a user address could result + in communications destined for a previous owner of a device being + received by the new device owner or could allow the new device owner + to access information or services owned by the previous device owner. + + Additionally, since the IMEI identifies the mobile device, it + potentially could be used to identify and track users for the + purposes of surveillance and call data mining if sent in the clear. + + Since the IMEI is personally identifiable information, uses of the + IMEI URN with IETF protocols require a specification and IETF Expert + Review [14] in order to ensure that privacy concerns are + appropriately addressed. Protocols carrying the IMEI URN SHOULD at a + minimum use channels that are strongly hop-by-hop encrypted, and it + is RECOMMENDED that end-to-end encryption be used. + + Additional security considerations are specified in 3GPP TS 22.016 + [9]. Specifically, the IMEI is to be incorporated in a module that + is contained within the terminal. The IMEI SHALL NOT be changed + after the terminal's production process. It SHALL resist tampering, + i.e., manipulation and change, by any means (e.g., physical, + electrical, and software). + + + + + + + + + + + +Montemurro, et al. Informational [Page 13] + +RFC 7254 The GSMA and IMEI URN May 2014 + + +9. Acknowledgements + + This document draws heavily on the 3GPP work on Numbering, + Addressing, and Identification in 3GPP TS 23.003 [2] and also on the + style and structure used in RFC 4122 [12]. The authors would like to + thank Cullen Jennings, Lisa Dusseault, Dale Worley, Ivo Sedlacek, + Atle Monrad, James Yu, Mary Barnes, Tim Bray, S. Moonesamy, Alexey + Melnikov, Martin Duerst, John Klensin, Paul Kyzivat, Christer + Holmberg, Barry Leiba, and Stephen Farrell for their help and + comments. + +10. References + +10.1. Normative References + + [1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, + "Uniform Resource Names (URN) Namespace Definition Mechanisms", + BCP 66, RFC 3406, October 2002. + + [2] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 + (Release 8), March 2014, <ftp://ftp.3gpp.org/Specs/ + archive/23_series/23.003/>. + + [3] GSM Association, "IMEI Allocation and Approval Guidelines", PRD + TS.06 (DG06) Version 6.0, July 2011, + <http://www.gsma.com/newsroom/wp-content/uploads/2012/06/ + ts0660tacallocationprocessapproved.pdf>. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [6] 3GPP, "Mobile radio interface Layer 3 specification; Core + network protocols; Stage 3", 3GPP TS 24.008 (Release 8), June + 2013, <ftp://ftp.3gpp.org/Specs/archive/24_series/ 24.008/>. + + [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD + 63, RFC 3629, November 2003. + + [8] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [9] 3GPP, "International Mobile station Equipment Identities + (IMEI)", 3GPP TS 22.016 (Release 8), December 2009, + <ftp://ftp.3gpp.org/Specs/archive/22_series/22.016/>. + + + + + +Montemurro, et al. Informational [Page 14] + +RFC 7254 The GSMA and IMEI URN May 2014 + + +10.2. Informative References + + [10] Allen, A., Ed., "Using the International Mobile station + Equipment Identity (IMEI) Uniform Resource Name (URN) as an + Instance ID", RFC 7255, May 2014. + + [11] Jennings, C., Mahy, R., and F. Audet, "Managing Client- + Initiated Connections in the Session Initiation Protocol (SIP)", + RFC 5626, October 2009. + + [12] Leach, P., Mealling, M., and R. Salz, "A Universally Unique + IDentifier (UUID) URN Namespace", RFC 4122, July 2005. + + [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Montemurro, et al. Informational [Page 15] + +RFC 7254 The GSMA and IMEI URN May 2014 + + +Authors' Addresses + + Michael Montemurro (editor) + Blackberry + 4701 Tahoe Dr. + Mississauga, Ontario L4W 0B4 + Canada + + EMail: mmontemurro@blackberry.com + + + Andrew Allen + Blackberry + 1200 Sawgrass Corporate Parkway + Sunrise, Florida 33323 + USA + + EMail: aallen@blackberry.com + + + David McDonald + Eircom + + EMail: David.McDonald@meteor.ie + + + Paul Gosden + GSM Association + 1st Floor, Mid City Place, 71 High Holborn + London + England + + EMail: pgosden@gsma.com + + + + + + + + + + + + + + + + + + +Montemurro, et al. Informational [Page 16] + |