RFC5067 日本語訳

Network Working Group                                            S. Lind
Request for Comments: 5067                                     AT&T Labs
Category: Informational                                        P. Pfautz
                                                                    AT&T
                                                           November 2007

コメントを求めるワーキンググループS.リンド要求をネットワークでつないでください: 5067年のAT&T研究室カテゴリ: 情報のP.Pfautz AT&T2007年11月

                    Infrastructure ENUM Requirements

インフラストラクチャENUM要件

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document provides requirements for "infrastructure" or "carrier"
   ENUM (E.164 Number Mapping), defined as the use of RFC 3761
   technology to facilitate interconnection of networks for E.164 number
   addressed services, in particular but not restricted to VoIP (Voice
   over IP.)

このドキュメントはE.164番号のためにネットワークのインタコネクトを容易にする3761年のRFC技術の使用がサービスを扱った特定で定義されますが、VoIPに制限されなかった「インフラストラクチャ」か「キャリヤー」ENUM(E.164 Number Mapping)のための要件を提供します。(ボイス・オーバー IP。)

Table of Contents

目次

   1.  Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 1
     1.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . 1
     1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Requirements for Infrastructure ENUM  . . . . . . . . . . . . . 3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5

1. インフラストラクチャENUM. . . . . . . . . . . . . . . . . . . . . . 1 1.1。 定義. . . . . . . . . . . . . . . . . . . . . . . . 1 1.2。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 インフラストラクチャENUM. . . . . . . . . . . . . 3 4のための要件。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 6。 引用規格. . . . . . . . . . . . . . . . . . . . . 5

1.  Infrastructure ENUM

1. インフラストラクチャENUM

1.1.  Definition

1.1. 定義

   Infrastructure ENUM is defined as the use of the technology in RFC
   3761 [1] by the carrier-of-record (as defined below) for a specific
   E.164 number [2] to publish the mapping of the E.164 number into a
   URI [3] that identifies a specific point of interconnection to that
   service provider's network.  It is separate from any URIs that the
   end user, who registers their E.164 number, may wish to associate
   with that E.164 number.

インフラストラクチャENUMはそのサービスプロバイダーのネットワークにインタコネクトの特定のポイントを特定するURI[3]にE.164番号に関するマッピングを発表する特定のE.164番号[2]のための記録のキャリヤー(以下で定義されるように)によるRFC3761[1]の技術の使用と定義されます。 それはエンドユーザ(それらのE.164番号を示す)がそのE.164番号に関連づけたがっているかもしれないどんなURIからも別々です。

Lind & Pfautz                Informational                      [Page 1]

RFC 5067            Infrastructure ENUM Requirements       November 2007

[1ページ]RFC5067インフラストラクチャENUM要件2007年11月の情報のリンドとPfautz

   "Infrastructure ENUM" is distinguished from "End User ENUM", defined
   in RFC3761 [1], in which the entity or person having the right to use
   a number has the sole discretion about the content of the associated
   domain and thus the zone content.  From a domain registration
   perspective, the end user number assignee is thus the registrant.
   Within the infrastructure ENUM namespace, we use the term "carrier-
   of-record" for the entity having discretion over the domain and zone
   content and acting as the registrant.  The "carrier-of-record" is:

「インフラストラクチャENUM」は数を使用する権利を持っている実体か人が関連ドメインとその結果、ゾーン内容の内容に関して唯一の思慮深さを持っているRFC3761[1]で定義された「エンドユーザENUM」と区別されます。 ドメインの取得見解、エンドユーザ数の指定代理人から、その結果記入者は来ています。 インフラストラクチャENUM名前空間の中では、私たちはドメインとゾーン内容の上で分別があって、記入者として機能する実体に「記録のキャリヤー」という用語を使用します。 「記録のキャリヤー」は以下の通りです。

   o The Service Provider to which the E.164 number was allocated for
   end user assignment, whether by the National Regulatory Authority
   (NRA) or the International Telecommunication Union (ITU), for
   instance, a code under "International Networks" (+882) or "Universal
   Personal Telecommunications (UPT)" (+878) or,

