RFC5231 日本語訳

Network Working Group                                       W. Segmuller
Request for Comments: 5231                                      B. Leiba
Obsoletes: 3431                          IBM T.J. Watson Research Center
Category: Standards Track                                   January 2008

Segmullerがコメントのために要求するワーキンググループW.をネットワークでつないでください: 5231B.Leibaは以下を時代遅れにします。 3431年のIBM T.J.ワトソン研究所カテゴリ: 標準化過程2008年1月

              Sieve Email Filtering: Relational Extension

ふるいのメールフィルタリング: 関係拡大

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)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document describes the RELATIONAL extension to the Sieve mail
   filtering language defined in RFC 3028.  This extension extends
   existing conditional tests in Sieve to allow relational operators.
   In addition to testing their content, it also allows for testing of
   the number of entities in header and envelope fields.

このドキュメントはRFC3028で定義された言語をフィルターにかけるSieveメールにRELATIONAL拡張子について説明します。 この拡大は、関係演算子を許容するためにSieveでの既存の条件付きのテストを広げています。 また、それらの内容をテストすることに加えて、それは、ヘッダーと封筒分野の実体の数をテストすると考慮します。

   This document obsoletes RFC 3431.

このドキュメントはRFC3431を時代遅れにします。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 2
   3.  Comparators . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   4.  Match Types . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     4.1.  Match Type VALUE  . . . . . . . . . . . . . . . . . . . . . 3
     4.2.  Match Type COUNT  . . . . . . . . . . . . . . . . . . . . . 3
   5.  Interaction with Other Sieve Actions  . . . . . . . . . . . . . 4
   6.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   7.  Extended Example  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Changes since RFC 3431  . . . . . . . . . . . . . . . . . . . . 6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   11. Normative References  . . . . . . . . . . . . . . . . . . . . . 7

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 コンベンションは本書では.2 3を使用しました。 比較器. . . . . . . . . . . . . . . . . . . . . . . . . . 2 4。 タイプ. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1を合わせてください。 タイプ値. . . . . . . . . . . . . . . . . . . . . 3 4.2を合わせてください。 タイプカウント. . . . . . . . . . . . . . . . . . . . . 3 5に合ってください。 他のふるいの動作. . . . . . . . . . . . . 4 6との相互作用。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7。 拡張例. . . . . . . . . . . . . . . . . . . . . . . 6 8。 RFC3431.6 9以来の変化。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 7 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 7 11。 引用規格. . . . . . . . . . . . . . . . . . . . . 7

Segmuller & Leiba           Standards Track                     [Page 1]

RFC 5231              Sieve: Relational Extension           January 2008

Segmuller&Leiba規格はRFC5231ふるいを追跡します[1ページ]: 関係拡大2008年1月

1.  Introduction

1. 序論

   The RELATIONAL extension to the Sieve mail filtering language [Sieve]
   provides relational operators on the address, envelope, and header
   tests.  This extension also provides a way of counting the entities
   in a message header or address field.

言語[ふるい]をフィルターにかけるSieveメールへのRELATIONAL拡張子はアドレス、封筒、およびヘッダーテストの関係演算子を提供します。 また、この拡大はメッセージヘッダーかアドレス・フィールドで実体を数える方法を提供します。

   With this extension, the Sieve script may now determine if a field is
   greater than or less than a value instead of just equivalent.  One
   use is for the x-priority field: move messages with a priority
   greater than 3 to the "work on later" folder.  Mail could also be
   sorted by the from address.  Those userids that start with 'a'-'m' go
   to one folder, and the rest go to another folder.

この拡大で、Sieveスクリプトは、現在、分野がちょうど同等の代わりにより大きいか、または値より少ないかどうか決定するかもしれません。 x-優先権分野には1つの使用があります: 「より遅いことに対する仕事」フォルダーの優先より多くの3でメッセージを動かしてください。 また、メールを分類できた、アドレスから。 ''a'--'碁であり別のフォルダーに順調なあるフォルダー、および残りに始めるそれらのユーザID。

   The Sieve script can also determine the number of fields in the
   header, or the number of addresses in a recipient field, for example,
   whether there are more than 5 addresses in the to and cc fields.

また、Sieveスクリプトはヘッダーの分野の数、または受取人分野のアドレスの数を測定できます、中に5つ以上のアドレスが例えばあるか否かに関係なくそして、cc分野。

   The capability string associated with the extension defined in this
   document is "relational".

