RFC3421 日本語訳

Network Working Group                                            W. Zhao
Request for Comments: 3421                                H. Schulzrinne
Category: Experimental                               Columbia University
                                                              E. Guttman
                                                        Sun Microsystems
                                                            C. Bisdikian
                                                               W. Jerome
                                                                     IBM
                                                           November 2002

コメントを求めるワーキンググループW.チャオ要求をネットワークでつないでください: 3421時間Schulzrinneカテゴリ: 実験的なコロンビア大学のC.Bisdikian W.ジェロームIBM E.Guttmanサン・マイクロシステムズ2002年11月

   Select and Sort Extensions for the Service Location Protocol (SLP)

サービス位置のプロトコルのための拡大を選択して、分類してください。(SLP)

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document defines two extensions (Select and Sort) for the
   Service Location Protocol (SLP).  These extensions allow a User Agent
   (UA) to request that the Uniform Resource Locator (URL) entries in a
   Service Reply (SrvRply) be limited to the specified number, or be
   sorted according to the specified sort key list.  Using these two
   extensions together can facilitate discovering the best match, such
   as finding a service that has the maximum speed or the minimum load.

そして、このドキュメントが2つの拡大を定義する、(選ぶ、Sort) Service Locationプロトコル(SLP)のために。 これらの拡大で、Userエージェント(UA)は、Service Reply(SrvRply)のUniform Resource Locator(URL)エントリーが指定された数に制限されるか、または指定された分類用キーリストによると、分類されるよう要求できます。 これらの2つの拡張子を一緒に使用するのは、最も良いマッチを発見するのを容易にすることができます、最高回転数か最小負荷を持っているサービスを見つけるのなどように。

1. Introduction

1. 序論

   This document defines two extensions (Select and Sort) for SLP
   [RFC2608].  These extensions allow a UA to request that the URL
   entries in a SrvRply be limited to the specified number, or be sorted
   according to the specified sort key list.  A Directory Agent (DA) or
   Service Agent (SA) that supports the Select and/or Sort extensions
   MUST include the attribute keyword "select-enabled" and/or "sort-
   enabled" in its advertisement (DAAdvert or SAAdvert).  A UA SHOULD
   check these attributes of the contacting DA/SA before it uses the
   Select and/or Sort extensions to query the DA/SA.

そして、このドキュメントが2つの拡大を定義する、(選ぶ、Sort) SLP[RFC2608]のために。 これらの拡大で、UAは、SrvRplyのURLエントリーが指定された数に制限されるか、または指定された分類用キーリストによると、分類されるよう要求できます。 Select、そして/または、Sort拡張子をサポートするディレクトリエージェント(DA)かServiceエージェント(SA)が広告(DAAdvertかSAAdvert)で「選んで可能にされる」、そして/または、「可能にされた種類」という属性キーワードを入れなければなりません。 DA/SAについて質問するのにSelect、そして/または、Sort拡張子を使用する前にUA SHOULDは連絡しているDA/SAのこれらの属性をチェックします。

Zhao, et. al.                 Experimental                      [Page 1]

RFC 3421           Select and Sort Extensions for SLP      November 2002

etチャオ、アル。 実験的な[1ページ]RFC3421は2002年11月にSLPのために拡大を選択して、分類します。

   Using the Select extension, a UA can opt for finding just a few (not
   necessarily all) matching services, which is useful if the UA uses a
   low-bandwidth channel.  Using the Sort extension, a UA can ask the
   DA/SA to sort matching URL entries, which helps the UA to choose a
   service from multiple candidates.  Sorting by the server is more
   efficient than sorting by the client since for sorting purposes, the
   former does not need to pass the attributes of matching URLs to the
   client.  Furthermore, using the Select and Sort extensions together
   can facilitate discovering the best match, such as finding a service
   that has the maximum speed or the minimum load, or has a speed
   closest to a reference value.