o またはE.164番号がNational Regulatory Authority(NRA)か国際電気通信連合にかかわらずエンドユーザ課題のために割り当てられたService Provider(ITU)、例えば、「国際ネットワーク」(+882)か「普遍的な個人的なテレコミュニケーション(UPT)」でのコード(+878)。

   o if the number is ported, the service provider to which the number
   was ported, or

o または数を移植するなら数が移植されたサービスプロバイダー。

   o where numbers are assigned directly to end users, the service
   provider that the end user number assignee has chosen to provide a
   Public Switched Telephone Network/Public Land Mobile Network (PSTN/
   PLMN) point-of-interconnect for the number.

o 数が数のための内部連絡の直接エンドユーザ、エンドユーザ数の指定代理人がPublic Switched Telephone Network/公共のLandモバイルNetworkを提供するために選ばせているサービスプロバイダーに配属された(PSTN/ PLMN)ポイントであるところ。

   It is understood that the definition of carrier-of-record within a
   given jurisdiction is subject to modification by national
   authorities.

与えられた管轄の中の記録のキャリヤーの定義は国内当局で変更を受けることがあるのが理解されています。

1.2.  Background

1.2. バックグラウンド

   Voice service providers use E.164 numbers currently as their main
   naming and routing vehicle.  Infrastructure ENUM in e164.arpa or
   another publicly available tree allows service providers to link
   Internet-based resources such as URIs to E.164 numbers.  This allows
   service providers, in addition to interconnecting via the PSTN/PLMN
   (or exclusively), to peer via IP-based protocols.  Service providers
   may announce all E.164 numbers or number ranges they host, regardless
   of whether the final end user device is on the Internet, on IP-based
   open or closed Next Generation Networks (NGNs), or on the PSTN or
   PLMN, provided that an access point of some type to the destination
   service provider's network is available on the Internet.  There is
   also no guarantee that the originating service provider querying
   infrastructure ENUM is able to access the ingress network element of
   the destination provider's network.  Additional peering and
   accounting agreements requiring authentication may be necessary.  The
   access provided may also be to a shared network of a group of
   providers, resolving the final destination network within the shared
   network.

声のサービスプロバイダーは現在、それらの主な命名とルーティング乗り物としてE.164番号を使用します。 e164.arpaのインフラストラクチャENUMか別の公的に利用可能な木で、サービスプロバイダーはE.164番号へのURIなどのインターネットを利用するリソースをリンクできます。 IPベースのプロトコルでじっと見るためにPSTN/PLMN(排他的である)を通して内部連絡することに加えてこれはサービスプロバイダーを許容します。 サービスプロバイダーはすべてのE.164番号かそれらが接待する数の範囲を発表するかもしれません、インターネットの上、または、IPベースの開いているか閉じているNext Generation Networks(NGNs)の上、または、PSTNかPLMNの上に最終的なエンドユーザデバイスがあることにかかわらず、目的地サービスプロバイダーのネットワークへのタイプのアクセスポイントがインターネットで利用可能であれば。 また、インフラストラクチャENUMについて質問する起因するサービスプロバイダーが目的地プロバイダーのネットワークのイングレスネットワーク原理にアクセスできるという保証が全くありません。 追加じっと見るのと認証を必要とする会計協定が必要であるかもしれません。 また、プロバイダーのグループの共用回線網には提供されたアクセスがあるかもしれません、共用回線網の中で最終的な送信先ネットワークを決議して。

Lind & Pfautz                Informational                      [Page 2]

RFC 5067            Infrastructure ENUM Requirements       November 2007

[2ページ]RFC5067インフラストラクチャENUM要件2007年11月の情報のリンドとPfautz

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, RFC2119 [4].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[4])で説明されるように本書では解釈されることであるべきです。

3.  Requirements for Infrastructure ENUM

