idnits 2.17.1 draft-antti-gsm-sms-url-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC1738' is defined on line 268, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-antti-telephony-url-05 ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2303 (Obsoleted by RFC 3191) ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) -- Possible downref: Non-RFC (?) normative reference: ref. 'UCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'TDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMS' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Vaha-Sipila 2 Expires 24-Nov-1999 Nokia 3 19-May-1999 5 URLs for GSM Short Message Service 6 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 The distribution of this document before its expiry date is 36 unlimited. 38 Abstract 40 This document specifies a URL (Uniform Resource Locator) scheme "sms" 41 for specifying a recipient for an alphanumeric message (Short 42 Message) in a GSM-based mobile phone system. Short Messages are two- 43 way paging messages that can be sent from a suitably equipped 44 computer or a phone. 46 Table of Contents 48 1. Introduction ................................................ 3 50 1.1 What is GSM? .............................................. 3 52 1.2 Short Message Service ...................................... 3 54 1.3 Short Messages and the Internet ............................ 3 56 1.4 Formal Definitions ......................................... 4 58 1.5 Requirements ............................................... 4 60 2. The "sms" URL Scheme ........................................ 4 62 2.1 Applicability .............................................. 4 64 2.2 Formal Definition .......................................... 5 66 2.3 Parsing a "sms" URL ........................................ 5 68 2.4 Examples of Use ............................................ 6 70 2.5 Using "sms" URLs in HTML Forms ............................. 6 72 3. References .................................................. 6 74 4. Security Considerations ..................................... 7 76 5. Authors' Addresses .......................................... 8 78 6. Full Copyright Statement .................................... 8 80 1. Introduction 82 1.1 What is GSM? 84 GSM (Global System for Mobile Communications) is a digital mobile 85 phone standard which is used extensively in many parts of the world. 86 Named after its frequency band around 900 MHz, GSM-900 has provided 87 the basis for several other networks utilizing GSM technology. When 88 referring to "GSM" in this document, we mean any of these GSM-based 89 networks that operate a short message service. 91 1.2 Short Message Service 93 Short Messages [SMS] are two-way alphanumeric paging messages that 94 can be sent to and from GSM mobile phones. Short Messages can be 95 transmitted over the mobile phone's air interface using the 96 signalling channels so there is no delay for call setup. Short 97 Messages are stored by an entity called Short Message Service Centre 98 (SMSC) and sent to the recipient when the subscriber connects to the 99 network. The number of a cooperative SMSC must be known to the sender 100 when sending the message. 102 Short Messages can be mobile terminated (MT) or mobile originated 103 (MO). Mobile terminated messages are the ones that arrive to phones; 104 mobile originating messages are sent by a mobile subscriber. Networks 105 may support either, both or none of these. 107 A service similar to GSM SMS can be found also in other mobile phone 108 systems, but it may be called something else. The sender may not be 109 able to know whether it is capable of successfully sending a Short 110 Message to the recipient. The success depends on whether the network 111 operators have a suitable roaming agreement and a mechanism to 112 deliver the messages (theoretically it is possible to deliver short 113 messages between different network types, but this is not common at 114 the moment). It should be the network operator's responsibility to 115 inform the user about a success or a failure of the message delivery. 117 If there is a need to use the same scheme specifier for other network 118 types than GSM, this document should be updated. 120 1.3 Short Messages and the Internet 122 Short Messages can be used to transport almost any kind of data. 123 Some examples of possible uses for a Short Message are described 124 below. 126 The Hypertext Markup Language (HTML) provides a way to collect 127 information from the user and pass it to a remote server for 128 processing. This functionality is known as "forms". A filled-in form 129 is usually sent to the destination using Hypertext Transfer Protocol 130 (HTTP) or mail. Short Messages can be used as the transport for these 131 forms. As the Short Message service is "out-of-band" as far as normal 132 HTTP-over-TCP/IP is concerned, this provides a way to fill in forms 133 offline and send the data without making a TCP connection to the 134 remote server, as the set-up time, cost and overhead for a TCP 135 connection are large compared to a Short Message. Also, depending on 136 the network configuration, the sender's telephone number may be 137 included in the Short Message, thus providing a weak form of 138 authentication. 140 Short Messages can also provide an alternative to a "mailto" type 141 URL. When a "sms" type URL is activated, the user agent MAY start a 142 program for sending an SMS message, just as "mailto" may open a mail 143 client. 145 The recipient need not to be a mobile phone. It can be a server that 146 can process Short Messages, either by gatewaying them to another 147 messaging system or by parsing them for supplementary services. 149 GSM Short Messages have a maximum length of 160 characters (from the 150 SMS character set), or 140 octets. However, Short Messages can be 151 concatenated to form longer messages. It is up to the user agent to 152 decide whether to limit the length of the message and how to indicate 153 this limit in its user interface, if necessary. There is one 154 exception to this, see section 2.5. 156 1.4 Formal Definitions 158 Definitions are written using Augmented BNF for Syntax Specifications 159 [RFC2234]. 161 1.5 Requirements 163 Compliant software MUST follow this specification. Requirements are 164 indicated by capitalized words as specified in [RFC2119]. 166 2. The "sms" URL Scheme 168 2.1 Applicability 170 This URL scheme is intended for sending a Short Message to a certain 171 recipient(s) through service centre(s). The functionality is quite 172 similar to that of the "mailto" URL, which (as per [RFC2368]) can 173 also be used with a comma-separated list of email addresses. 175 In some situations, it may be necessary to guide the sender to send 176 the Short Message via a certain SMSC. For this purpose, this URL may 177 specify the number of the SMSC. 179 The notation for phone numbers is similar to that if [DRAFT-TELURL]. 180 Refer to that document and to [RFC2303] for information on why this 181 particular format was chosen. 183 How the Short Message is sent to the SMSC is outside the scope of 184 this specification. Short Messages can be sent over the GSM air 185 interface or by using a modem and a suitable protocol (such as UCP 186 [UCP] or TDP [TDP]). Also, Short Message service options like 187 deferred delivery and delivery notification requests are not in the 188 scope of this document. Such services MAY be requested from the 189 network by the user agent if necessary. 191 Short Messages sent as a result of this URL MUST be sent as class 1 192 Short Messages, if the user agent is able to specify the message 193 class. 195 2.2 Formal Definition 197 The URL is case-insensitive. The URL syntax is formally described as 198 follows: 200 sms-url = scheme ":" scheme-specific-part 201 scheme = "sms" 202 scheme-specific-part = subscriber-id [";via=" message-centre-id] 203 ["," scheme-specific-part] 204 subscriber-id = ["+"] phone-number 205 message-centre-id = ["+"] phone-number 206 phone-number = 1*phonedigit 207 phonedigit = digit / "-" / "." 208 digit = "0" / "1" / "2" / "3" / "4" / "5" / 209 "6" / "7" / "8" / "9" 211 2.3 Parsing a "sms" URL 213 1. is extracted. It is the phone number of the final 214 recipient and it MUST be written in international form with country 215 code, unless the number only works from inside a certain geographical 216 area or a network. Note that some numbers may work from several 217 networks but not from the whole world - these SHOULD be written in 218 international form. All international numbers MUST begin with a "+" 219 character. Hyphens and dots are only to aid readability. They MUST 220 NOT have any other meaning. 222 2. is extracted if present. User-agent SHOULD try 223 to send the message first using this SMSC. If that fails, user-agent 224 MAY try another SMSC. The number of the SMSC is subject to the same 225 rules as the "subscriber-id" (see above). 227 3. If the URL consists of a comma-separated list of recipients, all 228 of them are processed in this manner. Exactly the same content SHOULD 229 be sent to all of the listed recipients. 231 2.4 Examples of Use 233 sms:+3585551234567 235 This indicates a mobile terminated (MT) Short Message capable 236 recipient at the given telephone number. The message is sent using 237 the user-agent's default SMSC. 239 sms:+3585551234567;via=+3585551000100 241 This indicates that the Short Message should be sent using the SMSC 242 at the given number. 244 2.5 Using "sms" URLs in HTML Forms 246 When using a "sms" type URL as an action URL for HTML form submission 247 [RFC1866], the form contents MUST be packaged in the Short Message 248 just as they are packaged when using a "mailto" URL [RFC2368], using 249 "application/x-www-form-urlencoded" MIME type [RFC1866]. The Short 250 Message MUST NOT contain any HTTP headers, only the form data. The 251 MIME type is implicit. It will not be transferred in the Short 252 Message. 254 The user agent SHOULD inform the user about the possible security 255 hazards involved when submitting the form. 257 If the form submission is longer than the maximum Short Message size, 258 the user agent MAY either concatenate Short Messages, if it is able 259 to do so, or it MAY refuse to send the message. The user agent MUST 260 NOT send out partial form submissions. 262 3. References 264 [DRAFT-TELURL] URLs for Telephony. A. Vaha-Sipila. 1998. An 265 Internet-Draft (work in progress). 268 [RFC1738] Uniform Resource Locators (URL). December 1994. T. 269 Berners-Lee et al. 271 [RFC1866] Hypertext Markup Language - 2.0. T. Berners-Lee et al. 272 November 1995. RFC 1866. 274 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. 275 April 1997. S. Bradner. 277 [RFC2234] Augmented BNF for Syntax Specifications: ABNF. November 278 1997. D. Crocker et al. RFC 2234. 279 281 [RFC2303] Minimal PSTN Address Format in Internet Mail. March 1998. 282 C. Allocchio. RFC 2303. 284 [RFC2368] The mailto URL Scheme. July 1998. P. Hoffman et al. RFC 285 2368. 287 [UCP] Paging Systems; European Radio Message System (ERMES) (ETS 300 288 133-3). Part 3: Network Aspects. July 1992. European 289 Telecommunications Standards Institute. 291 [TDP] Telocator Data Paging Protocol (TDP). Version 2.0. July 27, 292 1995. Personal Communications Industry Association. 293 295 [SMS] Digital Cellular Telecommunications System (Phase 2+): 296 Technical Realization of the Short Message Service (SMS) Point-to- 297 Point (PP) (GSM 3.40). Version 5.2.0. May 1996. European 298 Telecommunications Standards Institute. 300 4. Security Considerations 302 It should be noted that the user agent SHOULD NOT send out Short 303 Messages without the knowledge of the user because of associated 304 risks, which include sending masses of Short Messages to a subscriber 305 without her consent and the costs involved in sending a Short 306 Message. 308 The user agent SHOULD have some mechanism that the user can use to 309 filter out unwanted destinations for Short Messages. The user agent 310 SHOULD also have some means of restricting the number of Short 311 Messages sent. 313 5. Authors' Addresses 315 Contact person and version control responsibility for this 316 specification: 318 Nokia Mobile Phones 319 Antti Vaha-Sipila 320 P. O. Box 68 321 FIN-33721 Tampere 322 Finland 324 Electronic mail: antti.vaha-sipila@nmp.nokia.com 326 Please include your name and electronic mail address in all 327 communications. If you want to receive the newest version of this 328 specification electronically, send mail to the address above. 330 This document expires on the 24th of November, 1999, or when a new 331 version is released. 333 6. Full Copyright Statement 335 To be included in the final RFC submission.