idnits 2.17.1 draft-wilde-sms-service-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 16, 2002) is 8135 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMS-CHAR' -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Wilde 3 Internet-Draft Swiss Federal Institute of 4 Expires: July 17, 2002 Technology 5 January 16, 2002 7 Registration of GSTN SMS Service Qualifier 8 draft-wilde-sms-service-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 17, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This memo describes the registration of the Short Message Service 40 (SMS) as a registered IANA service selector for Global Switched 41 Telephone Network (GSTN) numbers. SMS is not available for all GSTN 42 subscribers, but it has proven very popular with users of the Global 43 System for Mobile Communications (GSM), and has also been adapted to 44 other telephone network technologies such as the Integrated Services 45 Digital Network (ISDN). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1 What is GSM? . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2 What is SMS? . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2.1 SMS content . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2.2 SMS infrastructure . . . . . . . . . . . . . . . . . . . . 4 54 1.2.2.1 SMS Centers . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2.3 SMS Telematic Interworking . . . . . . . . . . . . . . . . 5 56 2. IANA registrations . . . . . . . . . . . . . . . . . . . . 6 57 2.1 IANA registration form for GSTN address service-selector 58 "SMS" . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.2 IANA registration form for GSTN address qualit-type1 60 keyword "SMSC" and value . . . . . . . . . . . . . . . . . 7 61 2.3 IANA registration form for GSTN address qualit-type1 62 keyword "PID" and value . . . . . . . . . . . . . . . . . 8 63 3. Security Considerations . . . . . . . . . . . . . . . . . 9 64 4. Change Log . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.1 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 11 66 Normative References . . . . . . . . . . . . . . . . . . . 11 67 Non-Normative References . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . 12 69 A. Where to send Comments . . . . . . . . . . . . . . . . . . 12 70 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12 71 Full Copyright Statement . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 76 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described in RFC 78 2119 [RFC2119]. 80 1.1 What is GSM? 82 GSM (Global System for Mobile Communications) is a digital mobile 83 phone standard which is used extensively in many parts of the world. 84 First named after its frequency band around 900 MHz, GSM-900 has 85 provided the basis for several other networks utilizing GSM 86 technology, in particular GSM networks operating in the frequency 87 bands around 1800 MHz and 1900 MHz. When referring to "GSM" in this 88 document, we mean any of these GSM-based networks that operate a 89 short message service. 91 1.2 What is SMS? 93 The Short Message Service [SMS] is an integral part of the GSM 94 network technology. It has been very successful and currently is a 95 major source of revenue for most GSM operators. SMS as a service is 96 so successful that other Global Switched Telephone Network (GSTN) 97 technologies have adapted it as well, in particular the Integrated 98 Services Digital Network (ISDN). Because of this development, this 99 memo uses the term "SMS client" to refer to user agents who are able 100 to send and/or receive SMS messages. 102 1.2.1 SMS content 104 GSM SMS messages are alphanumeric paging messages that can be sent to 105 and SMS clients. SMS messages have a maximum length of 160 106 characters (7-bit characters from the GSM character set [SMS-CHAR]), 107 or 140 octets. Other character sets (such as UCS-2 16-bit 108 characters, resulting in 80 character messages) MAY also be supported 109 [SMS-CHAR], but are defined as being OPTIONAL by the SMS 110 specification. 112 While the 160 character variety for SMS messages is by far the most 113 widely used one, there are numerous other content types for SMS 114 messages, such as small bitmaps ("operator logos") and simple formats 115 for musical notes ("ring tones"). However, these formats are 116 proprietary and are not considered in this memo. 118 SMS messages are very limited in length (140 octets), and the first 119 versions of the SMS specification did not specify any standardized 120 methods for concatenating SMS messages. As a consequence, several 121 proprietary methods were invented, but the current SMS specification 122 does specify message concatenation. In order to deal with this 123 situation, SMS clients composing messages SHOULD use the standard 124 concatenation method based on the header in the TP-User Data field as 125 specified in [SMS]. When sending a message to an SMS recipient whose 126 support for concatenated messages is unknown, the SMS client MAY opt 127 to use the backwards-compatible (text-based) concatenation method 128 defined in [SMS]. Proprietary concatenation methods SHOULD NOT be 129 used except in closed systems, where the capabilities of the 130 recipient(s) are always known. 132 1.2.2 SMS infrastructure 134 SMS messages can be transmitted over an SMS client's network 135 interface using the signalling channels of the underlying GSTN 136 infrastructure, so there is no delay for call setup. Alternatively, 137 SMS messages MAY be submitted through other front-ends (for example 138 such as Web services), which makes it possible for SMS clients to run 139 on computers which are not directly connected to a GSTN network 140 supporting SMS. 142 1.2.2.1 SMS Centers 144 SMS messages are stored by an entity called Short Message Service 145 Center (SMSC), and sent to the recipient when the subscriber connects 146 to the network. The number of a cooperative SMSC must be known to 147 the SMS sender (ie, the entity submitting the SMS message to a GSTN 148 infrastructure) when sending the message (usually, the SMSC's number 149 is configured in the SMS client and specific for the network operator 150 to which the sender has subscribed). In most situations, the SMSC 151 number is part of the sending SMS client's configuration. However, 152 in some special cases (such as when the SMS recipient only accepts 153 messages from a certain SMSC), it may be necessary to send the SMS 154 message over a specific SMSC. 156 Short messages can be mobile terminated (MT) or mobile originated 157 (MO). MT messages are the ones that arrive at SMS clients; MO 158 messages are sent by SMS clients. Networks may support either, both, 159 or none of these. For the purpose of this memo, it is important that 160 the sending SMS client is allowed to submit MO messages, and that the 161 receiver is allowed to receive MT messages. 163 The exact setup of message submission and delivery is not subject of 164 this memo, it may incorporate additional hops in addition to the pure 165 SMS transport. For example, the sending SMS client may use a Web 166 service to submit the SMS message, and the receiving SMS client may 167 be set up to forward the SMS to an email account. For the purpose of 168 this memo, it is important that the receiver can be addressed by a 169 GSTN number, and that the sender can submit an SMS message using this 170 number. 172 1.2.3 SMS Telematic Interworking 174 While in most cases SMS messages are exchanged between SMS clients, 175 the SMS specification also includes provisions for so-called 176 "Telematic Interworking". In this scenario, the SMS message 177 specifies a Protocol Identifier, which identifies the service to 178 which the SMS message has to be submitted. In effect, this 179 implements a gateway functionality in the SMSC. 181 Telematic Interworking supports a number of services from Fax through 182 Telex and Internet Email up to voice telephone, where the gateway is 183 expected to make a text-to-speech transformation. The set of 184 possible services is defined by the SMS specification [SMS], but 185 network operators are not required to support any of these services. 186 SMS clients SHOULD implement support for Telematic Interworking, 187 which among other things means that users must be able to set the 188 Protocol Identifier field of generated SMS messages. If clients 189 support Telematic Interworking, they MUST indicate to the user the 190 changed semantics of the receiver number (eg, if Fax is selected, the 191 receiver will be contacted via Fax rather than SMS). 193 In the following list the telematic devices (ie, the services that 194 can be addressed using the Telematic Interworking mechanism) defined 195 by the SMS specification are described. The abbreviations are not 196 taken from the SMS specification, but are introduced by this memo for 197 identifying the device type using an SMS service qualifier keyword. 199 "IMPL": In this case the device type is implicitly defined, either 200 because the SMS Center knows it, or because it can be concluded on 201 the basis of the address. 203 "TELEX": Telex device 205 "G3FAX": Group 3 telefax device 207 "G4FAX": Group 4 telefax device 209 "VOICE": Voice telephone (this requires conversion to speech, but 210 there is no mechanism to specify a language) 212 "ERMES": ERMES (European Radio Messaging System) 214 "NATPAG": National paging system (this does not specify a specific 215 paging systems but implies that the SMS center knows about a 216 particular national paging system) 218 "VIDEOTEX": Videotex 220 teletex: Teletex, either with an unspecified carrier or using PSPDN, 221 CSPDN, PSTN, or ISDN as carrier 223 "UCI": UCI (Universal Computer Interface) 225 reserved: 7 combinations are reserved which do not have a specified 226 meaning 228 "MH": Some message handling facility known to the SMS center (not 229 further specified) 231 x400: X.400-based message handling system 233 email: Internet electronic mail 235 specific: 7 combinations are defined to have a meaning specific to 236 each SMS center, their usage is based on mutual agreement between 237 SMS clients and the SMS center. 239 It is important to notice that some of the above devices require 240 additional information to be specified (in particular, the "Internet 241 electronic mail" format). The SMS specification defines the methods 242 how this has to be done (effectively by embedding the email 243 information into the SMS message's text). 245 2. IANA registrations 247 Based on the requirements defined in RFC 3191 [RFC3191], the IANA 248 registration forms for the "SMS" service-selector, and "SMSC" and 249 "PID" qualif-type1 elements are defined here. Syntax definitions are 250 given using the Augmented BNF for Syntax Specifications [RFC2234]. 252 2.1 IANA registration form for GSTN address service-selector "SMS" 254 To: IANA@iana.org 255 Subject: Registration of new values for the GSTN address 256 service-selector specifier "SMS" 258 service-selector name: SMS 260 Description of Use: SMS - specify that the GSTN address refers to a 261 GSTN subscriber who is capable of receiving messages using the GSM 262 Short Message Service (SMS). However, if a "PID" qualif-type1 263 element is present for this service selector, then the GSTN 264 address must be interpreted according to the rules for the "PID" 265 qualif-type1 element's value. 267 For a complete description refer to RFC 3191 and draft-wilde-sms- 268 service-01. 270 Security Considerations: See the Security Consideration section of 271 draft-wilde-sms-service-01. 273 Person & email address to contact for further information: 275 Erik Wilde 276 Swiss Federal Institute of Technology 277 ETH-Zentrum 278 8092 Zurich 279 Switzerland 280 tel:+41-1-6325132 281 fax:+41-1-6321035 282 mailto:ietf@dret.net 284 2.2 IANA registration form for GSTN address qualit-type1 keyword "SMSC" 285 and value 287 To: IANA@iana.org 288 Subject: Registration of new values for the GSTN address 289 qualif-type1 element "SMSC" 291 qualif-type1 "keyword" name: SMSC 293 qualif-type1 "value" ABNF definition: The ABNF definition for the 294 value of the SMSC keyword is taken from draft-allocchio-gstn-01 296 sub-addr = gstn-phone 297 gstn-phone = ( global-phone / local-phone ) 298 global-phone = "+" 1*( DIGIT / written-sep ) 299 local-phone = [ exit-code ] dial-number / exit-code [ dial-number ] 300 exit-code = phone-string 301 dial-number = phone-string 302 phone-string = 1*( DTMF / pause / tonewait / written-sep ) 303 DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" ) 304 pause = "p" 305 tonewait = "w" 306 written-sep = ( "-" / "." ) 308 Description of Use: SMSC - In some situations, it may be necessary to 309 guide the sender of an SMS message to send the message via a 310 certain Short Message Service Center (SMSC). If the SMSC qualif- 311 type1 element is present, an SMS client SHOULD try to send the 312 message first using the specified SMSC. If that fails, the SMS 313 client MAY try another SMSC (such as the default SMSC for that 314 client). 316 Further description is available in draft-wilde-sms-service-01 318 Use Restriction: The use of the "SMSC" qualif-type1 element is 319 restricted to the "SMS" service-selector, it has no meaning 320 outside the SMS service defined by the "SMS" service-selector. 322 Security Considerations: See the Security Consideration section of 323 draft-wilde-sms-service-01. 325 Person & email address to contact for further information: 327 Erik Wilde 328 Swiss Federal Institute of Technology 329 ETH-Zentrum 330 8092 Zurich 331 Switzerland 332 tel:+41-1-6325132 333 fax:+41-1-6321035 334 mailto:ietf@dret.net 336 2.3 IANA registration form for GSTN address qualit-type1 keyword "PID" 337 and value 339 To: IANA@iana.org 340 Subject: Registration of new values for the GSTN address 341 qualif-type1 element "PID" 343 qualif-type1 "keyword" name: PID 345 qualif-type1 "value" ABNF definition: ... 347 sub-addr = "IMPL" / "TELEX" / "G3FAX" / "G4FAX" / "VOICE" 348 / "ERMES" / "NATPAG" / "VIDEOTEX" / teletex / "UCI" 349 / reserved / "MH" / x400 / email / specific 350 teletex = "TELETEX-" 351 ( "UNSPEC" / "PSPDN" / "CSPDN" / "PSTN" / "ISDN" ) 352 x400 = "X400:" x400addr 353 email = "SMTP:" address 354 reserved = "RES" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 355 specific = "SPEC" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 357 The "x400addr" definition is taken from ... (I am still looking 358 for a reasonably agreed-upon textual representation of X.400 mail 359 addresses...). 361 The "address" definition is taken from RFC 2822 [RFC2822] and 362 specifies an address that may either be an individual mailbox, or 363 a group of mailboxes. 365 Description of Use: PID - The protocol identifier is used to specify 366 SMS Telematic Interworking by selecting a specific protocol to use 367 for delivery to the recipient. 369 Further description is available in draft-wilde-sms-service-01 371 Use Restriction: The use of the "PID" qualif-type1 element is 372 restricted to the "SMS" service-selector, it has no meaning 373 outside the SMS service defined by the "SMS" service-selector. 375 Security Considerations: See the Security Consideration section of 376 draft-wilde-sms-service-01. 378 Person & email address to contact for further information: 380 Erik Wilde 381 Swiss Federal Institute of Technology 382 ETH-Zentrum 383 8092 Zurich 384 Switzerland 385 tel:+41-1-6325132 386 fax:+41-1-6321035 387 mailto:ietf@dret.net 389 3. Security Considerations 391 SMS messages are transported without any provisions for privacy or 392 integrity, so SMS users should be aware of these inherent security 393 problems of SMS messages. Unlike electronic mail, where additional 394 mechanisms exist to layer security features on top of the 395 infrastructure, there currently is no such framework for SMS 396 messages. 398 SMS messages very often are delivered almost instantaneously (if the 399 receiving SMS client is on line), but there is no guarantee for when 400 SMS messages will be delivered. In particular, SMS messages between 401 different network operators sometimes take a long time to be 402 delivered (hours or even days) or are not delivered at all, so 403 applications SHOULD NOT make any assumptions about the reliability 404 and performance of SMS message transmission. 406 In most networks, sending SMS messages is not a free service. 407 Therefore, SMS clients MUST make sure that any action that incurs 408 costs is acknowledged by the end user, unless explicitly instructed 409 otherwise by the end user. If an SMS client has different ways of 410 submitting an SMS message (such as a Web service and a phone line), 411 then the end user MUST have a way to control which way is chosen. 413 SMS clients often are limited devices (typically mobile phones), and 414 the sending SMS client SHOULD NOT make any assumptions about the 415 receiving SMS client supporting any non-standard services, such as 416 proprietary message concatenation or proprietary content types. 417 However, if the sending SMS client has prior knowledge about the 418 receiving SMS client, then he MAY use this knowledge to compose non- 419 standard SMS messages. 421 There are certain special SMS messages defined in [SMS] that can be 422 used, for example, to turn on indicators on the phone display, or to 423 send data to certain communication ports (comparable to UDP ports) on 424 the device. Certain proprietary systems (for example, the Wireless 425 Application Protocol [WAP])define configuration messages that may be 426 used to reconfigure the devices remotely. Any SMS client SHOULD make 427 sure that malicious use of such messages is not possible, for example 428 by filtering out certain SMS User Data headers. Gateways that accept 429 SMS messages e.g. in e-mail messages or web forms and pass them on 430 to an SMSC SHOULD implement this kind of 'firewalling' approach as 431 well. 433 Because the narrow bandwidth of the SMS communications channel, there 434 should also be checks in place for excessively long concatenated 435 messages. As an example, it may take two minutes to transfer thirty 436 concatenated text messages. 438 Unchecked input from a user MUST NOT be used to populate any other 439 fields in a Short Message other than the User Data field (not 440 including the User Data Header field). All other parts, including 441 the User Data Header, of the Short Message should be generated by 442 trusted means. 444 4. Change Log 446 4.1 From -00 to -01 448 o Added a number of new security considerations 450 o Added the "PID" qualif-type1 keyword and the section about "SMS 451 Telematic Interworking" Section 1.2.3 453 Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs 456 to Indicate Requirement Levels", RFC 457 2119, March 1997. 459 [RFC2234] Crocker, D. and P. Overell, "Augmented 460 BNF for Syntax Specifications: ABNF", 461 RFC 2234, November 1997. 463 [RFC2822] Resnick, P., "Internet Message Format", 464 RFC 2822, April 2001. 466 [RFC3191] Allocchio, C., "Minimal GSTN address 467 format in Internet Mail", RFC 3191, 468 October 2001. 470 [SMS] European Telecommunications Standards 471 Institute, "ETSI TS 100 901 (GSM 03.40 472 version 7.3.0 Release 1998): Digital 473 Cellular Telecommunications System 474 (Phase 2+); Technical realization of 475 the Short Message Service (SMS); Point- 476 to-Point (PP)", November 1999, . 479 [SMS-CHAR] European Telecommunications Standards 480 Institute, "ETSI TS 100 901 (GSM 03.38 481 version 7.2.0 Release 1998): Digital 482 Cellular Telecommunications System 483 (Phase 2+); Alphabets and language- 484 specific information", July 1999, 485 . 488 [draft-allocchio-gstn] Allocchio, C., "Text string notation 489 for Dial Sequences and GSTN / E.164 490 addresses", draft-allocchio-gstn-01 491 (work in progress), November 2001. 493 [draft-wilde-sms-service-01] Wilde, E., "Registration of GSTN SMS 494 Service Qualifier", draft-wilde-sms- 495 service-01 (work in progress), January 496 2002. 498 Non-Normative References 500 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 501 June 1999. 503 [WAP] WAP Forum, "Wireless Application Protocol - Architecture 504 Specification (WAP-210-WAPArch-20010712)", July 2001. 506 Author's Address 508 Erik Wilde 509 Swiss Federal Institute of Technology 510 ETH-Zentrum 511 8092 Zurich 512 Switzerland 514 Phone: +41-1-6325132 515 EMail: ietf@dret.net 516 URI: http://dret.net/netdret/ 518 Appendix A. Where to send Comments 520 Please send all comments about this document to Erik Wilde. 522 Appendix B. Acknowledgements 524 This document has been written using the IETF document DTD described 525 in RFC 2629 [RFC2629]. 527 Full Copyright Statement 529 Copyright (C) The Internet Society (2002). All Rights Reserved. 531 This document and translations of it may be copied and furnished to 532 others, and derivative works that comment on or otherwise explain it 533 or assist in its implementation may be prepared, copied, published 534 and distributed, in whole or in part, without restriction of any 535 kind, provided that the above copyright notice and this paragraph are 536 included on all such copies and derivative works. However, this 537 document itself may not be modified in any way, such as by removing 538 the copyright notice or references to the Internet Society or other 539 Internet organizations, except as needed for the purpose of 540 developing Internet standards in which case the procedures for 541 copyrights defined in the Internet Standards process must be 542 followed, or as required to translate it into languages other than 543 English. 545 The limited permissions granted above are perpetual and will not be 546 revoked by the Internet Society or its successors or assigns. 548 This document and the information contained herein is provided on an 549 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 550 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 551 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 552 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 553 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 555 Acknowledgement 557 Funding for the RFC Editor function is currently provided by the 558 Internet Society.