RFC 4415 - IANA Registration for Enumservice Voice 日本語訳

URL : https://tools.ietf.org/html/rfc4415
タイトル : RFC 4415 - EnumserviceボイスのIANA登録
翻訳編集 : 自動生成

Network Working Group                                        R. Brandner
Request for Comments: 4415                                    Siemens AG
Category: Standards Track                                      L. Conroy
                                             Siemens Roke Manor Research
                                                              R. Stastny
                                                                   Oefeg
                                                           February 2006

                IANA Registration for Enumservice Voice

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2006）。

Abstract

抽象

This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call.

このサービスは、生成されたユニフォームリソース識別子（URI）に保持されている連絡先ができることを示しENUM仕様RFC 3761で定義されたIANA登録プロセスに従って、この文書は、（定義されたサブタイプ「TEL」を有する）Enumservice「音声」を登録します対話型音声（オーディオ）の呼び出しを開始するために使用すること。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Voice Service Registration  . . . . . . . . . . . . . . . . . . 3
   4.  Example of voice:tel Enumservice  . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
       7.1.  Normative References  . . . . . . . . . . . . . . . . . . 6
       7.2.  Informative References  . . . . . . . . . . . . . . . . . 6

1. Introduction

1. はじめに

ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms E.164 numbers [2] into domain names and then uses DNS (RFC 1034 [3]) features such as delegation through NS records, and the use of Naming Authority Pointer (NAPTR) records, to look up the communication services available for a specific domain name.

ENUM（E.164番号マッピング、RFC 3761 [1]）E.164番号を変換するシステムである[2]ドメイン名に、次にDNSを使用する（RFC 1034 [3]）のNSレコードをそのような委任などの機能、および特定のドメイン名のために利用可能な通信サービスをルックアップするために、権限ポインタ（NAPTR）レコードに名前を付けるの使用。

This document registers an Enumservice according to the guidelines given in RFC 3761 to be used for provisioning in the services field of a NAPTR [4] resource record to indicate what class of functionality a given endpoint offers. The registration is defined within the Dynamic Delegation Discovery System (DDDS, [5] [6] [4] [7] [8]) hierarchy, for use with the "E2U" DDDS application defined in RFC 3761.

このドキュメントは、Enumserviceは、RFC 3761で与えられたガイドラインに従って、特定のエンドポイントが提供する機能のどのクラスを示すために、NAPTR [4]リソースレコードのサービス分野でのプロビジョニングに使用されるように登録します。登録は、RFC 3761で定義された "E2U" DDDSアプリケーションで使用するための階層、ダイナミックな委譲発見システム（[5] [6] [4] [7] [8] DDDS）内で定義されています。

Enumservices have a type and subtype. This latter is optional, as it may be implicit in the service type. The type defines the kind of communication session that can be initiated using the contact indicated by the URI generated by the enclosing NAPTR. In telecommunications engineering terms, it reflects the "teleservice".

Enumservicesはタイプとサブタイプを持っています。それはサービスのタイプに暗黙的であってもよいように、この後者は、任意です。タイプは、囲みNAPTRによって生成されたURIで示されるコンタクトを使用して開始することができる通信セッションの種類を定義します。電気通信工学の面では、「テレサービス」を反映しています。

The subtype defines the subsystem that is to be used to initiate the communication session. Note that the subtype definition is usually associated with the URI scheme that is to be used.

サブタイプは、通信セッションを開始するために使用されるサブシステムを定義します。サブタイプの定義は、通常使用されるURIスキームに関連付けられていることに留意されたいです。

Both the type and subtype (where present) must be supported for the NAPTR to be used by a potential correspondent.

タイプおよびサブタイプ（存在する場合）の両方が電位相手が使用するNAPTRのためにサポートしなければなりません。

There are a number of DDDS applications in addition to ENUM (for example, see [7] and [8]). However, an Enumservice indication operates only within the context of the "E2U" (ENUM) DDDS Application.

ENUMに加えDDDSアプリケーションの数がある（例えば、文献[7]と[8]）。しかし、Enumservice指示は、「E2U」（ENUM）DDDSアプリケーションのコンテキスト内で動作します。

Whilst the protocol elements that make up ENUM are defined in the above documents and in this one, further examples of the use to which these may be put are given in other documents, for example, in ETSI TS 102 172 [11].

