Internet DRAFT - draft-montemurro-gsma-imei-urn
draft-montemurro-gsma-imei-urn
Network Working Group M. Montemurro, Ed.
Internet-Draft A. Allen
Intended status: Informational Blackberry
Expires: August 30, 2014 D. McDonald
Eircom
P. Gosden
GSM Association
February 26, 2014
A Uniform Resource Name Namespace for the Global System for Mobile
communications Association (GSMA) and the International Mobile station
Equipment Identity (IMEI)
draft-montemurro-gsma-imei-urn-20
Abstract
This specification specifies a Uniform Resource Name namespace for
the GSMA (Global System for Mobile communications Association) and a
Namespace Specific String (NSS) for the IMEI (International Mobile
station Equipment Identity), and an associated parameter for the
IMEISV (International Mobile station Equipment Identity and Software
Version number). The IMEI and IMEISV were introduced as part of the
specification for Global System for Mobile communications (GSM) and
are also now incorporated by the 3rd Generation Partnership Project
(3GPP) as part of the 3GPP specification for GSM, the Universal
Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term
Evolution). 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 Identifying
Information and need to be treated accordingly.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2014.
Montemurro, et al. Expires August 30, 2014 [Page 1]
Internet-Draft The GSMA and IMEI URN February 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. Expires August 30, 2014 [Page 2]
Internet-Draft The GSMA and IMEI URN February 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Namespace Registration Template . . . . . . . . . . . . . . . 5
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. IMEI Parameters . . . . . . . . . . . . . . . . . . . . . 9
4.2. IMEI Format . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 10
4.2.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 10
4.2.3. Spare . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. Binary Encoding . . . . . . . . . . . . . . . . . . . 10
4.3. IMEISV Format . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 11
4.3.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 11
4.3.3. Software Version Number (SVN) . . . . . . . . . . . . 11
4.3.4. Binary Encoding . . . . . . . . . . . . . . . . . . . 11
5. Community considerations . . . . . . . . . . . . . . . . . . . 12
6. Namespace considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security and privacy considerations . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative references . . . . . . . . . . . . . . . . . . . 14
10.2. Informative references . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Montemurro, et al. Expires August 30, 2014 [Page 3]
Internet-Draft The GSMA and IMEI URN February 2014
1. Introduction
This specification specifies a Uniform Resource Name (URN) namespace
for the GSMA (GSM Association) and a NSS for the IMEI (International
Mobile station Equipment Identity), and associated parameter for the
Software Version number from the IMEISV (International Mobile station
Equipment Identity and Software Version number) as per the namespace
registration requirement found in RFC 3406 [1]. The NID (Namespace
Identifier) 'gsma' is for identities used in GSM, UMTS and LTE
networks. The IMEI and the IMEISV are managed by the GSMA, so this
NID is managed by the GSMA. Whilst this specification currently
specifies 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
conensus).
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 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 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]
that specifies the IMEI and IMEISV.
The GSM Association (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
mobile phones and wireless services work globally and are easily
accessible. Further details about the GSMA role in allocating the
IMEI and the IMEISV and the IMEI and IMEISV allocation guidelines can
be found in GSMA Permanent Reference Document (PRD) TS 06 [3].
Montemurro, et al. Expires August 30, 2014 [Page 4]
Internet-Draft The GSMA and IMEI URN February 2014
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' requested
Registration Information:
Registration version number: 1
Registration date: 2014-01-12
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:
Montemurro, et al. Expires August 30, 2014 [Page 5]
Internet-Draft The GSMA and IMEI URN February 2014
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 and
;IETF consensus
;required
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
/ "-" / "." / "_" / "%" / ":"
A 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 augmented Backus-Naur Form (ABNF) includes the set
of core rules in RFC 5234 [5], and are not repeated here.
Montemurro, et al. Expires August 30, 2014 [Page 6]
Internet-Draft The GSMA and IMEI URN February 2014
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
The <future-gsma-specifier>, and <gsma-defined-nonempty> can
comprise any ASCII characters compliant with the above ABNF.
The GSMA will take responsibility for the NSS 'imei'.
Additional NSS may be added for future identifiers needed by the
GSMA using the procedure for URN NSS changes and additions
(currently through the publication of future Informational RFCs
approved by IETF consensus).
Relevant ancillary documentation:
See IMEI Allocation and Approval Guidelines [3] and 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.
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.
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
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.
Montemurro, et al. Expires August 30, 2014 [Page 7]
Internet-Draft The GSMA and IMEI URN February 2014
The TAC and SNR portions of the IMEI and IMEISVs 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 the TAC and SNR
values once assigned are not re-assigned to other Mobile
Equipment. 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:
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]
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 '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: GSMA URN is global in scope.
Montemurro, et al. Expires August 30, 2014 [Page 8]
Internet-Draft The GSMA and IMEI URN February 2014
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 specified here requires the use of the
procedure for URN NSS changes and additions (currently the
publication of a future Informational RFCs approved by IETF
consensus). The reason why use of the 'vers' parameter was chosen
for extensibility instead of defining a new NSS (e.g. 'imei2') is
that 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.
draft-allen-dispatch-imei-urn-as-instanceid-13 [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 equal to 0
or the definition of additional parameters that are intended to be
used as part of an instance ID will require an update to
draft-allen-dispatch-imei-urn-as-instanceid-13 [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:
Montemurro, et al. Expires August 30, 2014 [Page 9]
Internet-Draft The GSMA and IMEI URN February 2014
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 within the TAC.
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].
Montemurro, et al. Expires August 30, 2014 [Page 10]
Internet-Draft The GSMA and IMEI URN February 2014
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 in Section 4.2.1.
4.3.2. Serial Number (SNR)
The SNR is the same as the SNR in the IMEI in 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].
Montemurro, et al. Expires August 30, 2014 [Page 11]
Internet-Draft The GSMA and IMEI URN February 2014
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 URN's 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 needs 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.
Montemurro, et al. Expires August 30, 2014 [Page 12]
Internet-Draft The GSMA and IMEI URN February 2014
7. IANA considerations
In accordance with BCP 66 (RFC 3406) [1], IANA is asked to register
the Formal URN Namespace 'gsma' in the Registry of URN Namespaces,
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). Unfortuantely
there are currently examples of some applications which are using the
IMEI for authorisation. 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.
Whilst 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.
Therfore 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 is a similar concern to the use of the User-Agent header in SIP
(Session Initiation Protocol) 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 as 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 allow the new device owner to
Montemurro, et al. Expires August 30, 2014 [Page 13]
Internet-Draft The GSMA and IMEI URN February 2014
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 survellience 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 in order to ensure that the privacy concerns are appropriately
addressed. Protocols carrying the IMEI URN SHOULD at a minimum use
strongly hop-by-hop encrypted channels and that it is RECOMMENDED
that end-to-end encryption is used
Additional security considerations are specified in 3GPP TS 22.016
[9]. Specifically the IMEI is to be incorporated in a module which
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).
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, "TS 23.003: Numbering, addressing and identification
(Release 8)", 3GPP 23.003, September 2012,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
[3] GSMA 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/
Montemurro, et al. Expires August 30, 2014 [Page 14]
Internet-Draft The GSMA and IMEI URN February 2014
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, "TS 24.008: Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3 (Release 8)", 3GPP 24.008,
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, "TS 22.016: International Mobile station Equipment
Identities (IMEI) (Release 8)", 3GPP 22.016, December 2009,
<ftp://ftp.3gpp.org/Specs/archive/22_series/22.016/>.
10.2. Informative references
[10] Allen, A., "Using the International Mobile station Equipment
Identity(IMEI) URN as an Instance ID, work in progress",
Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-13,
February 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.
Montemurro, et al. Expires August 30, 2014 [Page 15]
Internet-Draft The GSMA and IMEI URN February 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. Expires August 30, 2014 [Page 16]