Select拡張子を使用して、UAは、サービスに合いながらまさしくいくつかが(必ずすべてであるというわけではない)であることがわかるために選ぶことができます。(UAが低バンド幅チャンネルを使用するなら、それは、役に立ちます)。 Sort拡張子を使用して、UAはURLエントリーに合っている種類にDA/SAを招くことができます。(それは、UAが複数の候補からサービスを選ぶのを助けます)。 前者がソーティング目的のために合っているURLの属性をクライアントに渡す必要はないので、サーバによるソーティングはクライアントによるソーティングより効率的です。 その上、SelectとSort拡張子を一緒に使用するのは、最も良いマッチを発見するのを容易にすることができます、最高回転数か最小負荷を持っているか、または基準値の最も近くに速度を持っているサービスを見つけるのなどように。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted according to in BCP 14, RFC 2119
   [RFC2119].

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

2. Select Extension

2. 拡大を選択してください。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Select Extension ID = 0x4002  |  Next Extension Offset (NEO)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NEO, cont'd   |      Number of URL Entries    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension ID=0×4002を選択してください。| 次の拡大が相殺された、(新、)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO、contはそうするでしょう。| URLエントリーの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1. Select Extension

図1。 拡大を選択してください。

   The format of the Select extension is shown in Figure 1.  A UA uses
   this extension in a Service Request (SrvRqst) to limit the maximum
   number (say, n) of URL entries to be returned.  When a DA/SA receives
   a SrvRqst with a Select extension, it MUST use a Select extension in
   the corresponding SrvRply to indicate the total number (say, m) of
   matching URL entries if the DA/SA supports this extension, otherwise
   the DA/SA MUST set the error code in the corresponding SrvRply to
   OPTION_NOT_UNDERSTOOD [RFC2608].  If n < m, then only the first n
   matching URL entries are returned, else all m matching URL entries
   are returned.  As a special case, a UA may set n to zero to obtain
   the number of matching URL entries without retrieving the entries
   themselves.

Select拡張子の書式は図1に示されます。 UAは、返されるURLエントリーの最大数(たとえば、n)を制限するのにService Request(SrvRqst)でこの拡張子を使用します。 DA/SAがSelect拡張子があるSrvRqstを受けるとき、DA/SAがこの拡大を支持するなら、それは、合っているURLエントリーの総数(たとえば、m)を示すのに対応するSrvRplyでSelect拡張子を使用しなければなりません。さもなければ、DA/SA MUSTはOPTION_NOT_UNDERSTOOD[RFC2608]への対応するSrvRplyにエラーコードをはめ込みます。 次に、最初のn合っているURLエントリーだけをn<m返すなら、ほかに、すべてのm、合っているURLエントリーを返します。 特殊なものとして、UAはエントリー自体を検索しないで合っているURLエントリーの数を得るゼロにnを設定するかもしれません。

   We denote a Select extension as Select(number).  Thus, Select(3)
   means that the corresponding SrvRply can have at most three URL
   entries.

私たちはSelect(数)としてSelect拡張子を指示します。 したがって、Select(3)は、対応するSrvRplyがほとんどの3つのURLエントリーに攻撃できることを意味します。

Zhao, et. al.                 Experimental                      [Page 2]

RFC 3421           Select and Sort Extensions for SLP      November 2002

etチャオ、アル。 実験的な[2ページ]RFC3421は2002年11月にSLPのために拡大を選択して、分類します。

3. Sort Extension

3. 種類の拡大

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sort Extension ID = 0x4003   |  Next Extension Offset (NEO)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NEO, cont'd   |   length of <sort-key-list>   |<sort-key-list>\
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 種類の拡大ID=0x4003| 次の拡大が相殺された、(新、)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO、contはそうするでしょう。| <の種類の主要なリストの>の長さ|<種類の主要なリストの>\+++++++++++++++++++++++++++++++++

                         Figure 2. Sort Extension

