idnits 2.17.1 draft-wilde-sms-uri-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The "body" is used to define the body of the SMS message to be composed. It MUST not appear more than once in an "sms" URI. It consists of percent-encoded UTF-8 characters. Implementations MUST make sure that the "body" characters are converted to a suitable character encoding before sending, the most popular being the 7-bit SMS character encoding, another variant (though not as universally supported as 7-bit SMS) is the UCS-2 character encoding (both specified in [SMS-CHAR]). Implementations MAY choose to discard (or convert) characters in the that are not supported by the SMS character set they are using to send the SMS message. If they do discard or convert characters, they MUST notify the user. -- 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 (Oct 23, 2009) is 5297 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML401' ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMS-CHAR' -- Obsolete informational reference (is this intentional?): RFC 2368 (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Wilde 3 Internet-Draft UC Berkeley 4 Intended status: Standards Track A. Vaha-Sipila 5 Expires: April 26, 2010 Nokia 6 Oct 23, 2009 8 URI Scheme for GSM Short Message Service 9 draft-wilde-sms-uri-20 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 26, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This memo specifies the Uniform Resource Identifier (URI) scheme 48 "sms" for specifying one or more recipients for an SMS message. SMS 49 messages are two-way paging messages that can be sent from and 50 received by a mobile phone or a suitably equipped networked device. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. What is GSM? . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. What is SMS? . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. The "sms" URI Scheme . . . . . . . . . . . . . . . . . . . . . 7 58 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 59 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 8 60 2.3. Processing an "sms" URI . . . . . . . . . . . . . . . . . 10 61 2.4. Comparing "sms" URIs . . . . . . . . . . . . . . . . . . . 10 62 2.5. Examples of Use . . . . . . . . . . . . . . . . . . . . . 11 63 2.6. Using "sms" URIs in HTML Forms . . . . . . . . . . . . . . 11 64 3. URI Scheme Registration . . . . . . . . . . . . . . . . . . . 12 65 3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 12 66 3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 12 68 3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 12 69 3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 13 70 3.6. Applications/Protocols that use this URI Scheme Name . . . 13 71 3.7. Interoperability Considerations . . . . . . . . . . . . . 13 72 3.8. Security Considerations . . . . . . . . . . . . . . . . . 13 73 3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 6.1. From -19 to -20 . . . . . . . . . . . . . . . . . . . . . 15 78 6.2. From -18 to -19 . . . . . . . . . . . . . . . . . . . . . 15 79 6.3. From -17 to -18 . . . . . . . . . . . . . . . . . . . . . 16 80 6.4. From -16 to -17 . . . . . . . . . . . . . . . . . . . . . 16 81 6.5. From -15 to -16 . . . . . . . . . . . . . . . . . . . . . 16 82 6.6. From -14 to -15 . . . . . . . . . . . . . . . . . . . . . 17 83 6.7. From -13 to -14 . . . . . . . . . . . . . . . . . . . . . 17 84 6.8. From -12 to -13 . . . . . . . . . . . . . . . . . . . . . 17 85 6.9. From -11 to -12 . . . . . . . . . . . . . . . . . . . . . 18 86 6.10. From -10 to -11 . . . . . . . . . . . . . . . . . . . . . 18 87 6.11. From -09 to -10 . . . . . . . . . . . . . . . . . . . . . 18 88 6.12. From -08 to -09 . . . . . . . . . . . . . . . . . . . . . 18 89 6.13. From -07 to -08 . . . . . . . . . . . . . . . . . . . . . 18 90 6.14. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 19 91 6.15. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 19 92 6.16. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 19 93 6.17. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 19 94 6.18. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 19 95 6.19. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 19 96 6.20. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 19 97 6.21. Change Log of draft-wilde-sms-service . . . . . . . . . . 20 98 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 101 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 102 Appendix A. Syntax of 'telephone-subscriber' . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 105 1. Introduction 107 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 108 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in RFC 110 2119 [RFC2119]. 112 1.1. What is GSM? 114 GSM (Global System for Mobile Communications) is a digital mobile 115 phone standard which is used extensively in many parts of the world. 116 First named after its frequency band around 900 MHz, GSM-900 has 117 provided the basis for several other networks utilizing GSM 118 technology, in particular GSM networks operating in the frequency 119 bands around 1800 MHz and 1900 MHz. When referring to "GSM" in this 120 document, we mean any of these GSM-based networks that operate a 121 short message service. 123 1.2. What is SMS? 125 The Short Message Service (SMS) [SMS] is an integral part of the GSM 126 network technology. It has been very successful and currently is a 127 major source of revenue for many GSM operators. SMS as a service is 128 so successful that other Global Switched Telephone Network (GSTN) 129 technologies have adopted it as well, in particular the Integrated 130 Services Digital Network (ISDN). Because of this development, this 131 memo uses the term "SMS client" to refer to user agents that are able 132 to send and/or receive SMS messages. 134 1.2.1. SMS content 136 GSM SMS messages are alphanumeric paging messages that can be sent to 137 and from SMS clients. SMS messages have a maximum length of 160 138 characters (7-bit characters from the GSM character set [SMS-CHAR]), 139 or 140 octets. Other character sets (such as UCS-2 16-bit 140 characters, resulting in 70 character messages) MAY also be supported 141 [SMS-CHAR], but are defined as being optional by the SMS 142 specification. Consequently, applications handling SMS messages as 143 part of a chain of character processing applications MUST make sure 144 that character sets are correctly mapped to and from the character 145 set used for SMS messages. 147 While the 160 character variety for SMS messages is by far the most 148 widely used one, there are numerous other content types for SMS 149 messages, such as small bitmaps ("operator logos") and simple formats 150 for musical notes ("ring tones"). However, these formats are 151 proprietary and are not considered in this memo. 153 SMS messages are limited in length (140 octets), and the first 154 versions of the SMS specification did not specify any standardized 155 methods for concatenating SMS messages. As a consequence, several 156 proprietary methods were invented, but the current SMS specification 157 does specify message concatenation. In order to deal with this 158 situation, SMS clients composing messages SHOULD use the standard 159 concatenation method based on the header in the TP-User Data field as 160 specified in the SMS specification [SMS]. When sending a message to 161 an SMS recipient whose support for concatenated messages is unknown, 162 the SMS client MAY opt to use the backwards-compatible (text-based) 163 concatenation method defined in the SMS specification [SMS]. 164 Proprietary concatenation methods SHOULD NOT be used except in closed 165 systems, where the capabilities of the recipient(s) are always known. 167 1.2.2. SMS infrastructure 169 SMS messages can be transmitted over an SMS client's network 170 interface using the signaling channels of the underlying GSTN 171 infrastructure, so there is no delay for call setup. Alternatively, 172 SMS messages may be submitted through other front-ends (for example 173 Web-based services), which makes it possible for SMS clients to run 174 on computers which are not directly connected to a GSTN network 175 supporting SMS. 177 SMS messages sent with the GSTN SMS service MUST be sent as class 1 178 SMS messages, if the client is able to specify the message class. 180 1.2.2.1. SMS Centers 182 For delivery within GSTN networks, SMS messages are stored by an 183 entity called SMS Center (SMSC), and sent to the recipient when the 184 subscriber connects to the network. The number of a cooperative SMSC 185 must be known to the SMS sender (i.e., the entity submitting the SMS 186 message to a GSTN infrastructure) when sending the message (usually, 187 the SMSC's number is configured in the SMS client and specific for 188 the network operator to which the sender has subscribed). In most 189 situations, the SMSC number is part of the sending SMS client's 190 configuration. However, in some special cases (such as when the SMS 191 recipient only accepts messages from a certain SMSC), it may be 192 necessary to send the SMS message over a specific SMSC. The scheme 193 specified in this memo does not support the specification of SMSC 194 numbers, so in case of scenarios where messages have to be sent 195 through a certain SMSC, there must be some other context establishing 196 this requirement, or message delivery may fail. 198 1.2.3. Uniform Resource Identifiers 200 One of the core specifications for identifying resources on the 201 Internet is RFC 3986 [RFC3986], specifying the syntax and semantics 202 of a Uniform Resource Identifier (URI). The most important notion of 203 URIs are "schemes", which define a framework within which resources 204 can be uniquely identified and addressed. URIs enable users to 205 access resources, and are used for very diverse schemes such as 206 access protocols (HTTP, FTP), broadcast media (TV channels 207 [RFC2838]), messaging (email [RFC2368]), and even telephone numbers 208 (voice [RFC3966]). 210 URIs often are mentioned together with Uniform Resource Names (URNs) 211 and/or Uniform Resource Locators (URLs), and it often is unclear how 212 to separate these concepts. For the purpose of this memo, only the 213 term URI will be used, referring to the most fundamental concept. 214 The World Wide Web Consortium (W3C) has issued a note 215 [uri-clarification] discussing the topic of URIs, URNs, and URLs in 216 detail. 218 1.2.4. SMS Messages and the Internet 220 One of the important reasons for the universal access of the Web is 221 the ability to access all information through a unique interface. 222 This kind of integration makes it easy to provide information as well 223 as to consume it. One aspect of this integration is the support of 224 user agents (in the case of the Web, commonly referred to as 225 browsers) for multiple content formats (such as HTML, GIF, JPEG) and 226 access schemes (such as HTTP, HTTPS, FTP). 228 The "mailto" scheme has proven to be very useful and popular, because 229 most user agents support it by providing an email composition 230 facility when the user selects (e.g., clicks on) the URI. Similarly, 231 the "sms" scheme can be supported by user agents by providing an SMS 232 message composition facility when the user selects the URI. In cases 233 where the user agent does not provide a built-in SMS message 234 composition facility, the scheme could still be supported by opening 235 a Web page which provides such a service. The specific Web page to 236 be used could be configured by the user, so that each user could use 237 the SMS message composition service of his choice. 239 The goal of this memo is to specify the "sms" URI scheme, so that 240 user agents (such as Web browsers and email clients) can start to 241 support it. The "sms" URI scheme identifies SMS message endpoints as 242 resources. When "sms" URIs are dereferenced, implementations MAY 243 create a message and present it to be edited before being sent, or 244 they MAY invoke additional services to provide the functionality 245 necessary for composing a message and sending it to the SMS message 246 endpoint. In either case, simply activating a link with an "sms" URI 247 SHOULD NOT cause a message to be sent without prior user 248 confirmation. 250 1.2.4.1. SMS Messages and the Web 252 SMS messages can provide an alternative to "mailto" URIs [RFC2368], 253 or "tel" or "fax" URIs [RFC3966]. When a "sms" URI is activated, the 254 user agent MAY start a program for sending an SMS message, just as 255 "mailto" may open a mail client. Unfortunately, most browsers do not 256 support the external handling of internally unsupported URI schemes 257 in the same generalized way as most of them support external handling 258 of content for media types which they do not support internally. 259 Ideally, user agents should implement generic URI parsers and provide 260 a way to associate unsupported schemes with external applications (or 261 Web-based services). 263 The recipient of an SMS message need not be a mobile phone. It can 264 be a server that can process SMS messages, either by gatewaying them 265 to another messaging system (such as regular electronic mail), or by 266 parsing them for supplementary services. 268 SMS messages can be used to transport almost any kind of data (even 269 though there is a very tight size limit), but the only standardized 270 data formats are character-based messages in different character 271 encodings. SMS messages have a maximum length of 160 characters 272 (when using 7-bit characters from the SMS character set), or 140 273 octets. However, SMS messages can be concatenated to form longer 274 messages. It is up to the user agent to decide whether to limit the 275 length of the message, and how to indicate this limit in its user 276 interface, if necessary. There is one exception to this, see 277 Section 2.6. 279 1.2.4.2. SMS Messages and Forms 281 The Hypertext Markup Language (HTML) [HTML401] provides a way to 282 collect information from a user and pass it to a server for 283 processing. This functionality is known as "HTML forms". A 284 filled-in form is usually sent to the destination using the Hypertext 285 Transfer Protocol (HTTP) or email. However, SMS messages can also be 286 used as the transport mechanism for these forms. Depending on the 287 network configuration, the sender's telephone number may be included 288 in the SMS message, thus providing a weak form of authentication. 290 2. The "sms" URI Scheme 292 Syntax definitions are given using the Augmented BNF (ABNF) for 293 syntax specifications [RFC5234]. 295 2.1. Applicability 297 This URI scheme provides information that can be used for sending SMS 298 message(s) to specified recipient(s). The functionality is 299 comparable to that of the "mailto" URI, which (as per RFC 2368 300 [RFC2368]) can also be used with a comma-separated list of email 301 addresses. 303 The notation for phone numbers is taken from [RFC3966] and its 304 Erratum 203. Appendix A provides a corrected syntax of the telephone 305 number. Refer to this document for information on why this 306 particular format was chosen. 308 How SMS messages are sent to the SMSC or other intermediaries is 309 outside the scope of this specification. SMS messages can be sent 310 over the GSM air interface, by using a modem and a suitable protocol, 311 or by accessing services over other protocols, such as a Web-based 312 service for sending SMS messages. Also, SMS message service options 313 like deferred delivery and delivery notification requests are not 314 within the scope of this document. Such services MAY be requested 315 from the network by the user agent if necessary. 317 SMS messages sent as a result of this URI MUST be sent as class 1 SMS 318 messages, if the user agent is able to specify the message class. 320 2.2. Formal Definition 322 The URI scheme's keywords specified in the following syntax 323 description are case-insensitive. The syntax of an "sms" URI is 324 formally described as follows, where the URI base syntax is taken 325 from RFC 3986 [RFC3986]: 327 sms-uri = scheme ":" sms-hier-part [ "?" sms-fields ] 328 scheme = "sms" 329 sms-hier-part = sms-recipient *( "," sms-recipient ) 330 sms-recipient = telephone-subscriber ; defined in RFC 3966 331 sms-fields = sms-field *( "&" sms-field ) 332 sms-field = sms-field-name "=" escaped-value 333 sms-field-name = "body" / sms-field-ext ; "body" MUST only appear once 334 sms-field-ext = 1*( unreserved ) 335 escaped-value = *( unreserved / pct-encoded ) ; defined in RFC 3986 337 Some illustrative examples using this syntax are given in 338 Section 2.5. 340 The syntax definition for is taken from RFC 341 3966 [RFC3966] (Section 5.1). Please consider Erratum 203 in that 342 specification. For the reader's convenience, Appendix A contains a 343 fixed syntax of the telephone number URI scheme including Erratum 344 203, but RFC 3966 (plus all applicable errata) is the normative 345 reference. The description of phone numbers in RFC 3966 states 346 (quoted from RFC 3966, Section 5.1): "The 'telephone-subscriber' part 347 of the URI indicates the number. The phone number can be represented 348 in either global (E.164) or local notation. All phone numbers MUST 349 use the global form unless they cannot be represented as such. 350 Numbers from private numbering plans, emergency ('911', '112'), and 351 some directory-assistance numbers (e.g., '411') and other 'service 352 codes' (numbers of the form N11 in the United States) cannot be 353 represented in global (E.164) form and need to be represented as a 354 local number with a context. Local numbers MUST be tagged with a 355 'phone-context'." 357 This specification defines a single : "body". Extensions 358 to this specification MAY define additional fields. Extensions MUST 359 NOT change the semantics of the specifications they are extending. 360 Unknown fields encountered in "sms" URIs MUST be ignored by 361 implementations. 363 The "body" is used to define the body of the SMS message 364 to be composed. It MUST not appear more than once in an "sms" URI. 365 It consists of percent-encoded UTF-8 characters. Implementations 366 MUST make sure that the "body" characters are converted 367 to a suitable character encoding before sending, the most popular 368 being the 7-bit SMS character encoding, another variant (though not 369 as universally supported as 7-bit SMS) is the UCS-2 character 370 encoding (both specified in [SMS-CHAR]). Implementations MAY choose 371 to discard (or convert) characters in the that are not 372 supported by the SMS character set they are using to send the SMS 373 message. If they do discard or convert characters, they MUST notify 374 the user. 376 The syntax definition for refers to the text of an 377 SMS where all (as per RFC 3986 [RFC3986]) characters in 378 the SMS text are percent-encoded, please refer to RFC 3986 [RFC3986] 379 for the definition of and , and the details 380 about percent-encoding. 382 User agents SHOULD support multiple recipients, and SHOULD make it 383 clear to users what the entire list of recipients is, before 384 committing the user to sending all the messages. 386 2.3. Processing an "sms" URI 388 The following list describes the steps for processing an "sms" URI: 390 1. The phone number of the first is extracted. It 391 is the phone number of the final recipient and it MUST be written 392 in international form with country code, unless the number only 393 works from inside a certain geographical area or a network. Note 394 that some numbers may work from several networks but not from the 395 whole world - these SHOULD be written in international form. 396 According to RFC 3966 [RFC3966], all international numbers MUST 397 begin with a "+" character. Hyphens, dots, and parentheses 398 (referred to as "visual separators" in RFC 3966) are used only to 399 improve readability and MUST NOT convey any other meaning. 401 2. The "body" is extracted, if present. 403 3. The user agent SHOULD provide some means for message composition, 404 either by implementing this itself, or by accessing a service 405 providing it. Message composition SHOULD start with the body 406 extracted from the "body" , if present. 408 4. After message composition, a user agent SHOULD try to send the 409 message first using the default delivery method employed by that 410 user agent. If that fails, the user agent MAY try another 411 delivery method. 413 5. If the URI contains a comma-separated list of recipients (i.e., 414 it contains multiple parts), all of them are 415 processed in this manner. Exactly the same message SHOULD be 416 sent to all of the listed recipients, which means that the 417 message resulting from the message composition step for the first 418 recipient is used unaltered for all other recipients as well. 420 2.4. Comparing "sms" URIs 422 Two "sms" URIs are equivalent according to the following rules. 423 Since the definition of the is taken from RFC 424 3966 [RFC3966], equivalence of individual values of is based on the rules defined in Section 4 of RFC 3966 426 [RFC3966], repeated here for convenience: 428 o Both must be either a 'local-number' or a 'global-number', i.e., 429 start with a '+'. 431 o The 'global-number-digits' and the 'local-number-digits' must be 432 equal, after removing all visual separators. 434 o For mandatory additional parameters and the 'phone-context' and 435 'extension' parameters defined in RFC 3966 [RFC3966], the 'phone- 436 context' parameter value is compared as a host name if it is a 437 'domainname' or digit by digit if it is 'global-number-digits'. 438 The latter is compared after removing all 'visual-separator' 439 characters. 441 o Parameters are compared according to 'pname', regardless of the 442 order they appeared in the URI. If one URI has a parameter name 443 not found in the other, the two URIs are not equal. 445 o URI comparisons are case-insensitive. 447 Since "sms" URIs can contain multiple s as well 448 as , in addition to adopting the rules defined for 449 comparing as defined by RFC 3966 [RFC3966], 450 two "sms" URIs are only equivalent if their are 451 identical, and if all s, compared pairwise as a 452 set (i.e., without taking sequence into consideration), are 453 equivalent. 455 2.5. Examples of Use 457 sms:+15105550101 459 This indicates an SMS message capable recipient at the given 460 telephone number. The message is sent using the user agent's default 461 SMS delivery method. 463 sms:+15105550101,+15105550102 465 This indicates SMS message capable recipients at the given telephone 466 numbers. The identical message should be sent to both recipients 467 using the user agent's default SMS delivery method. 469 sms:+15105550101?body=hello%20there 471 In this case, a message (initially being set to "hello there", which 472 may be modified by the user before sending) will be sent via SMS 473 using the user agent's default SMS delivery method. 475 2.6. Using "sms" URIs in HTML Forms 477 When using a "sms" type URI as an action URI for HTML form submission 478 [HTML401], the form contents MUST be packaged in the SMS message just 479 as they are packaged when using a "mailto" URI [RFC2368], using the 480 "application/x-www-form-urlencoded" media type (as defined by HTML 481 [HTML401]), effectively packaging all form data into URI compliant 482 syntax [RFC3986]. The SMS message MUST NOT contain any HTTP header 483 fields, only the form data. The media type is implicit. It MUST NOT 484 be transferred in the SMS message. Since the SMS message contains 485 the form field values, the body of an "sms" type URI used 486 for an HTML form will be ignored. 488 The character encoding used for form submissions MUST be UTF-8 489 [RFC3629]. It should be noted, however, that user agents MUST 490 percent-encode form submissions before sending them (this encoding is 491 specified by the URI syntax [RFC3986]). 493 The user agent SHOULD inform the user about the possible security 494 hazards involved when submitting the form (it is probably being sent 495 as plain text over an air interface). 497 If the form submission is longer than the maximum SMS message size, 498 the user agent MAY either concatenate SMS messages, if it is able to 499 do so, or it MAY refuse to send the message. The user agent MUST NOT 500 send out partial form submissions. 502 3. URI Scheme Registration 504 This memo requests the registration of the Uniform Resource 505 Identifier (URI) scheme "sms" for specifying one or more recipients 506 for an SMS message. The registration request complies with RFC 4395 507 [RFC4395]. 509 3.1. URI Scheme Name 511 sms 513 3.2. Status 515 Permanent 517 3.3. URI Scheme Syntax 519 See Section 2. 521 3.4. URI Scheme Semantics 523 The "sms" URI scheme defines a way how a message may be composed 524 which is then transmitted using the SMS message transmission method. 525 This scheme can thus be compared to be "mailto" URI scheme [RFC2368]. 526 See Section 2.3 for the details of operation. 528 3.5. Encoding Considerations 530 The optional body field of "sms" URIs may contain a message text, but 531 this text uses percent-encoded UTF-8 characters and thus can always 532 be represented using URI characters. See Section 2 for the details 533 of encoding. 535 3.6. Applications/Protocols that use this URI Scheme Name 537 The "sms" URI scheme is intended to be used in a similar way as the 538 "mailto" URI scheme [RFC2368]. By using "sms" URIs, authors can 539 embed information into documents which can be used as a starting 540 point for initiating message composition. Whether the client is 541 sending the message itself (for example over a GSM air interface) or 542 redirecting the user to a third party for message composition (such 543 as a Web service for sending SMS messages) is outside of the scope of 544 the URI scheme definition. 546 3.7. Interoperability Considerations 548 No interoperability issues have been identified. 550 3.8. Security Considerations 552 See Section 4. 554 3.9. Contact 556 Erik Wilde 557 School of Information 558 UC Berkeley 559 Berkeley, CA 94720-4600 560 U.S.A. 561 tel:+1-510-6432252 562 mailto:dret@berkeley.edu 564 4. Security Considerations 566 SMS messages are transported without any provisions for privacy or 567 integrity, so SMS users should be aware of these inherent security 568 problems of SMS messages. Unlike electronic mail, where additional 569 mechanisms exist to layer security features on top of the basic 570 infrastructure, there currently is no such framework for SMS 571 messages. 573 SMS messages very often are delivered almost instantaneously (if the 574 receiving SMS client is online), but there is no guarantee for when 575 SMS messages will be delivered. In particular, SMS messages between 576 different network operators sometimes take a long time to be 577 delivered (hours or even days) or are not delivered at all, so 578 applications SHOULD NOT make any assumptions about the reliability 579 and performance of SMS message transmission. 581 In most networks, sending SMS messages is not a free service. 582 Therefore, SMS clients MUST make sure that any action that incurs 583 costs is acknowledged by the end user, unless explicitly instructed 584 otherwise by the end user. If an SMS client has different ways of 585 submitting an SMS message (such as a Web service and a phone line), 586 then the end user MUST have a way to control which way is chosen. 588 SMS clients often are limited devices (typically mobile phones), and 589 the sending SMS client SHOULD NOT make any assumptions about the 590 receiving SMS client supporting any non-standard services, such as 591 proprietary message concatenation or proprietary content types. 592 However, if the sending SMS client has prior knowledge about the 593 receiving SMS client, then he MAY use this knowledge to compose non- 594 standard SMS messages. 596 There are certain special SMS messages defined in the SMS 597 specification [SMS] that can be used, for example, to turn on 598 indicators on the phone display, or to send data to certain 599 communication ports (comparable to UDP ports) on the device. Certain 600 proprietary systems (for example, the Wireless Application Protocol 601 [WAP]) define configuration messages that may be used to reconfigure 602 the devices remotely. Any SMS client SHOULD make sure that malicious 603 use of such messages is not possible, for example by filtering out 604 certain SMS User Data header fields. Gateways that accept SMS 605 messages (e.g., in e-mail messages or Web forms) and pass them on to 606 an SMSC SHOULD implement this kind of "firewalling" approach as well. 608 Because the narrow bandwidth of the SMS communications channel, there 609 should also be checks in place for excessively long concatenated 610 messages. As an example, it may take two minutes to transfer thirty 611 concatenated text messages. 613 Unchecked input from a user MUST NOT be used to populate any other 614 fields in an SMS message other than the User Data field (not 615 including the User Data Header field). All other parts, including 616 the User Data Header, of the short message should only be generated 617 by trusted means. 619 By including "sms" URIs in unsolicited messages (a.k.a. "spam") or 620 other types of advertising, the originator of the "sms" URIs may 621 attempt to reveal an individual's phone number and/or to link the 622 identity (i.e., e-mail address) used for messaging with the identity 623 (i.e., phone number) used for the mobile phone. This attempt to 624 collect information may be a privacy issue, and user agents may make 625 users aware of that risk before composing or sending SMS messages. 626 Users agents which do not provide any feedback about this privacy 627 issue make users more vulnerable to this kind of attack. 629 A user agent SHOULD NOT send out SMS messages without the knowledge 630 of the user, because of associated risks, which include sending 631 masses of SMS messages to a subscriber without his consent, and the 632 costs involved in sending an SMS message. 634 As suggested functionality, the user agent MAY offer a possibility 635 for the user to filter out those phone numbers that are expressed in 636 local format, as most premium-rate numbers are expressed in local 637 format, and because determining the correct local context (and hence 638 the validity of the number to this specific user) may be very 639 difficult. 641 When using "sms" URIs as targets of forms (as described in 642 Section 2.6), the user agent SHOULD inform the user about the 643 possible security hazards involved when submitting the form (it is 644 probably being sent as plain text over an air interface). 646 5. IANA Considerations 648 Upon publication of this memo as an RFC, IANA has registered the 649 "sms" URI scheme, using the template in Section 3, in accordance with 650 RFC 4395 [RFC4395]. 652 6. Change Log 654 This section will not be part of the final RFC text, it serves as a 655 container to collect the history of the individual draft versions. 656 To the editor: Please remove this section before publication as RFC. 658 6.1. From -19 to -20 660 o Added Section 2.4 defining how to compare SMS URIs. 662 o Minor editorial changes. 664 6.2. From -18 to -19 666 o Changed phone numbers in Section 2.5 to match the rules for 667 reserved phone numbers in the +1 country code (as given by http:// 668 www.nanpa.com/nas/public/ 669 form555MasterReport.do?method=display555MasterReport). 671 o Changed "sms-field-ext = *( unreserved )" to "sms-field-ext = 1*( 672 unreserved )" (i.e., field name cannot be empty). 674 o Changed the registration request from "Provisional" to 675 "Permanent". 677 o Renamed [8.2] from "Non-Normative References" to "Informative 678 References". 680 o Minor text changes. 682 6.3. From -17 to -18 684 o Added normative reference to [HTML401] for the "application/ 685 x-www-form-urlencoded" media type. 687 o Changed to become (with "body" as the only 688 predefined field name) and to become , to allow extensions and defined extension model to be 690 mustIgnore. 692 6.4. From -16 to -17 694 o Changed phone numbers in Section 2.5 to be clearly identifiable 695 example phone numbers. 697 o Changed syntax of to use (defined 698 internally) instead of (which had been reused from RFC 699 3986). 701 o Removed RFC 2822 from the references (unused). 703 o Moved Section 2 outside of Section 1, becoming a top-level 704 section. 706 o Renamed to to avoid confusion with RFC 707 3986 tokens. 709 o Removed unused tokens from Appendix A. 711 6.5. From -15 to -16 713 o Changed phone numbers to be defined by the 714 part of RFC 3966 [RFC3966] rather than being defined here. 716 o Removed the intermediate part and defined to directly use . 719 o Replaced reference to [RFC5234] in Section 5 with correct 720 reference to [RFC4395]. 722 6.6. From -14 to -15 724 o RFC 4234 (ABNF) has been obsoleted by [RFC5234]. 726 6.7. From -13 to -14 728 o Updated abstract of Section 3 to the new abstract of the complete 729 document (mentioning of gateway functionality removed). 731 o Removed the "smsc" qualifier which allowed the specification of an 732 SMSC to be used for SMS message delivery. 734 o Removed the section about interfacing between a user agent 735 processing an "sms" URI, and a Web-based service for SMS 736 composition and sending. 738 o Replaced "gstn-phone" with "sms-number" in Section 2.3 739 (inconsistency from earlier syntax revision). 741 o Replaced all quotes around ABNF symbols within text with <...> to 742 clearly identify them as ABNF. 744 o Updated all references to their complete XML version. 746 o Added Section 5. 748 6.8. From -12 to -13 750 o Updated [SMS] to point to the latest version of the SMS spec (3GPP 751 TS 23.040 V7.0.1). 753 o Removed support for telematic interworking from the draft. This 754 feature of SMS messaging is hard to understand, poorly supported 755 by clients as well as network operators, and for these reasons 756 would have been likely to see poor adoption in implementations 757 anyway. 759 o Added some text making it more clear that all recipients SHOULD be 760 sent the exact same message. 762 o Several small editorial changes. 764 6.9. From -11 to -12 766 o Integrated draft-wilde-sms-service-11 and 767 draft-wilde-sms-uri-registration-00 into this draft. This draft 768 is now self-contained. 770 o Changed the phone number notation to use the definition from RFC 771 3966 [RFC3966] rather than RFC 3601 (RFC 3966 is a simpler 772 notation disallowing some of the special characters allowed by RFC 773 3601). 775 o Rephrased various parts of Section 4. 777 o Removed Section "Author/Change Controller". 779 o RFC 2806 (tel URI scheme) has been obsoleted by [RFC3966]. 781 6.10. From -10 to -11 783 o RFC 2234 (ABNF) has been obsoleted by RFC4234. 785 o Updated reference information for [SMS] and [SMS-CHAR]. 787 o Minor textual changes. 789 6.11. From -09 to -10 791 o Added security consideration about filtering local format phone 792 numbers. 794 o Changed IPR clause from RFC 3667 to RFC 3978 (updated version of 795 RFC 3667). 797 6.12. From -08 to -09 799 o Fixed syntax error in hier-part and sms-recipient non-terminals, 800 which allowed sms-recipients to be concatenated without comma 801 separation. 803 6.13. From -07 to -08 805 o URIs are now defined by RFC 3986 [RFC3986], so the text (including 806 the syntax definitions) and the references have been updated. 808 6.14. From -06 to -07 810 o Changed IPR clause from RFC 2026 to RFC 3667 (updated version of 811 RFC 2026). 813 6.15. From -05 to -06 815 o Updated reference from draft-allocchio-gstn to RFC 3601. 817 6.16. From -04 to -05 819 o Updated reference to SMS spec to the version referenced in the SMS 820 service draft. 822 6.17. From -03 to -04 824 o Updated reference to draft-allocchio-gstn (to revision -05). 826 6.18. From -02 to -03 828 o Changed ordering of "change Log" section (descending to 829 ascending). 831 o Clarified the wording at the beginning of Section 2.2 about only 832 the keywords of the scheme being case-insensitive. 834 o Changed "sms-body" to be a URI query string. 836 o Added some text describing "sms" URIs as addressing resources. 838 6.19. From -01 to -02 840 o Changed the sms-body field to percent-encoded UTF-8 characters. 842 6.20. From -00 to -01 844 o Added the "sms-body" field and its processing rules. 846 o Added section about using "sms" URIs as query strings for SMS Web 847 services. 849 o Fixed typo in ABNF (said "global-phone" instead of "gstn-phone"). 851 o Added some explanatory text about form submissions using email 852 telematic interworking. 854 o Added some text about character encoding in form submissions. 856 6.21. Change Log of draft-wilde-sms-service 858 This section contains the change log of draft-wilde-sms-service-11 859 before it was incorporated into this document at version 860 draft-wilde-sms-uri-12. 862 6.21.1. From -10 to -11 864 o RFC 2234 (ABNF) has been obsoleted by RFC4234. 866 o Added new security issue in Section 4. 868 o Updated reference information for [SMS] and [SMS-CHAR]. 870 o Minor textual changes. 872 6.21.2. From -09 to -10 874 o Changed IPR clause from RFC 3667 to RFC 3978 (updated version of 875 RFC 3667). 877 6.21.3. From -08 to -09 879 o No changes, re-release for alignment with draft-wilde-sms-uri. 881 6.21.4. From -07 to -08 883 o No changes, re-release for alignment with draft-wilde-sms-uri. 885 6.21.5. From -06 to -07 887 o Changed IPR clause from RFC 2026 to RFC 3667 (updated version of 888 RFC 2026). 890 6.21.6. From -05 to -06 892 o Updated reference from draft-allocchio-gstn-05 to RFC 3601. 894 6.21.7. From -04 to -05 896 o No changes, re-release for alignment with draft-wilde-sms-uri. 898 6.21.8. From -03 to -04 900 o Updated reference to draft-allocchio-gstn (to revision -05). 902 6.21.9. From -02 to -03 904 o Changed ordering of "change Log" section (descending to 905 ascending). 907 o Fixed some spelling errors. 909 6.21.10. From -01 to -02 911 o Removed address specification for X.400 SMS from ABNF 912 (surprisingly not part of the SMS spec). 914 o Added some explanatory text about character set mapping for SMS 915 messages. 917 o Added text requiring the use of message class 1 for sending SMS 918 messages. 920 6.21.11. From -00 to -01 922 o Added a number of new security considerations. 924 o Added the "PID" qualif-type1 keyword and the section about "SMS 925 Telematic Interworking" (removed in -13, available as Section 926 1.2.3 in -12). 928 7. Acknowledgements 930 This document has been prepared using the IETF document DTD described 931 in RFC 2629 [RFC2629]. 933 Thanks to (listed alphabetically) Claudio Allocchio, Derek Atkins, 934 Nevil Brownlee, John Cowan, Leslie Daigle, Lisa Dusseault, Miguel 935 Garcia, Vijay Gurbani, Alfred Hoenes, Cullen Jennings, Graham Klyne, 936 Larry Masinter, Alexey Melnikov, Michael Patton, and Magnus 937 Westerlund for their comments. 939 8. References 941 8.1. Normative References 943 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 944 Specification", W3C REC-html401, December 1999, 945 . 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC 2119, March 1997. 950 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 951 10646", STD 63, RFC 3629, November 2003. 953 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 954 RFC 3966, December 2004. 956 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 957 Resource Identifier (URI): Generic Syntax", STD 66, 958 RFC 3986, January 2005. 960 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 961 Registration Procedures for New URI Schemes", BCP 115, 962 RFC 4395, February 2006. 964 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 965 Specifications: ABNF", RFC 5234, January 2008. 967 [SMS] European Telecommunications Standards Institute, "3GPP TS 968 23.040 V7.0.1 (2007-03): 3rd Generation Partnership 969 Project; Technical Specification Group Core Network and 970 Terminals; Technical realization of the Short Message 971 Service (SMS) (Release 7)", March 2007, . 975 [SMS-CHAR] 976 European Telecommunications Standards Institute, "TS 100 977 900 (GSM 03.38 version 7.2.0 Release 1998): Digital 978 Cellular Telecommunications System (Phase 2+); Alphabets 979 and language-specific information", July 1999, . 983 8.2. Informative References 985 [RFC2368] Hoffmann, P., Masinter, L., and J. Zawinski, "The mailto 986 URL scheme", RFC 2368, June 1998. 988 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 989 June 1999. 991 [RFC2838] Zigmond, D. and M. Vickers, "Uniform Resource Identifiers 992 for Television Broadcasts", RFC 2838, May 2000. 994 [WAP] WAP Forum, "Wireless Application Protocol - Architecture 995 Specification (WAP-210-WAPArch-20010712)", July 2001. 997 [uri-clarification] 998 World Wide Web Consortium, "URIs, URLs, and URNs: 999 Clarifications and Recommendations 1.0", W3C uri- 1000 clarification , September 2001, 1001 . 1003 Appendix A. Syntax of 'telephone-subscriber' 1005 The following syntax is reproduced from Section 3 of RFC 3966 1006 [RFC3966]. It defines the part used in the 1007 "sms" URI scheme syntax. Please note that it includes Erratum 203 1008 for RFC 3966, which changes the definition of . 1010 telephone-subscriber = global-number / local-number 1011 global-number = global-number-digits *par 1012 local-number = local-number-digits *par context *par 1013 par = parameter / extension / isdn-subaddress 1014 isdn-subaddress = ";isub=" 1*paramchar 1015 extension = ";ext=" 1*phonedigit 1016 context = ";phone-context=" descriptor 1017 descriptor = domainname / global-number-digits 1018 global-number-digits = "+" *phonedigit DIGIT *phonedigit 1019 local-number-digits = 1020 *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex 1021 domainname = *( domainlabel "." ) toplabel [ "." ] 1022 domainlabel = alphanum 1023 / alphanum *( alphanum / "-" ) alphanum 1024 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 1025 parameter = ";" pname ["=" pvalue ] 1026 pname = 1*( alphanum / "-" ) 1027 pvalue = 1*paramchar 1028 paramchar = param-unreserved / unreserved / pct-encoded 1029 unreserved = alphanum / mark 1030 mark = "-" / "_" / "." / "!" / "~" / "*" / 1031 "'" / "(" / ")" 1032 pct-encoded = "%" HEXDIG HEXDIG 1033 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" 1034 phonedigit = DIGIT / [ visual-separator ] 1035 phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] 1036 visual-separator = "-" / "." / "(" / ")" 1037 alphanum = ALPHA / DIGIT 1039 Authors' Addresses 1041 Erik Wilde 1042 UC Berkeley 1043 Berkeley, CA 94720-4600 1044 U.S.A. 1046 Phone: +1-510-6432253 1047 Email: dret@berkeley.edu 1048 URI: http://dret.net/netdret/ 1050 Antti Vaha-Sipila 1051 Nokia 1053 Email: antti.vaha-sipila@nokia.com 1054 URI: http://www.iki.fi/avs/