RFC4570 日本語訳

Network Working Group                                           B. Quinn
Request for Comments: 4570                                 BoxnArrow.com
Category: Standards Track                                   R. Finlayson
                                                     Live Networks, Inc.
                                                               July 2006

コメントを求めるワーキンググループB.クイン要求をネットワークでつないでください: 4570年のBoxnArrow.comカテゴリ: 規格はInc.2006年7月にR.のフィンリースンのライブネットワークを追跡します。

           Session Description Protocol (SDP) Source Filters

セッション記述プロトコル(SDP)ソースフィルタ

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 describes how to adapt the Session Description Protocol
   (SDP) to express one or more source addresses as a source filter for
   one or more destination "connection" addresses.  It defines the
   syntax and semantics for an SDP "source-filter" attribute that may
   reference either IPv4 or IPv6 address(es) as either an inclusive or
   exclusive source list for either multicast or unicast destinations.
   In particular, an inclusive source-filter can be used to specify a
   Source-Specific Multicast (SSM) session.

このドキュメントは1つ以上の目的地「接続」アドレスのためのソースフィルタとして1つ以上のソースアドレスを表すために、Session記述プロトコル(SDP)を適合させる方法を説明します。 それはどちらかのマルチキャストのための包括的であるか排他的なソース・リストかユニキャストの目的地のどちらかとしての参照のIPv4かIPv6アドレス(es)のどちらかがそうするかもしれないSDP「ソースフィルタ」属性のために構文と意味論を定義します。 特に、Source特有のMulticast(SSM)セッションを指定するのに包括的なソースフィルタを使用できます。

1.  Introduction

1. 序論

   The Session Description Protocol [SDP] provides a general purpose
   format for describing multimedia sessions in announcements or
   invitations.  SDP uses an entirely textual data format (the US-ASCII
   subset of [UTF-8]) to maximize portability among transports.  SDP
   does not define a protocol, but only the syntax to describe a
   multimedia session with sufficient information to discover and
   participate in that session.  Session descriptions may be sent using
   any number of existing application protocols for transport (e.g.,
   Session Announcement Protocol (SAP), SIP, Real Time Streaming
   Protocol (RTSP), email, and HTTP).

Session記述プロトコル[SDP]は発表か招待状におけるマルチメディアセッションについて説明するための汎用の形式を提供します。 SDPは、輸送の中で移植性を最大にするのに、完全に原文のデータの形式([UTF-8]の米国-ASCII部分集合)を使用します。 SDPは、そのセッションのときに発見して、参加する十分な情報とのマルチメディアセッションについて説明するためにプロトコルではなく、構文だけを定義します。 セッション記述に輸送(例えば、Session Announcementプロトコル(SAP)、SIP、レアルTime Streamingプロトコル(RTSP)、メール、およびHTTP)にいろいろな既存のアプリケーション・プロトコルを使用させるかもしれません。

   Typically, session descriptions reference an IP multicast address for
   the "connection-address" (destination), though unicast addresses or
   fully qualified domain names (FQDNs) MAY also be used.  The "source-

また、通常、ユニキャストアドレスか完全修飾ドメイン名(FQDNs)ですが、IPマルチキャストが「接続アドレス」(目的地)に扱うセッション記述参照は使用されるかもしれません。 「ソース」

Quinn, et al.               Standards Track                     [Page 1]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[1ページ]

   filter" attribute defined in this document qualifies the session
   traffic by identifying the address (or FQDN) of legitimate sources
   (senders).  The intent is for receivers to use the source and
   destination address pair(s) to filter traffic, so that applications
   receive only legitimate session traffic.

正統のソース(送付者)のアドレス(または、FQDN)を特定することによって、本書では定義された「フィルタ」属性はセッショントラフィックに資格を与えます。 意図は受信機がトラフィックをフィルターにかけるのにソースと目的地アドレス組を使用することです、アプリケーションが正統のセッショントラフィックだけを受けるように。

   Receiver applications are expected to use the SDP source-filter
   information to identify traffic from legitimate senders, and discard
   traffic from illegitimate senders.  Applications and hosts may also
   share the source-filter information with network elements (e.g., with
   routers using [IGMPv3]) so they can potentially perform the traffic
   filtering operation further "upstream," closer to the source(s).

正統の送付者からトラフィックを特定して、違法な送付者からトラフィックを捨てるために受信側アプリケーションがSDPソースフィルタ情報を使用すると予想されます。 また、アプリケーションとホストは、さらにソースの「上流へ」と、近くで潜在的にトラフィック濾過手術を実行できるようにネットワーク要素(例えば、ルータが[IGMPv3]を使用している)とソースフィルタ情報を共有するかもしれません。

   The "source-filter" attribute can appear at the session level and/or
   the media level.

「ソースフィルタ」属性はセッションレベル、そして/または、メディアレベルに現れることができます。

1.1.  Motivation

1.1. 動機

   The purpose of a source-filter is to help protect receivers from
   traffic sent from illegitimate source addresses.  Filtering traffic
   can help to preserve content integrity and protect against Denial of
   Service (DoS) attacks.

ソースフィルタの目的は違法なソースアドレスから送られたトラフィックから受信機を保護するのを助けることです。 トラフィックをフィルターにかけるのは、満足している保全を保持して、サービス妨害(DoS)攻撃から守るのを助けることができます。

   For multicast destination addresses, receiver applications MAY apply
   source-filters using the Multicast Source Filter APIs [MSF-API].
   Hosts are likely to implement these APIs using protocol mechanisms to
   convey the source filters to local multicast routers.  Other
   "upstream" multicast routers MAY apply the filters and thereby
   provide more explicit multicast group management and efficient
   utilization of network resources.  The protocol mechanisms to enable
   these operations are beyond the scope of this document, but their
   potential provided motivation for SDP source-filters.