定義される拡大に関連している能力ストリングは本書では「関係しています」。

2.  Conventions Used in This Document

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.

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

   Conventions for notations are as in [Sieve] section 1.1, including
   the use of [Kwds] and the use of [ABNF].

[ふるい]セクション1.1、包含における[Kwds]の使用と[ABNF]の使用として記法のためのコンベンションがあります。

3.  Comparators

3. 比較器

   This document does not define any comparators or exempt any
   comparators from the require clause.  Any comparator used must be
   treated as defined in [Sieve].

このドキュメントがどんな比較器も定義もしませんし、どんな比較器からも免除もしていない、節を必要としてください。 [ふるい]で定義されるように使用されるどんな比較器も扱わなければなりません。

   The "i;ascii-numeric" comparator, as defined in [RFC4790], MUST be
   supported for any implementation of this extension.  The comparator
   "i;ascii-numeric" MUST support at least 32-bit unsigned integers.

「i;、ASCII数値、」 この拡大のどんな実現のためにも[RFC4790]で定義される比較器を支えなければなりません。 比較器、「i;、ASCII数値、」 少なくとも32ビットの符号のない整数を支持しなければなりません。

   Larger integers MAY be supported.  Note: the "i;ascii-numeric"
   comparator does not support negative numbers.

より大きい整数は支持されるかもしれません。 以下に注意してください。 「i; 」 比較器がサポートしないASCII数値負数。

Segmuller & Leiba           Standards Track                     [Page 2]

RFC 5231              Sieve: Relational Extension           January 2008

Segmuller&Leiba規格はRFC5231ふるいを追跡します[2ページ]: 関係拡大2008年1月

4.  Match Types

4. タイプを合わせてください。

   This document defines two new match types.  They are the VALUE match
   type and the COUNT match type.

このドキュメントは2つの新しいマッチタイプを定義します。 それらはVALUEマッチタイプです、そして、COUNTはタイプに合っています。

   The syntax is:

構文は以下の通りです。

   MATCH-TYPE =/ COUNT / VALUE

マッチタイプ=/カウント/値

   COUNT = ":count" relational-match

「COUNT=」: 」 関係マッチを数えてください。

   VALUE = ":value" relational-match

「VALUE=」: 」 関係マッチを評価してください。

   relational-match = DQUOTE
           ("gt" / "ge" / "lt" / "le" / "eq" / "ne") DQUOTE
           ; "gt" means "greater than", the C operator ">".
           ; "ge" means "greater than or equal", the C operator ">=".
           ; "lt" means "less than", the C operator "<".
           ; "le" means "less than or equal", the C operator "<=".
           ; "eq" means "equal to", the C operator "==".
           ; "ne" means "not equal to", the C operator "!=".

関係マッチはDQUOTE("gt"/"ge"/"lt"/"le"/"eq"/「Ne」)DQUOTEと等しいです。 "gt"が意味する、「すばらしさ、」、Cオペレータ">"。 ; "ge"が意味する、「すばらしさ、同輩、」、Cオペレータ「>=。」 ; "lt"が意味する、「より少なさ、」、Cオペレータ"<"。 ; "le"は「以下か等しいこと」を意味して、Cオペレータは「<=」です。 ; "eq"は「等しいこと」を意味して、Cオペレータは「=」です。 ; 「」 「Ne」は「等しくないこと」を意味して、Cオペレータは=です。」

4.1.  Match Type VALUE

4.1. タイプ値を合わせてください。

   The VALUE match type does a relational comparison between strings.

VALUEマッチタイプはストリングでの関係比較をします。

   The VALUE match type may be used with any comparator that returns
   sort information.

VALUEマッチタイプは種類の情報を返すどんな比較器と共にも使用されるかもしれません。

   A value from the message is considered the left side of the relation.
   A value from the test expression, the key-list for address, envelope,
   and header tests, is the right side of the relation.

メッセージからの値は関係の左側であると考えられます。 テスト表現からの値(アドレス、封筒、およびヘッダーテストのための主要なリスト)は関係の右側です。

   If there are multiple values on either side or both sides, the test
   is considered true if any pair is true.

複数の値が側か両側のどちらかにあれば、何か組が本当であるなら、テストは本当であると考えられます。

4.2.  Match Type COUNT

4.2. マッチタイプは数えます。

   The COUNT match type first determines the number of the specified
   entities in the message and does a relational comparison of the
   number of entities, as defined below, to the values specified in the
   test expression.

