RFC3953 日本語訳

Network Working Group                                        J. Peterson
Request for Comments: 3953                                       NeuStar
Category: Standards Track                                   January 2005

コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 3953年のNeuStarカテゴリ: 標準化過程2005年1月

                Telephone Number Mapping (ENUM) Service
                  Registration for Presence Services

存在サービスのための電話番号マッピング(ENUM)サービス登録

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document registers a Telephone Number Mapping (ENUM) service for
   presence.  Specifically, this document focuses on provisioning pres
   URIs in ENUM.

このドキュメントは存在のためにTelephone Number Mapping(ENUM)サービスを登録します。 明確に、このドキュメントは、ENUMでpres URIに食糧を供給するのは焦点を合わせます。

Table of Contents

目次

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. ENUM Service Registration  . . . . . . . . . . . . . . . . . . . 2
   3. Presence for E.164 Numbers . . . . . . . . . . . . . . . . . . . 2
   4. The 'E2U+pres' Enumservice . . . . . . . . . . . . . . . . . . . 3
   5. Example of E2U+pres Enumservice  . . . . . . . . . . . . . . . . 4
   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 4
   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 5
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 5
      8.2.  Informative References . . . . . . . . . . . . . . . . . . 5
   Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . . 7

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 ENUMは登録. . . . . . . . . . . . . . . . . . . 2 3を修理します。 E.164No.. . . . . . . . . . . . . . . . . . . 2 4のための存在。 'E2U+pres'Enumservice. . . . . . . . . . . . . . . . . . . 3 5。 E2U+pres Enumservice. . . . . . . . . . . . . . . . 4 6に関する例。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 5 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 5作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . . 7

Peterson                    Standards Track                     [Page 1]

RFC 3953        ENUM Registration for Presence Services     January 2005

ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[1ページ]。

1. Introduction

1. 序論

   ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS
   (Domain Name Service, RFC 1034 [8]) to translate telephone numbers,
   such as +12025332600, into URIs (Uniform Resource Identifiers, RFC
   2396 [9]), such as pres:user@host.com.  ENUM exists primarily to
   facilitate the interconnection of systems that rely on telephone
   numbers with those that use URIs to identify resources.

電話番号を翻訳してください、+12025332600などのように、URIに。ENUM、(E.164 Number Mapping、RFC3761[1])がDNSを使用するシステムである、(ドメインName Service、RFC1034[8])、(Uniform Resource Identifier、RFC2396[9])(pres: user@host.com としてのそのようなもの)。 ENUMは、主としてリソースを特定するのにURIを使用するもので電話番号を当てにするシステムのインタコネクトを容易にするために存在しています。

   Presence is a service defined in RFC 2778 [2] that allows users of a
   communications service to monitor one another's availability and
   disposition in order to make decisions about communicating.  Presence
   information is highly dynamic and generally characterizes whether a
   user is online or offline, busy or idle, away from communications
   devices or nearby, and the like.

存在は情報提供サービスのユーザが交信に関する決定をするようにお互いの有用性と気質をモニターできるRFC2778[2]で定義されたサービスです。 存在情報は、非常にダイナミックであり、一般に、ユーザがオンライン、オフライン、忙しいか、活動していないか、コミュニケーション装置から遠くにいるまたは近いか、そして、同様のものを特徴付けます。

   The IETF has defined a generic URI used to identify a presence
   service for a particular resource: the 'pres' URI scheme (defined in
   CPP [4]).  This document describes an enumservice for advertising
   presence information associated with an E.164 number.

IETFは特定のリソースのための存在サービスを特定するのに使用される一般的なURIを定義しました: 'pres'URIは計画します。(CPP[4])では、定義されます。 このドキュメントはE.164番号に関連している広告存在情報のためにenumserviceについて説明します。

2.  ENUM Service Registration

2. ENUMサービス登録

   As defined in [1], the following is a template covering information
   needed for the registration of the enumservice specified in this
   document:

[1]で定義されるように、↓これは本書では指定されたenumserviceの登録に必要である情報をカバーするテンプレートです:

      Service name: "E2U+pres"

サービス名: 「E2U+pres」

      URI scheme(s): "pres:"

URI計画: 「pres:」

      Functional Specification: See section 4.

機能的な仕様: セクション4を見てください。

      Security considerations: See section 6.

セキュリティ問題: セクション6を見てください。

      Intended usage: COMMON

意図している用法: 一般的

      Author: Jon Peterson (jon.peterson@neustar.biz)

以下を書いてください。 ジョン・ピーターソン( jon.peterson@neustar.biz )

      Any other information that the author deems interesting: See
      section 3.

作者がおもしろいと考えるいかなる他の情報も: セクション3を見てください。

3.  Presence for E.164 Numbers

3. E.164番号のための存在

   This document specifies an enumservice field that allows presence
   information to be provided for an E.164 number.  This may include
   presence states associated with telephones, or presence of non-
   telephony communications services advertised by ENUM.

このドキュメントは存在情報がE.164番号に提供されるのを許容するenumservice分野を指定します。 これが電話に関連している存在州を含むかもしれませんか、または非電話の情報提供サービスの存在はENUMで広告を出しました。

Peterson                    Standards Track                     [Page 2]

RFC 3953        ENUM Registration for Presence Services     January 2005

ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[2ページ]。

   Endpoints that participate in a presence architecture are known
   (following the framework in RFC 2778 [2]) as watchers and
   presentities.  Watchers subscribe to the presence of presentities and
   are notified when the presence of a presentity changes.  Watchers
   generally monitor the presence of a group of presentities with whom
   they have an ongoing association.  As an example, consider how this
   might apply to a telephony service.  Most cellular telephones today
   have an address book-like feature, a small database of names and
   telephone numbers.  Such a telephone might act as a watcher,
   subscribing to the presence of some or all of the telephone numbers
   in its address book.  The display of the telephone might then show
   its user, when a presence-enabled telephone number is selected, the
   availability of the destination.  With this information, the user
   might change their calling habits to correspond better to the
   availability of his or her associates.

存在構造に参加する終点が知られています。(ウォッチャーとpresentitiesとしてRFC2778[2])で枠組みに従います。 ウォッチャーは、presentitiesの存在に加入して、presentityの存在が変化するとき、通知されます。 一般に、ウォッチャーは彼らが進行中の協会を持っているpresentitiesのグループの存在をモニターします。 例として、これがどのように電話サービスに適用されるかもしれないか考えてください。 ほとんどの携帯電話には、今日、アドレス帳のような特徴、名前と電話番号の小さいデータベースがあります。 そのような電話はウォッチャーとして務めるかもしれません、アドレス帳での電話番号のいくつかかすべての存在に加入して。 次に、電話の表示はユーザを見せているかもしれません、存在によって可能にされた電話番号が選択されるとき、目的地の有用性。 この情報で、ユーザは、より一層その人の仲間の有用性に相当するように彼らの呼ぶ習慣を変えるかもしれません。

   The presence information that is shared varies by communications
   service.  The IETF has defined a Presence Information Data Format (or
   PIDF [6]) for describing the presence data associated with a
   presentity.  The baseline PIDF specification declares only two
   presence states: OPEN and CLOSED (these terms are defined in RFC 2778
   [2]); the former suggests that the destination resource is able to
   accept communication requests, the latter that it is not.  These two
   states provide useful but rudimentary insight into the communications
   status of a presentity.  For that reason, PIDF is an extensible
   format, and new sorts of statuses can be defined for specific
   communications services.  For example, a telephony-based presence
   service might define a status corresponding to 'busy'.  Extending
   PIDF for telephony services is, however, outside the scope of this
   document.

共有される存在情報は情報提供サービスで異なります。 IETFはPresence情報Data Formatを定義しました。(または、presentityに関連している存在データについて説明するためのPIDF[6])。 基線PIDF仕様は2つの存在州だけを宣言します: オープンとCLOSED、(これらの用語はRFC2778[2])で定義されます。 それは後者ですが、前者は、目的地リソースがコミュニケーション要求を受け入れることができると示唆します。 これらの2つの州がpresentityのコミュニケーション状態に関する役に立ちますが、初歩的な洞察を提供します。 その理由で、PIDFは広げることができる形式です、そして、特定の情報提供サービスのために新しい種類の状態は定義できます。 例えば、電話ベースの存在サービスは'忙しくする'ために対応する状態を定義するかもしれません。 しかしながら、このドキュメントの範囲の外に電話サービスのためにPIDFを広げるのがあります。