マルチキャスト送付先アドレスのために、Multicast Source Filter API[MSF-API]を使用して、受信側アプリケーションはソースフィルタを当てはまるかもしれません。 ホストは、地方のマルチキャストルータまでソースフィルタを運ぶのにプロトコルメカニズムを使用することでこれらのAPIを実装しそうです。 他の「上流」のマルチキャストルータは、フィルタを適用して、その結果、ネットワーク資源の、より明白なマルチキャスト集団経営と効率的な利用を提供するかもしれません。 これらの操作を可能にするプロトコルメカニズムはしかし、このドキュメント、SDPソースフィルタに関する彼らの潜在的提供された動機の範囲を超えています。

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 RFC 2119 [REQMNT].

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

3.  The "source-filter" Attribute

3. 「ソースフィルタ」属性

   The SDP source-filter attribute does not change any existing SDP
   syntax or semantics, but defines a format for additional session
   description information.  Specifically, source-filter syntax can
   prescribe one or more unicast addresses as either legitimate or
   illegitimate sources for any (or all) SDP session description
   "connection-address" field values.

SDPソースフィルタ属性は、少しの既存のSDP構文や意味論も変えませんが、追加セッション記述情報のために書式を定義します。 明確に、ソースフィルタ構文はどんな(すべて)SDPセッション記述「接続アドレス」分野値のための正統の、または、違法なソースも1つ以上のユニキャストアドレスに定めることができます。

Quinn, et al.               Standards Track                     [Page 2]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[2ページ]

   Note that the unicast source addresses specified by this attribute
   are those that are seen by a receiver.  Therefore, if source
   addresses undergo translation en route from the original sender to
   the receiver - e.g., due to Network Address Translation (NAT) or some
   tunneling mechanism - then the SDP "source-filter" attribute, as
   presented to the receiver, will not be accurate unless the source
   addresses therein are also translated accordingly.

この属性によって指定されたユニキャストソースアドレスが受信機によって見られるものであることに注意してください。したがって、ソースアドレスが元の送り主から例えば、Network Address Translation(NAT)か何らかのトンネリングメカニズムによる受信機への途中で、翻訳を受けて、また、そこにソースアドレスがそれに従って、翻訳されない場合、受信機に提示されるSDP「ソースフィルタ」属性は正確にならないでしょう。

   The source-filter attribute has the following syntax:

ソースフィルタ属性に、以下の構文があります:

       a=source-filter: <filter-mode> <filter-spec>

=ソースフィルタ: <フィルタモード><フィルタ仕様>。

   The <filter-mode> is either "incl" or "excl" (for inclusion or
   exclusion, respectively).  The <filter-spec> has four sub-components:

<フィルタモード>は"incl"か"excl"(包含か除外のためにそれぞれ)のどちらかです。 <フィルタ仕様>には、4つのサブコンポーネントがあります:

       <nettype> <address-types> <dest-address> <src-list>

<nettype><は><dest-アドレス><src-リスト>をアドレスでタイプします。

   A <filter-mode> of "incl" means that an incoming packet is accepted
   only if its source address is in the set specified by <src-list>.  A
   <filter-mode> of "excl" means that an incoming packet is rejected if
   its source address is in the set specified by <src-list>.

"incl"のモードをフィルターにかけるのである<>は、<src-リスト>によって指定されたセットにソースアドレスがある場合にだけ入って来るパケットが受け入れられることを意味します。 "excl"のモードをフィルターにかけるのである<>は、<src-リスト>によって指定されたセットにソースアドレスがあるなら入って来るパケットが拒絶されることを意味します。

   The first sub-field, <nettype>, indicates the network type, since SDP
   is protocol independent.  This document is most relevant to the value
   "IN", which designates the Internet Protocol.

最初のサブ分野(<nettype>)は、SDPがプロトコル独立者であるので、ネットワークタイプを示します。 このドキュメントは「中の」値に最も関連しています。(それは、プロトコルにインターネットを指定します)。

   The second sub-field, <address-types>, identifies the address family,
   and for the purpose of this document may be either <addrtype> value
   "IP4" or "IP6".  Alternately, when <dest-address> is an FQDN, the
   value MAY be "*" to apply to both address types, since either address
   type can be returned from a DNS lookup.

2番目のサブ分野、<が>をアドレスでタイプして、アドレスファミリーを特定して、このドキュメントの目的のための<addrtype>価値であるかもしれない、「IP4"か"IP6""。 <dest-アドレス>がFQDNであるときに、交互に、値はともにタイプに演説するのに申し込むためには「*」であるかもしれません、DNSルックアップからアドレスタイプを返すことができるので。

   The third sub-field, <dest-address>, is the destination address,
   which MUST correspond to one or more of the session's "connection-
   address" field values.  It may be either a unicast or multicast
   address, an FQDN, or the "*" wildcard to match any/all of the
   session's "connection-address" values.

3番目のサブ分野(<dest-アドレス>)は送付先アドレスです。(そのアドレスはセッションの「接続アドレス」分野値の1つ以上に一致しなければなりません)。 それは、セッションの「接続アドレス」のすべてが評価するどんな/も合わせるためにはユニキャストかマルチキャストアドレスのどちらか、FQDN、または「*」ワイルドカードであるかもしれません。

   The fourth sub-field, <src-list>, is the list of source
   hosts/interfaces in the source-filter, and consists of one or more
   unicast addresses or FQDNs, separated by space characters.