図2。 種類の拡大

   The format of the Sort extension is shown in Figure 2.  A UA uses
   this extension in a SrvRqst to request the URL entries in the
   corresponding SrvRply be sorted according to the sort-key-list. The
   sort-key-list is defined using Augmented Backus-Naur Form (ABNF)
   [RFC2234] as follows:

Sort拡張子の書式は図2に示されます。 UAは、種類の重要リストによると、対応するSrvRplyのURLエントリーが分類されるよう要求するのにSrvRqstでこの拡張子を使用します。 種類の重要リストは以下のAugmented BN記法(ABNF)[RFC2234]を使用することで定義されます:

   sort-key-list  = sort-key / sort-key "," sort-key-list
   sort-key       = key-name ":" type ":" ordering [":" ref-value]
   key-name       = attr-tag from Section 5 of RFC 2608
   type           = "s" / "i"
                    ; "s" for string type
                    ; "i" for integer type
   ordering       = "+" / "-"
                    ; "+" for increasing order
                    ; "-" for decreasing order
   ref-value      = intval from Section 5 of RFC 2608

」 「種類の重要リスト=分類用キー/分類用キー」、種類の重要リスト分類用キー=キー名、」、:、」 「タイプしてください」:、」 RFC2608タイプのセクション5からの注文[「:」 審判値]主要な名前=attr-タグは「s」/「i」と等しいです。 ストリングタイプのための「s」。 整数型注文のための「i」は「+」/「-」と等しいです。 増加するための「+」は注文されます。 RFC2608のセクション5からオーダー審判価値=intvalを減少させるための「--」

   Each sort-key in the sort-key-list has a key-name, a type specifier,
   an ordering specifier, and an optional reference value.  The key-name
   MUST be a valid attribute name, and its type is explicitly specified.
   Although SLP has five attribute types (integer, string, boolean,
   opaque and keyword), we only consider integer sort and string sort
   since keyword attributes (they have no values) never need to be
   sorted, and boolean and opaque attributes can be sorted as strings if
   needed.  The integer sort uses the integerOrderingMatch rule defined
   in X.520 [X520], whereas the string sort is performed based on
   lexical ordering.  Strings are compared using the rules defined in
   Section 6.4 of RFC 2608.

種類の重要リストの各分類用キーには、主要な名前、型指定子、注文している特許説明書の作成書、および任意の基準値があります。 主要な名前は妥当な属性名であるに違いありません、そして、タイプは明らかに指定されます。 SLPには、5人の属性タイプ(整数、ストリング、論理演算子、不透明なもの、およびキーワード)がいますが、私たちは、キーワード属性(それらには、値が全くない)が、決して分類される必要がなくて、必要であるならストリングとして論理演算子と不透明な属性は分類できるので、整数種類とストリング・ソートを考えるだけです。 整数種類はX.520[X520]で定義されたintegerOrderingMatch規則を使用しますが、ストリング・ソートは語彙注文に基づいて実行されます。 ストリングは、RFC2608のセクション6.4で定義された規則を使用することで比較されます。

   Only integer keys may have a reference value, causing the sort to be
   based on the distance to the reference value.  A reference-based
   sort, such as "X:i:+:12", requires the following two steps:

整数キーだけには、基準値があるかもしれません、種類が基準値への距離に基づくことを引き起こして。 参照ベースの種類と、そのようなもの、「以下の2がX: i: +: 何12インチも、必要である、以下のステップ:、」

   Step 1. For each matching service, if its attribute X has a value of
           x, then use |x-12| as its metric.

1を踏んでください。 xの値、当時の使用が属性Xにあるならそれぞれサービスに合うように|x-12| それがメートル法であるので。

Zhao, et. al.                 Experimental                      [Page 3]

RFC 3421           Select and Sort Extensions for SLP      November 2002

etチャオ、アル。 実験的な[3ページ]RFC3421は2002年11月にSLPのために拡大を選択して、分類します。

   Step 2. Use the metrics obtained in Step 1 to sort attribute X
           for matching services.

