idnits 2.17.1 draft-wilde-sms-service-07.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 612. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (Jan 10, 2005) is 7046 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 520, but no explicit reference was found in the text == Unused Reference: 'RFC3601' is defined on line 533, 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: 9 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: July 11, 2005 Technology 5 Jan 10, 2005 7 Registration of GSTN SMS Service Qualifier 8 draft-wilde-sms-service-07 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 11, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This memo describes the registration of the Short Message Service 44 (SMS) as a registered IANA service selector for Global Switched 45 Telephone Network (GSTN) numbers. SMS is not available for all GSTN 46 subscribers, but it has proven very popular with users of the Global 47 System for Mobile Communications (GSM), and has also been adapted to 48 other telephone network technologies such as the Integrated Services 49 Digital Network (ISDN). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 What is GSM? . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 What is SMS? . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2.1 SMS content . . . . . . . . . . . . . . . . . . . . . 3 57 1.2.2 SMS infrastructure . . . . . . . . . . . . . . . . . . 4 58 1.2.3 SMS Telematic Interworking . . . . . . . . . . . . . . 5 59 2. IANA registrations . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1 IANA registration form for GSTN address 61 service-selector "SMS" . . . . . . . . . . . . . . . . . . 7 62 2.2 IANA registration form for GSTN address qualit-type1 63 keyword "SMSC" and value . . . . . . . . . . . . . . . . . 7 64 2.3 IANA registration form for GSTN address qualit-type1 65 keyword "PID" and value . . . . . . . . . . . . . . . . . 9 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 4. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.1 From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 11 69 4.2 From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 11 70 4.3 From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 11 71 4.4 From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 11 72 4.5 From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 11 73 4.6 From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 12 74 4.7 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 12 75 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 77 5.2 Non-Normative References . . . . . . . . . . . . . . . . . . 13 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 79 A. Where to send Comments . . . . . . . . . . . . . . . . . . . . 13 80 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 81 Intellectual Property and Copyright Statements . . . . . . . . 15 83 1. Introduction 85 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 86 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in RFC 88 2119 [RFC2119]. 90 1.1 What is GSM? 92 GSM (Global System for Mobile Communications) is a digital mobile 93 phone standard which is used extensively in many parts of the world. 94 First named after its frequency band around 900 MHz, GSM-900 has 95 provided the basis for several other networks utilizing GSM 96 technology, in particular GSM networks operating in the frequency 97 bands around 1800 MHz and 1900 MHz. When referring to "GSM" in this 98 document, we mean any of these GSM-based networks that operate a 99 short message service. 101 1.2 What is SMS? 103 The Short Message Service [SMS] is an integral part of the GSM 104 network technology. It has been very successful and currently is a 105 major source of revenue for many GSM operators. SMS as a service is 106 so successful that other Global Switched Telephone Network (GSTN) 107 technologies have adapted it as well, in particular the Integrated 108 Services Digital Network (ISDN). Because of this development, this 109 memo uses the term "SMS client" to refer to user agents who are able 110 to send and/or receive SMS messages. 112 1.2.1 SMS content 114 GSM SMS messages are alphanumeric paging messages that can be sent to 115 and SMS clients. SMS messages have a maximum length of 160 116 characters (7-bit characters from the GSM character set [SMS-CHAR]), 117 or 140 octets. Other character sets (such as UCS-2 16-bit 118 characters, resulting in 70 character messages) MAY also be supported 119 [SMS-CHAR], but are defined as being OPTIONAL by the SMS 120 specification. Consequently, applications handling SMS messages as 121 part of a chain of character processing applications MUST make sure 122 that character sets are correctly mapped to and from the character 123 set used for SMS messages. 125 While the 160 character variety for SMS messages is by far the most 126 widely used one, there are numerous other content types for SMS 127 messages, such as small bitmaps ("operator logos") and simple formats 128 for musical notes ("ring tones"). However, these formats are 129 proprietary and are not considered in this memo. 131 SMS messages are very limited in length (140 octets), and the first 132 versions of the SMS specification did not specify any standardized 133 methods for concatenating SMS messages. As a consequence, several 134 proprietary methods were invented, but the current SMS specification 135 does specify message concatenation. In order to deal with this 136 situation, SMS clients composing messages SHOULD use the standard 137 concatenation method based on the header in the TP-User Data field as 138 specified in [SMS]. When sending a message to an SMS recipient whose 139 support for concatenated messages is unknown, the SMS client MAY opt 140 to use the backwards-compatible (text-based) concatenation method 141 defined in [SMS]. Proprietary concatenation methods SHOULD NOT be 142 used except in closed systems, where the capabilities of the 143 recipient(s) are always known. 145 1.2.2 SMS infrastructure 147 SMS messages can be transmitted over an SMS client's network 148 interface using the signalling channels of the underlying GSTN 149 infrastructure, so there is no delay for call setup. Alternatively, 150 SMS messages MAY be submitted through other front-ends (for example 151 such as Web services), which makes it possible for SMS clients to run 152 on computers which are not directly connected to a GSTN network 153 supporting SMS. 155 SMS messages sent as with the GSTN SMS service MUST be sent as class 156 1 SMS messages, if the client is able to specify the message class. 158 1.2.2.1 SMS Centers 160 SMS messages are stored by an entity called Short Message Service 161 Center (SMSC), and sent to the recipient when the subscriber connects 162 to the network. The number of a cooperative SMSC must be known to 163 the SMS sender (ie, the entity submitting the SMS message to a GSTN 164 infrastructure) when sending the message (usually, the SMSC's number 165 is configured in the SMS client and specific for the network operator 166 to which the sender has subscribed). In most situations, the SMSC 167 number is part of the sending SMS client's configuration. However, 168 in some special cases (such as when the SMS recipient only accepts 169 messages from a certain SMSC), it may be necessary to send the SMS 170 message over a specific SMSC. 172 Short messages can be mobile terminated (MT) or mobile originated 173 (MO). MT messages are the ones that arrive at SMS clients; MO 174 messages are sent by SMS clients. Networks may support either, both, 175 or none of these. For the purpose of this memo, it is important that 176 the sending SMS client is allowed to submit MO messages, and that the 177 receiver is allowed to receive MT messages. 179 The exact setup of message submission and delivery is not subject of 180 this memo, it may incorporate additional hops in addition to the pure 181 SMS transport. For example, the sending SMS client may use a Web 182 service to submit the SMS message, and the receiving SMS client may 183 be set up to forward the SMS to an email account. For the purpose of 184 this memo, it is important that the receiver can be addressed by a 185 GSTN number, and that the sender can submit an SMS message using this 186 number. 188 1.2.3 SMS Telematic Interworking 190 While in most cases SMS messages are exchanged between SMS clients, 191 the SMS specification also includes provisions for so-called 192 "Telematic Interworking". In this scenario, the SMS message 193 specifies a Protocol Identifier, which identifies the service to 194 which the SMS message has to be submitted. In effect, this 195 implements a gateway functionality in the SMSC. 197 Telematic Interworking supports a number of services from Fax through 198 Telex and Internet Email up to voice telephone, where the gateway is 199 expected to make a text-to-speech transformation. The set of 200 possible services is defined by the SMS specification [SMS], but 201 network operators are not required to support any of these services. 202 SMS clients SHOULD implement support for Telematic Interworking, 203 which among other things means that users must be able to set the 204 Protocol Identifier field of generated SMS messages. If clients 205 support Telematic Interworking, they MUST indicate to the user the 206 changed semantics of the receiver number (eg, if Fax is selected, the 207 receiver will be contacted via Fax rather than SMS). 209 In the following list the telematic devices (ie, the services that 210 can be addressed using the Telematic Interworking mechanism) defined 211 by the SMS specification are described. The abbreviations are not 212 taken from the SMS specification, but are introduced by this memo for 213 identifying the device type using an SMS service qualifier keyword. 215 "IMPL": In this case the device type is implicitly defined, either 216 because the SMS Center knows it, or because it can be concluded on 217 the basis of the address. 219 "TELEX": Telex device 221 "G3FAX": Group 3 telefax device 223 "G4FAX": Group 4 telefax device 224 "VOICE": Voice telephone (this requires conversion to speech, but 225 there is no mechanism to specify a language) 227 "ERMES": ERMES (European Radio Messaging System) 229 "NATPAG": National paging system (this does not specify a specific 230 paging systems but implies that the SMS center knows about a 231 particular national paging system) 233 "VIDEOTEX": Videotex 235 teletex: Teletex, either with an unspecified carrier or using PSPDN, 236 CSPDN, PSTN, or ISDN as carrier 238 "UCI": UCI (Universal Computer Interface) 240 reserved: 7 combinations are reserved which do not have a specified 241 meaning 243 "MH": Some message handling facility known to the SMS center (not 244 further specified) 246 x400: X.400-based message handling system 248 The SMS specification fails to specify how X.400 OR addresses are 249 actually embedded into SMS messages, so even though there is a 250 Protocol Identifier for X.400, it is impossible to encode the 251 recipient(s) of a message. 253 email: Internet electronic mail 255 The recipient(s) of SMS messages gatewayed to Internet electronic 256 mail are specified in the message's user data in a way defined by 257 the SMS specification. 259 specific: 7 combinations are defined to have a meaning specific to 260 each SMS center, their usage is based on mutual agreement between 261 SMS clients and the SMS center. 263 It is important to notice that some of the above devices require 264 additional information to be specified (in particular, the "Internet 265 electronic mail" format). The SMS specification defines the methods 266 how this has to be done (effectively by embedding the email 267 information into the SMS message's text). 269 2. IANA registrations 271 Based on the requirements defined in RFC 3191 [RFC3191], the IANA 272 registration forms for the "SMS" service-selector, and "SMSC" and 273 "PID" qualif-type1 elements are defined here. Syntax definitions are 274 given using the Augmented BNF for Syntax Specifications [RFC2234]. 276 2.1 IANA registration form for GSTN address service-selector "SMS" 278 To: IANA@iana.org 279 Subject: Registration of new values for the GSTN address 280 service-selector specifier "SMS" 282 service-selector name: SMS 284 Description of Use: SMS - specify that the GSTN address refers to a 285 GSTN subscriber who is capable of receiving messages using the GSM 286 Short Message Service (SMS). However, if a "PID" qualif-type1 287 element is present for this service selector, then the GSTN 288 address must be interpreted according to the rules for the "PID" 289 qualif-type1 element's value (this may also mean that the GSTN 290 address has to be ignored). 292 For a complete description refer to RFC 3191 and 293 draft-wilde-sms-service-07. 295 Security Considerations: See the Security Consideration section of 296 draft-wilde-sms-service-07. 298 Person & email address to contact for further information: 300 Erik Wilde 301 Swiss Federal Institute of Technology 302 ETH-Zentrum 303 8092 Zurich 304 Switzerland 305 tel:+41-1-6325132 306 fax:+41-1-6321035 307 mailto:erik.wilde@dret.net 309 2.2 IANA registration form for GSTN address qualit-type1 keyword "SMSC" 310 and value 312 To: IANA@iana.org 313 Subject: Registration of new values for the GSTN address 314 qualif-type1 element "SMSC" 316 qualif-type1 "keyword" name: SMSC 318 qualif-type1 "value" ABNF definition: The ABNF definition for the 319 value of the SMSC keyword is taken from RFC 3601 321 sub-addr = gstn-phone 322 gstn-phone = ( global-phone / local-phone ) 323 global-phone = "+" 1*( DIGIT / written-sep ) 324 local-phone = [ exit-code ] dial-number / exit-code [ dial-number ] 325 exit-code = phone-string 326 dial-number = phone-string 327 phone-string = 1*( DTMF / pause / tonewait / written-sep ) 328 DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" ) 329 pause = "p" 330 tonewait = "w" 331 written-sep = ( "-" / "." ) 333 Description of Use: SMSC - In some situations, it may be necessary to 334 guide the sender of an SMS message to send the message via a 335 certain Short Message Service Center (SMSC). If the SMSC 336 qualif-type1 element is present, an SMS client SHOULD try to send 337 the message first using the specified SMSC. If that fails, the 338 SMS client MAY try another SMSC (such as the default SMSC for that 339 client). 341 Further description is available in draft-wilde-sms-service-07 343 Use Restriction: The use of the "SMSC" qualif-type1 element is 344 restricted to the "SMS" service-selector, it has no meaning 345 outside the SMS service defined by the "SMS" service-selector. 347 Security Considerations: See the Security Consideration section of 348 draft-wilde-sms-service-07. 350 Person & email address to contact for further information: 352 Erik Wilde 353 Swiss Federal Institute of Technology 354 ETH-Zentrum 355 8092 Zurich 356 Switzerland 357 tel:+41-1-6325132 358 fax:+41-1-6321035 359 mailto:erik.wilde@dret.net 361 2.3 IANA registration form for GSTN address qualit-type1 keyword "PID" 362 and value 364 To: IANA@iana.org 365 Subject: Registration of new values for the GSTN address 366 qualif-type1 element "PID" 368 qualif-type1 "keyword" name: PID 370 qualif-type1 "value" ABNF definition: The ABNF syntax definition of 371 the PID qualifier is as follows: 373 sub-addr = "IMPL" / "TELEX" / "G3FAX" / "G4FAX" / "VOICE" 374 / "ERMES" / "NATPAG" / "VIDEOTEX" / teletex / "UCI" 375 / reserved / "MH" / "X400" / email / specific 376 teletex = "TELETEX-" 377 ( "UNSPEC" / "PSPDN" / "CSPDN" / "PSTN" / "ISDN" ) 378 email = "SMTP:" address 379 reserved = "RES" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 380 specific = "SPEC" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 382 The "x400" definition is functionally incomplete (because there is 383 no way how the actual OR address can be specified), but provided 384 here for completeness. 386 The "address" definition is taken from RFC 2822 [RFC2822] and 387 specifies an address that may either be an individual mailbox, or 388 a group of mailboxes. 390 Description of Use: PID - The protocol identifier is used to specify 391 SMS Telematic Interworking by selecting a specific protocol to use 392 for delivery to the recipient. 394 Further description is available in draft-wilde-sms-service-07 396 Use Restriction: The use of the "PID" qualif-type1 element is 397 restricted to the "SMS" service-selector, it has no meaning 398 outside the SMS service defined by the "SMS" service-selector. 400 Security Considerations: See the Security Consideration section of 401 draft-wilde-sms-service-07. 403 Person & email address to contact for further information: 405 Erik Wilde 406 Swiss Federal Institute of Technology 407 ETH-Zentrum 408 8092 Zurich 409 Switzerland 410 tel:+41-1-6325132 411 fax:+41-1-6321035 412 mailto:erik.wilde@dret.net 414 3. Security Considerations 416 SMS messages are transported without any provisions for privacy or 417 integrity, so SMS users should be aware of these inherent security 418 problems of SMS messages. Unlike electronic mail, where additional 419 mechanisms exist to layer security features on top of the 420 infrastructure, there currently is no such framework for SMS 421 messages. 423 SMS messages very often are delivered almost instantaneously (if the 424 receiving SMS client is on line), but there is no guarantee for when 425 SMS messages will be delivered. In particular, SMS messages between 426 different network operators sometimes take a long time to be 427 delivered (hours or even days) or are not delivered at all, so 428 applications SHOULD NOT make any assumptions about the reliability 429 and performance of SMS message transmission. 431 In most networks, sending SMS messages is not a free service. 432 Therefore, SMS clients MUST make sure that any action that incurs 433 costs is acknowledged by the end user, unless explicitly instructed 434 otherwise by the end user. If an SMS client has different ways of 435 submitting an SMS message (such as a Web service and a phone line), 436 then the end user MUST have a way to control which way is chosen. 438 SMS clients often are limited devices (typically mobile phones), and 439 the sending SMS client SHOULD NOT make any assumptions about the 440 receiving SMS client supporting any non-standard services, such as 441 proprietary message concatenation or proprietary content types. 442 However, if the sending SMS client has prior knowledge about the 443 receiving SMS client, then he MAY use this knowledge to compose 444 non-standard SMS messages. 446 There are certain special SMS messages defined in [SMS] that can be 447 used, for example, to turn on indicators on the phone display, or to 448 send data to certain communication ports (comparable to UDP ports) on 449 the device. Certain proprietary systems (for example, the Wireless 450 Application Protocol [WAP])define configuration messages that may be 451 used to reconfigure the devices remotely. Any SMS client SHOULD make 452 sure that malicious use of such messages is not possible, for example 453 by filtering out certain SMS User Data headers. Gateways that accept 454 SMS messages e.g. in e-mail messages or web forms and pass them on 455 to an SMSC SHOULD implement this kind of 'firewalling' approach as 456 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 4.1 From -06 to -07 473 o Changed IPR clause from RFC 2026 to RFC 3667 (updated version of 474 RFC 2026) 476 4.2 From -05 to -06 478 o Updated reference from draft-allocchio-gstn-05 to RFC 3601. 480 4.3 From -04 to -05 482 o No changes, re-release for alignment with draft-wilde-sms-uri. 484 4.4 From -03 to -04 486 o Updated reference to draft-allocchio-gstn (to revision -05). 488 4.5 From -02 to -03 490 o Changed ordering of "change Log" section (descending to 491 ascending). 493 o Fixed some spelling errors. 495 4.6 From -01 to -02 497 o Removed address specification for X.400 SMS from ABNF 498 (surprisingly not part of the SMS spec). 500 o Added some explanatory text about character set mapping for SMS 501 messages. 503 o Added text requiring the use of message class 1 for sending SMS 504 messages. 506 4.7 From -00 to -01 508 o Added a number of new security considerations. 510 o Added the "PID" qualif-type1 keyword and the section about "SMS 511 Telematic Interworking" Section 1.2.3. 513 5. References 515 5.1 Normative References 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", RFC 2119, March 1997. 520 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 521 Mapping between X.400 and RFC 822/MIME", RFC 2156, January 522 1998. 524 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 525 Specifications: ABNF", RFC 2234, November 1997. 527 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 528 2001. 530 [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet 531 Mail", RFC 3191, October 2001. 533 [RFC3601] Allocchio, C., "Text string notation for Dial Sequences 534 and GSTN / E.164 addresses", RFC 3601, September 2003. 536 [SMS] European Telecommunications Standards Institute, "ETSI TS 537 100 901 (GSM 03.40 version 7.3.0 Release 1998): Digital 538 Cellular Telecommunications System (Phase 2+); Technical 539 realization of the Short Message Service (SMS); 540 Point-to-Point (PP)", November 1999, 541 . 543 [SMS-CHAR] 544 European Telecommunications Standards Institute, "ETSI TS 545 100 901 (GSM 03.38 version 7.2.0 Release 1998): Digital 546 Cellular Telecommunications System (Phase 2+); Alphabets 547 and language-specific information", July 1999, 548 . 550 [draft-wilde-sms-service-07] 551 Wilde, E., "Registration of GSTN SMS Service Qualifier", 552 draft-wilde-sms-service-07 (work in progress), Jul 2004. 554 [draft-wilde-sms-uri-07] 555 Wilde, E., "URI scheme for GSM Short Message Service", 556 draft-wilde-sms-service-07 (work in progress), Jul 2004. 558 5.2 Non-Normative References 560 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 561 June 1999. 563 [WAP] WAP Forum, "Wireless Application Protocol - Architecture 564 Specification (WAP-210-WAPArch-20010712)", July 2001. 566 Author's Address 568 Erik Wilde 569 Swiss Federal Institute of Technology 570 ETH-Zentrum 571 8092 Zurich 572 Switzerland 574 Phone: +41-1-6325132 575 EMail: erik.wilde@dret.net 576 URI: http://dret.net/netdret/ 578 Appendix A. Where to send Comments 580 Please send all comments and questions concerning this document to 581 Erik Wilde. 583 Appendix B. Acknowledgements 585 This document has been prepared using the IETF document DTD described 586 in RFC 2629 [RFC2629]. 588 Thanks to Claudio Allocchio and Antti Vaha-Sipila for their comments. 590 Intellectual Property Statement 592 The IETF takes no position regarding the validity or scope of any 593 Intellectual Property Rights or other rights that might be claimed to 594 pertain to the implementation or use of the technology described in 595 this document or the extent to which any license under such rights 596 might or might not be available; nor does it represent that it has 597 made any independent effort to identify any such rights. Information 598 on the procedures with respect to rights in RFC documents can be 599 found in BCP 78 and BCP 79. 601 Copies of IPR disclosures made to the IETF Secretariat and any 602 assurances of licenses to be made available, or the result of an 603 attempt made to obtain a general license or permission for the use of 604 such proprietary rights by implementers or users of this 605 specification can be obtained from the IETF on-line IPR repository at 606 http://www.ietf.org/ipr. 608 The IETF invites any interested party to bring to its attention any 609 copyrights, patents or patent applications, or other proprietary 610 rights that may cover technology that may be required to implement 611 this standard. Please address the information to the IETF at 612 ietf-ipr@ietf.org. 614 Disclaimer of Validity 616 This document and the information contained herein are provided on an 617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 619 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 620 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 621 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 624 Copyright Statement 626 Copyright (C) The Internet Society (2005). This document is subject 627 to the rights, licenses and restrictions contained in BCP 78, and 628 except as set forth therein, the authors retain all their rights. 630 Acknowledgment 632 Funding for the RFC Editor function is currently provided by the 633 Internet Society.