4番目のサブ分野(<src-リスト>)は、ソースフィルタの送信元ホスト/インタフェースのリストであり、間隔文字によって切り離された1ユニキャストアドレスかFQDNsから成ります。

   The format and content of these semantic elements are derived from
   and compatible with those defined in [SDP].  For more detail, see
   Appendix A of this document.

これらの意味要素の形式と内容は、[SDP]で定義されるそれらと、派生していて互換性があります。 その他の詳細に関しては、このドキュメントのAppendix Aを見てください。

Quinn, et al.               Standards Track                     [Page 3]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[3ページ]

3.1.  Processing Rules

3.1. 処理規則

   There are a number of details to consider when parsing the SDP
   source-filter syntax.

SDPソースフィルタ構文を分析すると考えるために、多くの詳細があります。

   The <dest-address> value in a "source-filter" attribute MUST
   correspond to an existing <connection-field> value in the session
   description.  The only exception to this is when a "*" wildcard is
   used to indicate that the source-filter applies to all
   <connection-field> values.

「ソースフィルタ」属性で>がセッション記述で評価する既存の<接続分野に一致しなければならない>が、評価する<dest-アドレス。 これへの唯一の例外が「*」ワイルドカードがソースフィルタが>が評価するすべての<接続分野に適用されるのを示すのに使用される時です。

   When the <dest-address> value is a multicast address, the field value
   MUST NOT include the sub-fields <ttl> and <number of addresses> from
   the <connection-address> value.  If the <connection-address>
   specifies more than one multicast address (in the <number of
   addresses> field), then a source filter, if any, for each such
   address must be stated explicitly, using a separate "a=source-filter"
   line for each address (unless a "*" wildcard is used for
   <dest-address>).  See section 3.2.4 for an example.

>がマルチキャストアドレスであることを評価する<dest-アドレスであるときに、分野値は<接続アドレス>からの>が評価するアドレスのサブ分野<ttl>と<番号を含んではいけません。 <接続アドレス>が1つ以上のマルチキャストアドレス(>がさばくアドレスの<番号における)を指定するなら、明らかにそのような各アドレスのためのもしあればソースフィルタを述べなければなりません、各アドレスに「=ソースフィルタ」別々の系列を使用して(「*」ワイルドカードが<dest-アドレス>に使用されない場合)。 例に関してセクション3.2.4を見てください。

   When the <addrtype> value is the "*" wildcard, the <dest-address>
   MUST be either an FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6
   address).  See section 3.2.6 for an example.

<addrtype>価値が「*」ワイルドカードであるときに、<dest-アドレス>はFQDNか「*」のどちらかであるに違いありません(すなわち、それは、IPv4かIPv6アドレスであるはずがありません)。 例に関してセクション3.2.6を見てください。

   As has always been the case, the default behavior when a source-
   filter attribute is not provided in a session description is that all
   traffic sent to the specified <connection-address> value should be
   accepted (i.e., from any source address).  The source-filter grammar
   does not include syntax to express either "exclude none" or "include
   all."

いつもケース(ソースフィルタ属性がそれがセッション記述でいるならすべてのトラフィックが>が受け入れられるべきであるのを(すなわち、どんなソースアドレスからも)評価する指定された<接続アドレスに発信したということでないことのデフォルトの振舞い)でした。 ソースフィルタ文法は、「なにも除かないでください」か「すべてを含めてください」のどちらかを言い表すために構文を含んでいません。

   Like the standard <connection-field> described in [SDP], the location
   of the "source-filter" attribute determines whether it applies to the
   entire session or only to a specific medium (i.e., "session-level" or
   "media-level").  A media-level source-filter will always completely
   override a session-level source-filter.

[SDP]で説明された標準の<接続分野>のように、「ソースフィルタ」属性の位置は、それが全体のセッション、または、特定の媒体(すなわち、「セッションレベル」か「メディアレベル」)だけに適用されるかどうか決定します。 メディアレベルソースフィルタはセッションレベルソースフィルタを完全にいつもくつがえすでしょう。

   A "source-filter" need not be located at the same hierarchy level as
   its corresponding <connection-field>.  So, a media-level
   <source-filter> can reference a session-level <connection-field>
   value, and a session-level "source-filter" can be applied to all
   matching media-level <connection-field> values.  See section 3.2.3
   for an example.

「ソースフィルタ」は対応する<接続分野>と同じ階層構造レベルで位置する必要はありません。 それで、メディアレベルの<のフィルタ>缶の参照aセッションレベル<接続の出典を明示している分野の>価値、およびセッション平らな「ソースフィルタ」を>が評価するすべての合っているメディアレベル<接続分野に適用できます。 例に関してセクション3.2.3を見てください。

   An SDP description MUST NOT contain more than one session-level
   "source-filter" attribute that covers the same destination address,
   or more than one media-level "source-filter" attribute that covers
   the same destination address.

SDP記述は同じ送付先アドレスをカバーする1つ以上のセッションレベル「ソースフィルタ」属性、または同じ送付先アドレスをカバーする1つ以上のメディアレベル「ソースフィルタ」属性を含んではいけません。

Quinn, et al.               Standards Track                     [Page 4]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[4ページ]

   There is no specified limit to the number of entries allowed in the
   <src-list>; however, there are practical limits that should be
   considered.  For example, depending on the transport to be used for
   the session description, there may be a limit to the total size of
   the session description (e.g., as determined by the maximum payload
   in a single datagram).  Also, when the source-filter is applied to
   control protocols, there may be a limit to the number of source
   addresses that can be sent.  These limits are outside the scope of
   this document, but should be considered when defining source-filter
   values for SDP.