3. インフラストラクチャENUMのための要件

   1.  Infrastructure ENUM SHALL provide a means for a provider to
       populate DNS resource records (RRs) for the E.164 numbering
       resources for which it is the carrier-of-record in a single
       common publicly accessible namespace.  The single common
       namespace ultimately designated may or may not be the same as
       that designated for End User ENUM (e164.arpa.)  The Fully-
       Qualified Domain Name (FQDN) in the resulting resource records
       will not necessarily belong to or identify the carrier-of-record.

1. インフラストラクチャENUM SHALLは、ただ一つの一般的な公的にアクセスしやすい名前空間でそれが記録のキャリヤーであるE.164付番リソースのためのDNSリソース記録(RRs)に居住するために手段をプロバイダーに提供します。 エンドユーザENUMのためのそんなに指定されるのと同じくらいが(e164.arpa)であったかもしれないなら結局指定されたただ一つの一般的な名前空間 結果として起こるリソース記録のFullyの適切なDomain Name(FQDN)は必ず記録のキャリヤーをもの、というわけではありませんし、また特定するというわけではないでしょう。

   2.  Queries of infrastructure ENUM fully qualified domain names MUST
       return a result, even if the result is Refused (RCODE = 5).
       Queries must not be rejected without response, e.g., based on
       access control lists.

2. インフラストラクチャENUM完全修飾ドメイン名の質問は結果を返さなければなりません、結果がRefused(RCODE=5)であっても。 例えば、応答アクセスコントロールリストに基づいて質問を拒絶してはいけません。

   3.  Infrastructure ENUM SHALL support RRs providing a URI that can
       identify a point of interconnection for delivery to the carrier-
       of-record of communications addressed to the E.164 number.

3. インフラストラクチャENUM SHALLは、RRs提供が配送のために記録のキャリヤーにインタコネクトのポイントを特定できるE.164番号に扱われたコミュニケーションのURIであるとサポートします。

   4.  Infrastructure ENUM SHOULD be able to support an Internet
       Registry Information Service (IRIS) [5] capability that allows
       qualified parties to obtain information regarding the E.164
       numbering resources and the corresponding carrier-of-record.
       Determination of what information, if any, shall be available
       which parties for geographic numbers is a national matter.

4. インフラストラクチャENUM SHOULD、インターネットRegistry情報Service(IRIS)が適任のパーティーがE.164付番リソースと記録の対応するキャリヤーの情報を得ることができる[5]能力であるとサポートすることができてください。 地理的な数のためにパーティーへ行くもしあればどんな情報が利用可能になるかに関する決断は国家の問題です。

   5.  Implementation of infrastructure ENUM MUST NOT restrict the
       ability of an end user, in a competitive environment, to choose a
       Registrar and/or name server provider for End User ENUM
       registrations.

5. インフラストラクチャENUM MUST NOTの実装は、エンドユーザENUM登録証明書のためのRegistrar、そして/または、ネームサーバプロバイダーを選ぶために競争的な環境における、エンドユーザの能力を制限します。

   6.  The domain name chosen for infrastructure ENUM and any parent
       domains MUST be hosted on name servers that have performance
       characteristics and supporting infrastructure that is comparable
       to those deployed for the Internet root name servers.  Those name
       servers for infrastructure ENUM should be configured and operated
       according to the guidelines described in [6].

6. 性能の特性を持っているネームサーバで接待しなければならなくて、インフラストラクチャがそれであるとサポートするインフラストラクチャENUMとどんな親ドメインにも選ばれたドメイン名はインターネット根のネームサーバのために配布されたものに匹敵しています。 [6]で説明されたガイドラインによると、インフラストラクチャENUMのためのそれらのネームサーバは、構成されて、操作されるべきです。

   7.  Infrastructure ENUM MUST meet all reasonable privacy concerns
       about visibility of information over which an end user has no
       control.  It should, for example, support mechanisms to prevent

7. インフラストラクチャENUM MUSTはエンドユーザがコントロールを全く持っていない情報の目に見えることに関するすべての妥当なプライバシーの問題を満たします。 例えば、それは防ぐメカニズムをサポートするべきです。

Lind & Pfautz                Informational                      [Page 3]

RFC 5067            Infrastructure ENUM Requirements       November 2007