COUNTマッチタイプは、最初に、メッセージの指定された実体の数を測定して、実体の数の関係比較をします、以下で定義されるように、テスト表現で指定された値に。

   The COUNT match type SHOULD only be used with numeric comparators.

COUNTはタイプSHOULDに合っています。数値比較器と共に使用されるだけです。

   The Address Test counts the number of addresses (the number of
   "mailbox" elements, as defined in [RFC2822]) in the specified fields.
   Group names are ignored, but the contained mailboxes are counted.

Address Testは指定された分野のアドレス(中で定義されるとしての「メールボックス」要素[RFC2822]の数)の数を数えます。 グループ名は無視されますが、含まれたメールボックスは数えられます。

Segmuller & Leiba           Standards Track                     [Page 3]

RFC 5231              Sieve: Relational Extension           January 2008

Segmuller&Leiba規格はRFC5231ふるいを追跡します[3ページ]: 関係拡大2008年1月

   The Envelope Test counts the number of addresses in the specified
   envelope parts.  The envelope "to" will always have only one entry,
   which is the address of the user for whom the Sieve script is
   running.  Using this test, there is no way a Sieve script can
   determine if the message was actually sent to someone else.  The
   envelope "from" will be 0 if the MAIL FROM is empty, or 1 if MAIL
   FROM is not empty.

Envelope Testは指定された封筒の部品のアドレスの数を数えます。 封筒“to"には、1つのエントリーしかいつもあるというわけではないでしょう。(それは、Sieveスクリプトが走っているユーザのアドレスです)。 このテストを使用して、Sieveスクリプトが、メッセージが実際に他の誰かに送られたかどうか決定できる方法が全くありません。 MAIL FROMが空であるなら、封筒“from"が0になるだろうか、または1はMAIL FROMであるなら空ではありません。

   The Header Test counts the total number of instances of the specified
   fields.  This does not count individual addresses in the "to", "cc",
   and other recipient fields.

Header Testは指定された分野の例の総数を数えます。 これは“to"、「cc」、および他の受取人分野で個々のアドレスを数えません。

   In all cases, if more than one field name is specified, the counts
   for all specified fields are added together to obtain the number for
   comparison.  Thus, specifying ["to", "cc"] in an address COUNT test
   compares the total number of "to" and "cc" addresses; if separate
   counts are desired, they must be done in two comparisons, perhaps
   joined by "allof" or "anyof".