<src-リスト>に許容されたエントリーの数への指定限界が全くありません。 しかしながら、考えられるべきである実用的な限界があります。 例えば、セッション記述に使用されるために輸送によって、セッション記述の総サイズへの限界があるかもしれません(例えば、単一のデータグラムで最大積載量で決定するように)。 また、ソースフィルタがプロトコルを制御するために適用されるとき、送ることができるソースアドレスの数への限界があるかもしれません。 このドキュメントの範囲の外にこれらの限界がありますが、SDPのためにソースフィルタ値を定義するときには考えられるべきであってください。

3.2.  Examples

3.2. 例

   Here are a number of examples that illustrate how to use the source-
   filter attribute in some common scenarios.  We use the following
   session description components as the starting point for the examples
   to follow.  For each example, we show the source filter with
   additional relevant information and provide a brief explanation.

ここに、いくつかの共通したシナリオでソースフィルタ属性を使用する方法を例証する多くの例があります。 私たちは例が続く出発点として以下のセッション記述コンポーネントを使用します。 各例のために、私たちは、追加関連情報でソースフィルタを見せていて、短い説明を提供します。

      <session-description> =
           v=0
           o=The King <Elvis@example.com>
           s=Elvis Impersonation
           i=All Elvis, all the time
           u=http://www.example.com/ElvisLive/
           t=0 0
           a=recvonly

<セッション記述>=v=0oが King <Elvis@example.com と等しい、gt;、エルビスs=Impersonation iは= http://www.example.com/ElvisLive/ tが0 0a=recvonlyと等しいすべての時代uにエルビスと等しいです。

      <media-description 1> =
           m=audio 54320 RTP/AVP 0

1<メディア記述>=mはオーディオの54320RTP/AVP0と等しいです。

      <media-description 2> =
           m=video 54322 RTP/AVP 34

2<メディア記述>=mはビデオ54322RTP/AVP34と等しいです。

3.2.1.  Source-Specific Multicast Example

3.2.1. ソース特有のマルチキャストの例

   Multicast addresses in the Source-Specific Multicast [SSM] range
   require a single unicast sender address for each multicast
   destination, so the source-filter specification provides a natural
   fit.  In this example, a session member should receive only traffic
   sent from 192.0.2.10 to the multicast session address 232.3.4.5.

Source特有のMulticast[SSM]範囲のマルチキャストアドレスがそれぞれのマルチキャストの目的地へのただ一つのユニキャスト送付者アドレスを必要とするので、ソースフィルタ仕様は自然な発作を供給します。 この例では、セッションメンバーが192.0から送られたトラフィックだけを受けるべきである、マルチキャストセッションまでの.10が扱う.2、232.3、.4、.5

      <session-description>

<セッション記述>。

      c=IN IP4 232.3.4.5/127
      a=source-filter: incl IN IP4 232.3.4.5 192.0.2.10

=ソースフィルタあたりc=IN IP4 232.3.4.5/127: incl IN IP4 232.3.4.5 192.0.2.10

      <media-description 1>

<メディア記述1>。

Quinn, et al.               Standards Track                     [Page 5]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[5ページ]

   This source-filter example uses an inclusion list with a single
   multicast "connection-address" as the destination and single unicast
   address as the source.  Note that the value of the connection-address
   matches the value specified in the connection-field.

このソースフィルタの例はソースとして目的地とただ一つのユニキャストアドレスとしての単一のマルチキャスト「接続アドレス」がある包含リストを使用します。 それに注意してください。値が接続分野で指定した接続アドレス一致の値。

   Also note that since the connection-field is located in the session-
   description section, the source-filter applies to all media.

また、接続分野がセッション記述部に位置しているのでソースフィルタがすべてのメディアに適用されることに注意してください。

   Furthermore, if the SDP description specifies an RTP session (e.g.,
   its "m=" line(s) specify "RTP/AVP" as the transport protocol), then
   the "incl" specification will apply not only to RTP packets, but also
   to any RTCP packets that are sent to the specified multicast address.
   This means that, as a side effect of the "incl" specification, the
   only possible multicast RTCP packets will be "Sender Report" (SR)
   packets sent from the specified source address.

その上、SDP記述がRTPセッションを指定すると(例えば、「m=」系列はトランスポート・プロトコルとして"RTP/AVP"を指定します)、"incl"仕様はRTPパケットに適用するだけではなく、指定されたマルチキャストアドレスに送られるどんなRTCPパケットにも適用されるでしょう。 これは、唯一の可能なマルチキャストRTCPパケットが"incl"仕様の副作用として指定されたソースアドレスから送られた「送付者レポート」(SR)パケットになることを意味します。

   Because of this, an SDP description for a Source-Specific Multicast
   (SSM) RTP session SHOULD also include an

これ、またSHOULDが含むSource特有のMulticast(SSM)RTPセッションのためのSDP記述

      a=rtcp-unicast ...

a=rtcp-ユニキャスト…

   attribute, as described in [RTCP-SSM] (section 10.1).  This specifies
   that RTCP "Reception Report" (RR) packets are to be sent back via
   unicast.

[RTCP-SSM](セクション10.1)で説明されるように、結果と考えます。 これは、RTCP「レセプションレポート」(RR)パケットがユニキャストで返送されることになっていると指定します。

3.2.2.  Unicast Exclusion Example

3.2.2. ユニキャスト除外の例

   Typically, an SDP session <connection-address> value is a multicast
   address, although it is also possible to use either a unicast address
   or FQDN.  This example illustrates a scenario whereby a session
   description indicates the unicast source address 192.0.2.10 in an
   exclusion filter.  In effect, this sample source-filter says,
   "destination 192.0.2.11 should accept traffic from any sender
   *except* 192.0.2.10."

