GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7254

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7254.txt · Last modified: 2014/05/22 01:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki