idnits 2.17.1 draft-antti-gsm-sms-url-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 1) being 60 lines 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. ** There are 12 instances of lines with control characters in the document. 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) == Outdated reference: A later version (-11) exists of draft-antti-telephony-url-05 ** Obsolete normative reference: RFC 2303 (Obsoleted by RFC 3191) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'UCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'TDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMS' ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 11 errors (**), 0 flaws (~~), 4 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 27-Dec-1998 Nokia 3 22-Jun-1998 5 URLs for GSM Short Message Service 6 8 Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Distribution of this memo is unlimited. 30 Abstract 32 This document specifies a URL (Uniform Resource Locator) scheme 33 'gsm-sms' for specifying a recipient for an alphanumeric message 34 (Short Message) in a GSM-based mobile phone system. Short Messages 35 are two-way paging messages that can be sent from a suitable 36 equipped computer or a phone. 38 Contents 40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 1 41 1.1 What is GSM? . . . . . . . . . . . . . . . . . . . . . . . 1 42 1.2 Short Message Service . . . . . . . . . . . . . . . . . . 2 43 1.3 Short Messages and the Internet . . . . . . . . . . . . . 2 44 1.4 Formal Definitions . . . . . . . . . . . . . . . . . . . . 3 45 1.5 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. The "gsm-sms" URL Scheme . . . . . . . . . . . . . . . . . 3 47 2.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 3 48 2.2 Formal Definition . . . . . . . . . . . . . . . . . . . . 3 49 2.3 Parsing a "gsm-sms" URL . . . . . . . . . . . . . . . . . 4 50 2.4 Examples of Use . . . . . . . . . . . . . . . . . . . . . 4 51 3. References . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4. Security Considerations . . . . . . . . . . . . . . . . . 5 53 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 5 55 1. Introduction 57 1.1 What is GSM? 59 A. Vaha-Sipila URLs for GSM Short Message Service June 1998 60 GSM (Global System for Mobile Communications) is a digital mobile 61 phone standard which is used extensively in many parts of the 62 world. Named after its frequency band around 900 MHz, GSM-900 has 63 provided the basis for several other networks utilizing GSM 64 technology. When referring to "GSM" in this document, we mean any 65 of these GSM-based networks that operate a short message service. 67 1.2 Short Message Service 69 Short Messages [SMS] are two-way alphanumeric paging messages that 70 can be sent to and from GSM mobile phones. Short Messages are 71 transmitted over the mobile phone's air interface using the 72 signalling channels so there is no delay for call setup. Short 73 Messages are stored by an entity called Short Message Service 74 Centre (SMSC) and sent to the recipient when the subscriber 75 connects to the network. The number of a cooperative SMSC must be 76 known to the sender when sending the message. 78 Short messages can be mobile terminated (MT) or mobile originated 79 (MO). Mobile terminated messages are the ones that arrive to 80 phones; mobile originating messages are sent by a mobile 81 subscriber. Networks may support either, both or none of these. 83 A service similar to GSM SMS can be found also in other mobile 84 phone systems. Because the user-agent must know whether it is 85 capable of sending the message or not, the used system must be 86 indicated somewhere in the URL. To keep everything simple, this 87 document specifies a unique scheme specifier for a Short Message 88 in the GSM system. Other systems MUST use other scheme specifiers. 90 1.3 Short Messages and the Internet 92 Short Messages can be used to transport almost any kind of data. 93 Some examples of possible uses for a Short Message are described 94 below. 96 The Hypertext Markup Language (HTML) provides a way to collect 97 information from the user and pass it to a remote server for 98 processing. This functionality is known as "forms". A filled-in 99 form is usually sent to the destination using Hypertext Transfer 100 Protocol (HTTP) or mail. Short Messages can be used as the 101 transport for these forms. As the Short Message service is 102 "out-of-band" as far as normal HTTP-over-TCP/IP is concerned, this 103 provides a way to fill in forms offline and send the data without 104 making a TCP connection to the remote server, as the set-up time, 105 cost and overhead for a TCP connection are large compared to a 106 Short Message. Also, depending on the network configuration, the 107 sender's telephone number may be included in the Short Message, 108 thus providing a weak form of authentication. 110 Short Messages can also provide an alternative to a "mailto" type 111 URL. When a "gsm-sms" type URL is activated, the user agent MAY 112 start a program for sending an SMS message, just as "mailto" may 114 A. Vaha-Sipila URLs for GSM Short Message Service June 1998 115 open a mail client. 117 The recipient need not to be a mobile phone. It can be a server 118 that can process Short Messages, either by gatewaying them to 119 another messaging system or by parsing them for supplementary 120 services. 122 GSM Short Messages have a maximum length of 160 characters. 123 However, Short Messages can be concatenated to form longer 124 messages. It is up to the user agent to decide whether to limit 125 the length of the message and how to indicate this limit in its 126 user interface, if necessary. 128 1.4 Formal Definitions 130 Definitions are written using Augmented BNF for Syntax 131 Specifications [RFC2234]. 133 1.5 Requirements 135 Compliant software MUST follow this specification. Requirements 136 are indicated by capitalized words as specified in [RFC2119]. 138 2. The "gsm-sms" URL Scheme 140 2.1 Applicability 142 This URL scheme is intended for sending a Short Message to a 143 certain recipient(s) through service centre(s). The functionality 144 is quite similar to that of the "mailto" URL, which (as per 145 [RFC1738] only refers to one electronic mail address at a time, 146 but is often used with a comma-separated list of email addresses. 148 In some situations, it may be necessary to guide the sender to 149 send the Short Message via a certain SMSC. For this purpose, this 150 URL may specify the number of the SMSC. 152 The notation for phone numbers is similar to that if 153 [DRAFT-TELURL]. Refer to that document and to [RFC2303] for 154 information on why this particular format was chosen. 156 How the Short Message is sent to the SMSC is outside the scope of 157 this specification. Short Messages can be sent over the GSM air 158 interface or by using a modem and a suitable protocol (such as UCP 159 [UCP] or TDP [TDP]). Also, Short Message service options like 160 deferred delivery and delivery notification requests are not in 161 the scope of this document. Such services MAY be requested from 162 the network by the user agent if necessary. 164 2.2 Formal Definition 166 The URL is case-insensitive. The URL syntax is formally described 167 as follows: 169 A. Vaha-Sipila URLs for GSM Short Message Service June 1998 170 sms-url = scheme ":" scheme-specific-part 171 scheme = "gsm-sms" 172 scheme-specific-part = subscriber-id [";via=" message-centre-id] 173 ["," scheme-specific-part] 174 subscriber-id = ["+"] phone-number 175 message-centre-id = ["+"] phone-number 176 phone-number = 1*phonedigit 177 phonedigit = digit / "-" / "." 178 digit = "0" / "1" / "2" / "3" / "4" / "5" / 179 "6" / "7" / "8" / "9" 181 2.3 Parsing a "gsm-sms" URL 183 1. is extracted. It is the phone number of the 184 final recipient and it MUST be written in international form with 185 country code, unless the number only works from inside a certain 186 geographical area or a network. Note that some numbers may work 187 from several networks but not from the whole world - these SHOULD 188 be written in international form. All international numbers MUST 189 begin with a "+" character. Hyphens and dots are only to aid 190 readability. They MUST NOT have any other meaning. 192 2. is extracted if present. User-agent SHOULD 193 try to send the message first using this SMSC. If that fails, 194 user-agent MAY try another SMSC. The number of the SMSC is subject 195 to the same rules as the "subscriber-id" (see above). 197 3. If the URL consists of a comma-separated list of recipients, 198 all of them are processed in this manner. 200 2.4 Examples of Use 202 gsm-sms:+3585551234567 204 This indicates a mobile terminated (MT) Short Message capable 205 recipient at the given telephone number. The message is sent using 206 the user-agent's default SMSC. 208 gsm-sms:+3585551234567;via=+3585551000100 210 This indicates that the Short Message should be sent using the 211 SMSC at the given number. 213 3. References 215 [DRAFT-TELURL] URLs for Telephony. A. Vaha-Sipila. 1998. 216 An Internet-Draft (work in progress). 217 220 [RFC2303] Minimal PSTN Address Format in Internet Mail. March 1998. 221 C. Allocchio. RFC 2303. 222 224 A. Vaha-Sipila URLs for GSM Short Message Service June 1998 226 [RFC2234] Augmented BNF for Syntax Specifications: ABNF. 227 November 1997. D. Crocker et al. RFC 2234. 228 230 [UCP] Paging Systems; European Radio Message System (ERMES) (ETS 231 300 133-3). Part 3: Network Aspects. July 1992. European 232 Telecommunications Standards Institute. 234 [TDP] Telocator Data Paging Protocol (TDP). Version 2.0. July 27, 235 1995. Personal Communications Industry Association. 236 238 [SMS] Digital Cellular Telecommunications System (Phase 2+): 239 Technical Realization of the Short Message Service (SMS) 240 Point-to-Point (PP) (GSM 3.40). Version 5.2.0. May 1996. European 241 Telecommunications Standards Institute. 243 [RFC1738] Uniform Resource Locators (URL). December 1994. T. 244 Berners-Lee et al. 246 [RFC2119] Key words for use in RFCs to Indicate Requirement 247 Levels. April 1997. S. Bradner. 248 250 4. Security Considerations 252 It should be noted that the user agent SHOULD NOT send out Short 253 Messages without the knowledge of the user because of associated 254 risks, which include sending masses of Short Messages to a 255 subscriber without her consent and the costs involved in sending a 256 Short Message. 258 The user agent SHOULD have some mechanism that the user can use to 259 filter out unwanted destinations for Short Messages. The user 260 agent SHOULD also have some means of restricting the number of 261 Short Messages sent. 263 5. Authors' Addresses 265 Contact person and version control responsibility for this 266 specification: 268 Nokia Mobile Phones 269 Antti Vaha-Sipila 270 P. O. Box 68 271 FIN-33721 Tampere 272 Finland 274 Electronic mail: antti.vaha-sipila@nmp.nokia.com 276 Please include your name and electronic mail address in all 277 communications. If you want to receive the newest version of this 278 specification electronically, send mail to the address above. 280 A. Vaha-Sipila URLs for GSM Short Message Service June 1998 281 This document expires on the 27th of December, 1998, or when a 282 new version is released. 284 A. Vaha-Sipila URLs for GSM Short Message Service June 1998