idnits 2.17.1 draft-montemurro-gsma-imei-urn-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 25 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Additional security considerations are specified in 3GPP TS 22.016 [7]. 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). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2011) is 4669 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3406 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Montemurro, Ed. 3 Internet-Draft A. Allen 4 Intended status: Informational Research in Motion (RIM) 5 Expires: January 9, 2012 D. McDonald 6 unaffiliated 7 P. Gosden 8 GSM Association 9 July 8, 2011 11 A Uniform Resource Name Namespace for the GSM Association (GSMA) and the 12 International Mobile station Equipment Identity (IMEI) 13 draft-montemurro-gsma-imei-urn-08 15 Abstract 17 This specification defines a Uniform Resource Name namespace for the 18 GSMA and a sub namespace for the IMEI (International Mobile station 19 Equipment Identity), and associated parameter for the IMEISV 20 (International Mobile station Equipment Identity and Software Version 21 number). The IMEI is 15 decimal digits long and the IMEISV is 16 22 decimal digits long and both are encoded using Binary Encoded Decimal 23 (BCD). The IMEI and IMEISV were introduced as part of the 24 specification for Global System for Mobile (GSM) and are also now 25 incorporated by the 3rd Generation Partnership Project (3GPP) as part 26 of the 3GPP specification for GSM, the Universal Mobile 27 Telecommunications System (UMTS) and 3GPP LTE (Long Term Evolution). 28 The IMEI and IMEISV are used to uniquely identify Mobile Equipment 29 within these systems and are managed by the GSMA (GSM Association). 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 9, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Namespace Registration Template . . . . . . . . . . . . . . . 5 81 3.1. GSMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.1. IMEI Format . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.1.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 9 86 4.1.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 9 87 4.1.3. Spare . . . . . . . . . . . . . . . . . . . . . . . . 9 88 4.2. IMEISV Format . . . . . . . . . . . . . . . . . . . . . . 10 89 4.2.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 10 90 4.2.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 10 91 4.2.3. Software Version Number (SVN) . . . . . . . . . . . . 10 93 5. Community considerations . . . . . . . . . . . . . . . . . . . 10 95 6. Namespace considerations . . . . . . . . . . . . . . . . . . . 11 97 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 99 8. Security considerations . . . . . . . . . . . . . . . . . . . 11 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 104 10.1. Normative references . . . . . . . . . . . . . . . . . . . 12 105 10.2. Informative references . . . . . . . . . . . . . . . . . . 12 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 109 1. Introduction 111 This specification defines a Uniform Resource Name namespace for the 112 GSMA (GSM Association) and a sub namespace for the IMEI 113 (International Mobile station Equipment Identity), and associated 114 parameter for the Software Version number from the IMEISV 115 (International Mobile station Equipment Identity and Software Version 116 number) as per the namespace registration requirement found in [1]. 117 GSMA is an identifier for a namespace for identities used by Mobile 118 Equipment used in GSM, UMTS and LTE networks. The IMEI and the 119 IMEISV are managed by the GSMA, so this namespace would be managed by 120 the GSMA. Whilst this specification currently specifies only the 121 IMEI sub namespace under the GSMA URN namespace additional sub 122 namespaces under the GSMA namespace may be specified in the future by 123 the GSMA through the publication of future informational RFCs. 125 The IMEI is 15 decimal digits long and includes a Type Allocation 126 Code (TAC) of 8 decimal digits and the Serial Number (SNR) of 6 127 decimal digits plus a Spare decimal digit. The TAC identifies the 128 type of the Mobile Equipment and is chosen from a range of values 129 allocated to the Mobile Equipment manufacturer in order to uniquely 130 identify the model of the Mobile Equipment. The SNR is an individual 131 serial number that uniquely identifies each Mobile Equipment within 132 the TAC. The Spare digit is used as a security check to combat 133 potential spoofing and is always set to the value 0 when transmitted 134 by the Mobile Equipment. 136 The IMEISV is 16 decimal digits long and includes the TAC and SNR 137 same as for the IMEI but also a 2 decimal digit Software Version 138 Number (SVN) which is allocated by the Mobile Equipment manufacturer 139 to identify the software version of the Mobile Equipment. 141 The information here is meant to be a concise guide for those wishing 142 to use the IMEI and IMEISV as URNs. Nothing in this document should 143 be construed to override 3GPP TS 23.003 [2] that defines the IMEI and 144 IMEISV. 146 The GSM Association (GSMA) is a global trade association representing 147 more than 750 GSM mobile phone operators across 218 territories and 148 countries of the world. The primary goals of the GSMA are to ensure 149 mobile phones and wireless services work globally and are easily 150 accessible. Further details about the GSMA role in allocating the 151 IMEI and the IMEISV and the IMEI and IMEISV allocation guidelines can 152 be found in GSMA PRD DG.06 [3] 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [4]. 160 3. Namespace Registration Template 162 3.1. GSMA 164 Namespace ID: "gsma" requested 166 Registration Information: 168 Registration version number: 1 170 Registration date: 2011-07-08 172 Declared registrant of the namespace: GSM Association, 1st Floor, 173 Mid City Place, 71 High Holborn, London, England 175 Declaration of syntactic structure: 176 The identifier is expressed in ASCII characters and has a 177 hierarchical structure expressed using the augmented Backus-Naur 178 Form (ABNF) defined in [8] as follows: 180 gsma-urn = "urn:gsma:" gsma-specifier 181 *(":" gsma-specifier-defined-substring) 182 *(";" gsma-specifier-param) 184 gsma-specifier = "imei" / gsma-specifier-defined-string 185 gsma-specifier-defined-string = gsma-approved-nonempty-string 186 gsma-specifier-defined-substring = gsma-approved-nonempty-string 187 gsma-specifier-defined-param-name = gsma-approved-nonempty-string 188 gsma-specifier-defined-param-val = gsma-approved-string 189 gsma-specifier-param = 190 "svn" "=" software-version-string / 191 "vers" "=" gsma-format-version-string / 192 gsma-specifier-defined-param-name *1("=" gsma-specifier-defined-param-val) 193 software-version-string = 2DIGIT 194 gsma-format-version-string = DIGIT 195 gsma-approved-string = *unreserved 196 gsma-approved-nonempty-string = 1*unreserved 197 unreserved = ALPHA / DIGIT / "-" / "." / "_" 199 The GSMA namespace includes a predefined namespace for IMEI and 200 may be in the future extended to include other identifiers used by 201 Mobile Equipment used in GSM, UMTS or LTE networks or future 202 networks deployed by members of the GSMA. 204 A IMEI is an identifier under the GSMA namespace that uniquely 205 identifies Mobile Equipment used in GSM, UMTS and LTE networks. 207 The internal representation of a IMEI is a specific sequence of 208 bits in memory, as described in 3GPP TS 23.003 [2]. To accurately 209 represent a IMEI as a URN, it is necessary to convert the BCD bit 210 sequence to a string representation. Each field BCD bit sequence 211 has its value printed as a decimal digit string with the most 212 significant digit first. 214 The following augmented Backus-Naur Form (ABNF) includes the set 215 of core rules in RFC 5234 [8], and are not repeated here. 217 The formal definition of the IMEI string representation for the 218 gsma-specifier-defined-substring for the "imei" gsma-specifier is 219 provided by the following ABNF [8]: 221 IMEI = tac "-" snr "-" spare 222 tac = 8DIGIT 223 snr = 6DIGIT 224 spare = 1DIGIT 225 For example: 226 urn:gsma:imei:90420156-025763-0;vers=0 228 The optional "vers" parameter is included for extensibility of the 229 namespace, for example if the IMEI format is extended in the 230 future (such as with additional digits or using hex digits). A 231 value of "vers" equal to 0 or the absence of the "vers" parameter 232 means the URN format is compliant with the format specified here. 233 Any change to the format specified here requires the publication 234 of a future informational RFC. 236 The IMEISV is an identifier that uniquely identifies Mobile 237 Equipment and associated software versions used in GSM and UMTS 238 networks. The internal representation of a IMEISV is a specific 239 sequence of bits in memory, as described in 3GPP TS 23.003 [2] 240 To represent the IMEISV the URN parameter "svn" is appended to the 241 IMEI URN and set equal to the decimal string representation of the 242 two software version number (svn) bits in the IMEISV and the spare 243 digit in the IMEI gsma-specifier-defined-substring is set to zero. 245 For example: 246 urn:gsma:imei:90420156-025763-0;svn=42 248 The , , , 250 and can comprise any ASCII 251 characters compliant with URN syntax and must not contain the ":" 252 character or ";" character or "=" character(see STD 66, RFC 2141 253 [5]). The exclusion of the colon from the list of other 254 characters means that the colon can only occur as a delimiter 255 between string values. The exclusion of the semicolon from the 256 list of other characters means that the semicolon can only occur 257 as a delimiter for parameter values. The exclusion of the "=" 258 character from the list of other characters means that the "=" 259 character can only occur as an operator for parameter values. 261 The GSMA will take responsibility for the gsma-specifier "imei" 262 and manage the sub level. 264 Additional gsma-specifiers may be added in the future through 265 informational RFCs. 267 Relevant ancillary documentation: 268 See IMEI Allocation and Approval Guidelines [3] and 3GPP TS 23.003 269 [2]. 271 Identifier uniqueness considerations: 272 Identifiers in the "gsma" namespace are defined and assigned in 273 the requested namespace by the GSMA after ensuring that the URNs 274 to be assigned are unique. Uniqueness is achieved by checking 275 against the registry of previously assigned names. 277 Procedures are in place to ensure that each IMEI is uniquely 278 assigned by the Mobile Equipment manufacturer so that it is 279 guaranteed to uniquely identify that particular Mobile Equipment. 280 Procedures are in place to ensure that each IMEISV is uniquely 281 assigned by the Mobile Equipment manufacturer so that it is 282 guaranteed to uniquely identify that particular Mobile Equipment 283 and the specific software version installed. 285 Identifier persistence considerations: 286 The GSMA is committed to maintaining uniqueness and persistence of 287 all resources identified by assigned URNs. 289 As the NID sought is "gsma" and GSMA is the long standing acronym 290 for the trade association that represents the mobile phone 291 operators the URN should also persist indefinitely (at least as 292 long as there is a need for its use). The assignment process 293 guarantees that names are not reassigned. The binding between the 294 name and its resource is permanent. 296 The TAC and SNR portions of IMEISVs are stored in the Mobile 297 Equipment so they remain persistent. The SVN may be modified by 298 software when new versions are installed but should be persistent 299 for the duration of the installation of that specific version of 300 software. 302 Process of identifier assignment: 303 GSMA will manage the (including "imei"), , , , and identifier resources to maintain 307 uniqueness. 309 The process for IMEI and IMEISV assignment is documented in GSMA 310 PRD DG.06[3] 312 Process for identifier resolution: 313 Since the GSMA namespace is not globally resolvable, this is not 314 applicable. 316 Rules for Lexical Equivalence: 317 Consider each field of the IMEI gsma-defined substring to be a 318 sequence of decimial digits. Then, to compare a pair of IMEIs, 319 arithmetically compare the corresponding fields of the gsma- 320 defined substring from each IMEI in order of significance and 321 according to their data type. Two IMEIs are equal if and only if 322 all the corresponding fields are equal. 324 The lexical equivalence of the GSMA namespace-specific strings 325 (NSSs) is defined as an exact, but not case-sensitive, string 326 match. 328 Any identifier in GSMA namespaces can be compared using the normal 329 mechanisms for percent-encoded UTF-8 strings. 331 Conformance with URN Syntax: 333 The string representation of the GSMA URN and of the IMEI sub 334 namespace is fully compatible with the URN syntax. 336 Validation Mechanism: 337 The IMEI can be validated using the mechanism defined in Annex B 338 of 3GPP TS 23.003 [2]. There is no mechanism defined to validate 339 the SVN field of the IMEISV. 341 Scope: GSMA URN is global in scope. 343 4. Specification 345 4.1. IMEI Format 347 The IMEI format is 15 decimal digits encoded in 8 octets using BCD as 348 defined in 3GPP TS 24.008 [6]. The most significant digit is coded 349 in the most significant bits of octet 1. The least significant digit 350 is coded in the least significant bits of octet 8. 352 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 353 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 354 | | | S| 355 | T | S | p| 356 | A | N | a| 357 | C | R | r| 358 | | | e| 359 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 360 1 2 3 4 5 6 7 8 Octets 362 4.1.1. Type Allocation Code (TAC) 364 The TAC is a 8 decimal digit value. The TAC identifies the type of 365 the Mobile Equipment and is chosen from a range of values allocated 366 to the Mobile Equipment manufacturer in order to uniquely identify 367 the model of the Mobile Equipment. 369 4.1.2. Serial Number (SNR) 371 The SNR is a 6 decimal digit value. The SNR is an individual serial 372 number that uniquely identifies each Mobile Equipment within the TAC. 374 4.1.3. Spare 376 The Spare is a single decimal digit that is used as a security check 377 digit to combat potential spoofing. The Spare is always set to zero 378 when transmitted by the Mobile Equipment. Annex B of 3GPP TS 23.003 379 [2] defines a mechanism for computing the actual check digit in order 380 to validate the TAC and SNR. 382 4.2. IMEISV Format 384 The IMEISV format is 16 decimal digits encoded in 8 octets using BCD 385 as defined in 3GPP TS 24.008 [6]. The most significant digit is 386 coded in the most significant bits of octet 1. The least significant 387 digit is coded in the least significant bits of octet 8. 389 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 390 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 391 | | | | 392 | T | S | S | 393 | A | N | V | 394 | C | R | N | 395 | | | | 396 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 397 1 2 3 4 5 6 7 8 Octets 399 4.2.1. Type Allocation Code (TAC) 401 The TAC is the same as for the IMEI in Section 5.1.1. 403 4.2.2. Serial Number (SNR) 405 The SNR is the same as for the IMEI in Section 5.1.2. 407 4.2.3. Software Version Number (SVN) 409 The Software Version Number is allocated by the Mobile Equipment 410 manufacturer to identify the software version of the Mobile 411 Equipment. 413 5. Community considerations 415 GSM, UMTS and LTE mobile devices will be interoperating with Internet 416 devices for a variety of voice and data services. To do this, they 417 need to make use of Internet protocols that will operate end to end 418 between devices in GSM/UMTS/LTE networks and those in the general 419 internet. Many of these protocols require the use of URN's as 420 identifiers. Within the GSM/UMTS/LTE networks, mobile devices are 421 identified by their IMEI and IMEISV. Internet users will need to be 422 able to receive and include the GSMA URN in various Internet protocol 423 elements to facilitate communication between pure internet based 424 devices and GSM/UMTS/LTE mobile devices. Thus the existence and 425 syntax of these namespaces needs to be available to the general 426 internet community and the namespace needs to be reserved with IANA 427 in order to guarantee uniqueness and prevent potential namespace 428 conflicts both within the internet and within GSM/UMTS/LTE networks. 430 6. Namespace considerations 432 A URN was considered the most appropriate URI to represent the IMEI 433 and IMEISV as these identifiers may be used and transported similarly 434 to the Universally Unique Identifier (UUID)which is defined as a URN 435 in [9]. Since specifications for protocols that are used to 436 transport device identifiers often require the device identifier to 437 be globally unique and in the URN format it is necessary that the URN 438 formats are defined to represent the IMEI and IMEISV. 440 7. IANA considerations 442 In accordance with BCP 66 [1], IANA is asked to register the Formal 443 URN Namespace 'GSMA' in the Registry of URN Namespaces, using the 444 registration template presented in Section 3 of this document. 446 8. Security considerations 448 IMEIs (with the Spare value set to zero) are displayable on most 449 Mobile Equipment; therefore, they must not be used as security 450 capabilities (identifiers whose mere possession grants access), for 451 example. 453 Revealing the specific software version of the terminal might make 454 the terminal more vulnerable to attacks against software that is 455 known to contain security holes. Care therefore should be taken 456 regarding use of the IMEISV as it could help a malicious device 457 identify Mobile Equipment running software that is known to be 458 vulnerable to certain attacks. This is a similar concern to the use 459 of the User-Agent header in SIP as specified in RFC 3261 [10]. It is 460 therefore RECOMMENDED that the IMEISV is not delivered to devices 461 that are not trusted. 463 Additional security considerations are specified in 3GPP TS 22.016 464 [7]. Specifically the IMEI is to be incorporated in a module which 465 is contained within the terminal. The IMEI SHALL not be changed 466 after the terminal's production process. It SHALL resist tampering, 467 i.e. manipulation and change, by any means (e.g. physical, electrical 468 and software). 470 9. Acknowledgements 472 This document draws heavily on the 3GPP work on Numbering, Addressing 473 and Identification in 3GPP TS 23.003 [2] and also on the style and 474 structure used in RFC 4122 [9]. The authors would like to thank 475 Cullen Jennings, Lisa Dusseault, Dale Worley, and Ivo Sedlacek for 476 their help and comments. 478 10. References 480 10.1. Normative references 482 [1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 483 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 484 BCP 66, RFC 3406, October 2002. 486 [2] 3GPP, "TS 23.003: Numbering, addressing and identification 487 (Release 8)", 3GPP 23.003, September 2008, 488 . 490 [3] GSMA Association, "IMEI Allocation and Approval Guidelines", 491 PRD DG.06 version 3.6, February 2008, 492 . 494 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 495 Levels", BCP 14, RFC 2119, March 1997. 497 [5] Moats, R., "URN Syntax", RFC 2141, May 1997. 499 [6] 3GPP, "TS 24.008: Mobile radio interface Layer 3 specification; 500 Core network protocols; Stage 3 (Release 8)", 3GPP 24.008, 501 September 2008, 502 . 504 [7] 3GPP, "TS 22.016: International Mobile station Equipment 505 Identities (IMEI)(Release 7)", 3GPP 22.016, May 2007, 506 . 508 10.2. Informative references 510 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 511 Specifications: ABNF", STD 68, RFC 5234, January 2008. 513 [9] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 514 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 516 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 517 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 518 Session Initiation Protocol", RFC 3261, June 2002. 520 Authors' Addresses 522 Michael Montemurro (editor) 523 Research in Motion (RIM) 524 4701 Tahoe Dr 525 Mississauga, Ontario L4W 0B4 526 Canada 528 Phone: unlisted 529 Fax: unlisted 530 Email: mmontemurro@rim.com 532 Andrew Allen 533 Research in Motion (RIM) 534 1200 Sawgrass Corporate Parkway 535 Sunrise, Florida 33323 536 USA 538 Phone: unlisted 539 Fax: unlisted 540 Email: aallen@rim.com 542 David McDonald 543 unaffiliated 545 Phone: unlisted 546 Fax: unlisted 547 Email: mcdonalddm@hotmail.com 549 Paul Gosden 550 GSM Association 551 1st Floor, Mid City Place, 71 High Holborn, 552 London 553 England 555 Phone: unlisted 556 Fax: unlisted 557 Email: pgosden@gsm.org