URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)
Extracted elements (29)
The notation for phone numbers is taken from RFC 3966 (the 'tel' URI) including Erratum 203, because that format was specifically designed for representing telephone numbers in URIs. The 'sms' scheme reuses this work rather than defining its own phone number syntax.
The 'sms' scheme is modeled closely on the 'mailto' URI scheme (RFC 2368), providing analogous functionality for SMS that mailto provides for email: it allows authors to embed a pre-addressed, optionally pre-populated message composition starting point in documents.
The 'sms' URI scheme does not support specification of SMSC (SMS Center) numbers. In scenarios where messages must be sent through a certain SMSC, some other context must establish this requirement, or message delivery may fail. This is a deliberate scope limitation.
The body field uses percent-encoded UTF-8 characters, but implementations must convert to a suitable SMS character encoding (7-bit GSM or UCS-2) before transmission. UCS-2 is not as universally supported as 7-bit SMS encoding.
The sending SMS client SHOULD NOT assume the receiving client supports non-standard services such as proprietary message concatenation or proprietary content types, unless the sender has prior knowledge about the receiver's capabilities.
When sending to an SMS recipient whose support for concatenated messages is unknown, the SMS client MAY use the backwards-compatible text-based concatenation method defined in the SMS specification rather than the header-based standard method.
Applications handling SMS messages as part of a character-processing chain MUST make sure that character sets are correctly mapped to and from the character set used for SMS messages.
If an HTML form submission via 'sms' URI is longer than the maximum SMS message size, the user agent MAY concatenate SMS messages or refuse to send, but MUST NOT send partial form submissions.
If implementations discard or convert characters in the body field that are not supported by the SMS character set being used, they MUST notify the user.
Phone numbers in 'sms' URIs MUST be written in international form with country code (beginning with '+') unless the number only works inside a certain geographic area or network. Visual separators (hyphens, dots, parentheses) MUST NOT convey any meaning other than readability.
Simply activating a link with an 'sms' URI SHOULD NOT cause a message to be sent without prior user confirmation. User agents SHOULD provide means for message composition before sending.
SMS clients composing messages SHOULD use the standard concatenation method based on the header in the TP-User Data field. Proprietary concatenation methods SHOULD NOT be used except in closed systems where recipient capabilities are always known.
SMS clients MUST make sure that any action incurring costs is acknowledged by the end user, unless explicitly instructed otherwise. If multiple submission methods exist, the end user MUST have a way to control which method is chosen.
SMS messages sent as a result of an 'sms' URI MUST be sent as class 1 SMS messages, if the user agent is able to specify the message class.
The 'body' sms-field MUST NOT appear more than once in an 'sms' URI. It consists of percent-encoded UTF-8 characters, and implementations MUST convert the body characters to a suitable SMS character encoding (e.g., 7-bit SMS or UCS-2) before sending.
Unchecked input from a user MUST NOT be used to populate any SMS message fields other than the User Data field. All other parts including the User Data header SHOULD only be generated by trusted means.
Unknown fields encountered in 'sms' URIs MUST be ignored by implementations. Extensions MAY define additional fields but MUST NOT change the semantics of the specifications they extend.
When multiple recipients are listed in an 'sms' URI, exactly the same message SHOULD be sent to all listed recipients without alteration. User agents SHOULD support multiple recipients and SHOULD make the entire recipient list clear to users before sending.
When using 'sms' URIs as HTML form action targets, form contents MUST be packaged using 'application/x-www-form-urlencoded' media type, encoded as UTF-8 and percent-encoded. The SMS message MUST NOT contain HTTP header fields, and the media type MUST NOT be transferred in the SMS message.
By including 'sms' URIs in spam or advertising, originators may attempt to reveal an individual's phone number or link an email identity to a mobile phone identity. User agents MAY make users aware of this risk before composing or sending SMS messages. User agents that provide no such feedback make users more vulnerable to this attack.
User agents MAY offer the ability to filter out phone numbers expressed in local format, as most premium-rate numbers use local format and determining the correct local context for a specific user may be very difficult.
The 'sms' URI scheme follows the syntax: sms-uri = scheme ":" sms-hier-part [ "?" sms-fields ], where sms-hier-part contains one or more comma-separated telephone-subscriber recipients. The scheme supports an optional 'body' field for pre-populating message text using percent-encoded UTF-8 characters.
The 'sms' URI scheme processing steps: extract the first recipient's phone number, extract the 'body' field if present, provide a message composition interface pre-populated with the body, attempt to send using the default delivery method, and repeat for all listed recipients.
URI comparison rules for 'sms' URIs: two URIs are equivalent only if their sms-fields are identical and all telephone-subscriber values are equivalent (compared pairwise as a set, case-insensitively, after removing visual separators).
IANA has registered the 'sms' URI scheme as a permanent URI scheme in accordance with RFC 4395. The registration template is provided in Section 3 of this document.
Applications SHOULD NOT make assumptions about the reliability and performance of SMS message transmission, as messages between different network operators may take hours or days to be delivered, or may not be delivered at all.
SMS messages are transported without any provisions for privacy or integrity. Unlike email, no framework exists for layering security features on top of the basic SMS infrastructure, so users should be aware of these inherent security problems.
Special SMS messages defined in the SMS specification can be used to turn on indicators on phone displays, send data to communication ports, or remotely reconfigure devices (e.g., WAP configuration messages). SMS clients SHOULD filter out malicious use of such User Data header fields; gateways SHOULD implement 'firewalling' of such messages.
The formal ABNF syntax defines sms-uri as: scheme ":" sms-hier-part [ "?" sms-fields ], with sms-fields composed of sms-field-name "=" escaped-value pairs delimited by "&". The 'body' field name MUST appear only once; sms-field-ext allows extension field names composed of unreserved characters.