idnits 2.17.1 draft-wilde-sms-service-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 640. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 (Feb 08, 2006) is 6650 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) == Unused Reference: 'RFC2156' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC3601' is defined on line 561, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- 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: 7 errors (**), 0 flaws (~~), 5 warnings (==), 10 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: August 12, 2006 Technology 5 Feb 08, 2006 7 Registration of GSTN SMS Service Qualifier 8 draft-wilde-sms-service-11 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 12, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This memo describes the registration of the Short Message Service 42 (SMS) as a registered IANA service selector for Global Switched 43 Telephone Network (GSTN) numbers. SMS is not available for all GSTN 44 subscribers, but it has proven very popular with users of the Global 45 System for Mobile Communications (GSM), and has also been adapted to 46 other telephone network technologies such as the Integrated Services 47 Digital Network (ISDN). 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. What is GSM? . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. What is SMS? . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. IANA registrations . . . . . . . . . . . . . . . . . . . . . . 6 55 2.1. IANA registration form for GSTN address 56 service-selector "SMS" . . . . . . . . . . . . . . . . . . 7 57 2.2. IANA registration form for GSTN address qualit-type1 58 keyword "SMSC" and value . . . . . . . . . . . . . . . . . 7 59 2.3. IANA registration form for GSTN address qualit-type1 60 keyword "PID" and value . . . . . . . . . . . . . . . . . 9 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 4. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.1. From -10 to -11 . . . . . . . . . . . . . . . . . . . . . 11 64 4.2. From -09 to -10 . . . . . . . . . . . . . . . . . . . . . 11 65 4.3. From -08 to -09 . . . . . . . . . . . . . . . . . . . . . 12 66 4.4. From -07 to -08 . . . . . . . . . . . . . . . . . . . . . 12 67 4.5. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 12 68 4.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 12 69 4.7. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 12 70 4.8. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 12 71 4.9. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 12 72 4.10. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 12 73 4.11. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 12 74 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 5.2. Non-Normative References . . . . . . . . . . . . . . . . . 14 77 Appendix A. Where to send Comments . . . . . . . . . . . . . . . 14 78 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Intellectual Property and Copyright Statements . . . . . . . . . . 16 82 1. Introduction 84 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 85 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in RFC 87 2119 [RFC2119]. 89 1.1. What is GSM? 91 GSM (Global System for Mobile Communications) is a digital mobile 92 phone standard which is used extensively in many parts of the world. 93 First named after its frequency band around 900 MHz, GSM-900 has 94 provided the basis for several other networks utilizing GSM 95 technology, in particular GSM networks operating in the frequency 96 bands around 1800 MHz and 1900 MHz. When referring to "GSM" in this 97 document, we mean any of these GSM-based networks that operate a 98 short message service. 100 1.2. What is SMS? 102 The Short Message Service [SMS] is an integral part of the GSM 103 network technology. It has been very successful and currently is a 104 major source of revenue for many GSM operators. SMS as a service is 105 so successful that other Global Switched Telephone Network (GSTN) 106 technologies have adapted it as well, in particular the Integrated 107 Services Digital Network (ISDN). Because of this development, this 108 memo uses the term "SMS client" to refer to user agents who are able 109 to send and/or receive SMS messages. 111 1.2.1. SMS content 113 GSM SMS messages are alphanumeric paging messages that can be sent to 114 and SMS clients. SMS messages have a maximum length of 160 115 characters (7-bit characters from the GSM character set [SMS-CHAR]), 116 or 140 octets. Other character sets (such as UCS-2 16-bit 117 characters, resulting in 70 character messages) MAY also be supported 118 [SMS-CHAR], but are defined as being OPTIONAL by the SMS 119 specification. Consequently, applications handling SMS messages as 120 part of a chain of character processing applications MUST make sure 121 that character sets are correctly mapped to and from the character 122 set used for SMS messages. 124 While the 160 character variety for SMS messages is by far the most 125 widely used one, there are numerous other content types for SMS 126 messages, such as small bitmaps ("operator logos") and simple formats 127 for musical notes ("ring tones"). However, these formats are 128 proprietary and are not considered in this memo. 130 SMS messages are very limited in length (140 octets), and the first 131 versions of the SMS specification did not specify any standardized 132 methods for concatenating SMS messages. As a consequence, several 133 proprietary methods were invented, but the current SMS specification 134 does specify message concatenation. In order to deal with this 135 situation, SMS clients composing messages SHOULD use the standard 136 concatenation method based on the header in the TP-User Data field as 137 specified in [SMS]. When sending a message to an SMS recipient whose 138 support for concatenated messages is unknown, the SMS client MAY opt 139 to use the backwards-compatible (text-based) concatenation method 140 defined in [SMS]. Proprietary concatenation methods SHOULD NOT be 141 used except in closed systems, where the capabilities of the 142 recipient(s) are always known. 144 1.2.2. SMS infrastructure 146 SMS messages can be transmitted over an SMS client's network 147 interface using the signalling channels of the underlying GSTN 148 infrastructure, so there is no delay for call setup. Alternatively, 149 SMS messages MAY be submitted through other front-ends (for example 150 such as Web services), which makes it possible for SMS clients to run 151 on computers which are not directly connected to a GSTN network 152 supporting SMS. 154 SMS messages sent as with the GSTN SMS service MUST be sent as class 155 1 SMS messages, if the client is able to specify the message class. 157 1.2.2.1. SMS Centers 159 SMS messages are stored by an entity called SMS Center (SMSC), and 160 sent to the recipient when the subscriber connects to the network. 161 The number of a cooperative SMSC must be known to the SMS sender 162 (i.e., the entity submitting the SMS message to a GSTN 163 infrastructure) when sending the message (usually, the SMSC's number 164 is configured in the SMS client and specific for the network operator 165 to which the sender has subscribed). In most situations, the SMSC 166 number is part of the sending SMS client's configuration. However, 167 in some special cases (such as when the SMS recipient only accepts 168 messages from a certain SMSC), it may be necessary to send the SMS 169 message over a specific SMSC. 171 Short messages can be mobile terminated (MT) or mobile originated 172 (MO). MT messages are the ones that arrive at SMS clients; MO 173 messages are sent by SMS clients. Networks may support either, both, 174 or none of these. For the purpose of this memo, it is important that 175 the sending SMS client is allowed to submit MO messages, and that the 176 receiver is allowed to receive MT messages. 178 The exact setup of message submission and delivery is not subject of 179 this memo, it may incorporate additional hops in addition to the pure 180 SMS transport. For example, the sending SMS client may use a Web 181 service to submit the SMS message, and the receiving SMS client may 182 be set up to forward the SMS to an email account. For the purpose of 183 this memo, it is important that the receiver can be addressed by a 184 GSTN number, and that the sender can submit an SMS message using this 185 number. 187 1.2.3. SMS Telematic Interworking 189 While in most cases SMS messages are exchanged between SMS clients, 190 the SMS specification also includes provisions for so-called 191 "Telematic Interworking". In this scenario, the SMS message 192 specifies a Protocol Identifier, which identifies the service to 193 which the SMS message has to be submitted. In effect, this 194 implements a gateway functionality in the SMSC. 196 Telematic Interworking supports a number of services from Fax through 197 Telex and Internet Email up to voice telephone, where the gateway is 198 expected to make a text-to-speech transformation. The set of 199 possible services is defined by the SMS specification [SMS], but 200 network operators are not required to support any of these services. 201 SMS clients SHOULD implement support for Telematic Interworking, 202 which among other things means that users must be able to set the 203 Protocol Identifier field of generated SMS messages. If clients 204 support Telematic Interworking, they MUST indicate to the user the 205 changed semantics of the receiver number (e.g., if Fax is selected, 206 the receiver will be contacted via Fax rather than SMS). 208 In the following list the telematic devices (i.e., the services that 209 can be addressed using the Telematic Interworking mechanism) defined 210 by the SMS specification are described. The abbreviations are not 211 taken from the SMS specification, but are introduced by this memo for 212 identifying the device type using an SMS service qualifier keyword. 214 "IMPL": In this case the device type is implicitly defined, either 215 because the SMS Center knows it, or because it can be concluded on 216 the basis of the address. 218 "TELEX": Telex device 220 "G3FAX": Group 3 telefax device 222 "G4FAX": Group 4 telefax device 223 "VOICE": Voice telephone (this requires conversion to speech, but 224 there is no mechanism to specify a language) 226 "ERMES": ERMES (European Radio Messaging System) 228 "NATPAG": National paging system (this does not specify a specific 229 paging systems but implies that the SMS center knows about a 230 particular national paging system) 232 "VIDEOTEX": Videotex 234 teletex: Teletex, either with an unspecified carrier or using PSPDN, 235 CSPDN, PSTN, or ISDN as carrier 237 "UCI": UCI (Universal Computer Interface) 239 reserved: 7 combinations are reserved which do not have a specified 240 meaning 242 "MH": Some message handling facility known to the SMS center (not 243 further specified) 245 x400: X.400-based message handling system 247 The SMS specification fails to specify how X.400 OR addresses are 248 actually embedded into SMS messages, so even though there is a 249 Protocol Identifier for X.400, it is impossible to encode the 250 recipient(s) of a message. 252 email: Internet electronic mail 254 The recipient(s) of SMS messages gatewayed to Internet electronic 255 mail are specified in the message's user data in a way defined by 256 the SMS specification. 258 specific: 7 combinations are defined to have a meaning specific to 259 each SMS center, their usage is based on mutual agreement between 260 SMS clients and the SMS center. 262 It is important to notice that some of the above devices require 263 additional information to be specified (in particular, the "Internet 264 electronic mail" format). The SMS specification defines the methods 265 how this has to be done (effectively by embedding the email 266 information into the SMS message's text). 268 2. IANA registrations 269 Based on the requirements defined in RFC 3191 [RFC3191], the IANA 270 registration forms for the "SMS" service-selector, and "SMSC" and 271 "PID" qualif-type1 elements are defined here. Syntax definitions are 272 given using the Augmented BNF for Syntax Specifications [RFC4234]. 274 2.1. IANA registration form for GSTN address service-selector "SMS" 276 To: IANA@iana.org 277 Subject: Registration of new values for the GSTN address 278 service-selector specifier "SMS" 280 service-selector name: SMS 282 Description of Use: SMS - specify that the GSTN address refers to a 283 GSTN subscriber who is capable of receiving messages using the GSM 284 Short Message Service (SMS). However, if a "PID" qualif-type1 285 element is present for this service selector, then the GSTN 286 address must be interpreted according to the rules for the "PID" 287 qualif-type1 element's value (this may also mean that the GSTN 288 address has to be ignored). 290 For a complete description refer to RFC 3191 and 291 draft-wilde-sms-service-11. 293 Security Considerations: See the Security Consideration section of 294 draft-wilde-sms-service-11. 296 Person & email address to contact for further information: 298 Erik Wilde 299 Swiss Federal Institute of Technology 300 ETH-Zentrum 301 8092 Zurich 302 Switzerland 303 tel:+41-1-6325132 304 fax:+41-1-6321035 305 mailto:erik.wilde@dret.net 307 2.2. IANA registration form for GSTN address qualit-type1 keyword 308 "SMSC" and value 310 To: IANA@iana.org 311 Subject: Registration of new values for the GSTN address 312 qualif-type1 element "SMSC" 314 qualif-type1 "keyword" name: SMSC 316 qualif-type1 "value" ABNF definition: The ABNF definition for the 317 value of the SMSC keyword is taken from RFC 3601 319 sub-addr = gstn-phone 320 gstn-phone = ( global-phone / local-phone ) 321 global-phone = "+" 1*( DIGIT / written-sep ) 322 local-phone = [ exit-code ] dial-number / exit-code [ dial-number ] 323 exit-code = phone-string 324 dial-number = phone-string 325 phone-string = 1*( DTMF / pause / tonewait / written-sep ) 326 DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" ) 327 pause = "p" 328 tonewait = "w" 329 written-sep = ( "-" / "." ) 331 Description of Use: SMSC - In some situations, it may be necessary to 332 guide the sender of an SMS message to send the message via a 333 certain Short Message Service Center (SMSC). If the SMSC qualif- 334 type1 element is present, an SMS client SHOULD try to send the 335 message first using the specified SMSC. If that fails, the SMS 336 client MAY try another SMSC (such as the default SMSC for that 337 client). 339 Further description is available in draft-wilde-sms-service-11. 341 Use Restriction: The use of the "SMSC" qualif-type1 element is 342 restricted to the "SMS" service-selector, it has no meaning 343 outside the SMS service defined by the "SMS" service-selector. 345 Security Considerations: See the Security Consideration section of 346 draft-wilde-sms-service-11. 348 Person & email address to contact for further information: 350 Erik Wilde 351 Swiss Federal Institute of Technology 352 ETH-Zentrum 353 8092 Zurich 354 Switzerland 355 tel:+41-1-6325132 356 fax:+41-1-6321035 357 mailto:erik.wilde@dret.net 359 2.3. IANA registration form for GSTN address qualit-type1 keyword "PID" 360 and value 362 To: IANA@iana.org 363 Subject: Registration of new values for the GSTN address 364 qualif-type1 element "PID" 366 qualif-type1 "keyword" name: PID 368 qualif-type1 "value" ABNF definition: The ABNF syntax definition of 369 the PID qualifier is as follows: 371 sub-addr = "IMPL" / "TELEX" / "G3FAX" / "G4FAX" / "VOICE" 372 / "ERMES" / "NATPAG" / "VIDEOTEX" / teletex / "UCI" 373 / reserved / "MH" / "X400" / email / specific 374 teletex = "TELETEX-" 375 ( "UNSPEC" / "PSPDN" / "CSPDN" / "PSTN" / "ISDN" ) 376 email = "SMTP:" address 377 reserved = "RES" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 378 specific = "SPEC" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 380 The "x400" definition is functionally incomplete (because there is 381 no way how the actual OR address can be specified), but provided 382 here for completeness. 384 The "address" definition is taken from RFC 2822 [RFC2822] and 385 specifies an address that may either be an individual mailbox, or 386 a group of mailboxes. 388 Description of Use: PID - The protocol identifier is used to specify 389 SMS Telematic Interworking by selecting a specific protocol to use 390 for delivery to the recipient. 392 Further description is available in draft-wilde-sms-service-11. 394 Use Restriction: The use of the "PID" qualif-type1 element is 395 restricted to the "SMS" service-selector, it has no meaning 396 outside the SMS service defined by the "SMS" service-selector. 398 Security Considerations: See the Security Consideration section of 399 draft-wilde-sms-service-11. 401 Person & email address to contact for further information: 403 Erik Wilde 404 Swiss Federal Institute of Technology 405 ETH-Zentrum 406 8092 Zurich 407 Switzerland 408 tel:+41-1-6325132 409 fax:+41-1-6321035 410 mailto:erik.wilde@dret.net 412 3. Security Considerations 414 SMS messages are transported without any provisions for privacy or 415 integrity, so SMS users should be aware of these inherent security 416 problems of SMS messages. Unlike electronic mail, where additional 417 mechanisms exist to layer security features on top of the 418 infrastructure, there currently is no such framework for SMS 419 messages. 421 SMS messages very often are delivered almost instantaneously (if the 422 receiving SMS client is online), but there is no guarantee for when 423 SMS messages will be delivered. In particular, SMS messages between 424 different network operators sometimes take a long time to be 425 delivered (hours or even days) or are not delivered at all, so 426 applications SHOULD NOT make any assumptions about the reliability 427 and performance of SMS message transmission. 429 In most networks, sending SMS messages is not a free service. 430 Therefore, SMS clients MUST make sure that any action that incurs 431 costs is acknowledged by the end user, unless explicitly instructed 432 otherwise by the end user. If an SMS client has different ways of 433 submitting an SMS message (such as a Web service and a phone line), 434 then the end user MUST have a way to control which way is chosen. 436 SMS clients often are limited devices (typically mobile phones), and 437 the sending SMS client SHOULD NOT make any assumptions about the 438 receiving SMS client supporting any non-standard services, such as 439 proprietary message concatenation or proprietary content types. 440 However, if the sending SMS client has prior knowledge about the 441 receiving SMS client, then he MAY use this knowledge to compose non- 442 standard SMS messages. 444 There are certain special SMS messages defined in [SMS] that can be 445 used, for example, to turn on indicators on the phone display, or to 446 send data to certain communication ports (comparable to UDP ports) on 447 the device. Certain proprietary systems (for example, the Wireless 448 Application Protocol [WAP]) define configuration messages that may be 449 used to reconfigure the devices remotely. Any SMS client SHOULD make 450 sure that malicious use of such messages is not possible, for example 451 by filtering out certain SMS User Data headers. Gateways that accept 452 SMS messages e.g. in e-mail messages or web forms and pass them on to 453 an SMSC SHOULD implement this kind of 'firewalling' approach as well. 455 Because the narrow bandwidth of the SMS communications channel, there 456 should also be checks in place for excessively long concatenated 457 messages. As an example, it may take two minutes to transfer thirty 458 concatenated text messages. 460 Unchecked input from a user MUST NOT be used to populate any other 461 fields in a Short Message other than the User Data field (not 462 including the User Data Header field). All other parts, including 463 the User Data Header, of the Short Message should be generated by 464 trusted means. 466 By including SMS URIs in unsolicited messages (aka "spam") or other 467 types of advertising, the originator of the SMS URIs may attempt to 468 reveal an individual's phone number and/or to link the identity 469 (i.e., e-mail address) used for messaging with the identity (i.e., 470 phone number) used for the mobile phone. This attempt to collect 471 information may be a privacy issue, and users agents MAY users make 472 aware of that risk before composing or sending SMS messages. 474 4. Change Log 476 This section will not be part of the final RFC text, it serves as a 477 container to collect the history of the individual draft versions. 479 4.1. From -10 to -11 481 o RFC 2234 (ABNF) has been obsoleted by [RFC4234]. 483 o Added new security issue in Section Section 3. 485 o Updated reference information for [SMS] and [SMS-CHAR]. 487 o Minor textual changes. 489 4.2. From -09 to -10 491 o Changed IPR clause from RFC 3667 to RFC 3978 (updated version of 492 RFC 3667). 494 4.3. From -08 to -09 496 o No changes, re-release for alignment with draft-wilde-sms-uri. 498 4.4. From -07 to -08 500 o No changes, re-release for alignment with draft-wilde-sms-uri. 502 4.5. From -06 to -07 504 o Changed IPR clause from RFC 2026 to RFC 3667 (updated version of 505 RFC 2026). 507 4.6. From -05 to -06 509 o Updated reference from draft-allocchio-gstn-05 to RFC 3601. 511 4.7. From -04 to -05 513 o No changes, re-release for alignment with draft-wilde-sms-uri. 515 4.8. From -03 to -04 517 o Updated reference to draft-allocchio-gstn (to revision -05). 519 4.9. From -02 to -03 521 o Changed ordering of "change Log" section (descending to 522 ascending). 524 o Fixed some spelling errors. 526 4.10. From -01 to -02 528 o Removed address specification for X.400 SMS from ABNF 529 (surprisingly not part of the SMS spec). 531 o Added some explanatory text about character set mapping for SMS 532 messages. 534 o Added text requiring the use of message class 1 for sending SMS 535 messages. 537 4.11. From -00 to -01 539 o Added a number of new security considerations. 541 o Added the "PID" qualif-type1 keyword and the section about "SMS 542 Telematic Interworking" Section 1.2.3. 544 5. References 546 5.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", RFC 2119, March 1997. 551 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 552 Mapping between X.400 and RFC 822/MIME", RFC 2156, 553 January 1998. 555 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 556 April 2001. 558 [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet 559 Mail", RFC 3191, October 2001. 561 [RFC3601] Allocchio, C., "Text string notation for Dial Sequences 562 and GSTN / E.164 addresses", RFC 3601, September 2003. 564 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 565 Specifications: ABNF", RFC 4234, October 2005. 567 [SMS] European Telecommunications Standards Institute, "3GPP TS 568 03.40 (Version 7.5.0 Release 1998): 3rd Generation 569 Partnership Project; Technical Specification Group 570 Terminals; Technical realization of the Short Message 571 Service (SMS)", December 2001, . 574 [SMS-CHAR] 575 European Telecommunications Standards Institute, "TS 100 576 900 (GSM 03.38 version 7.2.0 Release 1998): Digital 577 Cellular Telecommunications System (Phase 2+); Alphabets 578 and language-specific information", July 1999, . 582 [draft-wilde-sms-service-11] 583 Wilde, E., "Registration of GSTN SMS Service Qualifier", 584 draft-wilde-sms-service-11 (work in progress), Aug 2005. 586 5.2. Non-Normative References 588 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 589 June 1999. 591 [WAP] WAP Forum, "Wireless Application Protocol - Architecture 592 Specification (WAP-210-WAPArch-20010712)", July 2001. 594 Appendix A. Where to send Comments 596 Please send all comments and questions concerning this document to 597 Erik Wilde. 599 Appendix B. Acknowledgements 601 This document has been prepared using the IETF document DTD described 602 in RFC 2629 [RFC2629]. 604 Thanks to Claudio Allocchio and Antti Vaha-Sipila for their comments. 606 Author's Address 608 Erik Wilde 609 Swiss Federal Institute of Technology 610 ETH-Zentrum 611 8092 Zurich 612 Switzerland 614 Phone: +41-44-6325132 615 Email: erik.wilde@dret.net 616 URI: http://dret.net/netdret/ 618 Intellectual Property Statement 620 The IETF takes no position regarding the validity or scope of any 621 Intellectual Property Rights or other rights that might be claimed to 622 pertain to the implementation or use of the technology described in 623 this document or the extent to which any license under such rights 624 might or might not be available; nor does it represent that it has 625 made any independent effort to identify any such rights. Information 626 on the procedures with respect to rights in RFC documents can be 627 found in BCP 78 and BCP 79. 629 Copies of IPR disclosures made to the IETF Secretariat and any 630 assurances of licenses to be made available, or the result of an 631 attempt made to obtain a general license or permission for the use of 632 such proprietary rights by implementers or users of this 633 specification can be obtained from the IETF on-line IPR repository at 634 http://www.ietf.org/ipr. 636 The IETF invites any interested party to bring to its attention any 637 copyrights, patents or patent applications, or other proprietary 638 rights that may cover technology that may be required to implement 639 this standard. Please address the information to the IETF at 640 ietf-ipr@ietf.org. 642 Disclaimer of Validity 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 647 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 648 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 649 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Copyright Statement 654 Copyright (C) The Internet Society (2006). This document is subject 655 to the rights, licenses and restrictions contained in BCP 78, and 656 except as set forth therein, the authors retain all their rights. 658 Acknowledgment 660 Funding for the RFC Editor function is currently provided by the 661 Internet Society.