4.  The 'E2U+pres' Enumservice

4. 'E2U+pres'Enumservice

   Traditionally, the services field of an NAPTR record (as defined in
   [10]) contains a string composed of two subfields: a 'protocol'
   subfield and a 'resolution service' subfield.  ENUM in particular
   defines an 'E2U' (E.164 to URI) resolution service.  This document
   defines an 'E2U+pres' enumservice for presence.

伝統的に、NAPTRのサービス分野は記録します。(中で定義されるように、[10])は2つの部分体で構成されたストリングを含んでいます: 'プロトコル'部分体と'解決サービス'部分体。 ENUMは'E2U'(URIへのE.164)解決サービスを特に定義します。 このドキュメントは存在のために'E2U+pres'enumserviceを定義します。

   The scheme of the URI that will appear in the regexp field of an
   NAPTR record using the 'E2U+pres' enumservice SHOULD be the 'pres'
   URI scheme.  Other URI schemes appropriate to presence services MAY
   be used; however, the use of the 'pres' URI scheme ensures a greater
   level of compatibility than would the use of any URI specific to a
   particular presence protocol.  The purpose of a pres URI is to
   provide a generic way to locate a presence service.  Techniques for
   dereferencing the pres URI to locate a presence service are given in
   [5].

NAPTR記録のregexp分野に'pres'がURI計画であったなら'E2U+pres'enumservice SHOULDを使用することで現れるURIの計画。 存在サービスに適切な他のURI計画は使用されるかもしれません。 しかしながら、'pres'URI計画の使用は特定の存在プロトコルに特定のどんなURIの使用もそうするだろうより大きいレベルの互換性を確実にします。 pres URIの目的は存在サービスの場所を見つける一般的な方法を提供することです。 [5]で存在サービスの場所を見つけるようにpres URIに「反-参照をつけ」るためのテクニックを与えます。

Peterson                    Standards Track                     [Page 3]

RFC 3953        ENUM Registration for Presence Services     January 2005

ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[3ページ]。

   The 'pres' URI scheme does not identify any particular protocol that
   will be used to handle presence operations (such as subscriptions and
   notifications).  Rather, the mechanism in [5] details a way to
   discover whether the presence protocol(s) supported by the watcher
   is/are also supported by the presentity.  SIP [7] is one protocol
   that can be used to convey presence information and manage
   subscriptions/notifications.

'pres'URI計画は存在操作(購読や通知などの)を扱うのに使用されるどんな特定のプロトコルも特定しません。 むしろ、[5]のメカニズムはまた、ウォッチャーによってサポートされた存在プロトコルが/であるかどうかがpresentityが支持されると発見する方法を詳しく述べます。 SIP[7]は存在情報を伝えて、購読/通知を管理するのに使用できる1つのプロトコルです。

5.  Example of E2U+pres enumservice

5. E2U+pres enumserviceに関する例

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

↓これはNAPTRリソース記録にこのドキュメントによって登録されたenumserviceの使用に関する例です。

$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
   IN NAPTR 100 10 "u" "E2U+pres" "!^.*$!pres:jon.peterson@example.net!"

$起源3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa。 「$!pres: NAPTR100 10「u」「E2U+pres!」」 ^* jon.peterson@example.net! 」

6.  Security Considerations

6. セキュリティ問題

   DNS does not make policy decisions about the records it shares with
   an inquirer.  All DNS records must be assumed to be available to all
   inquirers at all times.  The information provided within an ENUM
   record set must therefore be considered open to the public -- which
   is a cause for some privacy considerations.