通常>がまた、ユニキャストアドレスかFQDNのどちらかを使用するのも可能ですが、マルチキャストアドレスであることを評価するSDPセッション<接続アドレス。 この例がセッション記述がユニキャストソースアドレスを示すシナリオを例証する、192.0、.2、.10、除外フィルタで。 *192.0を除いたどんな送付者*からもトラフィックを受け入れるべきです。事実上、このサンプルソースフィルタが言う、「目的地、192.0、.2、.11、.2 .10インチ。

      <session-description>

<セッション記述>。

      c=IN IP4 192.0.2.11
      a=source-filter: excl IN IP4 192.0.2.11 192.0.2.10

=ソースフィルタあたりc=IN IP4 192.0.2.11: excl IN IP4 192.0.2.11 192.0.2.10

      <media-description 1>

<メディア記述1>。

3.2.3.  Multiple Session Address Example

3.2.3. 複数のセッションアドレスの例

   This source-filter example uses the wildcard "*" value for
   <dest-addr> to correspond to any/all <connection-address> values.
   Hence, the only legitimate source for traffic sent to either

このソースフィルタの例は、<dest-addr>がすべての<接続アドレス>が評価するどんな/にも相当するのにワイルドカード「*」値を使用します。 したがって、トラフィックのための唯一の正統のソースがどちらかに発信しました。

Quinn, et al.               Standards Track                     [Page 6]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[6ページ]

   232.2.2.2 or 232.4.4.4 multicast addresses is 192.0.2.10.  Traffic
   sent from any other unicast source address should be discarded by the
   receiver.

232.4の.4.4マルチキャストアドレスが192.0です。または、232.2.2.2、.2 .10。 いかなる他のユニキャストソースアドレスからも送られたトラフィックは受信機によって捨てられるべきです。

      <session-description>

<セッション記述>。

      a=source-filter: incl IN IP4 * 192.0.2.10

=ソースフィルタ: incl IN IP4*192.0.2.10

      <media-description 1>

<メディア記述1>。

      c=IN IP4 232.2.2.2/127

cがIN IP4 232.2.2.2/と等しい、127

      <media-description 2>

<メディア記述2>。

      c=IN IP4 232.4.4.4/63

cがIN IP4 232.4.4.4/と等しい、63

3.2.4.  Multiple Multicast Address Example

3.2.4. 複数のマルチキャストアドレスの例

   In this example, the <connection-address> specifies three multicast
   addresses: 224.2.1.1, 224.2.1.2, and 224.2.1.3.  The first and third
   of these addresses are given source filters.  However, in this
   example the second address - 224.2.1.2 - is *not* given a source
   filter.

この例では、<接続アドレス>は3つのマルチキャストアドレスを指定します: そして、224.2.1.1、224.2 .1 .2、224.2 .1 .3。 これらのアドレスの1番目と3番目にソースフィルタを与えます。 しかしながら、この例の2番目のアドレス--224.2 .1 .2--*は*当然のことaソースフィルタではありませんか?

      <session-description>

<セッション記述>。

      c=IN IP4 224.2.1.1/127/3
      a=source-filter: incl IN IP4 224.2.1.1 192.0.2.10
      a=source-filter: incl IN IP4 224.2.1.3 192.0.2.42

=ソースフィルタあたりc=IN IP4 224.2.1.1/127/3: =ソースフィルタあたりincl IN IP4 224.2.1.1 192.0.2.10: incl IN IP4 224.2.1.3 192.0.2.42

      <media-description 1>

<メディア記述1>。

3.2.5.  IPv6 Multicast Source-Filter Example

3.2.5. IPv6マルチキャストソースフィルタの例

   This simple example defines a single session-level source-filter that
   references a single IPv6 multicast destination and source pair.  The
   IP multicast traffic sent to FFOE::11A is valid only from the unicast
   source address 2001:DB8:1:2:240:96FF:FE25:8EC9.

この簡単な例は単一のIPv6マルチキャストの目的地とソース組に参照をつける単一のセッションレベルソースフィルタを定義します。 IPマルチキャストトラフィックはFFOEに発信しました:、:11Aは単にユニキャストソースアドレス2001から有効です: DB8: 1:2:240:96FF:FE25:8EC9。

   <session-description>

<セッション記述>。

   c=IN IP6 FF0E::11A/127
   a=source-filter incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9

IP6 FF0Eのc=:、:11A/127aはソースフィルタincl IN IP6 FF0Eと等しいです:、:11A2001: DB8:1:2:240:96FF:FE25:8EC9

   <media-description 1>

<メディア記述1>。

Quinn, et al.               Standards Track                     [Page 7]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[7ページ]

3.2.6.  IPv4 and IPv6 FQDN Example

3.2.6. IPv4とIPv6 FQDNの例

   This example illustrates use of the <addrtype> "*" wildcard, along
   with multicast and source FQDNs that may resolve to either an IPv6 or
   IPv4 address, or both.  Although typically both the multicast and
   source addresses will be the same (either both IPv4 or both IPv6),
   using the wildcard for addrtype in the source filter allows asymmetry
   between the two addresses (so an IPv4 source address may be used with
   an IPv6 multicast address).

この例は<addrtype>「*」ワイルドカードの使用を例証します、IPv6かIPv4のどちらかにアドレス、または両方を決議するかもしれないマルチキャストとソースFQDNsと共に。 通常マルチキャストとソースアドレスの両方が同じになる、(両方、IPv4か両方、IPv6)、addrtypeにソースフィルタでワイルドカードを使用すると、2つのアドレスの間の非対称は許容されます(したがって、IPv4ソースアドレスはIPv6マルチキャストアドレスと共に使用されるかもしれません)。

      <session-description>

<セッション記述>。

      c=IN IP4 channel-1.example.com/127
      c=IN IP6 channel-1.example.com/127
      a=source-filter: incl IN * channel-1.example.com src-1.example.com

