[要約] RFC 7254は、GSMAとIMEIのためのUniform Resource Name（URN）の名前空間を定義しています。このRFCの目的は、GSMAとIMEIに関連する情報を一意に識別するためのURNの使用を促進することです。
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)
Mobile Systems for Mobile Communications Association（GSMA）およびInternational Mobile Station Equipment Identity（IMEI）のグローバルシステムのUniform Resource Name名前空間
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.
この仕様は、Global System for Mobile Communications Association（GSMA）のUniform Resource Name（URN）名前空間と、International Mobile Station Equipment Identity（IMEI）の名前空間固有の文字列（NSS）、およびInternationalの関連パラメーターを定義します。モバイルステーションの装置IDとソフトウェアバージョン番号（IMEISV）。 IMEIとIMEISVは、GSMの仕様の一部として導入され、GSM、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）、および3GPP Long Term Evolutionの3GPP仕様の一部として、第3世代パートナーシッププロジェクト（3GPP）にも組み込まれました。 （LTE）ネットワーク。 IMEIおよびIMEISVは、これらのシステム内のモバイル機器を一意に識別するために使用され、GSMAによって管理されます。この名前空間のURNには、ほとんどの場合個人を特定できる情報が含まれており、それに応じて処理する必要があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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.
このドキュメントには、2008年11月10日より前に公開または公開された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
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).
この仕様は、Global System for Mobile Communications Association（GSMA）のUniform Resource Name（URN）名前空間と、International Mobile Station Equipment Identity（IMEI）の名前空間固有の文字列（NSS）、およびInternationalの関連パラメーターを定義します。 RFC 3406 [1]にある名前空間の登録要件に従って、移動局の機器識別およびソフトウェアバージョン番号（IMEISV）。名前空間識別子（NID） 'gsma'は、GSM、Universal Mobile Telecommunications System（UMTS）、およびLong Term Evolution（LTE）ネットワークで使用されるIDです。 IMEIとIMEISVはGSMAによって管理されるため、このNIDはGSMAによって管理されます。この仕様では現在、「gsma」NIDの下で「imei」NSSのみを定義していますが、「gsma」NIDの下で追加のNSSは、将来、URN NSS変更および追加の手順を使用してGSMAによって指定される可能性があります（現在、出版物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桁の10進数で、8桁のタイプアロケーションコード（TAC）と6桁のシリアル番号（SNR）、および予備の10進数が含まれています。 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桁の10進数で、IMEIと同じようにTACとSNRが含まれていますが、モバイルのソフトウェアバージョンを識別するためにモバイル機器メーカーによって割り当てられた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として使用することを希望する人のための簡潔なガイドとなることを目的としています。このドキュメントの内容は、IMEIおよびIMEISVを指定する3GPP技術仕様（TS）23.003 [2]をオーバーライドするものと解釈されるべきではありません。
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の主な目標は、携帯電話とワイヤレスサービスがグローバルに機能し、簡単にアクセスできるようにすることです。 IMEIとIMEISVの割り当てにおけるGSMAの役割、および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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [4]で説明されているように解釈されます。
Namespace ID: 'gsma'
名前空間ID： 'gsma'
Registration Information:
登録情報：
Registration version number: 1
登録バージョン番号：1
Registration date: 2014-01-12 Declared registrant of the namespace:
登録日：2014-01-12宣言された名前空間の登録者：
Registering organization:
登録組織：
Name: GSM Association
名前：GSM協会
Address: 1st Floor, Mid City Place,
住所：Mid City Place 1階
71 High Holborn, London, England
71 High Holborn、ロンドン、イギリス
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:
この識別子は、American Standard Code for Information Interchange（ASCII）文字で表され、RFC 5234 [5]で定義されているAugmented Backus-Naur Form（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
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は、GSM、UMTS、およびLTEネットワークで使用されるモバイルデバイスを一意に識別する「gsma」NIDの下の識別子です。
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として正確に表すには、受信したバイナリ（Binary Coded Decimal（BCD））エンコードビットシーケンスを10進数の文字列表現に変換する必要があります。各フィールドは、最上位の数字を最初に持つ10進数の文字列として人間に表示されます。
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」が1つ含まれており、その正式な定義は次のABNF（RFC 5234）[5]によって提供されています。
imeival = tac "-" snr "-" spare
imeival = tac "-" snr "-"スペア
tac = 8DIGIT
snr = 6DIGIT
spare = DIGIT
<future-gsma-specifier> and <gsma-defined-nonempty> can comprise any ASCII characters compliant with the above ABNF.
<future-gsma-specifier>および<gsma-defined-nonempty>は、上記のABNFに準拠する任意のASCII文字で構成できます。
The GSMA will take responsibility for the 'gsma' namespace, including the 'imei' NSS.
GSMAは、「imei」NSSを含む「gsma」名前空間を担当します。
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.
「gsma」NIDの下の識別子は、割り当てられるURNが一意であることを確認した後、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.
2つのGSMA IMEI URNは、「versival」パラメーターが比較の目的で無視されることを除いて、同じ「imeival」値と同じパラメーター値が同じ順番である場合に同等です。これらの比較はすべて大文字と小文字を区別しません。
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.
オプションの「vers」パラメーターとABNFの「ext-imei」フィールドは、「imei」NSSの拡張性のために含まれています-たとえば、IMEI形式が将来拡張される場合（追加の数字を使用するか、16進数を使用するなど）数字）。この場合、「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 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.
「imei」NSSの形式を変更するには、URN NSSの変更と追加の手順を使用する必要があります（現在、IETFのコンセンサスによって承認された将来のInformational RFCの公開による）。多くのアプリケーションが「imeival」の文字列比較を実行するだけでよい可能性が高いため、新しいNSS（「imei2」など）を定義する代わりに、拡張性のために「vers」パラメーターの使用が選択されました。したがって、「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]では、RFC 5626 [11]で指定されているように、GSMA IMEI URNをインスタンスIDとして使用する方法を指定しています。 0以外の「vers」パラメーターの将来の値、またはインスタンスIDの一部として使用することを目的とした追加パラメーターの定義では、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].
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の2つのソフトウェアバージョン番号（svn）桁の10進数文字列表現、およびIMEI「imeival」のスペア桁に等しく設定されます。ゼロに設定されます。
For example:
例えば：
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桁の10進数です。 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.
SNRは6桁の10進数です。 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.
スペアは1桁の10進数です。 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桁の10進数であり、3GPP TS 24.008 [6]で定義されているBCDを使用します。図1は、メモリに格納されたBCDエンコードされたIMEIの抽象的な表現です（メモリ内の実際の格納形式は実装固有です）。図1では、TACの最上位桁はオクテット1の最下位ビットでコーディングされています。SNRの最上位桁はオクテット5の最下位ビットでコーディングされています。スペア桁は最下位ビットでコーディングされています。セルラーシグナリングメッセージのID要素に含まれる場合、TACの最上位桁は、3GPP TS 24.008 [6]の図10.5.4のID要素の数字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
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).
SNRは、IMEIのSNRと同じです（セクション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形式は、セルラーシグナリングメッセージに含まれる場合、3GPP TS 24.008 [6]で定義されているように、BCDを使用して8オクテットにエンコードされた16桁の10進数です。図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
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 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.
GSM、UMTS、およびLTEモバイルデバイスは、さまざまな音声およびデータサービスのためにインターネットデバイスと相互運用します。これを行うには、GSM / UMTS / LTEネットワークのデバイスと一般的なインターネットのデバイスの間でエンドツーエンドで動作するインターネットプロトコルを使用する必要があります。これらのプロトコルの一部では、識別子としてURNを使用する必要があります。 GSM / UMTS / LTEネットワーク内では、モバイルデバイスはIMEIまたはIMEISVによって識別されます。インターネットユーザーは、純粋なインターネットベースのデバイスとGSM / UMTS / LTEモバイルデバイス間の通信を容易にするために、GSMA URNを受信してさまざまなインターネットプロトコル要素に含めることができる必要があります。したがって、これらの名前空間の存在と構文は、一般的なインターネットコミュニティで使用できる必要があり、一意性を保証し、インターネット内とGSM / UMTS / LTEネットワーク内の両方で名前空間の競合が発生する可能性を防ぐために、IANAで名前空間を予約する必要があります。 。逆に、インターネットの実装は一般的にIMEI識別子を持ちません。このような実装によって生成される識別子は、通常、「gsma」以外の名前空間内のURNであり、コンテキストによっては、非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.
これらの識別子は、RFC 4122 [12]でURNとして定義されているUniversally Unique Identifier（UUID）と同様に使用および転送できるため、URNはIMEIおよびIMEISVを表す最も適切なURIと見なされていました。デバイス識別子の転送に使用されるプロトコルの仕様では、デバイス識別子がグローバルに一意であり、URN形式であることが必要な場合が多いため、IMEIおよびIMEISVを表すようにURN形式を定義する必要があります。
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に記載されている登録テンプレートを使用して、「Uniform Resource Names（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をセキュリティ機能（単なる所有物がアクセスを許可する識別子）として使用してはなりません（MUST NOT）。残念ながら、現在、認可に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）は、信頼されていないデバイスに配信してはなりません（MUST NOT）。 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をユーザーIDまたはユーザーアドレスとして使用してはなりません（MUST NOT）応用。 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は個人を特定できる情報であるため、IETFプロトコルでIMEI URNを使用するには、プライバシーの懸念に適切に対処するために、仕様と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]の番号付け、アドレス指定、および識別に関する3GPPの作業、およびRFC 4122 [12]で使用されるスタイルと構造に重点を置いています。著者は、カレン・ジェニングス、リサ・デュッソー、デール・ウォーリー、イヴォ・セドラセク、アトル・モンラド、ジェームズ・ユー、メアリー・バーンズ、ティム・ブレイ、S。 Leiba、およびStephen Farrellの協力とコメント。
[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、「Uniform Resource Names（URN）Namespace Definition Mechanisms」、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/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>.
[3] GSM Association、「IMEI Allocation and Approval Guidelines」、PRD TS.06（DG06）Version 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] Moats、R。、「URN構文」、RFC 2141、1997年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、「International Mobile Station Equipment Identities（IMEI）」、3GPP TS 22.016（Release 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] アレン、A。、編、「International Mobile Station Equipment Identity（IMEI）のUniform Resource Name（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、「Managing Client-Initiated Connections in the Session Initiation Protocol（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、「A Universally Unique Identifier（UUID）URN Namespace」、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：Session Initiation Protocol」、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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Michael Montemurro (editor) Blackberry 4701 Tahoe Dr. Mississauga, Ontario L4W 0B4 Canada
Michael Montemurro（編集者）Blackberry 4701 Tahoe Dr.ミシサガオンタリオ州L4W 0B4カナダ
EMail: mmontemurro@blackberry.com
Andrew Allen Blackberry 1200 Sawgrass Corporate Parkway Sunrise, Florida 33323 USA
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
ポールゴスデンGSMアソシエーション1階、ミッドシティプレイス、71 High Holborn London England
EMail: pgosden@gsma.com