idnits 2.17.1 draft-wilde-sms-service-10.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 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 623. ** 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 (Aug 03, 2005) is 6834 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 535, but no explicit reference was found in the text == Unused Reference: 'RFC3601' is defined on line 548, but no explicit reference was found in the text ** 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: 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: February 4, 2006 Technology 5 Aug 03, 2005 7 Registration of GSTN SMS Service Qualifier 8 draft-wilde-sms-service-10 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 February 4, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 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 1.2.1 SMS content . . . . . . . . . . . . . . . . . . . . . 3 55 1.2.2 SMS infrastructure . . . . . . . . . . . . . . . . . . 4 56 1.2.3 SMS Telematic Interworking . . . . . . . . . . . . . . 5 57 2. IANA registrations . . . . . . . . . . . . . . . . . . . . . . 6 58 2.1 IANA registration form for GSTN address 59 service-selector "SMS" . . . . . . . . . . . . . . . . . . 7 60 2.2 IANA registration form for GSTN address qualit-type1 61 keyword "SMSC" and value . . . . . . . . . . . . . . . . . 7 62 2.3 IANA registration form for GSTN address qualit-type1 63 keyword "PID" and value . . . . . . . . . . . . . . . . . 9 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 4. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1 From -09 to -10 . . . . . . . . . . . . . . . . . . . . . 11 67 4.2 From -08 to -09 . . . . . . . . . . . . . . . . . . . . . 11 68 4.3 From -07 to -08 . . . . . . . . . . . . . . . . . . . . . 11 69 4.4 From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 11 70 4.5 From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 11 71 4.6 From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 12 72 4.7 From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 12 73 4.8 From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 12 74 4.9 From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 12 75 4.10 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 12 76 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 78 5.2 Non-Normative References . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 80 A. Where to send Comments . . . . . . . . . . . . . . . . . . . . 14 81 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 82 Intellectual Property and Copyright Statements . . . . . . . . 15 84 1. Introduction 86 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 87 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in RFC 89 2119 [RFC2119]. 91 1.1 What is GSM? 93 GSM (Global System for Mobile Communications) is a digital mobile 94 phone standard which is used extensively in many parts of the world. 95 First named after its frequency band around 900 MHz, GSM-900 has 96 provided the basis for several other networks utilizing GSM 97 technology, in particular GSM networks operating in the frequency 98 bands around 1800 MHz and 1900 MHz. When referring to "GSM" in this 99 document, we mean any of these GSM-based networks that operate a 100 short message service. 102 1.2 What is SMS? 104 The Short Message Service [SMS] is an integral part of the GSM 105 network technology. It has been very successful and currently is a 106 major source of revenue for many GSM operators. SMS as a service is 107 so successful that other Global Switched Telephone Network (GSTN) 108 technologies have adapted it as well, in particular the Integrated 109 Services Digital Network (ISDN). Because of this development, this 110 memo uses the term "SMS client" to refer to user agents who are able 111 to send and/or receive SMS messages. 113 1.2.1 SMS content 115 GSM SMS messages are alphanumeric paging messages that can be sent to 116 and SMS clients. SMS messages have a maximum length of 160 117 characters (7-bit characters from the GSM character set [SMS-CHAR]), 118 or 140 octets. Other character sets (such as UCS-2 16-bit 119 characters, resulting in 70 character messages) MAY also be supported 120 [SMS-CHAR], but are defined as being OPTIONAL by the SMS 121 specification. Consequently, applications handling SMS messages as 122 part of a chain of character processing applications MUST make sure 123 that character sets are correctly mapped to and from the character 124 set used for SMS messages. 126 While the 160 character variety for SMS messages is by far the most 127 widely used one, there are numerous other content types for SMS 128 messages, such as small bitmaps ("operator logos") and simple formats 129 for musical notes ("ring tones"). However, these formats are 130 proprietary and are not considered in this memo. 132 SMS messages are very limited in length (140 octets), and the first 133 versions of the SMS specification did not specify any standardized 134 methods for concatenating SMS messages. As a consequence, several 135 proprietary methods were invented, but the current SMS specification 136 does specify message concatenation. In order to deal with this 137 situation, SMS clients composing messages SHOULD use the standard 138 concatenation method based on the header in the TP-User Data field as 139 specified in [SMS]. When sending a message to an SMS recipient whose 140 support for concatenated messages is unknown, the SMS client MAY opt 141 to use the backwards-compatible (text-based) concatenation method 142 defined in [SMS]. Proprietary concatenation methods SHOULD NOT be 143 used except in closed systems, where the capabilities of the 144 recipient(s) are always known. 146 1.2.2 SMS infrastructure 148 SMS messages can be transmitted over an SMS client's network 149 interface using the signalling channels of the underlying GSTN 150 infrastructure, so there is no delay for call setup. Alternatively, 151 SMS messages MAY be submitted through other front-ends (for example 152 such as Web services), which makes it possible for SMS clients to run 153 on computers which are not directly connected to a GSTN network 154 supporting SMS. 156 SMS messages sent as with the GSTN SMS service MUST be sent as class 157 1 SMS messages, if the client is able to specify the message class. 159 1.2.2.1 SMS Centers 161 SMS messages are stored by an entity called Short Message Service 162 Center (SMSC), and sent to the recipient when the subscriber connects 163 to the network. The number of a cooperative SMSC must be known to 164 the SMS sender (ie, the entity submitting the SMS message to a GSTN 165 infrastructure) when sending the message (usually, the SMSC's number 166 is configured in the SMS client and specific for the network operator 167 to which the sender has subscribed). In most situations, the SMSC 168 number is part of the sending SMS client's configuration. However, 169 in some special cases (such as when the SMS recipient only accepts 170 messages from a certain SMSC), it may be necessary to send the SMS 171 message over a specific SMSC. 173 Short messages can be mobile terminated (MT) or mobile originated 174 (MO). MT messages are the ones that arrive at SMS clients; MO 175 messages are sent by SMS clients. Networks may support either, both, 176 or none of these. For the purpose of this memo, it is important that 177 the sending SMS client is allowed to submit MO messages, and that the 178 receiver is allowed to receive MT messages. 180 The exact setup of message submission and delivery is not subject of 181 this memo, it may incorporate additional hops in addition to the pure 182 SMS transport. For example, the sending SMS client may use a Web 183 service to submit the SMS message, and the receiving SMS client may 184 be set up to forward the SMS to an email account. For the purpose of 185 this memo, it is important that the receiver can be addressed by a 186 GSTN number, and that the sender can submit an SMS message using this 187 number. 189 1.2.3 SMS Telematic Interworking 191 While in most cases SMS messages are exchanged between SMS clients, 192 the SMS specification also includes provisions for so-called 193 "Telematic Interworking". In this scenario, the SMS message 194 specifies a Protocol Identifier, which identifies the service to 195 which the SMS message has to be submitted. In effect, this 196 implements a gateway functionality in the SMSC. 198 Telematic Interworking supports a number of services from Fax through 199 Telex and Internet Email up to voice telephone, where the gateway is 200 expected to make a text-to-speech transformation. The set of 201 possible services is defined by the SMS specification [SMS], but 202 network operators are not required to support any of these services. 203 SMS clients SHOULD implement support for Telematic Interworking, 204 which among other things means that users must be able to set the 205 Protocol Identifier field of generated SMS messages. If clients 206 support Telematic Interworking, they MUST indicate to the user the 207 changed semantics of the receiver number (eg, if Fax is selected, the 208 receiver will be contacted via Fax rather than SMS). 210 In the following list the telematic devices (ie, the services that 211 can be addressed using the Telematic Interworking mechanism) defined 212 by the SMS specification are described. The abbreviations are not 213 taken from the SMS specification, but are introduced by this memo for 214 identifying the device type using an SMS service qualifier keyword. 216 "IMPL": In this case the device type is implicitly defined, either 217 because the SMS Center knows it, or because it can be concluded on 218 the basis of the address. 220 "TELEX": Telex device 222 "G3FAX": Group 3 telefax device 224 "G4FAX": Group 4 telefax device 225 "VOICE": Voice telephone (this requires conversion to speech, but 226 there is no mechanism to specify a language) 228 "ERMES": ERMES (European Radio Messaging System) 230 "NATPAG": National paging system (this does not specify a specific 231 paging systems but implies that the SMS center knows about a 232 particular national paging system) 234 "VIDEOTEX": Videotex 236 teletex: Teletex, either with an unspecified carrier or using PSPDN, 237 CSPDN, PSTN, or ISDN as carrier 239 "UCI": UCI (Universal Computer Interface) 241 reserved: 7 combinations are reserved which do not have a specified 242 meaning 244 "MH": Some message handling facility known to the SMS center (not 245 further specified) 247 x400: X.400-based message handling system 249 The SMS specification fails to specify how X.400 OR addresses are 250 actually embedded into SMS messages, so even though there is a 251 Protocol Identifier for X.400, it is impossible to encode the 252 recipient(s) of a message. 254 email: Internet electronic mail 256 The recipient(s) of SMS messages gatewayed to Internet electronic 257 mail are specified in the message's user data in a way defined by 258 the SMS specification. 260 specific: 7 combinations are defined to have a meaning specific to 261 each SMS center, their usage is based on mutual agreement between 262 SMS clients and the SMS center. 264 It is important to notice that some of the above devices require 265 additional information to be specified (in particular, the "Internet 266 electronic mail" format). The SMS specification defines the methods 267 how this has to be done (effectively by embedding the email 268 information into the SMS message's text). 270 2. IANA registrations 272 Based on the requirements defined in RFC 3191 [RFC3191], the IANA 273 registration forms for the "SMS" service-selector, and "SMSC" and 274 "PID" qualif-type1 elements are defined here. Syntax definitions are 275 given using the Augmented BNF for Syntax Specifications [RFC2234]. 277 2.1 IANA registration form for GSTN address service-selector "SMS" 279 To: IANA@iana.org 280 Subject: Registration of new values for the GSTN address 281 service-selector specifier "SMS" 283 service-selector name: SMS 285 Description of Use: SMS - specify that the GSTN address refers to a 286 GSTN subscriber who is capable of receiving messages using the GSM 287 Short Message Service (SMS). However, if a "PID" qualif-type1 288 element is present for this service selector, then the GSTN 289 address must be interpreted according to the rules for the "PID" 290 qualif-type1 element's value (this may also mean that the GSTN 291 address has to be ignored). 293 For a complete description refer to RFC 3191 and 294 draft-wilde-sms-service-10. 296 Security Considerations: See the Security Consideration section of 297 draft-wilde-sms-service-10. 299 Person & email address to contact for further information: 301 Erik Wilde 302 Swiss Federal Institute of Technology 303 ETH-Zentrum 304 8092 Zurich 305 Switzerland 306 tel:+41-1-6325132 307 fax:+41-1-6321035 308 mailto:erik.wilde@dret.net 310 2.2 IANA registration form for GSTN address qualit-type1 keyword "SMSC" 311 and value 313 To: IANA@iana.org 314 Subject: Registration of new values for the GSTN address 315 qualif-type1 element "SMSC" 317 qualif-type1 "keyword" name: SMSC 319 qualif-type1 "value" ABNF definition: The ABNF definition for the 320 value of the SMSC keyword is taken from RFC 3601 322 sub-addr = gstn-phone 323 gstn-phone = ( global-phone / local-phone ) 324 global-phone = "+" 1*( DIGIT / written-sep ) 325 local-phone = [ exit-code ] dial-number / exit-code [ dial-number ] 326 exit-code = phone-string 327 dial-number = phone-string 328 phone-string = 1*( DTMF / pause / tonewait / written-sep ) 329 DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" ) 330 pause = "p" 331 tonewait = "w" 332 written-sep = ( "-" / "." ) 334 Description of Use: SMSC - In some situations, it may be necessary to 335 guide the sender of an SMS message to send the message via a 336 certain Short Message Service Center (SMSC). If the SMSC qualif- 337 type1 element is present, an SMS client SHOULD try to send the 338 message first using the specified SMSC. If that fails, the SMS 339 client MAY try another SMSC (such as the default SMSC for that 340 client). 342 Further description is available in draft-wilde-sms-service-10. 344 Use Restriction: The use of the "SMSC" qualif-type1 element is 345 restricted to the "SMS" service-selector, it has no meaning 346 outside the SMS service defined by the "SMS" service-selector. 348 Security Considerations: See the Security Consideration section of 349 draft-wilde-sms-service-10. 351 Person & email address to contact for further information: 353 Erik Wilde 354 Swiss Federal Institute of Technology 355 ETH-Zentrum 356 8092 Zurich 357 Switzerland 358 tel:+41-1-6325132 359 fax:+41-1-6321035 360 mailto:erik.wilde@dret.net 362 2.3 IANA registration form for GSTN address qualit-type1 keyword "PID" 363 and value 365 To: IANA@iana.org 366 Subject: Registration of new values for the GSTN address 367 qualif-type1 element "PID" 369 qualif-type1 "keyword" name: PID 371 qualif-type1 "value" ABNF definition: The ABNF syntax definition of 372 the PID qualifier is as follows: 374 sub-addr = "IMPL" / "TELEX" / "G3FAX" / "G4FAX" / "VOICE" 375 / "ERMES" / "NATPAG" / "VIDEOTEX" / teletex / "UCI" 376 / reserved / "MH" / "X400" / email / specific 377 teletex = "TELETEX-" 378 ( "UNSPEC" / "PSPDN" / "CSPDN" / "PSTN" / "ISDN" ) 379 email = "SMTP:" address 380 reserved = "RES" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 381 specific = "SPEC" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 383 The "x400" definition is functionally incomplete (because there is 384 no way how the actual OR address can be specified), but provided 385 here for completeness. 387 The "address" definition is taken from RFC 2822 [RFC2822] and 388 specifies an address that may either be an individual mailbox, or 389 a group of mailboxes. 391 Description of Use: PID - The protocol identifier is used to specify 392 SMS Telematic Interworking by selecting a specific protocol to use 393 for delivery to the recipient. 395 Further description is available in draft-wilde-sms-service-10. 397 Use Restriction: The use of the "PID" qualif-type1 element is 398 restricted to the "SMS" service-selector, it has no meaning 399 outside the SMS service defined by the "SMS" service-selector. 401 Security Considerations: See the Security Consideration section of 402 draft-wilde-sms-service-10. 404 Person & email address to contact for further information: 406 Erik Wilde 407 Swiss Federal Institute of Technology 408 ETH-Zentrum 409 8092 Zurich 410 Switzerland 411 tel:+41-1-6325132 412 fax:+41-1-6321035 413 mailto:erik.wilde@dret.net 415 3. Security Considerations 417 SMS messages are transported without any provisions for privacy or 418 integrity, so SMS users should be aware of these inherent security 419 problems of SMS messages. Unlike electronic mail, where additional 420 mechanisms exist to layer security features on top of the 421 infrastructure, there currently is no such framework for SMS 422 messages. 424 SMS messages very often are delivered almost instantaneously (if the 425 receiving SMS client is on line), but there is no guarantee for when 426 SMS messages will be delivered. In particular, SMS messages between 427 different network operators sometimes take a long time to be 428 delivered (hours or even days) or are not delivered at all, so 429 applications SHOULD NOT make any assumptions about the reliability 430 and performance of SMS message transmission. 432 In most networks, sending SMS messages is not a free service. 433 Therefore, SMS clients MUST make sure that any action that incurs 434 costs is acknowledged by the end user, unless explicitly instructed 435 otherwise by the end user. If an SMS client has different ways of 436 submitting an SMS message (such as a Web service and a phone line), 437 then the end user MUST have a way to control which way is chosen. 439 SMS clients often are limited devices (typically mobile phones), and 440 the sending SMS client SHOULD NOT make any assumptions about the 441 receiving SMS client supporting any non-standard services, such as 442 proprietary message concatenation or proprietary content types. 443 However, if the sending SMS client has prior knowledge about the 444 receiving SMS client, then he MAY use this knowledge to compose non- 445 standard SMS messages. 447 There are certain special SMS messages defined in [SMS] that can be 448 used, for example, to turn on indicators on the phone display, or to 449 send data to certain communication ports (comparable to UDP ports) on 450 the device. Certain proprietary systems (for example, the Wireless 451 Application Protocol [WAP])define configuration messages that may be 452 used to reconfigure the devices remotely. Any SMS client SHOULD make 453 sure that malicious use of such messages is not possible, for example 454 by filtering out certain SMS User Data headers. Gateways that accept 455 SMS messages e.g. in e-mail messages or web forms and pass them on to 456 an SMSC SHOULD implement this kind of 'firewalling' approach as well. 458 Because the narrow bandwidth of the SMS communications channel, there 459 should also be checks in place for excessively long concatenated 460 messages. As an example, it may take two minutes to transfer thirty 461 concatenated text messages. 463 Unchecked input from a user MUST NOT be used to populate any other 464 fields in a Short Message other than the User Data field (not 465 including the User Data Header field). All other parts, including 466 the User Data Header, of the Short Message should be generated by 467 trusted means. 469 4. Change Log 471 This section will not be part of the final RFC text, it serves as a 472 container to collect the history of the individual draft versions. 474 4.1 From -09 to -10 476 o Changed IPR clause from RFC 3667 to RFC 3978 (updated version of 477 RFC 3667). 479 4.2 From -08 to -09 481 o No changes, re-release for alignment with draft-wilde-sms-uri. 483 4.3 From -07 to -08 485 o No changes, re-release for alignment with draft-wilde-sms-uri. 487 4.4 From -06 to -07 489 o Changed IPR clause from RFC 2026 to RFC 3667 (updated version of 490 RFC 2026). 492 4.5 From -05 to -06 493 o Updated reference from draft-allocchio-gstn-05 to RFC 3601. 495 4.6 From -04 to -05 497 o No changes, re-release for alignment with draft-wilde-sms-uri. 499 4.7 From -03 to -04 501 o Updated reference to draft-allocchio-gstn (to revision -05). 503 4.8 From -02 to -03 505 o Changed ordering of "change Log" section (descending to 506 ascending). 508 o Fixed some spelling errors. 510 4.9 From -01 to -02 512 o Removed address specification for X.400 SMS from ABNF 513 (surprisingly not part of the SMS spec). 515 o Added some explanatory text about character set mapping for SMS 516 messages. 518 o Added text requiring the use of message class 1 for sending SMS 519 messages. 521 4.10 From -00 to -01 523 o Added a number of new security considerations. 525 o Added the "PID" qualif-type1 keyword and the section about "SMS 526 Telematic Interworking" Section 1.2.3. 528 5. References 530 5.1 Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", RFC 2119, March 1997. 535 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 536 Mapping between X.400 and RFC 822/MIME", RFC 2156, 537 January 1998. 539 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 540 Specifications: ABNF", RFC 2234, November 1997. 542 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 543 April 2001. 545 [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet 546 Mail", RFC 3191, October 2001. 548 [RFC3601] Allocchio, C., "Text string notation for Dial Sequences 549 and GSTN / E.164 addresses", RFC 3601, September 2003. 551 [SMS] European Telecommunications Standards Institute, "ETSI TS 552 100 901 (GSM 03.40 version 7.3.0 Release 1998): Digital 553 Cellular Telecommunications System (Phase 2+); Technical 554 realization of the Short Message Service (SMS); Point-to- 555 Point (PP)", November 1999, 556 . 558 [SMS-CHAR] 559 European Telecommunications Standards Institute, "ETSI TS 560 100 901 (GSM 03.38 version 7.2.0 Release 1998): Digital 561 Cellular Telecommunications System (Phase 2+); Alphabets 562 and language-specific information", July 1999, 563 . 565 [draft-wilde-sms-service-10] 566 Wilde, E., "Registration of GSTN SMS Service Qualifier", 567 draft-wilde-sms-service-10 (work in progress), Aug 2005. 569 5.2 Non-Normative References 571 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 572 June 1999. 574 [WAP] WAP Forum, "Wireless Application Protocol - Architecture 575 Specification (WAP-210-WAPArch-20010712)", July 2001. 577 Author's Address 579 Erik Wilde 580 Swiss Federal Institute of Technology 581 ETH-Zentrum 582 8092 Zurich 583 Switzerland 585 Phone: +41-1-6325132 586 Email: erik.wilde@dret.net 587 URI: http://dret.net/netdret/ 589 Appendix A. Where to send Comments 591 Please send all comments and questions concerning this document to 592 Erik Wilde. 594 Appendix B. Acknowledgements 596 This document has been prepared using the IETF document DTD described 597 in RFC 2629 [RFC2629]. 599 Thanks to Claudio Allocchio and Antti Vaha-Sipila for their comments. 601 Intellectual Property Statement 603 The IETF takes no position regarding the validity or scope of any 604 Intellectual Property Rights or other rights that might be claimed to 605 pertain to the implementation or use of the technology described in 606 this document or the extent to which any license under such rights 607 might or might not be available; nor does it represent that it has 608 made any independent effort to identify any such rights. Information 609 on the procedures with respect to rights in RFC documents can be 610 found in BCP 78 and BCP 79. 612 Copies of IPR disclosures made to the IETF Secretariat and any 613 assurances of licenses to be made available, or the result of an 614 attempt made to obtain a general license or permission for the use of 615 such proprietary rights by implementers or users of this 616 specification can be obtained from the IETF on-line IPR repository at 617 http://www.ietf.org/ipr. 619 The IETF invites any interested party to bring to its attention any 620 copyrights, patents or patent applications, or other proprietary 621 rights that may cover technology that may be required to implement 622 this standard. Please address the information to the IETF at 623 ietf-ipr@ietf.org. 625 Disclaimer of Validity 627 This document and the information contained herein are provided on an 628 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 629 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 630 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 631 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 632 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 633 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 Copyright Statement 637 Copyright (C) The Internet Society (2005). This document is subject 638 to the rights, licenses and restrictions contained in BCP 78, and 639 except as set forth therein, the authors retain all their rights. 641 Acknowledgment 643 Funding for the RFC Editor function is currently provided by the 644 Internet Society.