[3ページ]RFC5067インフラストラクチャENUM要件2007年11月の情報のリンドとPfautz

       discovery of unlisted numbers by comparison of ENUM registrations
       against directory listings, or inadvertent disclosure of user
       identity.

ディレクトリリストに対するENUM登録証明書の比較、またはユーザのアイデンティティの不注意な公開による電話帳に載っていない番号の発見。

   8.  Proposed implementations of infrastructure ENUM SHOULD:

8. インフラストラクチャENUM SHOULDの提案された実装:

       A.  Minimize changes required to existing requirements that are
           part of RFC 3761.

A. RFC3761の一部である既存の要件に必要である変化を最小にしてください。

       B.  Work with open as well as closed numbering plans.

開いていて閉じている付番によるB.仕事は計画されています。

       C.  Not require additional functionality of resolvers at large
           though they may require additional functionality in service
           provider resolvers that would make use of infrastructure
           ENUM.

彼らはインフラストラクチャENUMを利用するサービスプロバイダーレゾルバで追加機能性を必要とするかもしれませんが、C.は全体のレゾルバの追加機能性を必要としません。

       D.  Minimize the number of lookups required to obtain as many
           NAPTR (Naming Authority Pointer) records (end user and
           infrastructure) as possible.

D. できるだけ多くのNAPTR(Authority Pointerを命名する)記録(エンドユーザとインフラストラクチャ)を得るのに必要であるルックアップの数を最小にしてください。

       E.  Minimize knowledge of the numbering plan required of
           resolvers making use of Infrastructure ENUM.

E. レゾルバがInfrastructure ENUMを利用するのについて必要である付番プランに関する知識を最小にしてください。

       F.  Maximize synergies with End User ENUM.

F. エンドユーザENUMと共に相乗作用を最大にしてください。

       G.  Support interworking with private ENUM trees.  (In this
           context, a private ENUM tree is one that is not under
           e164.arpa or whatever namespace is chosen for infrastructure
           ENUM but uses instead a privately held domain.)

G. 個人的なENUM木がある織り込むことをサポートしてください。 (個人的なENUM木は、このような関係においては、e164.arpaの下にないものかインフラストラクチャENUMに選ばれていますが、代わりに個人的に保持されたドメインを使用する名前空間です何でも。)

4.  Security Considerations

4. セキュリティ問題

   Existing security considerations for ENUM (detailed in [1]) still
   apply.  Since infrastructure ENUM involves carriers where RFC 3761
   mainly considered indviduals, implementations meeting these
   requirements SHOULD reconsider the RFC 3761 security model given this
   difference in actors concerned.  Note that some registration
   validation issues concerning End User ENUM may not apply to
   infrastructure ENUM.  Where the Tier 1 registry is able to identify
   the provider serving a number, e.g., based on industry data for
   number block assignments and number portability, registration might
   be more easily automated and a separate registrar not required.

ENUMのための既存のセキュリティ問題、([1])でまだ詳しく述べられていて、適用してください。 インフラストラクチャENUMがRFC3761がindvidualsを主に考えたキャリヤーにかかわるので、関する俳優のこの違いを考えて、SHOULDがRFC3761セキュリティを再考するというこれらの必要条件を満たす実装がモデル化されます。 エンドユーザENUMに関するいくつかの登録合法化問題がインフラストラクチャENUMに適用されないかもしれないことに注意してください。 例えば、Tier1登録が数に役立つプロバイダーを特定できるところ数のブロック課題とナンバーポータビリティのための産業データに基づいて、登録は容易に自動化されているかもしれません、そして、別々の記録係は必要ではありません。

   Some parties have expressed concern that an infrastructure ENUM could
   compromise end user privacy by making it possible for others to
   identify unlisted or unpublished numbers based on their registration
   in ENUM.  This can be avoided if providers register all of the their
   allocated (as opposed to assigned) numbers.  Unassigned numbers