2を踏んでください。 結婚相談所のために属性Xを分類するためにStep1で得られた測定基準を使用してください。

   The SLP sort rules are adapted from the Lightweight Directory Access
   Protocol (LDAP) sort rules defined in RFC 2891 [RFC2891].  Note that
   sort in SLP is a best effort, no sort error will be returned from a
   DA/SA to a UA.

SLP種類の規則はRFC2891[RFC2891]で定義されたライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)種類の規則から適合させられます。 SLPの種類がaベストエフォート型であるというメモ、種類の誤りは全くDA/SAからUAまで返されないでしょう。

   (1) The sort-key-list is in order of highest to lowest sort key
       precedence (Section 1.1 of RFC 2891).

(1) 種類の重要リストが最も低い分類用キー先行(RFC2891のセクション1.1)に最も高いことの順にあります。

   (2) Each attribute SHOULD only occur in the sort-key-list once
       (Section 1.1 of RFC 2891).  If an attribute is included in the
       sort-key-list multiple times, only its first occurrence is
       considered, all other occurrences are ignored.

(2) それぞれの属性SHOULDは種類の重要リストに一度(RFC2891のセクション1.1)起こるだけです。 属性が種類の重要リストに複数の回含まれているなら、最初の発生だけが考えられて、他のすべての発生が無視されます。

   (3) For a multi-valued attribute, the least value in each entry
       SHOULD be used in sort (Section 2.2 of RFC 2891).

マルチ評価された属性のための(3)、最少は中古のコネが種類(RFC2891のセクション2.2)であったなら各エントリーでSHOULDを評価します。

   (4) An entry missing one or more of the sort keys is treated as
       having NULLs for those missing keys (Section 2.2 of RFC 2891).

(4) 分類用キーの1つ以上を逃すエントリーはそれらのなくなったキー(RFC2891のセクション2.2)のためにNULLsを持っているとして扱われます。

   (5) NULL is considered as a larger value than all other valid
       values (Section 2.2 of RFC 2891).

(5) NULLは他のすべての有効値(RFC2891のセクション2.2)より大きい値であるとみなされます。

   (6) As the attribute type in SLP is not enforced, an attribute may
       have inconsistent values.  For the purpose of sorting,
       inconsistent values may exist only when an attribute is
       sorted as integer.  Inconsistent values SHOULD be treated as
       NULLs.

(6)SLPの属性タイプが励行されないとき、属性に、矛盾した値があるかもしれません。 属性が整数として分類されるときだけ、ソーティングの目的のために、矛盾した値は存在するかもしれません。 矛盾、NULLsとして扱われた状態でSHOULDを評価します。

   When a DA/SA receives a SrvRqst with a Sort extension, it MUST set
   the error code in the corresponding SrvRply to OPTION_NOT_UNDERSTOOD
   [RFC2608] if the DA/SA does not support the Sort extension or cannot
   perform the requested sort.  The DA/SA sets the error code in the
   corresponding SrvRply to zero if it has successfully processed the
   SrvRqst and performed the requested sort.

DA/SAがSort拡張子があるSrvRqstを受けるとき、DA/SAがSort拡張子をサポートしないことができませんし、要求された種類を実行できないなら、それは_UNDERSTOOD[RFC2608]ではなくOPTION_への対応するSrvRplyにエラーコードをはめ込まなければなりません。 それが首尾よくSrvRqstを処理して、要求された種類を実行したなら、DA/SAは対応するSrvRplyのエラーコードをゼロに設定します。

   We denote a Sort extension as Sort(sort-key-list).  The following
   examples illustrate how to use the Sort extension.

私たちはSort(種類の重要リスト)としてSort拡張子を指示します。 以下の例はSort拡張子を使用する方法を例証します。

   o Integer sort on speed (decreasing order).

o 速度(減少しているオーダー)の整数種類。

        Sort(speed:i:-)

