[要約] RFC 5724は、GSMの短信サービス（SMS）のためのURIスキームに関する仕様であり、SMSメッセージの送受信を容易にするための方法を提供します。このRFCの目的は、異なるアプリケーションやプロトコル間でのSMSの統合と相互運用性を向上させることです。
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)
モバイル通信のためのグローバルシステムのためのURIスキーム（GSM）ショートメッセージサービス（SMS）
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.
このメモは、SMSメッセージの1つ以上の受信者を指定するための均一なリソース識別子（URI）スキーム「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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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（モバイル通信用のグローバルシステム）は、世界の多くの地域で広く使用されているデジタル携帯電話標準です。最初に900 MHz前後の周波数帯域にちなんで名付けられたGSM-900は、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メッセージの最大長は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.
SMSメッセージの160文字のコンテンツタイプは、最も広く使用されているものですが、小さなビットマップ（「オペレーターロゴ」）や音符の単純な形式（「Ring Tones」など、SMSメッセージには他にも多数のコンテンツタイプがあります。）。ただし、これらの形式は独自であり、このメモでは考慮されていません。
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 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メッセージの長さ（140オクテット）は制限されており、SMS仕様の最初のバージョンでは、SMSメッセージを連結するための標準化されたメソッドは指定されていませんでした。結果として、いくつかの独自の方法が発明されましたが、現在のSMS仕様はメッセージの連結を指定しています。この状況に対処するために、メッセージを作成する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）と呼ばれるエンティティによって保存され、サブスクライバーがネットワークに接続すると受信者に送信されます。協同組合のSMSCの数は、メッセージを送信するときにSMS送信者（つまり、SMSメッセージをGSTNインフラストラクチャに送信するエンティティ）に知られている必要があります（通常、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 protocols (HTTP, FTP), broadcast media (TV channels [RFC2838]), messaging (email [RFC2368]), and even telephone numbers (voice [RFC3966]).
インターネット上のリソースを識別するためのコア仕様の1つは[RFC3986]であり、ユニフォームリソース識別子（URI）の構文とセマンティクスを指定します。URIの最も重要な概念は「スキーム」であり、リソースを一意に特定して対処できるフレームワークを定義します。URISは、ユーザーがリソースにアクセスできるようにし、アクセスプロトコル（HTTP、FTP）、ブロードキャストメディア（TVチャンネル[RFC2838]）、メッセージング（電子メール[RFC2368]）、さらには電話番号などの非常に多様なスキームに使用できます。]）。
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という用語のみが使用され、最も基本的な概念を参照します。World Wide Web Consortium（W3C）は、URI、URN、およびURLのトピックについて詳細に議論するメモ[URI-Clorification]を発行しました。
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).
Webに普遍的にアクセスできる重要な理由の1つは、一意のインターフェイスを介してすべての情報にアクセスできることです。この種の統合により、情報を簡単に提供したり、消費したりできます。この統合の1つの側面は、複数のコンテンツ形式（HTML、GIF、JPEGなど）およびアクセススキーム（HTTP、HTTP、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を選択する（クリックする）ときに電子メール構成機能を提供することでそれをサポートしているため、非常に有用で人気があることが証明されています。同様に、ユーザーがURIを選択したときにSMSメッセージ構成機能を提供することにより、「SMS」スキームはユーザーエージェントによってサポートできます。ユーザーエージェントが組み込みのSMSメッセージ構成施設を提供していない場合、このようなサービスを提供するWebページを開くことで、スキームをサポートすることができます。使用する特定のWebページは、ユーザーが構成することができ、各ユーザーが選択した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.
このメモの目標は、ユーザーエージェント（Webブラウザーや電子メールクライアントなど）がサポートを開始できるように、「SMS」URIスキームを指定することです。「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」URIS [RFC2368]、または「Tel」または「Fax」URIS [RFC3966]の代替手段を提供できます。「SMS」URIがアクティブ化されると、ユーザーエージェントは、「Mailto」がメールクライアントを開くように、SMSメッセージを送信するプログラムを開始する場合があります。残念ながら、ほとんどのブラウザは、内部でサポートしていないメディアタイプのコンテンツの外部処理をサポートするのと同じ一般化された方法で、内部的にサポートされていない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メッセージを連結して、より長いメッセージを形成することができます。メッセージの長さを制限するかどうか、および必要に応じてユーザーインターフェイスにこの制限を示す方法を決定するのはユーザーエージェント次第です。これには1つの例外があります。セクション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.
HyperText Markup Language（HTML）[HTML401]は、ユーザーから情報を収集し、処理のためにサーバーに渡す方法を提供します。この機能は「HTMLフォーム」として知られています。通常、Fill-inフォームは、HyperText Transfer Protocol（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].
大文字のキーワード「必須」、「必要」、「必須」、「shall」、「shall "、" shall "、" should "、" nove "、" becommended "、" may "、および" optional "[RFC2119]に記載されているように解釈されます。
Syntax definitions are given using the Augmented BNF (ABNF) for syntax specifications [RFC5234].
構文定義は、構文仕様のために拡張BNF（ABNF）を使用して与えられます[RFC5234]。
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の機能に匹敵します。これは、（[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]とそのERRATUM 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メッセージは、Modemと適切なプロトコルを使用するか、SMSメッセージを送信するためのWebベースのサービスなど、他のプロトコルを介してサービスにアクセスすることにより、GSM Airインターフェイスを介して送信できます。また、延期された配送や配達通知のリクエストなどの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
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'."
<電話subscriber>の構文定義は、[RFC3966]のセクション5.1から取得されます。その仕様では、erratum 203 [err203]を検討してください。読者の便利さのために、付録Aには、Erratum 203を含む電話番号URIスキームの固定構文が含まれていますが、RFC 3966（およびすべての該当するErrata）は規範的な参照です。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-field>： "body"を定義します。この仕様の拡張は、追加のフィールドを定義する場合があります。拡張機能は、拡張している仕様のセマンティクスを変更してはなりません。「SMS」で遭遇した未知のフィールドは、実装によって無視する必要があります。
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.
「body」<sms-field>は、構成するSMSメッセージのボディを定義するために使用されます。「SMS」URIに複数回表示してはなりません。パーセントエンコードされたUTF-8文字で構成されています。実装は、「body」<sms-field>文字が送信する前に適切な文字エンコードに変換されることを確認する必要があります。最も人気のあるものは、7ビットSMS文字エンコードである別のバリアントです（ただし、7ビットSMSほど普遍的にサポートされていません。）はUCS-2文字エンコード（両方とも[SMS-Char]で指定）です。実装は、SMSメッセージを送信するために使用しているSMS文字セットではサポートされていない<sms-body>の文字を破棄（または変換）することを選択できます。文字を破棄または変換する場合、ユーザーに通知する必要があります。
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.
<Escaped-Value>の構文定義は、SMSテキストのすべての<Reserved>（[rfc3986]に従って）文字がパーセントであるSMSのテキストを指します。>および<pct-encoded>およびパーセントエンコードの詳細。
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-Recipient>の電話番号が抽出されます。これは最終的な受信者の電話番号であり、特定の地理的エリアまたはネットワーク内からのみ機能しない限り、国のコードを使用して国際形式で記述する必要があります。いくつかの数字は、いくつかのネットワークから機能する可能性があるが、全世界からではなく機能する可能性があることに注意してください。これらは国際的な形で書かれるべきであることに注意してください。[RFC3966]によると、すべての国際的な数字は「」キャラクターから開始する必要があります。ハイフン、ドット、括弧（RFC 3966の「視覚分離器」と呼ばれる）は、読みやすさを改善するためにのみ使用され、他の意味を伝えてはなりません。
2. The "body" <sms-field> is extracted, if present.
2. 存在する場合、「ボディ」<sms-field>が抽出されます。
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-field>から抽出された本体から始まる必要があります。
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:
次の規則に従って、2つの「SMS」URIが同等です。<thone-subscriber>の定義は[rfc3966]から取られるため、<電話subscriber>の個々の値の等価性は、[RFC3966]のセクション4で定義されているルールに基づいています。
o Both must be either a <local-number> or a <global-number<, i.e., start with a "+".
o どちらも<local-number>またはa <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>またはdigit-by digitの場合、ホスト名として比較されます。<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 パラメーターは、URIに表示された順序に関係なく、<pname>に従って比較されます。1つのURIが他のURIにないパラメーター名を持っている場合、2つの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は、[RFC3966]で定義されている<電話subscriber> sを比較するために定義されたルールを採用することに加えて、複数の<電話subscriber>と<sms-fields>を含むことができるため、2つの「SMS」URIS<sms-fields>が同一である場合にのみ同等であり、すべての<電話subscriber> sがペアワイズをセットとして比較した場合（つまり、シーケンスを考慮せずに）、同等です。
sms:+15105550101
SMS：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-Message対応の受信者を示しています。メッセージは、ユーザーエージェントのデフォルトSMS配信方法を使用して送信されます。
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-Message対応の受信者を示しています。同一のメッセージは、ユーザーエージェントのデフォルトSMS配信方法を使用して、両方の受信者に送信する必要があります。
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.
この場合、メッセージ（最初は「Hello There」に設定されています。これは、送信前にユーザーが変更することができます）は、ユーザーエージェントのデフォルトSMS配信方法を使用してSMSを介して送信されます。
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 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.
「SMS」タイプのURIをHTMLフォーム提出[HTML401]のアクションURIとして使用する場合、「MailTo」URI [RFC2368]を使用するときにパッケージ化されているように、フォームの内容をSMSメッセージにパッケージ化する必要があります。/x-www-form-urlencoded "Media Type（HTML [HTML401]で定義）、すべてのフォームデータをURIに準拠した構文[RFC3986]に効果的にパッケージ化します。SMSメッセージには、Formデータのみが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].
このメモは、SMSメッセージの1つ以上の受信者を指定するために、ユニフォームリソース識別子（URI）スキーム「SMS」の登録を要求します。登録要求は[RFC4395]に準拠しています。
sms
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」URISのオプションのボディフィールドにはメッセージテキストが含まれている場合がありますが、このテキストはパーセントエンコードされた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」URISを使用することにより、著者は情報をメッセージの構成を開始するための出発点として使用できるドキュメントに情報を埋め込むことができます。クライアントがメッセージ自体を送信している（たとえば、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
Erik Wilde School of Information UC Berkeley Berkeley、CA 94720-4600 U.S.A. Tel：1-510-6432252 Mailto：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メッセージは非常に頻繁に瞬時に配信されます（受信SMSクライアントがオンラインである場合）が、SMSメッセージがいつ配信されるかについては保証はありません。特に、異なるネットワークオペレーター間のSMSメッセージは、配信に長い時間がかかることがあります（数時間または数日）、またはまったく配信されないため、アプリケーションは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クライアントが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メッセージ（たとえば、電子メールメッセージや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通信チャネルの帯域幅が狭いため、過度に連結したメッセージのチェックも施行される必要があります。例として、30の連結テキストメッセージを転送するのに2分かかる場合があります。
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 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」URIを未承諾メッセージ（別名「スパム」）または他のタイプの広告に含めることにより、「SMS」URISの発信者は、個人の電話番号を表示したり、アイデンティティをリンクしたりしようとする場合があります（つまり、メールアドレス）携帯電話に使用される身元（つまり、電話番号）のメッセージングに使用されます。情報を収集しようとするこの試みはプライバシーの問題である可能性があり、ユーザーエージェントは、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.
（アルファベット順にリストされている）Claudio Allocchio、Derek Atkins、Nevil Brownlee、John Cowan、Leslie Daigle、Lisa Dusseault、Miguel Garcia、Vijay Gurbani、Alfred Hoenes、Cullen Jennings、Graham Klyne、Larry Masinter、Raber、そして彼らのコメントについてマグナス・ウェスターランド。
[Err203] RFC Errata, "Errata ID 203", RFC 3629, <http://www.rfc-editor.org>.
[ERR203] RFC errata、 "errata 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、「HTML 4.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。、「電話番号のTel 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、「Uniform Resource Identifier（URI）：Generic Syntax」、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] European Telecommunications Standards Institute、「3GPP TS 23.040 V7.0.1（2007-03）：第3世代パートナーシッププロジェクト;技術仕様グループコアネットワークと端末、ショートメッセージサービス（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] European Telecommunications Standards Institute、「TS 100 900（GSM 03.38バージョン7.2.0リリース1998）：Digital Cellular Telecommunications System（フェーズ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、「The Mailto URL Scheme」、RFC 2368、1998年6月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年6月。
[RFC2838] Zigmond, D. and M. Vickers, "Uniform Resource Identifiers for Television Broadcasts", RFC 2838, May 2000.
[RFC2838] Zigmond、D。およびM. Vickers、「テレビ放送のためのユニフォームリソース識別子」、RFC 2838、2000年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-Clorification] World Wide Web Consortium、「URIS、URLS、およびURNS：明確化と推奨事項1.0」、W3C URI-Clorification、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スキームの構文で使用される<電話サブスクリバー>パーツを定義します。RFC 3966のerratum 203 [err203]が含まれており、<isdn-subaddress>の定義が変更されます。
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.
Erik Wilde UC Berkeley Information School of Information Berkeley、CA 94720-4600 U.S.A.
Phone: +1-510-6432253
EMail: dret@berkeley.edu
URI: http://dret.net/netdret/
Antti Vaha-Sipila Nokia
Antti Vaha-Sipila Nokia
EMail: antti.vaha-sipila@nokia.com
URI: http://www.iki.fi/avs/