いくつかのパーティーがそれを他のものが特定するのにおいて可能にすることによってENUMがエンドユーザプライバシーであると感染することができるだろうインフラストラクチャが非記載したという関心かENUMで彼らの登録に基づく未発表の数を表しました。 プロバイダーがすべてを登録するならこれを避けることができる、それらの割り当てられた(割り当てにされると対照的に)番号。 割り当てられなかった数

Lind & Pfautz                Informational                      [Page 4]

RFC 5067            Infrastructure ENUM Requirements       November 2007

[4ページ]RFC5067インフラストラクチャENUM要件2007年11月の情報のリンドとPfautz

   should be provisioned to route to the provider's network in the same
   fashion as assigned numbers and only then provide an indication that
   they are unassigned.  In that way, provider registration of a number
   in ENUM provides no more information about the status of a number
   than could be obtained by dialing it.

それらが割り当てられないという指示を規定番号と同じファッションによるプロバイダーのネットワークに発送して、次に、提供するだけであるために食糧を供給されるべきです。 そのように、ENUMでの数のプロバイダー登録はそれにダイヤルすることによって得ることができるだろうより数の状態に関する詳しい情報を全く提供しません。

   Implementers should take care to avoid inadvertent disclosure of user
   identities, for example, in the URIs returned in response to
   infrastructure ENUM queries.

Implementersは、例えば、インフラストラクチャENUM質問に対応して返されたURIでユーザアイデンティティの不注意な公開を避けるために注意するはずです。

5.  IANA Considerations

5. IANA問題

   This document includes no actions to be taken by IANA.  The
   architecture ultimately chosen to meet the requirements may require
   IANA actions.

IANAによって取られるように、このドキュメントは動作を全く含んでいません。 結局条件を満たすために選ばれたアーキテクチャはIANA動作を必要とするかもしれません。

6.  Normative References

6. 引用規格

   [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.食事、「Uniform Resource Identifier(URI)ダイナミックな委譲発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。

   [2]  International Telecommunication Union-Telecommunication
        Standardization Sector, "The International Public
        Telecommunication Numbering Plan", Recommendation E.164",
        February 2005.

2005年2月の「[2]国際電気通信連合-電気通信標準化セクター、「国際公共の電気通信付番プラン」、推薦E.164」

   [3]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
        January 2005.

[3]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。

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

[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [5]  Newton, A. and M. Sanz, "IRIS: The Internet Registry Information
        Service (IRIS) Core Protocol", RFC 3981, January 2005.

[5] ニュートン、A.、およびM.サンス、「虹彩:」 「インターネット登録情報サービス(虹彩)コアプロトコル」、RFC3981、2005年1月。

   [6]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name
        Server Operational Requirements", BCP 40, RFC 2870, June 2000.

[6] ブッシュとR.とKarrenbergとD.とKosters、M.とR.Plzak、「根のネームサーバの操作上の要件」、BCP40、RFC2870、2000年6月。

Lind & Pfautz                Informational                      [Page 5]

RFC 5067            Infrastructure ENUM Requirements       November 2007

[5ページ]RFC5067インフラストラクチャENUM要件2007年11月の情報のリンドとPfautz

Authors' Addresses

作者のアドレス

   Steven Lind
   AT&T Labs
   180 Park Ave
   Florham Park, NJ  07932-0971
   USA

スティーブンリンドAT&T研究室180公園Ave Florham公園、ニュージャージー07932-0971米国

   EMail: sdlind@att.com

メール: sdlind@att.com

   Penn Pfautz
   AT&T
   200 S. Laurel Ave
   Middletown, NJ  07748
   USA

ペンPfautz AT&T200秒間ローレルAve Middletown、ニュージャージー07748米国

   EMail: ppfautz@att.com

メール: ppfautz@att.com

Lind & Pfautz                Informational                      [Page 6]

RFC 5067            Infrastructure ENUM Requirements       November 2007

[6ページ]RFC5067インフラストラクチャENUM要件2007年11月の情報のリンドとPfautz

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   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, THE IETF TRUST 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.

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

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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に情報を扱ってください。

Lind & Pfautz                Informational                      [Page 7]

リンドとPfautz情報です。[7ページ]