種類(速度: i(^o^)

     [Note] "i" means integer sort, and "-" means decreasing order.

[注意]「i」は整数種類を意味します、そして、「-」はオーダーを減少させることを意味します。

Zhao, et. al.                 Experimental                      [Page 4]

RFC 3421           Select and Sort Extensions for SLP      November 2002

etチャオ、アル。 実験的な[4ページ]RFC3421は2002年11月にSLPのために拡大を選択して、分類します。

   o Integer sort on load (increasing order) and speed (decreasing
     order).

o 負荷(増加するオーダー)と速度(減少しているオーダー)の整数種類。

        Sort(load:i:+,speed:i:-)

種類(速度: 負荷:i:+、i(^o^)

     [Note] "+" means increasing order.

[注意します] 「+」 オーダーを増加させる手段。

   o String sort on model (increasing order).

o モデル(増加するオーダー)の種類を結んでください。

        Sort(model:s:+)

種類(モデル: s: +)

     [Note] "s" means string sort.

[注意]「s」はストリング・ソートを意味します。

   o Integer sort on speed (increasing order), based on a reference
     value 12.

o 基準値12に基づいた速度(増加するオーダー)の整数種類。

        Sort(speed:i:+:12)

種類(速度: i: +: 12)

     [Note] For example, if we have four matching services, with the
     "speed" attribute as 8 (URL1), 10 (URL2), 12 (URL3), and 15 (URL4),
     then the sorted URL list will be "URL3,URL2,URL4,URL1" (based on
     the metric ordering of |12-12| < |12-10| < |12-15| < |12-8|).

[注意します] 例えば、私たちに4つの結婚相談所があると、8(URL1)としての「速度」属性で、10(URL2)、12(URL3)、および15(URL4)、当時の分類されたURLリストは「URL3、URL2、URL4、URL1"(| 12-12|<|12-10|<|12-15|<|12-8のメートル法の注文に基づいています|)」でしょう。

4. Using the Select and Sort Extensions Together

4. 選ぶのと種類の拡張子を一緒に使用します。

   In addition to being used individually, the Select and Sort
   extensions can be used together to facilitate discovering the best
   match, such as finding a service with the maximum speed.  When these
   two extensions appear in the same SrvRqst message, they MUST be
   processed in the order of their presence.  We show some examples
   next.

個別に使用されることに加えて、最も良いマッチを発見するのを容易にするのにSelectとSort拡張子を一緒に使用できます、最高回転数でサービスを見つけるのなどように。 これらの2つの拡大が同じSrvRqstメッセージに現れるとき、それらの存在の注文でそれらを処理しなければなりません。 私たちは次に、いくつかの例を示しています。

   o Find the service with the minimum load

o 最小負荷でサービスを見つけてください。

        Sort(load:i:+)
        Select(1)

種類(負荷: i: +)の選びます。(1)

   o Find the three fastest services

o 3つの最も速いサービスを見つけてください。

        Sort(speed:i:-)
        Select(3)

種類、(速度: i(^o^)、選ぶ。(3)

   o Find the service with the minimum load among the three fastest

o 3つの中に最小負荷がある状態で、最も速くサービスを見つけてください。

        Sort(speed:i:-)
        Select(3)
        Sort(load:i:+)
        Select(1)

種類、(速度: i(^o^) 選んだ(3)種類(負荷: i: +)は選択します。(1)

Zhao, et. al.                 Experimental                      [Page 5]

RFC 3421           Select and Sort Extensions for SLP      November 2002

etチャオ、アル。 実験的な[5ページ]RFC3421は2002年11月にSLPのために拡大を選択して、分類します。

   o Find the service that has a speed closest to 12

o 12の最も近くに速度を持っているサービスを見つけてください。

        Sort(speed:i:+:12)
        Select(1)

(速度: i: +: 12)が選択する種類(1)

5. IANA Considerations

5. IANA問題

   The Select and Sort extension IDs, 0x4002 and 0x4003, described in
   Section 2 and Section 3, respectively, have been assigned by IANA out
   of the SLP extension space (RFC 2608, Section 9.1) reserved for
   "mandatory to implement" extensions (i.e., the 0x4000-0x7FFF range).

拡大ID、0×4002、および0×4003がセクション2とセクション3でそれぞれ説明したSelectとSortはIANAによって「実行するために義務的」拡大(すなわち、0×4000 0x7FFFの範囲)のために予約されたSLP拡大スペース(RFC2608、セクション9.1)から割り当てられました。

6. Security Considerations

6. セキュリティ問題

   There are no new security issues beyond those described in RFC 2608.

どんな新しい安全保障問題もRFC2608で説明されたものを超えていません。

7. Acknowledgments

7. 承認

   Ira McDonald provided good suggestions.

イラ・マクドナルドは良い提案を提供しました。

8. Normative References

8. 引用規格

   [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
             Location Protocol, Version 2", RFC 2608, June 1999.

[RFC2608]Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。

   [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
             requirement levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

9. Non-normative References

9. 非引用規格

   [X520]    International Telephone Union, "The Directory: Selected
             Attribute Types", X.520, 1997.

国際[X520]が組合に電話をする、「ディレクトリ:」 「選択された属性タイプ」、X.520、1997。

   [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 2234, November 1997.

[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [RFC2891] Howes, T., Wahl, M. and A. Anantha, "LDAP Control Extension
             for Server Side Sorting of Search Results", RFC 2891,
             August 2000.

[RFC2891] ハウズ、T.、ウォール、M.、およびA.Anantha、「検索のサーバサイドソーティングのためのLDAPコントロール拡張子は結果として生じます」、RFC2891、2000年8月。

Zhao, et. al.                 Experimental                      [Page 6]

RFC 3421           Select and Sort Extensions for SLP      November 2002

etチャオ、アル。 実験的な[6ページ]RFC3421は2002年11月にSLPのために拡大を選択して、分類します。

10. Authors' Addresses

10. 作者のアドレス

   Weibin Zhao
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027-7003

Weibinチャオコンピュータサイエンス学部Columbia University1214アムステルダムアベニュー、ニューヨーク、ニューヨークのM.C.0401 10027-7003

   EMail: zwb@cs.columbia.edu

メール: zwb@cs.columbia.edu

   Henning Schulzrinne
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027-7003

ヘニングSchulzrinneコンピュータサイエンス学部Columbia University1214アムステルダムアベニュー、ニューヨーク、ニューヨークのM.C.0401 10027-7003

   EMail: hgs@cs.columbia.edu

メール: hgs@cs.columbia.edu

   Erik Guttman
   Sun Microsystems
   Eichhoelzelstr. 7
   74915 Waibstadt
   Germany

エリックGuttmanサン・マイクロシステムズEichhoelzelstr。 7 74915Waibstadtドイツ

   EMail: Erik.Guttman@sun.com

メール: Erik.Guttman@sun.com

   Chatschik Bisdikian
   IBM Corp.
   Thomas J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY 10532, USA

ニューヨーク 10532、Chatschik Bisdikian IBM社のトーマスJワトソンリサーチセンター19地平線Driveホーソーン(米国)

   EMail: bisdik@us.ibm.com

メール: bisdik@us.ibm.com

   William F. Jerome
   IBM Corp.
   Thomas J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY 10532, USA

ニューヨーク 10532、ウィリアムF.ジェロームIBM社のトーマスJワトソンリサーチセンター19地平線Driveホーソーン(米国)

   EMail: wfj@us.ibm.com

メール: wfj@us.ibm.com

Zhao, et. al.                 Experimental                      [Page 7]

RFC 3421           Select and Sort Extensions for SLP      November 2002

etチャオ、アル。 実験的な[7ページ]RFC3421は2002年11月にSLPのために拡大を選択して、分類します。

11. Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

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

Zhao, et. al.                 Experimental                      [Page 8]

etチャオ、アル。 実験的[8ページ]