ENUMを構成するプロトコル要素は、上記文書およびこのいずれかで定義されている一方で、これらは置くことができるため、使用のさらなる例は、他の文書に記載されている、例えば、ETSI TS 102 172 [11]。

This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call.

このサービスは、生成されたURIに保持されたコンタクトを開始するために使用することができることを示すENUM仕様RFC 3761で定義されたIANA登録プロセスに従ってこの文書は、（定義されたサブタイプ「TEL」を有する）Enumservice「声」を、レジスタ対話型音声（オーディオ）コール。

2. Terminology

2.用語

The 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 BCP 14, RFC 2119 [9].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[9]。

3. Voice Service Registration

3.音声サービス登録

Enumservice Name: "voice"

Enumservice名：「声」

Enumservice Type: "voice"

Enumserviceの種類：「声」

Enumservice Subtype: "tel"

Enumserviceサブタイプ： "TEL"

URI Scheme: 'tel:'

URIスキーム： 'TEL：'

Functional Specification:

機能仕様：

The kind of communication indicated by this Enumservice is "Interactive Voice". From a protocol perspective, this communication is expected to involve bidirectional media streams carrying audio data.

このEnumserviceが示す通信の種類は、「対話型音声」です。プロトコルの観点から、この通信は、オーディオデータを搬送する双方向メディアストリームを含むことが期待されます。

A client may imply that the person controlling population of a NAPTR holding this Enumservice indicates his capability to engage in an interactive voice session when contacted using the URI generated by this NAPTR.

クライアントは、このEnumserviceを保持NAPTRの人口を制御する人が、このNAPTRによって生成されたURIを使用して接触した場合に、対話型音声セッションに従事するために彼の能力を示すことを意味し得ます。

Security Considerations:

セキュリティの考慮事項：

See Section 5.

第5節を参照してください。

Intended Usage: COMMON

意図した使用法：COMMON

Authors:

著者：