IN IP4チャンネル-1.example.com/127c=cは=がソースでフィルターにかけるIN IP6チャンネル-1.example.com/127と等しいです: incl IN*チャンネル-1.example.com src-1.example.com

      <media-description 1>

<メディア記述1>。

3.3.  Offer-Answer Model Considerations

3.3. 申し出答えモデル問題

   The "source-filter" attribute is not intended to be used as an
   'offer' in an SDP offer-answer exchange [OFFER], because sets of
   source addresses do not represent 'capabilities' or 'limitations' of
   the offerer, and because the offerer does not, in general, have a
   priori knowledge of which IP source address(es) will be included in
   an answer.  While an answerer may include the "source-filter"
   attribute in his/her answer (e.g., to designate a SSM session), the
   answerer SHOULD ignore any "source-filter" attribute that was present
   in the original offer.

SDP申し出答え交換における'申し出'として「ソースフィルタ」属性が使用されることを意図しません[OFFER]、申出人にはIPソースアドレス(es)が答えに含まれている先験的な知識が一般にないのでソースアドレスのセットが申出人の'能力'か'制限'を表さないので。 answererがその人の答え(例えばSSMセッションを指定する)に「ソースフィルタ」属性を含んでいるかもしれない間、answerer SHOULDはどんなオリジナルの申し出で存在している「ソースフィルタ」属性も無視します。

4.  Interoperability Issues

4. 相互運用性問題

   Defining a list of legitimate sources for a multicast destination
   address represents a departure from the Any-Source Multicast (ASM)
   model, as originally described in [IGMPv1].  The ASM model supports
   anonymous senders and all types of multicast applications (e.g.,
   many-to-many).  Use of a source-filter excludes some (unknown or
   undesirable) senders, which lends itself more to one-to-many or few-
   to-few type multicast applications.

マルチキャスト送付先アドレスのために正統のソースのリストを定義すると、出発はAny-ソースMulticast(ASM)モデルから表されます、元々[IGMPv1]で説明されるように。 ASMモデルがマルチキャストアプリケーションの匿名の送付者とすべてのタイプをサポートする、(例えば、多く、-、-、多く) ソースフィルタの使用が何人かの(未知か望ましくありません)の送付者、どれが多くへの1つにそれ自体をさらに与えるか、そして、またはわずかしか除かない、-、わずかである、マルチキャストアプリケーションをタイプしてください。

   Although these two models have contrasting operational
   characteristics and requirements, they can coexist on the same
   network using the same protocols.  Use of source-filters do not
   corrupt the ASM semantics but provide more control for receivers, at
   their discretion.

これらの2つのモデルには、操作上の特性を対照して、要件がありますが、それらは、同じネットワークに同じプロトコルを使用することで共存できます。 ソースフィルタの使用は、彼らの裁量でASM意味論を崩壊させるのではなく、受信機のための、より多くのコントロールを提供します。

Quinn, et al.               Standards Track                     [Page 8]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[8ページ]

5.  Security Considerations

5. セキュリティ問題

   See [SDP] for security considerations specific to the Session
   Description Protocol in general.  The central issue relevant to using
   source address filters is the question of address authenticity.

一般に、Session記述プロトコルに特定のセキュリティ問題に関して[SDP]を見てください。 ソースアドレスフィルタを使用すると関連している主要な問題はアドレスの信憑性の問題です。

   Using the source IP address for authentication is weak, since
   addresses are often dynamically assigned and it is possible for a
   sender to "spoof" its source address (i.e., use one other than its
   own) in datagrams that it sends.  Proper router configuration,
   however, can reduce the likelihood of "spoofed" source addresses
   being sent to or from a network.  Specifically, border routers are
   encouraged to filter traffic so that datagrams with invalid source
   addresses are not forwarded (e.g., routers drop datagrams if the
   source address is non-local) [FILTERING].  This, however, does not
   prevent IP source addresses from being spoofed on a Local Area
   Network (LAN).

認証にソースIPアドレスを使用するのは弱いです、アドレスがしばしばダイナミックに割り当てられて、送付者が、ソースアドレスがデータグラムで(すなわち、それ自身のもの以外の使用1)であると「偽造すること」において発信するのが可能であるので。 しかしながら、適切なルータ構成はネットワークかネットワークから送られる「偽造している」ソースアドレスの見込みを減少させることができます。 明確に、境界ルータがトラフィックをフィルターにかけるよう奨励されるので、無効のソースアドレスがあるデータグラムは進められません(ソースアドレスが非ローカルであるなら、例えば、ルータはデータグラムを下げます)[FILTERING]。 しかしながら、これは、IPソースアドレスがローカル・エリア・ネットワーク(LAN)で偽造されるのを防ぎません。

   Also, as noted in section 3 above, tunneling or NAT mechanisms may
   require corresponding translation of the addresses specified in the
   SDP "source-filter" attribute, and furthermore, may cause a set of
   original source addresses to be translated to a smaller set of source
   addresses as seen by the receiver.

また、上では、トンネリングかNATメカニズムが必要とするかもしれないセクション3で注意されるように、アドレスの対応する翻訳がSDP「ソースフィルタ」属性で指定しました、そして、その上、受信機によって見られるように1セットの一次資料アドレスが、より小さいソースアドレスに翻訳されることを引き起こすかもしれません。

   Use of FQDNs for either <dest-address> or <src-list> values provides
   a layer of indirection that provides great flexibility.  However, it
   also exposes the source-filter to any security inadequacies that the
   DNS system may have.  If unsecured, it is conceivable that the DNS
   server could return illegitimate addresses.