DNSはそれが尋問者と共有する記録に関する政策決定をしません。 すべての尋問者にとっていつも利用可能であるとすべてのDNS記録を思わなければなりません。 したがって、公開されているとセットを考えなければならないというENUM記録の中で提供された情報--いくつかのプライバシー問題の原因である。

   Revealing a pres URI in and of itself is unlikely to introduce many
   privacy concerns, although, depending on the structure of the URI, it
   might reveal the full name or employer of the target.  The use of
   anonymous URIs mitigates this risk.  More serious privacy concerns
   are associated with the unauthorized distribution of presence
   information.  For this reason, presence protocols have a number of
   security requirements (detailed in RFC 2779 [3]) that call for
   authentication of watchers, integrity and confidentiality properties,
   and similar measures to prevent abuse of presence information.  Any
   presence protocol used in conjunction with the 'pres' URI scheme is
   required to meet these requirements.

そういうもののpres URIを明らかにする場合、多くのプライバシーの問題は紹介されそうにはありません、URIの構造によって、目標のフルネームか雇い主を明らかにするかもしれませんが。 匿名のURIの使用はこの危険を緩和します。 より重大なプライバシーの問題は存在情報の権限のない分配に関連しています。 存在プロトコルには、この理由で、多くのセキュリティ要件があります。(ウォッチャー、保全、秘密性の特性、および存在情報の乱用を防ぐ同様の測定の認証を求めるRFC2779[3])では、詳細です。 'pres'URI計画に関連して使用される存在プロトコルが、これらの必要条件を満たすのに必要です。

   Unlike a traditional telephone number, the resource identified by a
   pres URI may require that callers provide cryptographic credentials
   for authentication and authorization before presence information is
   returned.  In concert with presence protocols, ENUM can actually
   provide far greater protection from unwanted callers than does the
   existing PSTN, despite the public availability of ENUM records.

伝統的な電話番号と異なって、pres URIによって特定されたリソースは、存在情報を返す前に訪問者が暗号の信任状を認証と認可に提供するのを必要とするかもしれません。 存在プロトコルと協力して、ENUMは実際に求められていない訪問者からの既存のPSTNをするよりはるかに大きい保護を提供できます、ENUM記録の公共の有用性にもかかわらず。

Peterson                    Standards Track                     [Page 4]

RFC 3953        ENUM Registration for Presence Services     January 2005

ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[4ページ]。

7.  IANA Considerations

7. IANA問題

   This document registers the 'E2U+pres' enumservice under the
   enumservice registry described in the IANA considerations in RFC
   3761.  Details of the registration are given in section 2.

このドキュメントはRFC3761のIANA問題で説明されたenumservice登録の下の'E2U+pres'enumserviceを登録します。 登録の詳細はセクション2で明らかにされます。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

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

[1]FaltstromとP.とM.食事、「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーションへのE.164」、RFC3761、2004年4月。

   [2]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
        Instant Messaging", RFC 2778, February 2000.

2000年2月の[2] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。

   [3]  Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
        Messaging / Presence Protocol Requirements", RFC 2779, February
        2000.

[3] 日、M.とAggarwalとS.とモーア、G.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、2000年2月。

   [4]  Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
        August 2004.

[4] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2004年8月。

   [5]  Peterson, J., "Address Resolution for Instant Messaging and
        Presence", RFC 3861, August 2004.

[5] ピーターソン、J.、「インスタントメッセージングと存在のためのアドレス解決」、RFC3861、2004年8月。

8.2.  Informative References

8.2. 有益な参照

   [6]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
        J. Peterson, "Presence Information Data Format (PIDF)", RFC
        3863, August 2004.

[6] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。

   [7]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

[7] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [8]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
        13, RFC 1034, November 1987.

[8]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [9]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
        1998.

[9]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。

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

[10] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。

Peterson                    Standards Track                     [Page 5]

RFC 3953        ENUM Registration for Presence Services     January 2005

ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[5ページ]。

Author's Address

作者のアドレス

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St.
   Suite 570
   Concord, CA  94520
   USA

ジョンピーターソンNeuStar Inc.1800サター聖Suite570コンコード、カリフォルニア94520米国

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz/

以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/

Peterson                    Standards Track                     [Page 6]

RFC 3953        ENUM Registration for Presence Services     January 2005

ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[6ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Peterson                    Standards Track                     [Page 7]

ピーターソン標準化過程[7ページ]