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
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)
全球移动通信系统协会（GSMA）和国际移动站设备标识（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.
本规范定义了全球移动通信系统协会（GSMA）的统一资源名称（URN）命名空间和国际移动站设备标识（IMEI）的命名空间特定字符串（NSS），以及国际移动站设备标识和软件版本号（IMEISV）的相关参数。IMEI和IMEISV是作为GSM规范的一部分引入的，现在也作为GSM、通用移动通信系统（UMTS）和3GPP长期演进（LTE）网络的3GPP规范的一部分纳入第三代合作伙伴计划（3GPP）。IMEI和IMEISV用于唯一识别这些系统内的移动设备，并由GSMA管理。此名称空间中的URN几乎总是包含个人可识别信息，需要进行相应处理。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7254.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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 ....................................................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
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).
本规范定义了全球移动通信系统协会（GSMA）的统一资源名称（URN）命名空间和国际移动站设备标识（IMEI）的命名空间特定字符串（NSS），以及国际移动站设备标识和软件版本号（IMEISV）的相关参数，符合RFC 3406[1]中的名称空间注册要求。名称空间标识符（NID）“gsma”用于GSM、通用移动通信系统（UMTS）和长期演进（LTE）网络中使用的标识。IMEI和IMEISV由GSMA管理，因此此NID由GSMA管理。虽然本规范目前仅定义了“gsma”NID下的“imei”NSS，“gsma”NID下的其他NSS可能会在将来由gsma使用URN NSS更改和添加程序指定（目前通过发布IETF一致同意的未来信息RFC）。
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.
IMEI的长度为15位十进制数字，包括8位十进制数字的类型分配代码（TAC）和6位十进制数字的序列号（SNR）以及一个备用十进制数字。TAC识别移动设备的类型，并从分配给移动设备制造商的一系列值中选择，以便唯一地识别移动设备的型号。SNR是唯一标识TAC内每个移动设备的单个序列号。备用数字用作校验数字，以验证IMEI，并且在移动设备传输时始终设置为值0。
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.
IMEISV的长度为16位小数，包括TAC和SNR，与IMEI相同，但也包括2位小数的软件版本号（SVN），该版本号由移动设备制造商分配，用于识别移动设备的软件版本。
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.
此处的信息旨在为希望将IMEI和IMEISV用作URN的用户提供简明指南。本文件中的任何内容均不得解释为覆盖3GPP技术规范（TS）23.003[2]，其中规定了IMEI和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].
GSMA是一个全球贸易协会，代表全球220个地区和国家的近800家移动电话运营商。GSMA的主要目标是确保移动电话和无线服务在全球范围内工作并易于访问。有关GSMA在分配IMEI和IMEISV中的作用以及IMEI和IMEISV分配指南的更多详细信息，请参见GSMA永久参考文件（PRD）TS.06[3]。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
Namespace ID: 'gsma'
命名空间ID:'gsma'
Registration Information:
注册资料：
Registration version number: 1
注册版本号：1
Registration date: 2014-01-12
注册日期：2014-01-12
Declared registrant of the namespace:
已声明命名空间的注册人：
Registering organization:
注册机构：
Name: GSM Association
名称：GSM协会
Address: 1st Floor, Mid City Place,
地址：中城广场1楼，
71 High Holborn, London, England
71高霍尔伯恩，伦敦，英国
Designated contact person:
指定联络人：
Name: Paul Gosden
姓名：保罗·戈斯登
Coordinates: pgosden@gsma.com
协调：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:
标识符以美国信息交换标准代码（ASCII）字符表示，并具有使用RFC 5234[5]中定义的扩充巴科斯-诺尔形式（ABNF）表示的层次结构，如下所示：
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
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
/ "-" / "." / "_" / "%" / ":"
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
/ "-" / "." / "_" / "%" / ":"
An NSS for the IMEI is defined under the 'gsma' NID.
IMEI的NSS在“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.
IMEI是“gsma”NID下的标识符，唯一标识GSM、UMTS和LTE网络中使用的移动设备。
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.
IMEI的表示在3GPP TS 23.003[2]中定义。为了准确地将在蜂窝信令消息（参见3GPP TS 24.008[6]）中接收的IMEI表示为URN，有必要将接收的二进制（二进制编码的十进制（BCD））编码的位序列转换为十进制数字字符串表示。每个字段都以十进制数字字符串的形式表示，其中最重要的数字排在前面。
The following ABNF includes the set of core rules in RFC 5234 [5]; the core rules are not repeated here.
以下ABNF包括RFC 5234[5]中的核心规则集；这里不再重复核心规则。
A URN with the 'imei' NSS contains one 'imeival', and its formal definition is provided by the following ABNF (RFC 5234) [5]:
带有“imei”NSS的URN包含一个“imeival”，其正式定义由以下ABNF（RFC 5234）[5]提供：
imeival = tac "-" snr "-" spare
imeival=tac“-”snr“-”备用
tac = 8DIGIT
tac = 8DIGIT
snr = 6DIGIT
snr = 6DIGIT
spare = DIGIT
spare = DIGIT
<future-gsma-specifier> and <gsma-defined-nonempty> can comprise any ASCII characters compliant with the above ABNF.
<future gsma specifier>和<gsma defined NoneEmpty>可以包含符合上述ABNF的任何ASCII字符。
The GSMA will take responsibility for the 'gsma' namespace, including the 'imei' NSS.
GSMA将负责“GSMA”命名空间，包括“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.
GSMA可自行决定为未来所需的标识符添加额外的NSS。只有带有“imei”NSS的URN才被视为“GSMA imei URN”，在未来可能定义的其他NSS的IETF协议中使用将需要IETF协商一致。
Relevant ancillary documentation:
相关辅助文件：
See IMEI Allocation and Approval Guidelines (GSMA PRD TS.06) [3] and 3GPP TS 23.003 [2].
参见IMEI分配和批准指南（GSMA PRD TS.06）[3]和3GPP TS 23.003[2]。
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.
在确保要分配的URN是唯一的之后，“gsma”NID下的标识符由gsma定义和分配。唯一性是通过检查IANA注册表中以前分配的名称来实现的。
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.
制定程序以确保每个IMEI由移动设备制造商唯一分配，从而确保其唯一标识特定移动设备。
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.
制定程序以确保每个IMEISV由移动设备制造商唯一分配，从而确保其唯一标识特定移动设备设备和安装的特定软件版本。
Identifier persistence considerations:
标识符持久性注意事项：
The GSMA is committed to maintaining uniqueness and persistence of all resources identified by assigned URNs.
GSMA致力于维护分配的URN标识的所有资源的唯一性和持久性。
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.
由于寻求的NID是“gsma”，而“gsma”是代表移动电话运营商的行业协会的长期首字母缩略词，因此URN也应该无限期地存在（至少在需要使用它的情况下）。分配过程保证不会重新分配名称。名称与其资源之间的绑定是永久的。
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.
IMEI和IMEISV的TAC和SNR部分永久存储在移动设备中，因此只要移动设备存在，它们就保持持久性。TAC和SNR分配的过程记录在GSMA PRD TS.06[3]中，一旦分配，TAC和SNR值不会重新分配给其他移动设备。IMEISV的SVN部分可在安装新版本时由软件修改，但应在该特定版本软件的安装期间保持不变。
Process of identifier assignment:
标识符分配过程：
The GSMA will manage the <NSS> (including 'imei') and <future-gsma-specifier> identifier resources to maintain uniqueness.
GSMA将管理<NSS>（包括“imei”）和<future GSMA specifier>标识符资源，以保持唯一性。
The process for IMEI and IMEISV assignment is documented in GSMA PRD TS.06 [3].
IMEI和IMEISV分配过程记录在GSMA PRD TS.06[3]中。
Process for identifier resolution:
标识符解析过程：
Since the 'gsma' NSS is not currently globally resolvable, this is not applicable.
由于“gsma”NSS目前不可在全球解决，因此不适用。
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.
如果两个GSMA IMEI URN具有相同的“imeival”值，且具有相同顺序的相同参数值，则两个GSMA IMEI URN是等效的，但出于比较目的，将忽略“vers=0”参数除外。所有这些比较都不区分大小写。
Any identifier in the 'gsma' NSS can be compared using the normal mechanisms for percent-encoded UTF-8 strings (see RFC 3629 [7]).
“gsma”NSS中的任何标识符都可以使用百分比编码UTF-8字符串的正常机制进行比较（参见RFC 3629[7]）。
Conformance with URN Syntax:
符合URN语法：
The string representation of the 'gsma' NID and of the 'imei' NSS is fully compatible with the URN syntax (see RFC 2141 [8]).
“gsma”NID和“imei”NSS的字符串表示形式与URN语法完全兼容（请参阅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.
IMEI可以使用3GPP TS 23.003[2]附录B中定义的机制进行验证。没有定义验证IMEISV的SVN字段的机制。
Scope: The GSMA URN is global in scope.
作用域：GSMA URN在作用域中是全局的。
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.
ABNF中包含可选的“vers”参数和“ext imei”字段，用于“imei”NSS的扩展性——例如，如果imei格式在将来扩展（例如使用附加数字或十六进制数字）。在这种情况下，“vers”参数将包含一个非零值，“ext imei”将进一步定义以表示扩展imei格式的语法。“vers”参数的值等于0或缺少“vers”参数表示URN格式符合此处指定的格式。
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
“imei”NSS格式的任何更改都需要使用URN NSS更改和添加程序（目前通过发布IETF共识批准的未来信息RFC）。选择使用“vers”参数是为了扩展性，而不是定义一个新的NSS（例如，“imei2”），因为它可能有很多
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.
应用程序只需要执行“imeival”的字符串比较。因此，即使“imeival”的格式或长度在未来发生变化，此类应用程序也应继续工作，而无需更新以了解新的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].
RFC 7255[10]指定如何将GSMA IMEI URN用作RFC 5626[11]中指定的实例ID。除0之外的任何“vers”参数的未来值，或打算用作实例ID一部分的其他参数的定义，都需要更新到RFC 7255[10]。
For example:
例如：
urn:gsma:imei:90420156-025763-0;vers=0
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].
IMEISV是唯一标识GSM、UMTS和LTE网络中使用的移动设备及其相关软件版本的标识符。IMEISV的表示在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.
为了表示IMEISV，URN参数“svn”附加到GSMA IMEI URN，并设置为等于IMEISV中两个软件版本号（svn）数字的十进制字符串表示形式，IMEI“imeival”中的备用数字设置为零。
For example:
例如：
urn:gsma:imei:90420156-025763-0;svn=42
urn:gsma:imei:90420156-025763-0;svn=42
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.
TAC是一个8位小数的数值。TAC识别移动设备的类型，并从分配给移动设备制造商的一系列值中选择，以便唯一地识别移动设备的型号。
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.
信噪比为6位小数。SNR是唯一标识TAC内每个移动设备的单个序列号。
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.
备用是一个十进制数字。当IMEI存储在移动设备和网络设备上时，它包含一个用作校验位的值，旨在避免手动报告错误（例如，当客户在运营商的客户服务台注册被盗手机时）还有助于防止在网络设备中设置错误条目的可能性。通过移动设备传输时（包括采用IMEI URN格式时），备件始终设置为零。3GPP TS 23.003[2]的附录B规定了计算实际校验位的机制，以验证TAC和SNR。
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].
当包含在蜂窝信令消息中时，IMEI格式是以8个八位字节编码的15位十进制数字，使用3GPP TS 24.008[6]中定义的BCD。图1是存储在内存中的BCD编码IMEI的抽象表示（内存中的实际存储格式是特定于实现的）。在图1中，TAC的最高有效位编码为八位组1的最低有效位。SNR的最高有效位编码在八位组5的最低有效位中。备用数字以八位位组8的最低有效位编码。当包含在蜂窝信令消息中的标识元素中时，TAC的最高有效位包含在3GPP TS 24.008[6]图10.5.4中标识元素的数字1中。
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
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
图1:IMEI格式
The TAC is the same as the TAC in the IMEI (see Section 4.2.1).
TAC与IMEI中的TAC相同（见第4.2.1节）。
The SNR is the same as the SNR in the IMEI (see Section 4.2.2).
信噪比与IMEI中的信噪比相同（见第4.2.2节）。
The Software Version Number is allocated by the mobile device manufacturer to identify the software version of the mobile device.
软件版本号由移动设备制造商分配，以识别移动设备的软件版本。
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].
当包含在蜂窝信令消息中时，IMEISV格式为16位十进制数字，使用3GPP TS 24.008[6]中定义的BCD以8个八位字节编码。图2是存储在内存中的BCD编码IMEISV的抽象表示（内存中的实际存储格式是特定于实现的）。在图2中，TAC的最高有效位编码为八位组1的最高有效位。SNR的最高有效位编码在八位组5的最高有效位中。SVN的最高有效位编码为八位字节8的最高有效位。当包含在蜂窝信令消息中的标识元素中时，TAC的最高有效位包含在3GPP TS 24.008[6]图10.5.4中标识元素的数字1中。
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
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
图2:IMEISV格式
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
GSM、UMTS和LTE移动设备将与互联网设备互操作，提供各种语音和数据服务。要做到这一点，他们需要利用将在GSM/UMTS/LTE网络中的设备和普通互联网中的设备之间端到端运行的互联网协议。其中一些协议要求使用URN作为标识符。在GSM/UMTS/LTE网络中，移动设备通过其IMEI或IMEISV来识别。互联网用户需要能够接收GSMA URN并将其包含在各种互联网协议元素中，以促进纯互联网设备与GSM/UMTS/LTE移动设备之间的通信。因此，存在和
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.
这些名称空间的语法需要可供一般互联网社区使用，并且名称空间需要由IANA保留，以保证唯一性并防止互联网内和GSM/UMTS/LTE网络内潜在的名称空间冲突。相反，Internet实现通常不会拥有IMEI标识符。此类实现生成的标识符通常是名称空间中的URN，而不是“gsma”，并且根据上下文的不同，甚至可能是非URN URI。建议实现准备好处理“gsma”名称空间URN以外的URI，以帮助实现互操作性。
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.
URN被认为是表示IMEI和IMEISV的最合适的URI，因为这些标识符的使用和传输方式与通用唯一标识符（UUID）类似，后者在RFC 4122[12]中定义为URN。由于用于传输设备标识符的协议规范通常要求设备标识符是全局唯一的，并且采用URN格式，因此必须定义URN格式来表示IMEI和IMEISV。
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.
根据BCP 66（RFC 3406）[1]，IANA已使用本文件第3节中提供的注册模板在“统一资源名称（URN）名称空间”注册表中注册了正式的URN名称空间“gsma”。
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.
IMEI（但备用值设置为检查数字的值）可在大多数移动设备上显示，并且在许多情况下打印在电池盒内的外壳上。因此，任何对移动设备进行短暂物理访问的人都可以轻松获得IMEI。因此，IMEI不能用作安全功能（仅拥有就可以访问的标识符）。不幸的是，目前有一些应用程序使用IMEI进行授权。此外，一些服务提供商的客户服务部门已经知道使用IMEI的知识作为“证据”，证明呼叫者是移动设备的合法所有者。这两个都是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.
虽然移动设备的特定软件版本仅识别经过认证测试并通过认证测试的较低层软件，而不是操作系统或应用软件，但软件版本可以识别易受攻击或已知包含安全漏洞的软件。
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.
因此，IMEISV只能交付给运营商网络内的受信任实体，而不能提供给整个互联网，因为它可以帮助恶意设备识别移动设备正在运行已知易受某些攻击的软件。该问题类似于RFC 3261[13]中规定的会话发起协议（SIP）中用户代理报头的使用问题。因此，不得将IMEISV（即带有“svn”参数的IMEI URN）传递到不受信任的设备。IMEI几乎总是个人可识别信息，因此在所有情况下，必须将这些URN视为个人可识别信息。为了防止侵犯用户隐私，IMEI URN不得包含在旨在传达任何匿名级别的消息中。
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.
由于IMEI被永久分配给移动设备，并且当移动设备的所有权发生变化时（即使在设备的完整软件重新加载时），IMEI URN也不会被修改，因此应用程序不得将IMEI URN用作用户标识符或用户地址。使用IMEI来识别用户或将其作为用户地址可导致目的地为设备的先前所有者的通信被新设备所有者接收，或可允许新设备所有者访问先前设备所有者所拥有的信息或服务。
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.
此外，由于IMEI识别移动设备，因此如果以明文形式发送，它可能用于识别和跟踪用户，以便进行监视和呼叫数据挖掘。
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.
由于IMEI是个人可识别信息，将IMEI URN与IETF协议一起使用需要规范和IETF专家审查[14]，以确保隐私问题得到适当解决。承载IMEI URN的协议应至少使用经过强逐跳加密的通道，建议使用端到端加密。
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).
3GPP TS 22.016[9]中规定了其他安全注意事项。具体地说，IMEI将并入包含在终端内的模块中。在终端生产过程结束后，不得更改IMEI。它应能抵抗任何方式（如物理、电气和软件）的篡改，即操纵和更改。
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.
本文件大量借鉴了3GPP TS 23.003[2]中关于编号、寻址和标识的工作，以及RFC 4122[12]中使用的样式和结构。作者要感谢卡伦·詹宁斯、丽莎·杜肖奥、戴尔·沃利、伊沃·塞德拉克、阿特勒·蒙拉德、詹姆斯·余、玛丽·巴恩斯、蒂姆·布雷、S·穆内萨米、阿列克西·梅尔尼科夫、马丁·杜尔斯、约翰·克莱辛、保罗·基齐瓦特、克里斯特·霍姆伯格、巴里·莱巴和斯蒂芬·法雷尔的帮助和评论。
[1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[1] Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月。
[2] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 (Release 8), March 2014, <ftp://ftp.3gpp.org/Specs/ archive/23_series/23.003/>.
[2] 3GPP，“编号、寻址和标识”，3GPP TS 23.003（第8版），2014年3月<ftp://ftp.3gpp.org/Specs/ 存档/23_系列/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>.
[3] GSM协会，“IMEI分配和批准指南”，PRD TS.06（DG06）版本6.0，2011年7月<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.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[5] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[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/>.
[6] 3GPP，“移动无线电接口第3层规范；核心网络协议；第3阶段”，3GPP TS 24.008（第8版），2013年6月<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.
[7] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[8] Moats, R., "URN Syntax", RFC 2141, May 1997.
[8] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[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/>.
[9] 3GPP，“国际移动站设备标识（IMEI）”，3GPP TS 22.016（第8版），2009年12月<ftp://ftp.3gpp.org/Specs/archive/22_series/22.016/>.
[10] Allen, A., Ed., "Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID", RFC 7255, May 2014.
[10] Allen，A.，Ed.“使用国际移动站设备标识（IMEI）统一资源名（URN）作为实例ID”，RFC 7255，2014年5月。
[11] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[11] Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[12] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[12] Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[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.
[13] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[14] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Michael Montemurro (editor) Blackberry 4701 Tahoe Dr. Mississauga, Ontario L4W 0B4 Canada
Michael Montemurro（编辑）黑莓4701 Tahoe Missisauga博士，加拿大安大略省L4W 0B4
EMail: mmontemurro@blackberry.com
EMail: mmontemurro@blackberry.com
Andrew Allen Blackberry 1200 Sawgrass Corporate Parkway Sunrise, Florida 33323 USA
Andrew Allen Blackberry美国佛罗里达州Sawgrass Corporate Parkway Sunrise 1200号，邮编33323
EMail: aallen@blackberry.com
EMail: aallen@blackberry.com
David McDonald Eircom
大卫·麦克唐纳·艾尔科姆
EMail: David.McDonald@meteor.ie
EMail: David.McDonald@meteor.ie
Paul Gosden GSM Association 1st Floor, Mid City Place, 71 High Holborn London England
保罗·戈斯登GSM协会英国伦敦霍尔伯恩高71号米德城广场1楼
EMail: pgosden@gsma.com
EMail: pgosden@gsma.com