FQDNsの>が評価する<dest-アドレス>か<src-リストのどちらかの使用はかなりの柔軟性を提供する間接指定の層を提供します。 しかしながら、また、それはDNSシステムが持っているどんなセキュリティ不適当にもソースフィルタを暴露します。 非機密保護されるなら、DNSサーバが違法なアドレスを返すかもしれないのが想像できます。

   In addition, if source-filtering is implemented by sharing the
   source-filter information with network elements, then the security of
   the protocol(s) that are used for this (e.g., [IGMPv3]) becomes
   important, to ensure that legitimate traffic (and only legitimate
   traffic) is received.

さらに、ソースフィルタリングがソースフィルタ情報をネットワーク要素と共有することによって実装されるなら、これ(例えば、[IGMPv3])に使用されるプロトコルのセキュリティは、正統のトラフィック(そして、正統のトラフィックだけ)が受け取られているのを保証するために重要になります。

   For these reasons, receivers SHOULD NOT treat the SDP "source-filter"
   attribute as being its sole mechanism for protecting the integrity of
   received content.

これらの理由で、受信機SHOULD NOTは、受信された内容の保全を保護するために唯一のメカニズムであるとしてSDP「ソースフィルタ」属性を扱います。

Quinn, et al.               Standards Track                     [Page 9]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[9ページ]

6.  IANA Considerations

6. IANA問題

   As recommended by [SDP] (Appendix B), the new attribute name
   "source-filter" has been registered with IANA, as follows:

[SDP](付録B)によって推薦されるように、以下の通り新しい属性名前「ソースフィルタ」をIANAに登録してあります:

   The following contact information shall be used for all registrations
   included here:

以下の問い合わせ先はここにすべての登録証明書を含むのに使用されるものとします:

        Contact:      Ross Finlayson
                      email: finlayson (at) live555.com
                      phone: +1-650-254-1184

接触: ロスフィンリースンメール: finlayson (at) live555.com電話: +1-650-254-1184

      SDP Attribute ("att-field"):
        Attribute name:     source-filter
        Long form:          Source Filter
        Type of name:       att-field
        Type of attribute:  Session level or media level
        Subject to charset: No
        Purpose:            See this document
        Reference:          This document
        Values:             See this document, and registrations below

SDPは(「att-分野」)を結果と考えます: 名前を結果と考えてください: ソースフィルタLongは形成します: 名前のソースFilter Type: 属性のatt-分野Type: セッションレベルかメディアがcharsetにSubjectを平らにします: 目的がありません: このドキュメントReferenceを見てください: このドキュメントValues: このドキュメント、および以下の登録証明書を見てください。

7.  Acknowledgements

7. 承認

   The authors would like to thank Dave Thaler and Mark Handley, whose
   input provided much of the substance of this document.  Magnus
   Westerlund also provided valuable feedback during editing.

作者は入力がこのドキュメントの実体の多くを提供したデーヴThalerとマーク・ハンドレーに感謝したがっています。 また、マグヌスWesterlundは編集の間、有益なフィードバックを提供しました。

8.  Normative References

8. 引用規格

   [ABNF]      Crocker, D., Ed. and P. Overell, "Augmented BNF for
               Syntax Specifications: ABNF", RFC 4234, October 2005.

エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

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

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

   [SDP]       Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
               Description Protocol", RFC 4566, July 2006.

[SDP] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。

   [UTF-8]     Yergeau, F., "UTF-8, a transformation format of ISO
               10646", STD 63, RFC 3629, November 2003.

[UTF-8]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日

Quinn, et al.               Standards Track                    [Page 10]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[10ページ]

9.  Informative References

9. 有益な参照

   [FILTERING] Ferguson, P. and D. Senie, "Network Ingress Filtering:
               Defeating Denial of Service Attacks which employ IP
               Source Address Spoofing", BCP 38, RFC 2827, May 2000.

[フィルターにかけます] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。

   [IGMPv1]    Deering, S., "Host extensions for IP multicasting", STD
               5, RFC 1112, August 1989.

[IGMPv1] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。

   [IGMPv3]    Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
               Thyagarajan, "Internet Group Management Protocol, Version
               3", RFC 3376, October 2002.

[IGMPv3] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」

   [MSF-API]   Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
               Extensions for Multicast Source Filters", RFC 3678,
               January 2004.

[MSF-API] ターレル、D.、フェナー、B.、およびB.クイン、「マルチキャストソースフィルタのためのソケットインタフェース拡大」、RFC3678、2004年1月。

   [OFFER]     Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
               with Session Description Protocol (SDP)", RFC 3264, June
               2002.

[提供します] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。

   [RTCP-SSM]  Chesterfield, J., E. Schooler, J. Ott, "RTCP Extensions
               for Single-Source Multicast Sessions with Unicast
               Feedback", Work in Progress, October 2004.

[RTCP-SSM]チェスターフィールド、J.、E.学生、J.オット、「ユニキャストフィードバックとの単独のソースマルチキャストセッションのためのRTCP拡張子」は進行中(2004年10月)で働いています。

   [SSM]       Bhattacharyya, S., "An Overview of Source-Specific
               Multicast (SSM)", RFC 3569, July 2003.

[SSM]Bhattacharyya、2003年7月のS.、「ソース特有のマルチキャスト(SSM)の概要」RFC3569。

Quinn, et al.               Standards Track                    [Page 11]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[11ページ]

Appendix A.  Source-Filter Attribute Syntax

付録A.ソースフィルタ属性構文

   This appendix provides an Augmented BNF [ABNF] grammar for expressing
   an exclusion or inclusion list of one or more (IPv4 or IPv6) unicast
   source addresses.  It is intended as an extension to the grammar for
   the Session Description Protocol, as defined in [SDP].  Specifically,
   it describes the syntax for the new "source-filter" attribute field,
   which MAY be either a session-level or media-level attribute.

