doc: Add RFC documents

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]
+