[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 RFC 7254

Network Working Group                                 M. Montemurro, Ed.
Internet-Draft                                                  A. Allen
Intended status: Experimental                   Research in Motion (RIM)
Expires: April 16, 2007                                      D. McDonald
                                                         GSM Association
                                                        October 13, 2006


A Uniform Resource Name Namespace For The GSM Association (GSMA) and the
         International Mobile station Equipment Identity(IMEI)
                   draft-montemurro-gsma-imei-urn-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This specification defines a Uniform Resource Name namespace for the
   GSMA and sub namespaces for the IMEI (International Mobile station
   Equipment Identity), and for the IMEISV (International Mobile station
   Equipment Identity and Software Version number).  The IMEI is 15
   decimal digits long and the IMEISV is 16 decimal digits long and are



Montemurro, et al.       Expires April 16, 2007                 [Page 1]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   both encoded using Binary Encoded Decimal (BCD).  The IMEI and IMEISV
   were introduced as part of the specification for Global System for
   Mobile (GSM) and are also now incorporated by the 3rd Generation
   Partnership Project (3GPP) as part of the 3GPP specification for GSM,
   and the Universal Mobile Telecommunications System (UMTS).  The IMEI
   and IMEISV are used to uniquely identify Mobile Equipment within
   these systems and are managed by the GSMA (GSM Association).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4

   4.  Namespace Registration Templates . . . . . . . . . . . . . . .  5
     4.1.  GSMA . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  IMEI . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  IMEISV . . . . . . . . . . . . . . . . . . . . . . . . . .  9

   5.  Specification  . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  IMEI Format  . . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.1.  Type Allocation Code (TAC) . . . . . . . . . . . . . . 11
       5.1.2.  Serial Number (SNR)  . . . . . . . . . . . . . . . . . 11
       5.1.3.  Spare  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  IMEISV Format  . . . . . . . . . . . . . . . . . . . . . . 11
       5.2.1.  Type Allocation Code (TAC) . . . . . . . . . . . . . . 12
       5.2.2.  Serial Number (SNR)  . . . . . . . . . . . . . . . . . 12
       5.2.3.  Software Version Number (SVN)  . . . . . . . . . . . . 12

   6.  Security considerations  . . . . . . . . . . . . . . . . . . . 12

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 13

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15









Montemurro, et al.       Expires April 16, 2007                 [Page 2]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


1.  Introduction

   This specification defines a Uniform Resource Name namespace for the
   IMEI (International Mobile station Equipment Identity), and for the
   IMEISV (International Mobile station Equipment Identity and Software
   Version number.  The IMEI and the IMEISV are managed by the GSMA, so
   the namespaces would be managed by the GSMA.  Whilst this
   specification currently specifies only the IMEI and IMEISV sub
   namespaces under the GSMA URN namespace additional sub namespaces
   under the GSMA namespace may be specified in the future by the GSMA.

   The IMEI is 15 decimal digits long and includes a Type Allocation
   Code (TAC) of 8 decimal digits and the 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 security check to combat
   potential spoofing 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 IMEI is specified to be stored in a tamper proof fashion so that
   it cannot be overwritten or otherwise reprogrammed by software.

   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 TS 23.003 [1] that defines the IMEI and
   IMEISV.

   The GSM Association (GSMA) is a global trade association representing
   more than 690 GSM mobile phone operators across 214 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 PRD TW.06 [2]


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Montemurro, et al.       Expires April 16, 2007                 [Page 3]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   document are to be interpreted as described in [3].


3.  Motivation

   One of the main reasons for the IMEI is to be able to take measures
   against the use of stolen equipment or against equipment that is
   malfunctioning and causing operational problems for the network.

   The theft of mobile phones has become a significant problem in many
   countries and often involves the use of violence and intimidation
   which is frequently perpetrated against children.  The ability of the
   network to identify that a stolen mobile is being used and identify
   the subscription that is using it or to prevent its use should help
   to reduce these problems.

   The potential for damage by malfunctioning mobiles is also of
   increasing concern.  In earlier times when there was a limited well
   specified set of features and services that were defined for Mobile
   Equipment it was possible to define and conduct rigorous conformance
   testing of the Mobile Equipment to ensure its appropriateness for use
   on the Cellular network.  Now however as the networks and services
   are becoming much more complex, varied and feature rich with the
   associated drive for rapid deployment of new services leveraging the
   great flexibility provided by Internet Protocols this kind of
   rigourous conformance testing of every service, application and
   capability is becoming no longer viable.  As a result it is more
   likely that Mobile Equipment commercially deployed in the networks in
   future will not always exhibit the correct behaviors under all
   circumstances.  Sometimes this may result in more than just
   dissatisfaction for a particular mobile user but could potentially
   result in an unintended Denial of Service (DoS) attack on the network
   that could potentially impact thousands of other users.  The use of
   the IMEISV is additionally helpful in this respect as it allows
   specific problematic software versions of Mobile Equipment to be
   identified so that appropriate defensive or corrective action can be
   taken.

   There is also increasing concern that the increasingly disturbing
   phenomenon of malware such as viruses and other trojans will rapidly
   spread to Mobile Equipment.  This equipment has become more computer
   like through the increasing use of smartphones and PDAs with
   standardized Operating Systems.  Such devices support for
   downloadable installable applications and the communication potential
   through peer to peer IP to deliver these programs from one Mobile
   Phone to another.  There is a real concern that once the appearance
   of malware viruses on Mobile Equipment becomes common that
   coordinated DoS attacks could be conducted against Mobile Networks by



Montemurro, et al.       Expires April 16, 2007                 [Page 4]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   possibly millions of mobile phones.  Since the bandwidth capabilities
   of Cellular Networks are an order of magnitude lower than those of
   broadband access networks it is potentially much easier to congest a
   cellular network through a coordinated attack than the fixed network.
   These networks are also already relied upon for Emergency Services so
   the consequences of widespread network failure through coordinated
   Mobile Phone virus DoS attack are potentially much more severe.  The
   IMEI can play a significant role in identifying Mobile Equipment that
   is known to be infected with viruses and to prevent its use and limit
   potential damage to the operation of the network and the Mobile
   Equipment of other users.  Likewise the IMEISV can help identify
   Mobile Equipment running software versions vulnerable to attack by
   such malware.

   Currently GSM and UMTS network lower layers provide the ability to
   transport the IMEI and IMEISV between the Mobile Equipment and the
   network.  However these networks are now transitioning to IP Core
   Networks such as the 3GPP IP Multimedia Subssytem (IMS) where the
   cellular access network signaling is becoming decoupled from the IP
   based network and applications such that it is becoming more
   difficult for the session and application layers to obtain the IMEI
   and IMEISV of the Mobile Equipment involved in the session or
   accessing the application or server.  Also access for Mobile
   Equipment to these networks is now being extended via non cellular
   access technologies such as WLAN and Bluetooth and various broadband
   technologies that do not provide any transport layer support for the
   IMEI or IMEISV.  It is therefore necessary that support for transport
   of these identifiers by IP protocols be provided by defining URNs for
   them.


4.  Namespace Registration Templates

4.1.  GSMA

   Namespace ID:  "urn:gsma" requested

   Registration Information:

   Registration date:  2006-10-11

   Declared registrant of the namespace:  GSMA.

   Declaration of syntactic structure:


   GSMA is an identifier for a namespace for identifiers used by Mobile
   Equipment used in GSM and UMTS networks.



Montemurro, et al.       Expires April 16, 2007                 [Page 5]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   The identifier has a hierarchical structure as follows:
   urn:gsma:imei/imeisv/ <gsma-specifier>[: <gsma-specifier defined
   string>]+
      + denotes one or more occurrences of gsma-specifier defined
      strings all delimited by a colon."

   The GSMA namespace includes two predefined namespaces IMEI and IMEISV
   and may be in the future extended to include other identifiers used
   by Mobile Equipment used in GSM and UMTS networks or future networks
   deployed by members of the GSMA.

   For example:
   urn:gsma:imei:90420156-025763-0
   urn:gsma:imeisv:90420156-025763-42

   The <gsma-specifier> and <gsma-specifier> defined string can comprise
   any UTF-8 characters compliant with URI syntax and must not contain
   the ":" character (see STD 66, RFC 3986 [xref target="RFC3986"]).
   The exclusion of the colon from the list of other characters means
   that the colon can only occur as a delimiter between string values.

   The GSMA will take responsibility for the gsma-specifier "imei" and
   "imeisv".

   The GSMA will take responsibility to assign other gsma-specifiers and
   manage the sub level and its applicable gsma-specifier defined
   string(s).

   Relevant ancillary documentation:  None.

   Identifier uniqueness considerations:  Identifiers in the "gsma"
      namespace are defined and assigned in the requested namespace by
      the GSMA after ensuring that the URNs to be assigned are unique.
      Uniqueness is achieved by checking against the registry of
      previously assigned names.

   Identifier persistence considerations:


   The GSMA is committed to maintaining uniqueness and persistence of
   all resources identified by assigned URNs.

   As the URN 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 April 16, 2007                 [Page 6]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   Process of identifier assignment:


   GSMA will manage the <gsma-specifier> and <gsma-defined string>
   including "imei" and "imeisv" identifier resources to maintain
   uniqueness.

   The process of assigning additional URNs at the <gsma-specifier> sub-
   level will be managed by the GSMA.

   Process for identifier resolution:   Since the GSMA namespace is not
      globally resolvable, this is not applicable.

   Rules for Lexical Equivalence:


   The lexical equivalence of the GSMA namespace-specific strings (NSSs)
   is defined as an exact, but not case-sensitive, string match.

   Any identifier in GSMA namespaces can be compared using the normal
   mechanisms for percent-encoded UTF-8 strings.

   Conformance with URN Syntax:  The string representation of a IMEI is
      fully compatible with the URN syntax.

   Validation Mechanism:  None

   Scope:  GSMA URN is global in scope.


4.2.  IMEI

   Namespace ID:  "urn:gsma:imei" requested.

   Registration Information:

   Registration date:  2006-10-11

   Declared registrant of the namespace:  GSMA.

   Declaration of syntactic structure:  .


   A IMEI is an identifier under the GSMA namespace that uniquely
   identifies Mobile Equipment used in GSM and UMTS networks.

   The internal representation of a IMEI is a specific sequence of bits
   in memory, as described in 3GPP TS 23.003 [1].  To accurately



Montemurro, et al.       Expires April 16, 2007                 [Page 7]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   represent a IMEI as a URN, it is necessary to convert the BCD bit
   sequence to a string representation.

   Each field BCD bit sequence has its value printed as a decimal digit
   string with the most significant digit first.

   The formal definition of the IMEISV string representation is provided
   by the following ABNF [4]

   IMEI =  tac "-" snr "-" svn
   tac      = 8decDigit
   snr      = 6decDigit
   spare    = 1decDigit
   decDigit =  "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

   The following is an example of the string representation of a IMEI as
   a URN:

   urn:gsma:imei:90420156-025763-0

   Relevant ancillary documentation:  3GPP TS 23.003 [1] and GSMA PRD
      TW.06 [2]

   Identifier uniqueness considerations:  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.

   Identifier persistence considerations:  IMEIs are stored in the
      Mobile Equipment in a tamper proof non modifiable fashion so they
      remain persistent

   Process of identifier assignment:  The process for IMEI assignment is
      documented in GSMA PRD TW.06 [2].

   Process for identifier resolution:  Since IMEIs are not globally
      resolvable, this is not applicable.

   Rules for Lexical Equivalence:  Consider each field of the IMEISV to
      be a sequence of decimal digits.  Then, to compare a pair of
      IMEIs, arithmetically compare the corresponding fields from each
      IMEI in order of significance and according to their data type.
      Two IMEIs are equal if and only if all the corresponding fields
      are equal







Montemurro, et al.       Expires April 16, 2007                 [Page 8]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   Conformance with URN Syntax:  The string representation of a IMEI is
      fully compatible with the URN syntax.

   Validation mechanism:  The IMEI can be validated using the mechanism
      defined in Annex B of 3GPP TS 23.003 [1]

   Scope:  IMEIs are global in scope.


4.3.  IMEISV

   Namespace ID:  "urn:gsma:imeisv" requested

   Registration Information:

   Registration date:  2006-10-11

   Declared registrant of the namespace:  GSMA.

   Declaration of syntactic structure:


   A IMEISV is an identifier under the GSMA namespace that uniquely
   identifies Mobile Equipment and associated software versions used in
   GSM and UMTS networks.

   The internal representation of a IMEISV is a specific sequence of
   bits in memory, as described in 3GPP TS 23.003 [1].  To accurately
   represent a IMEISV as a URN, it is necessary to convert the BCD bit
   sequence to a string representation.

   Each field BCD bit sequence has its value printed as a decimal digit
   string with the most significant digit first.

   The formal definition of the IMEISV string representation is provided
   by the following ABNF [4]

   IMEISV =  tac "-" snr "-" svn
   tac      = 8decDigit
   snr      = 6decDigit
   svn      = 2decDigit
   decDigit =  "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

   The following is an example of the string representation of a IMEISV
   as a URN:






Montemurro, et al.       Expires April 16, 2007                 [Page 9]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   urn:gsma:imeisv:90420156-025763-42

   Relevant ancillary documentation:  3GPP TS 23.003 [1] and GSMA PRD
      TW.06 [2]

   Identifier uniqueness considerations:  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 TAC and SNR portions of
      IMEISVs are stored in the Mobile Equipment in a tamper proof non
      modifiable fashion so they remain persistent.  The SVN may be
      modified by software when new versions are installed but should be
      persistent for the duration of the installation of that specific
      version of software.

   Process of identifier assignment:  The process for IMEISV assignment
      is documented in GSMA PRD TW.06 [2].

   Process for identifier resolution:  Since IMEISVs are not globally
      resolvable, this is not applicable.

   Rules for Lexical Equivalence:  Consider each field of the IMEISV to
      be a sequence of decimal digits.  Then, to compare a pair of
      IMEISVs, arithmetically compare the corresponding fields from each
      IMEISV in order of significance and according to their data type.
      Two IMEISVs are equal if and only if all the corresponding fields
      are equal

   Conformance with URN Syntax:  The string representation of a IMEISV
      is fully compatible with the URN syntax.

   Validation mechanism:  The TAC and SNR fields of the IMEISV can be
      validated using the mechanism defined in Annex B of 3GPP TS 23.003
      [1].  There is no mechanism defined to validate the SVN field of
      the IMEISV.

   Scope:  IMEISVs are global in scope.



5.  Specification







Montemurro, et al.       Expires April 16, 2007                [Page 10]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


5.1.  IMEI Format

   The IMEI format is 15 decimal digits encoded in 8 octets using BCD as
   defined in 3GPP TS 24.008 [5].  The least significant digit is coded
   in the 1st 3 bits of octet 1.  The most significant digit is coded in
   the least significant bits of octet 8.  Last 4 digits of octet 8 are
   all 1's.

       1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  Decimal Digits
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               |           |S|
      |        T      |      S    |p|
      |        A      |      N    |a|
      |        C      |      R    |r|
      |               |           |e|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        1   2   3   4   5   6   7   8  Octets


5.1.1.  Type Allocation Code (TAC)

   The TAC is a 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.

5.1.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

5.1.3.  Spare

   The Spare is a single decimal digit that is used as a security check
   digit to combat potential spoofing.  The Spare is always set to zero
   when transmitted by the Mobile Equipment.  Annex B of 3GPP TS 23.003
   [1] defines a mechanism for computing the actual check digit in order
   to validate the TAC and SNR.

5.2.  IMEISV Format

   The IMEISV format is 16 decimal digits encoded in 8 octets using BCD
   as defined in 3GPP TS 24.008 [5].  The least significant digit is
   coded in the 1st 3 bits of octet 1.  The most significant digit is
   coded in the least significant bits of octet 8.






Montemurro, et al.       Expires April 16, 2007                [Page 11]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


       1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6  Decimal Digits
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               |           |   |
      |        T      |      S    | S |
      |        A      |      N    | V |
      |        C      |      R    | N |
      |               |           |   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        1   2   3   4   5   6   7   8   Octets


5.2.1.  Type Allocation Code (TAC)

   The TAC is the same as for the IMEI in Section 5.1.1.

5.2.2.  Serial Number (SNR)

   The SNR is the same as for the IMEI in Section 5.1.2.

5.2.3.  Software Version Number (SVN)

   The Software Version Number is allocated by the Mobile Equipment
   manufacturer to identify the software version of the Mobile
   Equipment.


6.  Security considerations

   IMEIs (with the Spare value set to zero) are displayable on most
   Mobile Equipment therefore they must not be used as security
   capabilities (identifiers whose mere possession grants access), for
   example.

   Care should be taken regarding use of the IMEISV as it could help a
   malicious device identify Mobile Equipment 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 as specified in RFC 3261
   [6].

   Additional security considerations are specified in 3GPP TS 22.016
   [7].


7.  Acknowledgements

   This document draws heavily on the 3GPP work on Numbering, Addressing
   and Identification in 3GPP TS 23.003 [1] and also on the style and
   structure used in RFC 4122 [8].



Montemurro, et al.       Expires April 16, 2007                [Page 12]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


8.  References

8.1.  Normative references

   [1]  3GPP, "TS 23.003: Numbering, addressing and identification
        (Release 7)", 3GPP 23.003, June 2006,
        <ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.

   [2]  GSMA Assocaition, "IMEI Allocation and Approval Guidelines",
        PRD TW.06 version 3.3.0, December 2004,
        <http://www.gsmworld.com/documents/twg/tw06.pdf>.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [5]  3GPP, "TS 24.008: Mobile radio interface Layer 3 specification;
        Core network protocols; Stage 3 (Release 7)", 3GPP 24.008,
        June 2006, <ftp://ftp.3gpp.org/Specs/archive/24_series/24.008/>.

8.2.  Informative references

   [6]  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.

   [7]  3GPP, "TS 22.016: International Mobile station Equipment
        Identities (IMEI)(Release 6)", 3GPP 22.016, January 2005,
        <ftp://ftp.3gpp.org/Specs/archive/22_series/22.016/>.

   [8]  Leach, P., Mealling, M., and R. Salz, "A Universally Unique
        IDentifier (UUID) URN Namespace", RFC 4122, July 2005.


Authors' Addresses

   Michael Montemurro (editor)
   Research in Motion (RIM)
   5090 Commerce Blvd
   Mississauga, Ontario  L4W 5W4
   Canada

   Phone: unlisted
   Fax:   unlisted
   Email: mmontemurro@rim.com




Montemurro, et al.       Expires April 16, 2007                [Page 13]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


   Andrew Allen
   Research in Motion (RIM)
   102 Decker Court, Suite 100
   Irving, Texas  75062
   USA

   Phone: unlisted
   Fax:   unlisted
   Email: aallen@rim.com


   David McDonald
   GSM Association
   Block 2, Deansgrange Business Park
   Deansgrange, Co. Dublin
   Ireland

   Phone: unlisted
   Fax:   unlisted
   Email: DMcDonald@gsm.org































Montemurro, et al.       Expires April 16, 2007                [Page 14]

Internet-Draft          The IMEI and IMEISV URNs            October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Montemurro, et al.       Expires April 16, 2007                [Page 15]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/