RFC4415 日本語訳
4415 IANA Registration for Enumservice Voice. R. Brandner, L. Conroy,R. Stastny. February 2006. (Format: TXT=15956 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Brandnerがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4415年のジーメンス株式会社カテゴリ: 標準化過程L.コンロイジーメンスRoke荘園研究R.Stastny Oefeg2006年2月
IANA Registration for Enumservice Voice
Enumservice声のためのIANA登録
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはENUM仕様に基づき定義されたIANA登録手続に従ってEnumservice「声」(定義された「副-タイプ」"tel"を持っている)RFC3761を登録します。 このサービスは、対話的な声(オーディオ)の呼び出しを開始するのに発生しているUniform Resource Identifier(URI)で保持された接触は使用できるのを示します。
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 サービス登録. . . . . . . . . . . . . . . . . . 3 4を声に出してください。 声に関する例: tel Enumservice. . . . . . . . . . . . . . . 4 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1。 引用規格. . . . . . . . . . . . . . . . . . 6 7.2。 有益な参照. . . . . . . . . . . . . . . . . 6
Brandner, et al. Standards Track [Page 1] RFC 4415 IANA Voice Enumservice Registration February 2006
Brandner、他 規格はIANA声のEnumservice登録2006年2月にRFC4415を追跡します[1ページ]。
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.
E.164 Number Mapping、RFC3761[1])はE.164番号[2]をドメイン名に変えて、次にDNSを使用するシステムです。ENUM、((RFC1034[3])は、特定のドメイン名に利用可能な通信サービスを見上げるためにNS記録を通した代表団や、Naming Authority Pointer(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.
NAPTR[4]リソース記録のサービス分野の食糧を供給するのに使用されるためにRFC3761で与えられたガイドラインによると、このドキュメントは、与えられた終点がどんなクラスの機能性を提供するかを示すためにEnumserviceを登録します。 登録はDynamic DelegationディスカバリーSystemの中で定義されます。(DDDS、「E2U」というDDDSアプリケーションがRFC3761で定義されている使用のための[5][6][4][7][8])階層構造。
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.
多くのDDDS利用がENUMに加えています。(例えば、[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 TS102 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.
このドキュメントはENUM仕様に基づき定義されたIANA登録手続に従ってEnumservice「声」(定義された「副-タイプ」"tel"を持っている)RFC3761を登録します。 このサービスは、対話的な声(オーディオ)の呼び出しを開始するのに発生しているURIで保持された接触は使用できるのを示します。
Brandner, et al. Standards Track [Page 2] RFC 4415 IANA Voice Enumservice Registration February 2006
Brandner、他 規格はIANA声のEnumservice登録2006年2月にRFC4415を追跡します[2ページ]。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[9])で説明されるように本書では解釈されることであるべきです。
3. Voice Service Registration
3. ボイスサービス登録
Enumservice Name: "voice"
Enumserviceは以下を命名します。 「声」
Enumservice Type: "voice"
Enumserviceはタイプします: 「声」
Enumservice Subtype: "tel"
Enumservice Subtype: "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.
クライアントは、このNAPTRによって発生したURIを使用することで連絡されるとこのEnumserviceを持ちながらNAPTRの人口を制御している人が対話的な声のセッションに従事する彼の能力を示すと暗示するかもしれません。
Security Considerations:
セキュリティ問題:
See Section 5.
セクション5を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Rudolf Brandner, Lawrence Conroy, and Richard Stastny (for author
contact detail, see Authors' Addresses section)
ラドルフBrandner、ローレンス・コンロイ、およびリチャードStastny(作者詳細な連絡先に関して、AuthorsのAddresses部を見てください)
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に責任がある人がPublic Switched Telephone Network(PSTN)かPublic LandのモバイルNetwork(PLMN)を通して発生しているURIの値を使用するのにおいてアクセスしやすいのを示します。
The kind of subsystem required to initiate a Voice Enumservice
with this subtype is a "Dialer". This is a subsystem that either
この「副-タイプ」でVoice Enumserviceを開始するのに必要であるサブシステムの種類は「ダイヤラー」です。 これはサブシステムそんなにのどちらかです。
Brandner, et al. Standards Track [Page 3] RFC 4415 IANA Voice Enumservice Registration February 2006
Brandner、他 規格はIANA声のEnumservice登録2006年2月にRFC4415を追跡します[3ページ]。
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.
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にするCommunications Service Providerとの関係を持っているかもしれません。 この場合、プロバイダーは、「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価値のSHOULD、(RFC3966[10])の「グローバルな電話番号」フォームを使用します。 NAPTRが現れるゾーンのコントローラが彼らのネットワークアクセスポイントと明白にリソース記録にアクセスできるすべてのクライアントとそのa呼び出しでそれを区別できるのを確信していない場合使用されていた状態でドキュメントSHOULD NOTがあるコネを定義するとき、「ローカルの電話番号」をその目的地に発送できます。
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!" .
$起源0.6.9.2.3.6.1.4.4.e164.arpa。 「3.8.0 NAPTR10 100「」 「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.
ENUMによって使用されるDNSがaグローバルである、分散データベース。 したがって、だれにとっても、そこに格納されたどんな情報も匿名で目に見えます。 これが電話帳での公表と質的に異なっていない間、それはこれが完了していたという少しも指示なしで「their」の情報を自動的に集めさせるか、またはだれが開けるかにデータ主体を開けます。
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を廃棄する」試みに使用されるかもしれません。
Brandner, et al. Standards Track [Page 4] RFC 4415 IANA Voice Enumservice Registration February 2006
Brandner、他 規格はIANA声のEnumservice登録2006年2月にRFC4415を追跡します[4ページ]。
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.
それらに送られた非要求されたメールを無視するのを助けるためにそのようなものにリストを掲示するとき、多くのメーリングリストユーザが、1つ以上のEメールアドレスを持って、「犠牲的な」メールアカウントを使用します。 これは発行された電話番号でそれほど簡単ではありません。 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(またはPublic LandのモバイルNetworkから)を通して音声通話を置くとき、送付者はこの動作のために請求されるかもしれません。 両方の種類のネットワークでは、数個の数に電話をするのは他のものに発信するより高価です。 両方の種類のネットワークには、「正常な」呼び出しよりかなり多くのレートに突進できる「保険料率」サービスがあります。 そういうものとして、エンドユーザが、電話をして、目的地番号が彼らに提示されると確認するように頼まれるのは重要です。 この目的地番号、しかし、由来しているユーザ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].
上に与えられた特定のセキュリティ問題に加えて、RFC3761で与えられたすべてのセキュリティ問題が適用されます、RFC3833[12]でカバーされたDNS特有の脅威と同様に。
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.
RFC3761で定義された枠組みに従って、IANAは単一の「副-タイプ」"tel"にEnumservice「声」を登録しました。 現在のドキュメントはクライアントのこのEnumserviceと予想されたふるまいを定義します。
Brandner, et al. Standards Track [Page 5] RFC 4415 IANA Voice Enumservice Registration February 2006
Brandner、他 規格はIANA声のEnumservice登録2006年2月にRFC4415を追跡します[5ページ]。
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.食事、「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。
[2] ITU-T, "The International Public Telecommunication Number
Plan", Recommendation E.164, May 1997.
[2] ITU-T(「国際公共の電気通信数のプラン」、推薦E.164)は1997がそうするかもしれません。
[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[3]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC1034、11月1987日
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[4] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[5] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC 3402, October 2002.
[6] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404,
October 2002.
[7] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)」、RFC3404、2002年10月。
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[8] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は5を分けます」。 「URI.ARPA課題手順」、RFC3405、2002年10月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[9] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[10]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
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 t102 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、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
Brandner, et al. Standards Track [Page 6] RFC 4415 IANA Voice Enumservice Registration February 2006
Brandner、他 規格はIANA声のEnumservice登録2006年2月にRFC4415を追跡します[6ページ]。
Authors' Addresses
作者のアドレス
Rudolf Brandner Siemens AG Hofmannstr. 51 81359 Munich Germany
ラドルフBrandnerジーメンス株式会社Hofmannstr。 51 81359ミュンヘンドイツ
Phone: +49-89-722-51003 EMail: rudolf.brandner@siemens.com
以下に電話をしてください。 +49-89-722-51003 メールしてください: rudolf.brandner@siemens.com
Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey United Kingdom
ローレンス・コンロイ・Siemens Roke Manor研究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 Postbox147 1103ウィーンオーストリア
Phone: +43-664-420-4100 EMail: Richard.stastny@oefeg.at
以下に電話をしてください。 +43-664-420-4100 メールしてください: Richard.stastny@oefeg.at
Brandner, et al. Standards Track [Page 7] RFC 4415 IANA Voice Enumservice Registration February 2006
Brandner、他 規格はIANA声のEnumservice登録2006年2月にRFC4415を追跡します[7ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは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 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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Brandner, et al. Standards Track [Page 8]
Brandner、他 標準化過程[8ページ]
一覧
スポンサーリンク