この付録は、1つ以上(IPv4かIPv6)のユニキャストソースアドレスの除外か包含リストを言い表すためにAugmented BNF[ABNF]に文法を供給します。 それはSession記述プロトコルのための文法への拡大[SDP]で定義されるように意図します。 明確に、それは新しい「ソースフィルタ」属性分野に構文について説明します。(それは、セッションレベルかメディアレベル属性のどちらかであるかもしれません)。

   The "dest-address" value in each source-filter field MUST match an
   existing connection-field value, unless the wildcard connection-
   address value "*" is specified.

それぞれのソースフィルタ分野の「dest-アドレス」値は既存の接続分野値に合わなければならなくて、ワイルドカード接続が値を記述しないなら、「*」は指定されます。

   source-filter =  "source-filter" ":" SP filter-mode SP filter-spec
                    ; SP is the ASCII 'space' character
                    ;  (0x20, defined in [ABNF]).

「ソースフィルタ=「ソースフィルタ」」:、」 SPフィルタモードSPフィルタ仕様。 SPはASCII'スペース'キャラクタです。 ([ABNF]で定義された0×20。)

   filter-mode =    "excl" / "incl"
                    ; either exclusion or inclusion mode.

フィルタモードは"excl"/"incl"と等しいです。 除外か包含モードのどちらか。

   filter-spec =    nettype SP address-types SP dest-address SP src-list
                    ; nettype is as defined in [SDP].

フィルタ仕様はnettype SPアドレスタイプSP dest-アドレスSP src-リストと等しいです。 nettypeが[SDP]で定義されるようにあります。

   address-types =  "*" / addrtype
                    ; "*" for all address types (both IP4 and IP6),
                    ;  but only when <dest-address> and <src-list>
                    ;  reference FQDNs.
                    ; addrtype is as defined in [SDP].

アドレスタイプは「*」/addrtypeと等しいです。 すべてのアドレスのための「*」は(IP4とIP6の両方)をタイプします。 -しかし、<dest-アドレスの>と<srcであるだけときには、>を記載してください。 参照FQDNs。 ; addrtypeが[SDP]で定義されるようにあります。

   dest-address =   "*" / basic-multicast-address / unicast-address
                    ; "*" applies to all connection-address values.
                    ; unicast-address is as defined in [SDP].

dest-アドレスはユニキャスト基本的なマルチキャスト「*」/アドレス/アドレスと等しいです。 「*」はすべての接続アドレス値に適用されます。 ; ユニキャストアドレスが[SDP]で定義されるようにあります。

   src-list =       *(unicast-address SP) unicast-address
                    ; one or more unicast source addresses (in
                    ;  standard IPv4 or IPv6 ASCII-notation form)
                    ;  or FQDNs.
                    ; unicast-address is as defined in [SDP].

src-リストは*(ユニキャストアドレスSP)ユニキャストアドレスと等しいです。 1つ以上のユニキャストソースアドレス(コネ; 標準のIPv4かIPv6ASCII-記法フォーム)。 または、FQDNs。 ; ユニキャストアドレスが[SDP]で定義されるようにあります。

   basic-multicast-address =   basic-IP4-multicast / basic-IP6-multicast
                               / FQDN / extn-addr
                               ; i.e., the same as multicast-address
                               ;  defined in [SDP], except that the
                               ;  /<ttl> and /<number of addresses>
                               ;  fields are not included.
                               ; FQDN and extn-addr are as defined
                               ;  in [SDP].

基本的なマルチキャストアドレスは基本的なIP6基本的なIP4マルチキャスト/マルチキャスト/FQDN/extn-addrと等しいです。 すなわち、マルチキャストアドレスと同じ。 それを除いて、[SDP]で定義される、。 アドレス>の/<ttl>と/<番号。 分野は含まれていません。 ; 定義されるとしてFQDNとextn-addrがあります。 [SDP]で。

Quinn, et al.               Standards Track                    [Page 12]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[12ページ]

   basic-IP4-multicast =       m1 3( "." decimal-uchar )
                               ; m1 and decimal-uchar are as defined
                               ;  in [SDP].

基本的なIP4マルチキャスト=m1 3、(「. 」 10進uchar、)、。 定義されるとしてm1と10進ucharがあります。 [SDP]で。

   basic-IP6-multicast =       hexpart
                               ; hexpart is as defined in [SDP].

基本的なIP6マルチキャストはhexpartと等しいです。 hexpartが[SDP]で定義されるようにあります。

Authors' Addresses

作者のアドレス

   Bob Quinn
   BoxnArrow.com
   31 Caldwell Road
   Waltham, MA 02453

Roadウォルサム、ボブクインBoxnArrow.com31Caldwell MA 02453

   Phone: +1-781-577-1539
   EMail: rcq@boxnarrow.com

以下に電話をしてください。 +1-781-577-1539 メールしてください: rcq@boxnarrow.com

   Ross Finlayson
   Live Networks, Inc.
   650 Castro St., suite 120-196
   Mountain View, CA 94041

マウンテンビュー、スイート120-196カリフォルニア ロスフィンリースンLive Networks Inc.650カストロ通り、94041

   EMail: finlayson@live555.com

メール: finlayson@live555.com

Quinn, et al.               Standards Track                    [Page 13]

RFC 4570                   SDP Source Filters                  July 2006

クイン、他 RFC4570SDPソースが2006年7月にフィルターにかける標準化過程[13ページ]

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)によって提供されます。

Quinn, et al.               Standards Track                    [Page 14]

クイン、他 標準化過程[14ページ]