Rudolf Brandner, Lawrence Conroy, and Richard Stastny (for author contact detail, see Authors' Addresses section)

ルドルフBrandner、ローレンスコンロイ、そしてリチャードStastny（著者の連絡先の詳細のために、著者のアドレスセクションを参照してください）

Any other information the author deems interesting:

著者は面白いと考えるその他の情報：

This Enumservice indicates that the person responsible for the NAPTR is accessible via the Public Switched Telephone Network (PSTN) or Public Land Mobile Network (PLMN) using the value of the generated URI.

このEnumserviceはNAPTRの責任者が、公開が生成URIの値を使用して電話網（PSTN）または公衆陸上モバイルネットワーク（PLMN）のスイッチを経由してアクセス可能であることを示しています。

The kind of subsystem required to initiate a Voice Enumservice with this subtype is a "Dialer". This is a subsystem that either provides a local connection to the PSTN or PLMN or provides an indirect connection to those networks. The subsystem will use the telephone number held in the generated URI to place a voice call. The voice call is placed to a network that uses E.164 numbers to route calls to an appropriate destination.

このサブタイプとの声Enumserviceを開始するのに必要なサブシステムの種類は、「ダイヤラ」です。これは、PSTNまたはPLMNへのローカル接続を提供したり、それらのネットワークへの間接接続を提供していずれかのサブシステムです。サブシステムは、音声通話を置くために生成されたURIで開催された電話番号を使用します。音声通話は、適切な宛先にコールをルーティングするためにE.164番号を使用するネットワークに配置されています。

Note that the PSTN/PLMN connection may be indirect. The end user receiving this NAPTR may have a relationship with a Communications Service Provider that accepts call initiation requests from that subsystem using an IP-based protocol such as SIP or H.323, and places the call to the PSTN using a remote gateway service. In this case, the provider either may accept requests using "tel:" URIs or has a defined mechanism to convert "tel:" URI values into a "protocol-native" form.

PSTN / PLMN接続が間接的であることに注意してください。このNAPTRを受信側ユーザは、SIPまたはH.323のようなIPベースのプロトコルを使用して、そのサブシステムから発信要求を受け付ける通信サービスプロバイダと関係を持って、リモートゲートウェイサービスを使用して、PSTNへの電話をかけることができます。この場合、プロバイダは、いずれかの「TEL：」を使用して要求を受け入れることができるURIをまたは「TEL：」に変換するように定義メカニズム有する「プロトコルネイティブ」形式にURI値。

The "tel:" URI value SHOULD be fully qualified (using the "global phone number" form of RFC 3966 [10]). A "local phone number" as defined in that document SHOULD NOT be used unless the controller of the zone in which the NAPTR appears is sure that it can be distinguished unambiguously by all clients that can access the resource record and that a call from their network access points can be routed to that destination.

「TEL：」URIの値は、完全修飾であるべきである（RFC 3966の「グローバル電話番号」の形式を使用して[10]）。 NAPTRが表示されているゾーンのコントローラがない限り使用してはならないことを文書で定義されている「ローカル電話番号は、」それはリソースレコードにアクセスすることができ、すべてのクライアントが、そのネットワークからの呼び出しという明確に区別することができることを確認していますアクセスポイントは、その宛先にルーティングすることができます。

4. Example of voice:tel Enumservice

声の4例：TEL Enumservice

The following is an example of the use of the Enumservice registered by this document in a NAPTR resource record.

以下は、NAPTRリソースレコードにこの文書によって登録Enumserviceの使用例です。

$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 3.8.0 NAPTR 10 100 "u" "E2U+voice:tel" "!^.*$!tel:+441414960000!" .

$ ORIGINの0.6.9.2.3.6.1.4.4.e164.arpa。 3.8.0 NAPTR 10 100 "U" "E2U +音声：TEL" "^ * $ TEL：！。！！441414960000" 。

5. Security Considerations

5.セキュリティについての考慮事項

DNS, as used by ENUM, is a global, distributed database. Thus, any information stored there is visible to anyone anonymously. Whilst this is not qualitatively different from publication in a telephone directory, it does open the data subjects to having "their" information collected automatically without any indication that this has been done or by whom.

DNSは、ENUMで使用されるように、グローバルな分散データベースです。したがって、そこに格納された任意の情報は、匿名で誰でも見ることができます。これは電話帳で出版とは質的に異なるものではない一方で、それは「彼ら」の情報は、これがまたは誰によって行われていること兆候なしに自動的に収集されたデータへの科目を開くありません。

Such data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, they are used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email sent increases when he or she posts to the mailing list; publication of a telephone number in ENUM is no different, and may be used for attempts to send "junk faxes" or "junk SMS", for example.

第三者によるこのようなデータの収穫は、多くの場合、要求されていない情報については、ターゲットのリストを生成するために使用されます。要するに、彼らは「スパム」に対処するために使用されています。ウェブアーカイブメーリングリストを使用して誰もが彼または彼女がメーリングリストに投稿するとき、「スパム」メールの容量が増加して送信されていることを認識しています。 ENUMの電話番号の出版物は異なっていない、例えば、「ジャンクファックス」または「ジャンクSMS」を送信しようとするために使用することができます。

Many mailing list users have more than one email address and use "sacrificial" email accounts when posting to such lists to help filter out unrequested emails sent to them. This is not so easy with published telephone numbers; the PSTN E.164 number assignment process is much more involved and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus, providing a "sacrificial" phone number in any publication is not possible.

多くのメーリングリストのユーザーが複数のメールアドレスを持っており、それらに送信された要求されていない電子メールをフィルタリング助けるために、このようなリストに投稿するときに「犠牲」の電子メールアカウントを使用します。これは、公表された電話番号とそう簡単ではありません。 PSTN E.164番号割り当てプロセスは、はるかに複雑で、通常は単一のE.164番号（または番号の一定範囲）であり、各PSTNアクセスに関連しています。したがって、いずれの刊行物に「犠牲」の電話番号を提供することはできません。

Due to the implications of publishing data on a globally accessible database, as a principle the data subjects MUST give their explicit informed consent to data being published in ENUM.

原則としてグローバルにアクセス可能なデータベース上のデータのパブリッシュの意味合いにデータ被験者はENUMで公開されているデータへの明示的なインフォームドコンセントを与える必要があります。

In addition, they should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent.

加えて、それらは、原因第三者による収穫中にこのようなデータのストレージに、出版物からのデータの除去が取られている任意のコピーを削除しない、ことを認識すべきです。実際には、任意の出版物は、永久的であってもよいです。

However, regulations in many regions will require that the data subjects can at any time request that the data be removed from publication and that their consent for its publication be explicitly confirmed at regular intervals.

しかし、多くの地域で規制が必要になりますそのデータの被験者データは公表から、その出版のための彼らの同意が明示的に定期的に確認することを取り除くことが、いつでも要求ですることができます。

When placing a voice call via the PSTN (or from the Public Land Mobile Network), the sender may be charged for this action. In both kinds of networks, calling some numbers is more expensive than sending to others; both kinds of networks have "premium rate" services that can be charged at a rate considerably more than a "normal" call. As such, it is important that end users be asked to confirm placing the call and that the destination number be presented to them. It is the originating user's choice whether or not to place a call to this destination number, but the originating user SHOULD be shown the destination number so that he or she can make this decision.

PSTN（または公衆陸上モバイルネットワークから）を介して音声通話を配置する場合は、送信者はこのアクションのために充電することができます。ネットワークの両方の種類では、いくつかの数字を呼び出すと、他の人に送信するよりも高価です。ネットワークの両方の種類は、「通常」のコールよりもかなりの速度で充電することができる「保険料率」サービスを持っています。このように、エンドユーザーが電話をかけると、宛先番号がそれらに提示されることを確認するように求められていることが重要です。これは、この先の番号に電話をかけるかどうかを元のユーザーの選択ですが、彼または彼女はこの決定を行うことができるように、発信ユーザは、相手先番号を示すべきである（SHOULD）。

In addition to the specific security considerations given above, all security considerations given in RFC 3761 apply, as well as the DNS-specific threats covered in RFC 3833 [12].

上述した特定のセキュリティ上の考慮事項に加えて、RFC 3761に指定されたすべてのセキュリティ上の考慮事項が適用され、同様にDNS固有の脅威は、RFC 3833 [12]でカバー。

6. IANA Considerations

6. IANAの考慮事項

The IANA has registered the Enumservice "voice" with a single subtype "tel" according to the framework defined in RFC 3761. The current document defines this Enumservice and the expected behaviour of clients.

IANAは、RFC 3761で定義されたフレームワークに従った単一のサブタイプ「TEL」とEnumservice「音声」を登録した現在のドキュメントが、このEnumserviceとクライアントの期待される動作を定義します。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.

[1] Faltstrom、P.及びM. Mealling、 "ユニフォームリソース識別子にE.164（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）"、RFC 3761、2004年4月。

[2] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.

[2] ITU-T、 "国際公共通信番号プラン"、勧告E.164を、1997年5月。

[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987.

[3] Mockapetris、P.、 "ドメイン名 - 概念と施設"、RFC 1034、1987年11月。

[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.

[4] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。

[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.

[5] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。

[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.

[6] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム"、RFC 3402、2002年10月。

[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.

[7] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）"、RFC 3404、2002年10月。

[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.

[8] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パートファイブ：URI.ARPAの割り当て手順"、RFC 3405、2002年10月。

[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.

[9]ブラドナーのは、S.は、RFC 2119、BCP 14、1997年3月 "のRFCsにおける使用のためのレベルを示すために"。

[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.

[10] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。

7.2. Informative References

7.2. 参考文献

[11] ETSI, "Minimum Requirements for Interoperability of ENUM Implementations", ETSI TS 102 172, January 2005.

[11] ETSI、 "ENUM実装の相互運用性のための最小要件"、ETSI TS 102 172 2005年1月。

[12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.

[12]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。

Authors' Addresses

著者のアドレス

Rudolf Brandner Siemens AG Hofmannstr. 51 81359 Munich Germany

ルドルフBrandnerシーメンスAG Hofmannstr。 51 81359ミュンヘンドイツ

Phone: +49-89-722-51003 EMail: rudolf.brandner@siemens.com

電話：+ 49-89-722-51003 Eメール：rudolf.brandner@siemens.com

Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey United Kingdom

ローレンスコンロイシーメンスRokeマナー研究Rokeマナーロムジーイギリス

Phone: +44-1794-833666 EMail: lwc@roke.co.uk

電話：+ 44-1794-833666電子メール：lwc@roke.co.uk

Richard Stastny Oefeg Postbox 147 1103 Vienna Austria

リチャードStastny Oefeg郵便受け147 1103ウィーンオーストリア

Phone: +43-664-420-4100 EMail: Richard.stastny@oefeg.at

電話：+ 43-664-420-4100電子メール：Richard.stastny@oefeg.at

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2006）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。