Internet Engineering Task Force (IETF) E. Wilde
Request for Comments: 5724 UC Berkeley
Category: Standards Track A. Vaha-Sipila
ISSN: 2070-1721 Nokia
January 2010
Internet Engineering Task Force (IETF) E. Wilde
Request for Comments: 5724 UC Berkeley
Category: Standards Track A. Vaha-Sipila
ISSN: 2070-1721 Nokia
January 2010
URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)
全球移动通信系统（GSM）短消息业务（SMS）的URI方案
Abstract
摘要
This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device.
此备忘录指定统一资源标识符（URI）方案“sms”，用于为sms消息指定一个或多个收件人。SMS消息是双向寻呼消息，可由移动电话或适当配备的网络设备发送和接收。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5724.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5724.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. What is GSM? ...............................................3
1.2. What is SMS? ...............................................3
1.2.1. SMS Content .........................................3
1.2.2. SMS Infrastructure ..................................4
1.2.2.1. SMS Centers ................................4
1.2.3. Uniform Resource Identifiers ........................4
1.2.4. SMS Messages and the Internet .......................5
1.2.4.1. SMS Messages and the Web ...................6
1.2.4.2. SMS Messages and Forms .....................6
1.3. Requirements Language ......................................6
2. The "sms" URI Scheme ............................................7
2.1. Applicability ..............................................7
2.2. Formal Definition ..........................................7
2.3. Processing an "sms" URI ....................................9
2.4. Comparing "sms" URIs .......................................9
2.5. Examples of Use ...........................................10
2.6. Using "sms" URIs in HTML Forms ............................10
3. URI Scheme Registration ........................................11
3.1. URI Scheme Name ...........................................11
3.2. Status ....................................................11
3.3. URI Scheme Syntax .........................................11
3.4. URI Scheme Semantics ......................................11
3.5. Encoding Considerations ...................................12
3.6. Applications/Protocols That Use This URI Scheme Name ......12
3.7. Interoperability Considerations ...........................12
3.8. Security Considerations ...................................12
3.9. Contact ...................................................12
4. Security Considerations ........................................12
5. IANA Considerations ............................................14
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
Appendix A. Syntax of telephone-subscriber .......................17
1. Introduction ....................................................3
1.1. What is GSM? ...............................................3
1.2. What is SMS? ...............................................3
1.2.1. SMS Content .........................................3
1.2.2. SMS Infrastructure ..................................4
1.2.2.1. SMS Centers ................................4
1.2.3. Uniform Resource Identifiers ........................4
1.2.4. SMS Messages and the Internet .......................5
1.2.4.1. SMS Messages and the Web ...................6
1.2.4.2. SMS Messages and Forms .....................6
1.3. Requirements Language ......................................6
2. The "sms" URI Scheme ............................................7
2.1. Applicability ..............................................7
2.2. Formal Definition ..........................................7
2.3. Processing an "sms" URI ....................................9
2.4. Comparing "sms" URIs .......................................9
2.5. Examples of Use ...........................................10
2.6. Using "sms" URIs in HTML Forms ............................10
3. URI Scheme Registration ........................................11
3.1. URI Scheme Name ...........................................11
3.2. Status ....................................................11
3.3. URI Scheme Syntax .........................................11
3.4. URI Scheme Semantics ......................................11
3.5. Encoding Considerations ...................................12
3.6. Applications/Protocols That Use This URI Scheme Name ......12
3.7. Interoperability Considerations ...........................12
3.8. Security Considerations ...................................12
3.9. Contact ...................................................12
4. Security Considerations ........................................12
5. IANA Considerations ............................................14
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
Appendix A. Syntax of telephone-subscriber .......................17
GSM (Global System for Mobile Communications) is a digital mobile phone standard that is used extensively in many parts of the world. First named after its frequency band around 900 MHz, GSM-900 has provided the basis for several other networks utilizing GSM technology, in particular, GSM networks operating in the frequency bands around 1800 MHz and 1900 MHz. When referring to "GSM" in this document, we mean any of these GSM-based networks that operate a short message service.
GSM（全球移动通信系统）是一种数字移动电话标准，在世界许多地方广泛使用。GSM-900最初以其900 MHz左右的频带命名，它为利用GSM技术的其他几个网络提供了基础，特别是在1800 MHz和1900 MHz左右的频带上运行的GSM网络。在本文件中提及“GSM”时，我们指的是运营短消息服务的任何基于GSM的网络。
The Short Message Service (SMS) [SMS] is an integral part of the GSM network technology. It has been very successful and currently is a major source of revenue for many GSM operators. SMS as a service is so successful that other Global Switched Telephone Network (GSTN) technologies have adopted it as well, in particular, the Integrated Services Digital Network (ISDN). Because of this development, this memo uses the term "SMS client" to refer to user agents that are able to send and/or receive SMS messages.
短消息服务（SMS）[SMS]是GSM网络技术的一个组成部分。它非常成功，目前是许多GSM运营商的主要收入来源。SMS作为一种服务是如此成功，以至于其他全球交换电话网（GSTN）技术也采用了它，特别是综合业务数字网（ISDN）。由于这一发展，本备忘录使用术语“SMS客户端”来指代能够发送和/或接收SMS消息的用户代理。
GSM SMS messages are alphanumeric paging messages that can be sent to and from SMS clients. SMS messages have a maximum length of 160 characters (7-bit characters from the GSM character set [SMS-CHAR]), or 140 octets. Other character sets (such as UCS-2 16-bit characters, resulting in 70-character messages) MAY also be supported [SMS-CHAR], but are defined as being optional by the SMS specification. Consequently, applications handling SMS messages as part of a chain of character-processing applications MUST make sure that character sets are correctly mapped to and from the character set used for SMS messages.
GSM SMS消息是可以发送到SMS客户端和从SMS客户端发送的字母数字寻呼消息。SMS消息的最大长度为160个字符（GSM字符集[SMS-CHAR]中的7位字符）或140个八位字节。其他字符集（如UCS-2 16位字符，产生70个字符的消息）也可以支持[SMS-CHAR]，但SMS规范将其定义为可选。因此，作为字符处理应用程序链的一部分处理SMS消息的应用程序必须确保字符集与用于SMS消息的字符集正确映射。
While the 160-character content type for SMS messages is by far the one most widely used, there are numerous other content types for SMS messages, such as small bitmaps ("operator logos") and simple formats for musical notes ("ring tones"). However, these formats are proprietary and are not considered in this memo.
虽然短信的160字符内容类型是目前使用最广泛的一种，但短信还有许多其他内容类型，如小位图（“运营商徽标”）和简单的音符格式（“铃声”）。但是，这些格式是专有的，不在本备忘录中考虑。
SMS messages are limited in length (140 octets), and the first versions of the SMS specification did not specify any standardized methods for concatenating SMS messages. As a consequence, several proprietary methods were invented, but the current SMS specification does specify message concatenation. In order to deal with this
SMS消息的长度是有限的（140个八位字节），SMS规范的第一个版本没有指定任何连接SMS消息的标准化方法。因此，发明了几种专有方法，但当前的SMS规范确实指定了消息连接。为了解决这个问题,
situation, SMS clients composing messages SHOULD use the standard concatenation method based on the header in the TP-User Data field as specified in the SMS specification [SMS]. When sending a message to an SMS recipient whose support for concatenated messages is unknown, the SMS client MAY opt to use the backwards-compatible (text-based) concatenation method defined in the SMS specification [SMS]. Proprietary concatenation methods SHOULD NOT be used except in closed systems, where the capabilities of the recipient(s) are always known.
在这种情况下，组成消息的SMS客户端应根据SMS规范[SMS]中指定的TP用户数据字段中的标头使用标准连接方法。当向支持连接消息未知的SMS收件人发送消息时，SMS客户端可以选择使用SMS规范[SMS]中定义的向后兼容（基于文本）连接方法。除非在封闭系统中，否则不应使用专有的连接方法，因为在封闭系统中，接收者的能力总是已知的。
SMS messages can be transmitted over an SMS client's network interface using the signaling channels of the underlying GSTN infrastructure, so there is no delay for call setup. Alternatively, SMS messages may be submitted through other front-ends (for example, Web-based services), which makes it possible for SMS clients to run on computers that are not directly connected to a GSTN network supporting SMS.
SMS消息可以使用底层GSTN基础设施的信令信道通过SMS客户端的网络接口传输，因此呼叫设置没有延迟。或者，SMS消息可以通过其他前端（例如，基于Web的服务）提交，这使得SMS客户端可以在未直接连接到支持SMS的GSTN网络的计算机上运行。
SMS messages sent with the GSTN SMS service MUST be sent as class 1 SMS messages, if the client is able to specify the message class.
如果客户端能够指定消息类别，则使用GSTN SMS服务发送的SMS消息必须作为类别1 SMS消息发送。
For delivery within GSTN networks, SMS messages are stored by an entity called SMS Center (SMSC) and sent to the recipient when the subscriber connects to the network. The number of a cooperative SMSC must be known to the SMS sender (i.e., the entity submitting the SMS message to a GSTN infrastructure) when sending the message (usually the SMSC's number is configured in the SMS client and specific for the network operator to which the sender has subscribed). In most situations, the SMSC number is part of the sending SMS client's configuration. However, in some special cases (such as when the SMS recipient only accepts messages from a certain SMSC), it may be necessary to send the SMS message over a specific SMSC. The scheme specified in this memo does not support the specification of SMSC numbers, so in case of scenarios where messages have to be sent through a certain SMSC, there must be some other context establishing this requirement or message delivery may fail.
对于GSTN网络内的传递，SMS消息由一个称为SMS中心（SMSC）的实体存储，并在用户连接到网络时发送给收件人。发送消息时，SMS发送方（即，向GSTN基础设施提交SMS消息的实体）必须知道合作SMSC的编号（通常SMSC的编号在SMS客户端中配置，并且特定于发送方订阅的网络运营商）。在大多数情况下，SMSC号码是发送SMS客户端配置的一部分。但是，在某些特殊情况下（例如，当SMS收件人仅接受来自特定SMSC的消息时），可能需要通过特定SMSC发送SMS消息。本备忘录中规定的方案不支持SMSC编号的规定，因此，在必须通过某个SMSC发送消息的情况下，必须有其他上下文建立此要求，否则消息传递可能失败。
One of the core specifications for identifying resources on the Internet is [RFC3986], specifying the syntax and semantics of a Uniform Resource Identifier (URI). The most important notion of URIs are "schemes", which define a framework within which resources can be uniquely identified and addressed. URIs enable users to access resources and are used for very diverse schemes, such as access
标识Internet上资源的核心规范之一是[RFC3986]，它指定了统一资源标识符（URI）的语法和语义。URI最重要的概念是“方案”，它定义了一个框架，在这个框架中可以唯一地识别和处理资源。URI使用户能够访问资源，并用于各种各样的方案，例如访问
protocols (HTTP, FTP), broadcast media (TV channels [RFC2838]), messaging (email [RFC2368]), and even telephone numbers (voice [RFC3966]).
协议（HTTP、FTP）、广播媒体（电视频道[RFC2838]）、消息（电子邮件[RFC2368]），甚至电话号码（语音[RFC3966]）。
URIs often are mentioned together with Uniform Resource Names (URNs) and/or Uniform Resource Locators (URLs), and it often is unclear how to separate these concepts. For the purpose of this memo, only the term URI will be used, referring to the most fundamental concept. The World Wide Web Consortium (W3C) has issued a note [uri-clarification] discussing the topic of URIs, URNs, and URLs in detail.
URI通常与统一资源名称（URN）和/或统一资源定位器（URL）一起提及，并且通常不清楚如何区分这些概念。在本备忘录中，仅使用术语URI，指的是最基本的概念。万维网联盟（W3C）发布了一份说明[uri澄清]，详细讨论了uri、URN和URL的主题。
One of the important reasons for the universal access of the Web is the ability to access all information through a unique interface. This kind of integration makes it easy to provide information as well as to consume it. One aspect of this integration is the support of user agents (in the case of the Web, commonly referred to as browsers) for multiple content formats (such as HTML, GIF, JPEG) and access schemes (such as HTTP, HTTPS, FTP).
网络普及的一个重要原因是能够通过一个独特的界面访问所有信息。这种集成使得提供信息和使用信息变得容易。这种集成的一个方面是对多种内容格式（如HTML、GIF、JPEG）和访问方案（如HTTP、HTTPS、FTP）的用户代理（在Web中，通常称为浏览器）的支持。
The "mailto" scheme has proven to be very useful and popular because most user agents support it by providing an email composition facility when the user selects (e.g., clicks on) the URI. Similarly, the "sms" scheme can be supported by user agents by providing an SMS message composition facility when the user selects the URI. In cases where the user agent does not provide a built-in SMS message composition facility, the scheme could still be supported by opening a Web page that provides such a service. The specific Web page to be used could be configured by the user, so that each user could use the SMS message composition service of his choice.
“mailto”方案已被证明是非常有用和流行的，因为大多数用户代理都通过在用户选择（例如单击）URI时提供电子邮件合成功能来支持它。类似地，“sms”方案可由用户代理通过在用户选择URI时提供sms消息合成设施来支持。在用户代理不提供内置SMS消息合成功能的情况下，仍然可以通过打开提供此类服务的网页来支持该方案。用户可以配置要使用的特定网页，以便每个用户都可以使用自己选择的SMS消息合成服务。
The goal of this memo is to specify the "sms" URI scheme so that user agents (such as Web browsers and email clients) can start to support it. The "sms" URI scheme identifies SMS message endpoints as resources. When "sms" URIs are dereferenced, implementations MAY create a message and present it to be edited before being sent, or they MAY invoke additional services to provide the functionality necessary for composing a message and sending it to the SMS message endpoint. In either case, simply activating a link with an "sms" URI SHOULD NOT cause a message to be sent without prior user confirmation.
本备忘录的目标是指定“sms”URI方案，以便用户代理（如Web浏览器和电子邮件客户端）可以开始支持它。“sms”URI方案将sms消息端点标识为资源。当“sms”URI被取消引用时，实现可能会创建一条消息并在发送之前将其呈现给编辑人员，或者它们可能会调用其他服务来提供编写消息并将其发送到sms消息端点所需的功能。在这两种情况下，仅激活带有“sms”URI的链接不应导致在未经用户事先确认的情况下发送消息。
SMS messages can provide an alternative to "mailto" URIs [RFC2368], or "tel" or "fax" URIs [RFC3966]. When an "sms" URI is activated, the user agent MAY start a program for sending an SMS message, just as "mailto" may open a mail client. Unfortunately, most browsers do not support the external handling of internally unsupported URI schemes in the same generalized way as most of them support external handling of content for media types that they do not support internally. Ideally, user agents should implement generic URI parsers and provide a way to associate unsupported schemes with external applications (or Web-based services).
SMS消息可以提供“mailto”URI[RFC2368]或“tel”或“fax”URI[RFC3966]的替代方案。当激活“sms”URI时，用户代理可以启动用于发送sms消息的程序，就像“mailto”可以打开邮件客户端一样。不幸的是，大多数浏览器不支持内部不支持的URI方案的外部处理，这与大多数浏览器支持内部不支持的媒体类型的内容的外部处理方式相同。理想情况下，用户代理应该实现通用URI解析器，并提供一种将不受支持的方案与外部应用程序（或基于Web的服务）关联的方法。
The recipient of an SMS message need not be a mobile phone. It can be a server that can process SMS messages, either by gatewaying them to another messaging system (such as regular electronic mail), or by parsing them for supplementary services.
SMS消息的接收者不必是移动电话。它可以是一个服务器，可以通过网关将SMS消息传送到另一个消息传递系统（如普通电子邮件）或通过解析它们以获得补充服务来处理SMS消息。
SMS messages can be used to transport almost any kind of data (even though there is a very tight size limit), but the only standardized data formats are character-based messages in different character encodings. SMS messages have a maximum length of 160 characters (when using 7-bit characters from the SMS character set), or 140 octets. However, SMS messages can be concatenated to form longer messages. It is up to the user agent to decide whether to limit the length of the message, and how to indicate this limit in its user interface if necessary. There is one exception to this; see Section 2.6.
SMS消息可用于传输几乎任何类型的数据（尽管大小限制非常严格），但唯一标准化的数据格式是采用不同字符编码的基于字符的消息。SMS消息的最大长度为160个字符（使用SMS字符集中的7位字符时），或140个八位字节。但是，可以将SMS消息连接起来以形成更长的消息。由用户代理决定是否限制消息的长度，以及在必要时如何在其用户界面中指示此限制。有一个例外；见第2.6节。
The Hypertext Markup Language (HTML) [HTML401] provides a way to collect information from a user and pass it to a server for processing. This functionality is known as "HTML forms". A filled-in form is usually sent to the destination using the Hypertext Transfer Protocol (HTTP) or email. However, SMS messages can also be used as the transport mechanism for these forms. Depending on the network configuration, the sender's telephone number may be included in the SMS message, thus providing a weak form of authentication.
超文本标记语言（HTML）[HTML401]提供了一种从用户收集信息并将其传递给服务器进行处理的方法。此功能称为“HTML表单”。填写的表单通常使用超文本传输协议（HTTP）或电子邮件发送到目的地。但是，SMS消息也可以用作这些表单的传输机制。根据网络配置，发送者的电话号码可以包括在SMS消息中，从而提供弱形式的认证。
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中大写的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Syntax definitions are given using the Augmented BNF (ABNF) for syntax specifications [RFC5234].
语法定义使用语法规范[RFC5234]的增广BNF（ABNF）给出。
This URI scheme provides information that can be used for sending SMS message(s) to specified recipient(s). The functionality is comparable to that of the "mailto" URI, which (as per [RFC2368]) can also be used with a comma-separated list of email addresses.
此URI方案提供可用于向指定收件人发送SMS消息的信息。该功能与“mailto”URI的功能相当，该URI（根据[RFC2368]）也可以与逗号分隔的电子邮件地址列表一起使用。
The notation for phone numbers is taken from [RFC3966] and its Erratum 203 [Err203]. Appendix A provides a corrected syntax of the telephone number. Refer to that document for information on why this particular format was chosen.
电话号码的符号取自[RFC3966]及其勘误表203[Err203]。附录A提供了正确的电话号码语法。有关选择此特定格式的原因，请参阅该文件。
How SMS messages are sent to the SMSC or other intermediaries is outside the scope of this specification. SMS messages can be sent over the GSM air interface by using a modem and a suitable protocol or by accessing services over other protocols, such as a Web-based service for sending SMS messages. Also, SMS message service options like deferred delivery and delivery notification requests are not within the scope of this document. Such services MAY be requested from the network by the user agent if necessary.
如何将SMS消息发送至SMSC或其他中介机构不在本规范的范围内。SMS消息可以通过GSM空中接口通过使用调制解调器和合适的协议发送，或者通过访问其他协议上的服务（例如用于发送SMS消息的基于Web的服务）发送。此外，诸如延迟传递和传递通知请求等SMS消息服务选项不在本文档的范围内。如有必要，用户代理可从网络请求此类服务。
SMS messages sent as a result of this URI MUST be sent as class 1 SMS messages, if the user agent is able to specify the message class.
如果用户代理能够指定消息类别，则根据此URI发送的SMS消息必须作为类别1 SMS消息发送。
The URI scheme's keywords specified in the following syntax description are case-insensitive. The syntax of an "sms" URI is formally described as follows, where the URI base syntax is taken from [RFC3986]:
以下语法描述中指定的URI方案的关键字不区分大小写。“sms”URI的语法正式描述如下，其中URI基本语法取自[RFC3986]：
sms-uri = scheme ":" sms-hier-part [ "?" sms-fields ]
scheme = "sms"
sms-hier-part = sms-recipient *( "," sms-recipient )
sms-recipient = telephone-subscriber ; defined in RFC 3966
sms-fields = sms-field *( "&" sms-field )
sms-field = sms-field-name "=" escaped-value
sms-field-name = "body" / sms-field-ext ; "body" MUST only appear once
sms-field-ext = 1*( unreserved )
escaped-value = *( unreserved / pct-encoded ) ; defined in RFC 3986
sms-uri = scheme ":" sms-hier-part [ "?" sms-fields ]
scheme = "sms"
sms-hier-part = sms-recipient *( "," sms-recipient )
sms-recipient = telephone-subscriber ; defined in RFC 3966
sms-fields = sms-field *( "&" sms-field )
sms-field = sms-field-name "=" escaped-value
sms-field-name = "body" / sms-field-ext ; "body" MUST only appear once
sms-field-ext = 1*( unreserved )
escaped-value = *( unreserved / pct-encoded ) ; defined in RFC 3986
Some illustrative examples using this syntax are given in Section 2.5.
第2.5节给出了使用此语法的一些示例。
The syntax definition for <telephone-subscriber> is taken from Section 5.1 of [RFC3966]. Please consider Erratum 203 [Err203] in that specification. For the reader's convenience, Appendix A contains a fixed syntax of the telephone number URI scheme, including Erratum 203, but RFC 3966 (plus all applicable errata) is the normative reference. The description of phone numbers in RFC 3966 (Section 5.1) states: "The 'telephone-subscriber' part of the URI indicates the number. The phone number can be represented in either global (E.164) or local notation. All phone numbers MUST use the global form unless they cannot be represented as such. Numbers from private numbering plans, emergency ("911", "112"), and some directory-assistance numbers (e.g., "411") and other "service codes" (numbers of the form N11 in the United States) cannot be represented in global (E.164) form and need to be represented as a local number with a context. Local numbers MUST be tagged with a 'phone-context'."
<telephone subscriber>的语法定义取自[RFC3966]的第5.1节。请考虑该规范中的勘误203 [Err203]。为方便读者，附录A包含电话号码URI方案的固定语法，包括勘误表203，但RFC 3966（加上所有适用勘误表）为规范性参考。RFC 3966（第5.1节）中对电话号码的描述指出：“URI中的‘电话订户’部分表示号码。电话号码可以用全局（E.164）或本地符号表示。所有电话号码必须使用全局形式，除非它们不能用全局形式表示。私人编号计划中的号码，紧急（”“911”、“112”）和一些目录帮助号码（例如，“411”）以及其他“服务代码”（美国为表格N11的号码）不能以全局（e.164）形式表示，需要以带有上下文的本地号码表示。本地号码必须用“电话上下文”标记。”
This specification defines a single <sms-field>: "body". Extensions to this specification MAY define additional fields. Extensions MUST NOT change the semantics of the specifications they are extending. Unknown fields encountered in "sms" URIs MUST be ignored by implementations.
本规范定义了单个<sms字段>：“正文”。本规范的扩展可以定义其他字段。扩展不得更改其扩展的规范的语义。实现必须忽略“sms”URI中遇到的未知字段。
The "body" <sms-field> 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" <sms-field> 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 <sms-body> 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.
“正文”<sms字段>用于定义要编写的sms消息的正文。它不能在“sms”URI中出现多次。它由百分比编码的UTF-8字符组成。实现必须确保在发送之前将“body”<sms field>字符转换为合适的字符编码，最流行的是7位sms字符编码，另一种变体（尽管没有7位sms普遍支持）是UCS-2字符编码（两者都在[sms-CHAR]中指定）。实现可以选择丢弃（或转换）<sms正文>中的字符，这些字符不受用于发送sms消息的sms字符集的支持。如果他们放弃或转换字符，他们必须通知用户。
The syntax definition for <escaped-value> refers to the text of an SMS where all <reserved> (as per [RFC3986]) characters in the SMS text are percent-encoded, please refer to [RFC3986] for the definitions of <unreserved> and <pct-encoded> and for details about percent-encoding.
<Escape value>的语法定义是指SMS文本中所有<reserved>（根据[RFC3986]）字符均采用百分比编码的文本，有关<unreserved>和<pct encoded>的定义以及百分比编码的详细信息，请参阅[RFC3986]。
User agents SHOULD support multiple recipients and SHOULD make it clear to users what the entire list of recipients is before committing the user to sending all the messages.
用户代理应支持多个收件人，并应在向用户提交发送所有邮件之前，向用户说明收件人的完整列表。
The following list describes the steps for processing an "sms" URI:
以下列表描述了处理“sms”URI的步骤：
1. The phone number of the first <sms-recipient> is extracted. It is the phone number of the final recipient and it MUST be written in international form with country code, unless the number only works from inside a certain geographical area or a network. Note that some numbers may work from several networks but not from the whole world -- these SHOULD be written in international form. According to [RFC3966], all international numbers MUST begin with a "+" character. Hyphens, dots, and parentheses (referred to as "visual separators" in RFC 3966) are used only to improve readability and MUST NOT convey any other meaning.
1. 提取第一个<sms收件人>的电话号码。它是最终收件人的电话号码，必须以国际形式书写，并带有国家代码，除非该号码仅在特定地理区域或网络内有效。请注意，一些数字可能来自多个网络，但不是来自全世界——这些数字应以国际形式书写。根据[RFC3966]，所有国际号码必须以“+”字符开头。连字符、点和括号（在RFC 3966中称为“可视分隔符”）仅用于提高可读性，不得传达任何其他含义。
2. The "body" <sms-field> is extracted, if present.
2. 提取“正文”<sms字段>（如果存在）。
3. The user agent SHOULD provide some means for message composition, either by implementing this itself or by accessing a service that provides it. Message composition SHOULD start with the body extracted from the "body" <sms-field>, if present.
3. 用户代理应该提供一些消息合成的方法，或者通过实现它本身，或者通过访问提供它的服务。消息合成应以从“正文”<sms字段>（如果存在）中提取的正文开始。
4. After message composition, a user agent SHOULD try to send the message first using the default delivery method employed by that user agent. If that fails, the user agent MAY try another delivery method.
4. 消息合成后，用户代理应首先尝试使用该用户代理使用的默认传递方法发送消息。如果失败，用户代理可以尝试其他传递方法。
5. If the URI contains a comma-separated list of recipients (i.e., it contains multiple <sms-recipient> parts), all of them are processed in this manner. Exactly the same message SHOULD be sent to all of the listed recipients, which means that the message resulting from the message composition step for the first recipient is used unaltered for all other recipients as well.
5. 如果URI包含以逗号分隔的收件人列表（即，它包含多个<sms recipient>部分），则所有收件人都将以这种方式处理。应将完全相同的消息发送给所有列出的收件人，这意味着第一个收件人的消息合成步骤产生的消息也将用于所有其他收件人，不会改变。
Two "sms" URIs are equivalent according to the following rules. Since the definition of the <telephone-subscriber> is taken from [RFC3966], equivalence of individual values of <telephone-subscriber> is based on the rules defined in Section 4 of [RFC3966], repeated here for convenience:
根据以下规则，两个“sms”URI是等效的。由于<telephone subscriber>的定义取自[RFC3966]，因此<telephone subscriber>的各个值的等效性基于[RFC3966]第4节中定义的规则，为方便起见在此重复：
o Both must be either a <local-number> or a <global-number<, i.e., start with a "+".
o 两者都必须是<local number>或<global number<，即以“+”开头。
o The <global-number-digits> and the <local-number-digits> must be equal, after removing all visual separators.
o 移除所有可视分隔符后，<全局数字>和<本地数字>必须相等。
o For mandatory additional parameters and the <phone-context> and <extension> parameters defined in [RFC3966], the <phone-context> parameter value is compared either as a host name if it is a <domainname> or digit-by-digit if it is <global-number-digits>. The latter is compared after removing all <visual-separator> characters.
o 对于强制性附加参数以及[RFC3966]中定义的<phone context>和<extension>参数，<phone context>参数值将作为主机名（如果是<domainname>）进行比较，如果是<global number digits>，则逐位进行比较。删除所有<visual separator>字符后，将比较后者。
o Parameters are compared according to <pname>, regardless of the order they appeared in the URI. If one URI has a parameter name not found in the other, the two URIs are not equal.
o 参数根据<pname>进行比较，而不管它们在URI中出现的顺序。如果一个URI的参数名在另一个URI中找不到，则两个URI不相等。
o URI comparisons are case-insensitive.
o URI比较不区分大小写。
Since "sms" URIs can contain multiple <telephone-subscriber>s as well as <sms-fields>, in addition to adopting the rules defined for comparing <telephone-subscriber>s as defined by [RFC3966], two "sms" URIs are only equivalent if their <sms-fields> are identical, and if all <telephone-subscriber>s, compared pairwise as a set (i.e., without taking sequence into consideration), are equivalent.
由于“sms”URI可以包含多个<telephone subscriber>以及<sms fields>，除了采用[RFC3966]定义的用于比较<telephone subscriber>的规则外，只有当两个“sms”URI的<sms fields>相同，并且如果所有<telephone subscriber>都作为一组成对比较时，它们才是等效的（即，不考虑顺序）是等效的。
sms:+15105550101
短信：+15105550101
This indicates an SMS-message-capable recipient at the given telephone number. The message is sent using the user agent's default SMS delivery method.
这表示在给定电话号码处有SMS消息功能的收件人。使用用户代理的默认SMS传递方法发送消息。
sms:+15105550101,+15105550102
sms:+15105550101,+15105550102
This indicates SMS-message-capable recipients at the given telephone numbers. The identical message should be sent to both recipients using the user agent's default SMS delivery method.
这表示在给定的电话号码上支持SMS消息的收件人。应使用用户代理的默认SMS传递方法将相同的消息发送给两个收件人。
sms:+15105550101?body=hello%20there
sms:+15105550101?body=hello%20there
In this case, a message (initially being set to "hello there", which may be modified by the user before sending) will be sent via SMS using the user agent's default SMS delivery method.
在这种情况下，将使用用户代理的默认SMS传递方法通过SMS发送消息（最初设置为“hello there”，用户可以在发送之前对其进行修改）。
When using an "sms" type URI as an action URI for HTML form submission [HTML401], the form contents MUST be packaged in the SMS message just as they are packaged when using a "mailto" URI [RFC2368], using the "application/x-www-form-urlencoded" media type (as defined by HTML [HTML401]), effectively packaging all form data into URI-compliant syntax [RFC3986]. The SMS message MUST NOT
当使用“sms”类型URI作为HTML表单提交[HTML401]的操作URI时，表单内容必须打包在sms消息中，就像使用“mailto”URI[RFC2368]打包一样，使用“application/x-www-form-urlencoded”媒体类型（由HTML[HTML401]定义）打包一样，有效地将所有表单数据打包为URI兼容语法[RFC3986]。SMS消息不能被删除
contain any HTTP header fields, only the form data. The media type is implicit. It MUST NOT be transferred in the SMS message. Since the SMS message contains the form field values, the body <sms-field> of an "sms" type URI used for an HTML form will be ignored.
包含任何HTTP头字段，仅包含表单数据。媒体类型是隐式的。不得在SMS消息中传输。由于SMS消息包含表单字段值，因此将忽略用于HTML表单的“SMS”类型URI的主体<SMS field>。
The character encoding used for form submissions MUST be UTF-8 [RFC3629]. It should be noted, however, that user agents MUST percent-encode form submissions before sending them (this encoding is specified by the URI syntax [RFC3986]).
用于表单提交的字符编码必须为UTF-8[RFC3629]。但是，应该注意，用户代理必须在发送表单提交之前对表单提交进行百分比编码（此编码由URI语法[RFC3986]指定）。
The user agent SHOULD inform the user about the possible security hazards involved when submitting the form (it is probably being sent as plain text over an air interface).
提交表单时，用户代理应告知用户可能涉及的安全隐患（可能通过空中接口以纯文本形式发送）。
If the form submission is longer than the maximum SMS message size, the user agent MAY either concatenate SMS messages, if it is able to do so, or it MAY refuse to send the message. The user agent MUST NOT send out partial form submissions.
如果表单提交长度超过最大SMS消息大小，则用户代理可以连接SMS消息（如果它能够这样做），也可以拒绝发送消息。用户代理不得发送部分表单提交。
This memo requests the registration of the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. The registration request complies with [RFC4395].
此备忘录要求注册统一资源标识符（URI）方案“sms”，以指定sms消息的一个或多个收件人。注册请求符合[RFC4395]。
sms
短讯服务
Permanent
永久的
See Section 2.
见第2节。
The "sms" URI scheme defines a way for a message to be composed and then transmitted using the SMS message transmission method. This scheme can thus be compared to be "mailto" URI scheme [RFC2368]. See Section 2.3 for the details of operation.
“sms”URI方案定义了一种方法，用于编写消息，然后使用sms消息传输方法进行传输。因此，可以将此方案与“mailto”URI方案[RFC2368]进行比较。有关操作的详细信息，请参见第2.3节。
The optional body field of "sms" URIs may contain a message text, but this text uses percent-encoded UTF-8 characters and thus can always be represented using URI characters. See Section 2 for the details of encoding.
“sms”URI的可选正文字段可能包含消息文本，但此文本使用百分比编码UTF-8字符，因此始终可以使用URI字符表示。有关编码的详细信息，请参见第2节。
The "sms" URI scheme is intended to be used in a similar way as the "mailto" URI scheme [RFC2368]. By using "sms" URIs, authors can embed information into documents that can be used as a starting point for initiating message composition. Whether the client is sending the message itself (for example, over a GSM air interface) or redirecting the user to a third party for message composition (such as a Web service for sending SMS messages) is outside of the scope of the URI scheme definition.
“sms”URI方案旨在以与“mailto”URI方案类似的方式使用[RFC2368]。通过使用“sms”URI，作者可以将信息嵌入到文档中，作为启动消息合成的起点。客户端是否正在发送消息本身（例如，通过GSM空中接口）或将用户重定向到第三方以进行消息合成（例如用于发送SMS消息的Web服务），不在URI方案定义的范围内。
No interoperability issues have been identified.
尚未发现互操作性问题。
See Section 4.
见第4节。
Erik Wilde School of Information UC Berkeley Berkeley, CA 94720-4600 U.S.A. tel:+1-510-6432252 mailto:dret@berkeley.edu
埃里克·王尔德信息学院加州大学伯克利分校伯克利分校94720-4600美国电话：+1-510-6432252邮箱：dret@berkeley.edu
SMS messages are transported without any provisions for privacy or integrity, so SMS users should be aware of these inherent security problems of SMS messages. Unlike electronic mail, where additional mechanisms exist to layer security features on top of the basic infrastructure, there currently is no such framework for SMS messages.
SMS消息的传输没有任何隐私或完整性规定，因此SMS用户应该了解SMS消息的这些固有安全问题。与电子邮件不同的是，在电子邮件中，存在额外的机制来将安全功能分层到基本基础设施之上，而目前还没有用于SMS消息的此类框架。
SMS messages very often are delivered almost instantaneously (if the receiving SMS client is online), but there is no guarantee for when SMS messages will be delivered. In particular, SMS messages between
短信通常几乎是即时发送的（如果接收短信的客户端在线），但无法保证何时发送短信。特别是，手机之间的短信
different network operators sometimes take a long time to be delivered (hours or even days) or are not delivered at all, so applications SHOULD NOT make any assumptions about the reliability and performance of SMS message transmission.
不同的网络运营商有时需要很长时间才能交付（数小时甚至数天），或者根本无法交付，因此应用程序不应该对SMS消息传输的可靠性和性能做出任何假设。
In most networks, sending SMS messages is not a free service. Therefore, SMS clients MUST make sure that any action that incurs costs is acknowledged by the end user, unless explicitly instructed otherwise by the end user. If an SMS client has different ways of submitting an SMS message (such as a Web service and a phone line), then the end user MUST have a way to control which way is chosen.
在大多数网络中，发送短信不是免费服务。因此，除非最终用户另有明确指示，否则SMS客户端必须确保导致成本的任何操作都得到最终用户的认可。如果SMS客户端有不同的方式提交SMS消息（例如Web服务和电话线），那么最终用户必须有一种方式来控制选择哪种方式。
SMS clients often are limited devices (typically mobile phones), and the sending SMS client SHOULD NOT make any assumptions about the receiving SMS client supporting any non-standard services, such as proprietary message concatenation or proprietary content types. However, if the sending SMS client has prior knowledge about the receiving SMS client, then he MAY use this knowledge to compose non-standard SMS messages.
SMS客户端通常是有限的设备（通常是移动电话），发送SMS客户端不应假设接收SMS客户端支持任何非标准服务，例如专有消息连接或专有内容类型。然而，如果发送SMS客户端事先知道接收SMS客户端，则他可以使用该知识来撰写非标准SMS消息。
There are certain special SMS messages defined in the SMS specification [SMS] that can be used, for example, to turn on indicators on the phone display or to send data to certain communication ports (comparable to UDP ports) on the device. Certain proprietary systems (for example, the Wireless Application Protocol [WAP]) define configuration messages that may be used to reconfigure the devices remotely. Any SMS client SHOULD make sure that malicious use of such messages is not possible, for example, by filtering out certain SMS User Data header fields. Gateways that accept SMS messages (e.g., in email messages or Web forms) and pass them on to an SMSC SHOULD implement this kind of "firewalling" approach as well.
SMS规范[SMS]中定义了某些特殊SMS消息，可用于打开手机屏幕上的指示灯或将数据发送到设备上的某些通信端口（与UDP端口相当）。某些专有系统（例如，无线应用协议[WAP]）定义了可用于远程重新配置设备的配置消息。任何SMS客户端都应确保不可能恶意使用此类消息，例如，通过过滤掉某些SMS用户数据头字段。接受SMS消息（如电子邮件或Web表单）并将其传递给SMSC的网关也应实现这种“防火墙”方法。
Because of the narrow bandwidth of the SMS communications channel, there should also be checks in place for excessively long concatenated messages. As an example, it may take two minutes to transfer thirty concatenated text messages.
由于SMS通信信道的带宽较窄，还应检查过长的连接消息。例如，传输三十条连接的文本消息可能需要两分钟。
Unchecked input from a user MUST NOT be used to populate any other fields in an SMS message other than the User Data field (not including the User Data header field). All other parts, including the User Data header, of the short message should only be generated by trusted means.
来自用户的未选中输入不得用于填充SMS消息中除用户数据字段（不包括用户数据标题字段）以外的任何其他字段。短信的所有其他部分，包括用户数据头，只能通过可信方式生成。
By including "sms" URIs in unsolicited messages (a.k.a. "spam") or other types of advertising, the originator of the "sms" URIs may attempt to reveal an individual's phone number and/or to link the identity (i.e., email address) used for messaging with the identity (i.e., phone number) used for the mobile phone. This attempt to
通过在未经请求的消息（也称为“垃圾邮件”）或其他类型的广告中包括“sms”uri，“sms”uri的发起人可尝试揭示个人的电话号码和/或将用于消息传递的身份（即电子邮件地址）与用于移动电话的身份（即电话号码）链接。这一尝试
collect information may be a privacy issue, and user agents may make users aware of that risk before composing or sending SMS messages. Users agents that do not provide any feedback about this privacy issue make users more vulnerable to this kind of attack.
收集信息可能是一个隐私问题，用户代理可能会在编写或发送SMS消息之前让用户意识到这一风险。不提供有关此隐私问题的任何反馈的用户代理会使用户更容易受到此类攻击。
A user agent SHOULD NOT send out SMS messages without the knowledge of the user because of associated risks, which include sending masses of SMS messages to a subscriber without his consent, and the costs involved in sending an SMS message.
用户代理不应在用户不知情的情况下发送SMS消息，因为存在相关风险，包括未经用户同意向用户发送大量SMS消息，以及发送SMS消息所涉及的成本。
As suggested functionality, the user agent MAY offer a possibility for the user to filter out those phone numbers that are expressed in local format, as most premium-rate numbers are expressed in local format, and because determining the correct local context (and hence the validity of the number to this specific user) may be very difficult.
作为建议的功能，用户代理可以为用户提供过滤掉以本地格式表示的那些电话号码的可能性，因为大多数费率号码是以本地格式表示的，并且因为确定正确的本地上下文（以及因此该号码对该特定用户的有效性）可能非常困难。
When using "sms" URIs as targets of forms (as described in Section 2.6), the user agent SHOULD inform the user about the possible security hazards involved when submitting the form (it is probably being sent as plain text over an air interface).
当使用“sms”URI作为表单的目标时（如第2.6节所述），用户代理应通知用户提交表单时可能涉及的安全隐患（可能是通过空中接口以纯文本形式发送）。
IANA has registered the "sms" URI scheme, using the template in Section 3, in accordance with [RFC4395].
IANA已根据[RFC4395]使用第3节中的模板注册了“sms”URI方案。
This document has been prepared using the IETF document DTD described in [RFC2629].
本文件使用[RFC2629]中描述的IETF文件DTD编制。
Thanks to (listed alphabetically) Claudio Allocchio, Derek Atkins, Nevil Brownlee, John Cowan, Leslie Daigle, Lisa Dusseault, Miguel Garcia, Vijay Gurbani, Alfred Hoenes, Cullen Jennings, Graham Klyne, Larry Masinter, Alexey Melnikov, Michael Patton, Robert Sparks, and Magnus Westerlund for their comments.
感谢（按字母顺序排列）克劳迪奥·阿洛奇、德里克·阿特金斯、内维尔·布朗利、约翰·考恩、莱斯利·戴格尔、丽莎·杜肖奥、米格尔·加西亚、维杰·古巴尼、阿尔弗雷德·霍恩斯、卡伦·詹宁斯、格雷厄姆·克莱恩、拉里·马辛特、阿列克西·梅尔尼科夫、迈克尔·巴顿、罗伯特·斯帕克斯和马格纳斯·韦斯特隆德的评论。
[Err203] RFC Errata, "Errata ID 203", RFC 3629, <http://www.rfc-editor.org>.
[Err203]RFC勘误表，“勘误表ID 203”，RFC 3629<http://www.rfc-editor.org>.
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C REC-html401, December 1999, <http://www.w3.org/TR/html401/>.
[HTML401]Raggett，D.，Le Hors，A.，和I.Jacobs，“HTML4.01规范”，W3C REC-HTML401，1999年12月<http://www.w3.org/TR/html401/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[SMS] European Telecommunications Standards Institute, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS) (Release 7)", March 2007, <http:// www.3gpp.org/ftp/Specs/archive/23_series/23.040/ 23040-701.zip>.
[SMS]欧洲电信标准协会，“3GPP TS 23.040 V7.0.1（2007-03）：第三代合作伙伴项目；技术规范组核心网络和终端；短消息服务（SMS）的技术实现（第7版）”，2007年3月，<http://www.3GPP.org/ftp/Specs/archive/23_series/23.040/23040-701.zip>。
[SMS-CHAR] European Telecommunications Standards Institute, "TS 100 900 (GSM 03.38 version 7.2.0 Release 1998): Digital Cellular Telecommunications System (Phase 2+); Alphabets and language-specific information", July 1999, <http:// www.3gpp.org/ftp/Specs/archive/03_series/03.38/ 0338-720.zip>.
[SMS-CHAR]欧洲电信标准协会，“TS 100 900（GSM 03.38版本7.2.0 1998年发布）：数字蜂窝通信系统（第2+阶段）；字母表和语言特定信息”，1999年7月，<http://www.3gpp.org/ftp/Specs/archive/03_series/03.38/0338-720.zip>。
[RFC2368] Hoffmann, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, June 1998.
[RFC2368]Hoffmann，P.，Masinter，L.，和J.Zawinski，“邮件URL方案”，RFC 2368，1998年6月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
[RFC2838] Zigmond, D. and M. Vickers, "Uniform Resource Identifiers for Television Broadcasts", RFC 2838, May 2000.
[RFC2838]Zigmond，D.和M.Vickers，“电视广播的统一资源标识符”，RFC 28382000年5月。
[WAP] WAP Forum, "Wireless Application Protocol - Architecture Specification (WAP-210-WAPArch-20010712)", July 2001.
[WAP]WAP论坛，“无线应用协议-体系结构规范（WAP-210-WAPArch-20010712）”，2001年7月。
[uri-clarification] World Wide Web Consortium, "URIs, URLs, and URNs: Clarifications and Recommendations 1.0", W3C uri-clarification , September 2001, <http://www.w3.org/TR/uri-clarification/>.
[uri澄清]万维网联盟，“uri、URL和URN：澄清和建议1.0”，W3C uri澄清，2001年9月<http://www.w3.org/TR/uri-clarification/>.
The following syntax is reproduced from Section 3 of [RFC3966]. It defines the <telephone-subscriber> part used in the "sms" URI scheme syntax. Please note that it includes Erratum 203 [Err203] for RFC 3966, which changes the definition of <isdn-subaddress>.
以下语法摘自[RFC3966]第3节。它定义了“sms”URI方案语法中使用的<telephone subscriber>部分。请注意，其中包括RFC 3966的勘误表203[Err203]，它更改了<isdn子地址>的定义。
telephone-subscriber = global-number / local-number
global-number = global-number-digits *par
local-number = local-number-digits *par context *par
par = parameter / extension / isdn-subaddress
isdn-subaddress = ";isub=" 1*paramchar
extension = ";ext=" 1*phonedigit
context = ";phone-context=" descriptor
descriptor = domainname / global-number-digits
global-number-digits = "+" *phonedigit DIGIT *phonedigit
local-number-digits =
*phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
domainname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter = ";" pname ["=" pvalue ]
pname = 1*( alphanum / "-" )
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / pct-encoded
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
alphanum = ALPHA / DIGIT
telephone-subscriber = global-number / local-number
global-number = global-number-digits *par
local-number = local-number-digits *par context *par
par = parameter / extension / isdn-subaddress
isdn-subaddress = ";isub=" 1*paramchar
extension = ";ext=" 1*phonedigit
context = ";phone-context=" descriptor
descriptor = domainname / global-number-digits
global-number-digits = "+" *phonedigit DIGIT *phonedigit
local-number-digits =
*phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
domainname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter = ";" pname ["=" pvalue ]
pname = 1*( alphanum / "-" )
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / pct-encoded
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
alphanum = ALPHA / DIGIT
Authors' Addresses
作者地址
Erik Wilde UC Berkeley School of Information Berkeley, CA 94720-4600 U.S.A.
埃里克·王尔德加州大学伯克利信息学院，加利福尼亚州伯克利，美国94720-4600。
Phone: +1-510-6432253
EMail: dret@berkeley.edu
URI: http://dret.net/netdret/
Phone: +1-510-6432253
EMail: dret@berkeley.edu
URI: http://dret.net/netdret/
Antti Vaha-Sipila Nokia
诺基亚安蒂·瓦哈·西皮拉
EMail: antti.vaha-sipila@nokia.com
URI: http://www.iki.fi/avs/
EMail: antti.vaha-sipila@nokia.com
URI: http://www.iki.fi/avs/