[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for GSMA IMEI urn draft review
4. Namespace Registration Templates
4.1. GSMA
Namespace ID: "urn:gsma" requested
Nit: the requested NID is "GSMA", not "URN:GSMA".
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 formatting in the section above is broken; it's very hard
to interpret with any precision. Please fix the formatting,
and allow for re-review.
WRT grammar syntaxes -- please be clear what the characters
are intended to mean. is "[ ]" optional, are "< >" productions,
etc.
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
Note that the UTF-8 characters that are complient with URI syntax
are, in fact, ASCII characters. Probably best to rephrase this so
as not to give the illusion that the URN supports UTF-8 8-bit
characters without encoding.
the ":" character (see STD 66, RFC 3986 [xref target="RFC3986"]).
NIT: Failed reference citationin the xml.
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
s/URN sought/NID sought/
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.
Hmm... You do not need to ask IANA for a sub-NID assignment. From the
documentation above, I understood GSMA was managing the sub-NID
assignments. This does not belong in this document.
Or, in the registration of GSMA as a NID, you are welcome
to specify further sub-NIDs, such as imei, without making
them "requests".
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.
The conditions above could/should be expressed more generally
in terms of the overall namespace ID request for GSMA.
4.3. IMEISV
Namespace ID: "urn:gsma:imeisv" requested
Same comment as above.
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.
Same comments as above.
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/>.
You do want to refer to the document defining URN NID registration
requirements, RFC3406.
And, in reviewing that, note the requirement for sections on
. Community Considerations
. Namespace Considerations
Thanks,
Leslie.
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 at 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 at rim.com
David McDonald
GSM Association
Block 2, Deansgrange Business Park
Deansgrange, Co. Dublin
Ireland
Phone: unlisted
Fax: unlisted
Email: DMcDonald at 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 at 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]
Michael Montemurro wrote:
We would like to solicit a review of the IMEI and IMEISV URN draft.
This work is
needed for equipment tracking in GSM systems and would be managed by the
GSM Association. You can find the draft at:
http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-00.txt
Thanks,
Mike