すべての場合では、1つ以上のフィールド名が指定されるなら、すべての指定された分野のためのカウントは、比較の数を得るために合計されます。 したがって、アドレスCOUNTテストにおける指定[“to"、「cc」]は“to"の総数と「cc」アドレスを比較します。 別々のカウントを望んでいるなら、恐らく"allof"か"anyof"によって参加された2つの比較でそれらをしなければなりません。

5.  Interaction with Other Sieve Actions

5. 他のふるいの動作との相互作用

   This specification adds two match types.  The VALUE match type only
   works with comparators that return sort information.  The COUNT match
   type only makes sense with numeric comparators.

この仕様は、2がタイプに合っていると言い足します。 VALUEマッチタイプは比較器でそのリターン種類の情報を扱うだけです。 COUNTマッチタイプは数値比較器で理解できるだけです。

   There is no interaction with any other Sieve operations, nor with any
   known extensions.  In particular, this specification has no effect on
   implicit KEEP, nor on any explicit message actions.

いかなる他のSieve操作、およびどんな知られている拡大との相互作用も全くありません。 特に、この仕様は内在しているKEEP、およびどんな明白なメッセージ動作のときにも効き目がありません。

6.  Example

6. 例

   Using the message:

メッセージを使用します:

      received: ...
      received: ...
      subject: example
      to: foo@example.com, baz@example.com
      cc: qux@example.com

受け取られている: …は受信されました: …対象: 以下への例 foo@example.com 、baz@example.com cc: qux@example.com

   The test:

テスト:

      address :count "ge" :comparator "i;ascii-numeric"
                      ["to", "cc"] ["3"]

:count"ge":comparatorを記述してください、「i;、」 ASCII数値の[“to"、「cc」]["3"]

   would evaluate to true, and the test

本当に評価するだろう、テスト

Segmuller & Leiba           Standards Track                     [Page 4]

RFC 5231              Sieve: Relational Extension           January 2008

Segmuller&Leiba規格はRFC5231ふるいを追跡します[4ページ]: 関係拡大2008年1月

      anyof ( address :count "ge" :comparator "i;ascii-numeric"
                      ["to"] ["3"],
              address :count "ge" :comparator "i;ascii-numeric"
                      ["cc"] ["3"] )

anyof(:count"ge":comparatorを記述してください、「i、; 」 ASCII数値[“to"]、[「3インチ]、:count"ge":comparatorを記述してください、「i;、ASCII数値、」 [「cc」]、[「3インチ)」

   would evaluate to false.

誤っているのに評価するでしょう。

   To check the number of received fields in the header, the following
   test may be used:

ヘッダーの容認された分野の数をチェックするために、以下のテストは使用されるかもしれません:

      header :count "ge" :comparator "i;ascii-numeric"
                      ["received"] ["3"]

ヘッダー:count"ge":comparator、「i;、ASCII数値、」 [「受信」]["3"]

   This would evaluate to false.  But

これは誤っているのに評価するでしょう。 しかし

      header :count "ge" :comparator "i;ascii-numeric"
                      ["received", "subject"] ["3"]

ヘッダー:count"ge":comparator、「i;、[「受け取られてい」て、「受けることがある」]のASCII数値["3"]

   would evaluate to true.

本当に評価するでしょう。

   The test:

テスト:

      header :count "ge" :comparator "i;ascii-numeric"
                      ["to", "cc"] ["3"]

ヘッダー:count"ge":comparator、「i;、」 ASCII数値の[“to"、「cc」]["3"]

   will always evaluate to false on an RFC 2822 compliant message
   [RFC2822], since a message can have at most one "to" field and at
   most one "cc" field.  This test counts the number of fields, not the
   number of addresses.

メッセージが1つの“to"分野と高々1つの「cc」分野しか最も攻撃できないので、いつもRFC2822対応することのメッセージ[RFC2822]で誤っているのに評価するでしょう。 このテストはアドレスの数ではなく、分野の数を数えます。

Segmuller & Leiba           Standards Track                     [Page 5]

RFC 5231              Sieve: Relational Extension           January 2008

Segmuller&Leiba規格はRFC5231ふるいを追跡します[5ページ]: 関係拡大2008年1月

7.  Extended Example

7. 拡張例

      require ["relational", "comparator-i;ascii-numeric", "fileinto"];

必要である、[「関係している」、「比較器i;、ASCII数値、」、"fileinto"]、。

      if header :value "lt" :comparator "i;ascii-numeric"
                ["x-priority"] ["3"]
      {
         fileinto "Priority";
      }

ヘッダー:value"lt":comparatorである、「i;、ASCII数値、」 [「x-優先権」]、[「3インチ]」fileinto「優先権」。

      elsif address :count "gt" :comparator "i;ascii-numeric"
                 ["to"] ["5"]
      {
         # everything with more than 5 recipients in the "to" field
         # is considered SPAM
         fileinto "SPAM";
      }

elsifアドレス:count"gt":comparator、「i、; 」 ASCII数値[“to"]、[「5インチ]」#5人以上の受取人が“to"分野#にあるすべてがスパムfileinto「スパム」であると考えられます。

      elsif address :value "gt" :all :comparator "i;ascii-casemap"
                 ["from"] ["M"]
      {
         fileinto "From N-Z";
      } else {
         fileinto "From A-M";
      }

elsifに、:value"gt":all:comparator「i; ASCIIでcasemapする」[“from"][「M」]を記述してください、「N-Z」からのfileinto;、ほか「A-M」からのfileinto。

      if allof ( address :count "eq" :comparator "i;ascii-numeric"
                         ["to", "cc"] ["1"] ,
                 address :all :comparator "i;ascii-casemap"
                         ["to", "cc"] ["me@foo.example.com"] )
      {
         fileinto "Only me";
      }

allofである、(:count"eq":comparatorを記述してください、「i;、」 ASCII数値の[“to"、「cc」]、[「1インチ]、:all:comparator「i; ASCIIでcasemapする」[“to"、「cc」][" me@foo.example.com ")を記述してください、」fileinto「唯一の私」。

8.  Changes since RFC 3431

8. RFC3431以来の変化

   Apart from several minor editorial/wording changes, the following
   list describes the notable changes to this specification since RFC
   3431.

数回の小さい方の社説/言葉遣い変化は別として、以下のリストはRFC3431以来のこの仕様に注目に値する変化を説明します。

   o  Updated references, including changing the comparator reference
      from the Application Configuration Access Protocol (ACAP) to the
      "Internet Application Protocol Collation Registry" document
      [RFC4790].

o Application Configuration Accessプロトコル(ACAP)から「インターネットアプリケーション・プロトコル照合登録」というドキュメント[RFC4790]までの比較器参照を変えるのを含む参照をアップデートしました。

   o  Updated and corrected the examples.

o 例をアップデートして、修正しました。

Segmuller & Leiba           Standards Track                     [Page 6]

RFC 5231              Sieve: Relational Extension           January 2008

Segmuller&Leiba規格はRFC5231ふるいを追跡します[6ページ]: 関係拡大2008年1月

   o  Added definition comments to ABNF for "gt", "lt", etc.

o "gt"、"lt"などのためのABNFへの加えられた定義コメント

   o  Clarified what RFC 2822 elements are counted in the COUNT test.

o どんなRFC2822要素がCOUNTテストで数えられるかをはっきりさせました。

   o  Removed the requirement to strip white space from header fields
      before comparing; a more general version of this requirement has
      been added to the Sieve base spec.

o 比較する前にヘッダーフィールドから余白を剥取るという要件を取り除きます。 この要件の、より一般的なバージョンはSieveベース仕様に加えられます。

9.  IANA Considerations

9. IANA問題

   The following template specifies the IANA registration of the
   relational Sieve extension specified in this document:

以下のテンプレートは本書では指定された関係Sieve拡張子のIANA登録を指定します:

   To: iana@iana.org
   Subject: Registration of new Sieve extension

To: iana@iana.org Subject: 新しいSieve拡張子の登録

   Capability name: relational
   Description:     Extends existing conditional tests in Sieve language
                    to allow relational operators
   RFC number:      RFC 5231
   Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>

能力名: 関係記述: 関係演算子RFC番号を許容するためにSieve言語における既存の条件付きのテストを広げています: RFC5231Contactアドレス: Sieve議論 list <ietf-mta-filters@imc.org 、gt。

10.  Security Considerations

10. セキュリティ問題

   An implementation MUST ensure that the test for envelope "to" only
   reflects the delivery to the current user.  Using this test, it MUST
   not be possible for a user to determine if this message was delivered
   to someone else.

実現は、封筒“to"のためのテストが現在のユーザに配送を反映するだけであるのを確実にしなければなりません。 このテストを使用して、ユーザが、このメッセージが他の誰かに送られたかどうかと決心しているのは、可能であるはずがありません。

   Additional security considerations are discussed in [Sieve].

[ふるい]で追加担保問題について議論します。

11.  Normative References

11. 引用規格

   [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。

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

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

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
              Application Protocol Collation Registry", RFC 4790,
              March 2007.

[RFC4790] ニューマンとC.とDuerst、M.とA.Gulbrandsen、「インターネットアプリケーション・プロトコル照合登録」、RFC4790、2007年3月。

   [Sieve]    Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", RFC 5228, January 2008.

エドグンサー、P.、[ふるい]T.ショウォーター、エド、「ふるい:」 「言語をフィルターにかけるメール」、RFC5228、2008年1月。

Segmuller & Leiba           Standards Track                     [Page 7]

RFC 5231              Sieve: Relational Extension           January 2008

Segmuller&Leiba規格はRFC5231ふるいを追跡します[7ページ]: 関係拡大2008年1月

Authors' Addresses

作者のアドレス

   Wolfgang Segmuller
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   US

ウォルフギャングSegmuller IBM T.J.ワトソン研究所19の地平線Driveニューヨーク10532ホーソーン(米国)

   Phone: +1 914 784 7408
   EMail: werewolf@us.ibm.com

以下に電話をしてください。 +1 7408年の914 784メール: werewolf@us.ibm.com

   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   US

バリーLeiba IBM T.J.ワトソン研究所19の地平線Driveニューヨーク10532ホーソーン(米国)

   Phone: +1 914 784 7941
   EMail: leiba@watson.ibm.com

以下に電話をしてください。 +1 7941年の914 784メール: leiba@watson.ibm.com

Segmuller & Leiba           Standards Track                     [Page 8]

RFC 5231              Sieve: Relational Extension           January 2008

Segmuller&Leiba規格はRFC5231ふるいを追跡します[8ページ]: 関係拡大2008年1月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

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

   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に情報を記述してください。

Segmuller & Leiba           Standards Track                     [Page 9]

Segmuller&Leiba標準化過程[9ページ]