Network Working Group J. Kempf
Request for Comments: 3082 J. Goldschmidt
Category: Experimental Sun Microsystems
March 2001
Notification and Subscription for SLP
Status of this 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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling.
サービスロケーションプロトコル（SLP）サービス・エージェント・クライアントが広告を掲載することができ、ユーザー・エージェント・クライアントがサービスを照会できる仕組みを提供します。彼らは特にそれを求める際に、ユーザーエージェントは唯一のサービス情報を取得するように設計は、非常に多くの需要主導型です。新しいサービスが現れたり消えたときに通知を必要とする、しかし、ユーザエージェントアプリケーションの別のクラスが存在します。 RFC 2608の設計では、これらのアプリケーションは、変更をキャッチするためにネットワークをポーリングすることを余儀なくされています。この文書では、我々は、変更が発生したときに、そのようなクライアントに通知することができるように、ポーリングの必要性を除去するためのプロトコルを記述します。
The Service Location Protocol (SLP) [1] provides a mechanism for service agent (SA) clients to advertise network services and for user agent (UA) clients to find them. The mechanism is demand-driven. UAs obtain service information by actively querying for it, and do not obtain any information unless they do so. While this design satisfies the requirements for most applications, there are some applications that require more timely information about the appearance or disappearance in the services of interest.
サービスロケーションプロトコル（SLP）は、[1]ネットワークサービスを宣伝するためのサービス・エージェント（SA）クライアント用とユーザーエージェント（UA）、クライアントがそれらを見つけるためのメカニズムを提供します。メカニズムは、需要主導型です。 UAは積極的にそれを照会することによって、サービス情報を取得し、彼らはそうしない限り、任意の情報を得ることはありません。この設計は、ほとんどのアプリケーションの要件を満たしながら、興味のあるサービスで出現または消失についてのよりタイムリーな情報を必要とするいくつかのアプリケーションがあります。
Ideally, these applications would like to be notified when a new service comes up or when a service disappears. In order to obtain this information with SLP as described in RFC 2608, such applications must poll the network to periodically refresh their local cache of available service advertisements.
理想的には、これらのアプリケーションは、新しいサービスが起動したときやサービスが消えたときに通知されるようにしたいと思います。 RFC 2608で説明したようにSLPで、この情報を得るためには、そのようなアプリケーションは、定期的に利用可能なサービスの広告を自分のローカルキャッシュをリフレッシュするためにネットワークをポーリングしなければなりません。
An example of such a client is a desktop GUI that wants to display network service icons as soon as they appear to provide users with an accurate picture of all services available to them.
そのようなクライアントの例では、すぐに彼らはそれらに利用可能な全てのサービスの正確な画像をユーザーに提供するために表示されるように、ネットワークサービスのアイコンを表示したいデスクトップGUIです。
Because polling is inefficient and wasteful of network and processor resources, we would like to provide these applications a mechanism whereby they can be explicitly notified of changes. In this document, we describe a scalable mechanism allowing UAs to be notified of changes in service availability.
ポーリングが非効率的なネットワークおよびプロセッサ資源の無駄であるので、我々はこれらのアプリケーションには、明示的に変更を通知することができる仕組みを提供したいと思います。この文書では、我々は、UAがサービスの可用性の変更を通知することができるスケーラブルなメカニズムを説明します。
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 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
In this section, we present some additional terminology beyond that in [1] and [3].
このセクションでは、我々はそれを超えていくつかの追加用語を提示する[1]と[3]。
Notification - A message sent to an interested agent informing that agent that a service has appeared or disappeared.
通知 - サービスが登場したり消えてしまったそのエージェントを知らせる興味がエージェントに送信されるメッセージ。
Subscription - A request to be informed about changes in service availability for a particular service type and scopes.
サブスクリ - 特定のサービスの種類とスコープのためのサービスの可用性の変更について通知される要求。
The primary design consideration in a notification protocol for SLP is that we would like it to exhibit the same high degree of scalability and robustness that the base SLP protocol exhibits. Notification should work in small networks with only a few SAs, as well as large enterprise networks with thousands of SAs and hundreds of DAs. Small networks should not be required to deploy DAs in order to receive the benefits of notification. We also want to assure that notification in large networks does not cause heavy processing loads to fall on any one particular SLP agent. This requires that the task of notification be distributed rather than centralized, to avoid loading down one agent with doing all the notification work. Finally, we would like the notification scheme to be robust in the face of DA failures, just as the base SLP design is.
SLPのための通知プロトコルにおける主要な設計上の考慮事項は、我々はそれがベースSLPプロトコル展示その拡張性と堅牢性の同じ高度を発揮したいということです。通知は、SASおよびDASの何百何千もの持つ唯一のSAの数だけでなく、大規模な企業ネットワークと小規模ネットワークで動作するはずです。小規模ネットワークは、通知の給付を受けるためにDAを展開するために必要とするべきではありません。また、重い処理負荷がいずれか1つの特定のSLPエージェントに落ちることはありません大規模なネットワークではその通知を保証します。これは、すべての通知の仕事をしてて1つのエージェントをダウンロードを避けるために、通知のタスクはむしろ、集中よりも分散されている必要があります。最後に、我々は基本SLPのデザインがあるのと同様に、通知方式はDAの障害に直面して堅牢になりたいです。
An important consideration is that the UA clients obtain notifications of SA events in a timely fashion. If a UA has subscribed to notification for a particular service type, the UA should receive such notification regardless of the state of intervening DAs. SLP is transparent with respect to DAs supporting a particular scope; that is, a UA can use any DA with a particular scope and expect to get the same service advertisements. Notifications should exhibit the same property. Whether or not a UA receives a notification should not depend on the DA to which they happen to connect. This preserves the DAs' identity as a pure cache.
重要な考慮事項は、UAクライアントがタイムリーにSAイベントの通知を求めることです。 UAは、特定のサービスタイプの通知に加入している場合、UAは、介在たDAの状態にかかわらず、このような通知を受け取る必要があります。 SLPは、特定の範囲を支持するのDAに対して透明です。つまり、UAが特定の範囲で任意のDAを使用し、同じサービスの広告を得ることを期待することができます。通知は同じ性質を示すべきです。 UAは、通知を受けたかどうかは、彼らが接続するために起こるためにDAに依存してはいけません。これは、純粋なキャッシュとしてDAのアイデンティティを保持します。
Another goal is that the notification messages contain enough information about the triggering event that the UA can determine whether or not it is of interest in the large majority of cases without having to issue another SLP request a priori. The UA may, of course, issue an SLP request for related reasons, but it should not have to issue a request to obtain more information on the event that triggered the notification in most cases. This reduces the amount of network traffic related to the event.
もう一つの目標は、通知メッセージは、UAが、それは別のSLP要求先験的を発行することなく、例の大多数に関心のあるかどうかを判断することができるトリガ・イベントに関する十分な情報が含まれていることです。 UAは、当然のことながら、関連する理由のためにSLP要求を発行することができるが、それはほとんどの場合、通知をトリガしたイベントの詳細情報を取得するための要求を発行する必要はありません。これは、イベントに関連するネットワークトラフィックの量を減らすことができます。
In order to simplify implementation, we would like to use similar mechanisms for notification in large and small networks. The mechanisms are not identical, obviously, but we want to avoid having radically different mechanisms that require completely separate implementations. Having similar mechanisms reduces the amount of code in UA and SA clients.
実装を簡素化するために、我々は大規模および小規模ネットワークでの通知のための同様のメカニズムを使用したいと思います。メカニズムは明らかに、同一ではないが、我々は完全に別の実装を必要と根本的に異なるメカニズムを持つ避けたいです。同様の機構を持つことは、UAとSAクライアントのコードの量を減らすことができます。
A minor goal is to make use of existing SLP message types and mechanisms wherever possible. This reduces the amount of code necessary to implement the notification mechanism, because much code can be reused between the base SLP and the notification mechanism. In particular, we expect to make use of the SLP extension mechanism in certain cases to support subscription.
マイナーな目標は、可能な限り既存のSLPのメッセージタイプとメカニズムを利用することです。多くのコードがベースSLPと通知機構との間に再利用することができるので、これは、通知メカニズムを実装するために必要なコードの量を減少させます。特に、我々は、サブスクリプションをサポートするために、特定のケースではSLPの拡張メカニズムを利用することを期待しています。
In order to support scalability, we split the design into two parts. A small network design is used when no DAs are present in the network. A large network design is used in networks with DAs. The following subsections describe the two designs.
スケーラビリティをサポートするために、我々は二つの部分にデザインを分割します。何のDASはネットワーク内に存在しないとき、小規模なネットワーク設計が使用されています。大規模なネットワーク設計は、DASとネットワークで使用されています。以下のサブセクションでは、2つの設計について説明します。
In networks without DAs, UAs are notified by an SA when the SA initially appears, and when the SA disappears. This allows UAs to know about the list of service types the SA supports. In small networks, there is no centralized agent available to administer subscriptions for newly appearing SAs. This rules out any kind of subscription design in which a UA subscribes to notifications for a particular service type in particular scopes of interest, because a newly appearing SA can't tell whether or not there are any subscriptions without a centralizing agent to tell it.
DAをせずにネットワークでは、ユーザーエージェントは、SAが最初に表示されたときにSAで通知、およびSAが消えたときにされています。これは、UAがSAをサポートするサービスの種類のリストについて知ることができます。小規模なネットワークでは、新規にSAを登場のサブスクリプションを管理するために利用可能な中央集中型のエージェントはありません。これは、新たに出現したSAは、それを伝えるために一元化剤を含まない任意のサブスクリプションがあるかどうかを伝えることができないので、UAは、関心のある特定のスコープ内の特定のサービスタイプの通知をサブスクライブするサブスクリプションのデザインのいずれかの種類を除外する。
As a result, SAs perform notification when they come on line and prior to shutting down regardless of their scope or service type, if they are capable of performing notification. This means that a UA receives notification of all types of changes for all scopes and service types, and consequently must be prepared to filter out those changes in which it is not interested (other scopes, other service types).
彼らはライン上で前にかかわらず、その範囲またはサービスタイプのシャットダウンに来るときに通知を行うことが可能である場合、結果として、SAは、通知を行います。これは、UAはすべてのスコープとサービスタイプの変更のすべてのタイプの通知を受け、その結果、それらが興味を持っていないである変更（他のスコープ、他のサービスタイプ）を除外するために用意されなければならないことを意味します。
The design requires SAs to perform notification by IP multicasting (or broadcasting in IPv4 if multicast is not available) SLP SrvReg or SrvDereg messages using the multicast transmit algorithm described in Section 9.0. The port number for notifications is not the default SLP port, because that port is only accessible to privileged users on some operating systems, but rather the port 1847, as assigned by IANA.
設計は、セクション9.0で説明したマルチキャスト送信アルゴリズムを使用して、（マルチキャストが利用できない場合、またはIPv4の放送）、IPマルチキャストにより通知を行うためにSLPのSrvRegまたはSrvDeregメッセージをSAを必要とします。通知のポート番号は、そのポートは、いくつかのオペレーティングシステム上の特権ユーザーにのみアクセス可能ですので、デフォルトのSLPポートではなく、IANAによって割り当てられているように、ポート1847、。
In IPv4, the SA performs multicast on the SLP multicast address (239.255.255.253, default TTL 255) and is administratively scoped in the same manner as SLP [4]. IPv4 UAs interested in notification join the multicast group 239.255.255.253 and listen on port 1847. In IPv6, the multicast is performed to the scoped IPv6 addresses for the service type advertised, as described in [8]. The SA advertises on all addresses up to and including the largest multicast scope that it supports. IPv6 UAs interested in notification join the multicast groups corresponding to the multicast scopes and service type in which they are interested and listen on port 1847. For example, an IPv6 UA that has access to site local scope and is interested in a service type whose hash is 42, calculated according to the algorithm in [8], joins the groups FF01:0:0:0:0:0:10042 through FF05:0:0:0:0:0:10042.
IPv4では、SAはSLPマルチキャストアドレス上でマルチキャスト（239.255.255.253、デフォルトTTL 255）を実行し、管理SLPと同様にスコープされている[4]。通知に興味のIPv4 UAはマルチキャストグループ239.255.255.253に参加するとIPv6のポート1847をリッスン、[8]に記載されているように、マルチキャストは、アドバタイズされたサービス・タイプのスコープのIPv6アドレスに行われます。 SAは、それがサポートする最大のマルチキャストスコープを含むすべてのまでのアドレスとにアドバタイズします。通知に興味を持ったIPv6 UAは、彼らが興味を持っている。例えば、ポート1847をリッスンするマルチキャストスコープとサービスタイプに対応するマルチキャストグループに参加し、サイトローカルスコープにアクセスし、そのハッシュサービスタイプに興味があるIPv6のUA [8]、グループに参加中のアルゴリズムに従って計算、42であるFF01：0：0：0：0：0：0：0：0：10042 0：0：FF05を介して10042。
In networks with DAs, a DA supporting a particular scope can act as an intermediary for administering UA subscriptions. A subscription consists of a service type and a collection of scopes. A UA interested in being notified about changes in a particular service type attaches the Subscribe extension to a SrvRqst message sent to the DA. The DA obtains multicast group addresses for notification based on the algorithm described in Section 8.0 and puts them into a NotifyAt extension which it attaches to the SrvRply. The UA listens on the group addresses in the reply for notifications.
DASとネットワークでは、特定の範囲を支持するDAは、UAサブスクリプションを管理するための媒体として作用することができます。サブスクリプションは、サービスの種類とスコープの集まりで構成されています。特定のサービスタイプの変更について通知されることに興味UAはDAに送信SrvRqstメッセージを購読拡張を取り付けます。 DAは、セクション8.0で説明したアルゴリズムに基づいて、通知のためのマルチキャストグループアドレスを取得し、それがSrvRplyに取り付けるNotifyAt拡張子にそれらを置きます。 UAは、通知の返信にグループアドレスをリッスンします。
When a new subscription comes in, existing SAs are informed about the subscription using the following procedure. The DA compares the service type and scopes in the new subscription against a list of existing subscriptions. If no previous subscription has the same service type and scopes, the DA MUST multicast a DAAdvert, using the multicast transmit algorithm described in Section 9.0, and MUST include the NotifyAt extension with the multicast group addresses for notification. If an existing subscription covers the same service type and scopes as the new subscription, the DA MUST NOT multicast a DAAdvert.
新しいサブスクリプションが入ってくるときに、既存のSAは、以下の手順を使用してサブスクリプションについて通知されています。 DAは、既存のサブスクリプションのリストに対して、新しいサブスクリプションにサービスタイプとスコープを比較します。以前のサブスクリプションは、同じサービスタイプとスコープを持っていない場合、DAは、セクション9.0で説明したマルチキャスト送信アルゴリズムを使用して、DAAdvertをマルチキャストしなければならない、および通知のためのマルチキャストグループアドレスとNotifyAt拡張を含まなければなりません。既存のサブスクリプションは、新しいサブスクリプションと同じサービスの種類と範囲をカバーする場合、DAはDAAdvertをマルチキャストしてはなりません。
A DA MUST keep track of subscriptions it has arranged as well as subscriptions arranged by other DAs in any scopes with which the DA is configured. To avoid multiple multicast NotifyAt messages, a DA MUST wait a random amount of time, uniformly distributed between 0 and 3 seconds before sending the multicast DAAdvert with NotifyAt. During this period, the DA MUST listen for NotifyAt messages that match the one from the new subscription. If a matching NotifyAt is detected, the DA MUST not multicast.
DAは、DAが構成されている任意のスコープ内の他のDAによって配置サブスクリプションと同様に配置されたサブスクリプションを追跡しなければなりません。メッセージNotifyAt複数のマルチキャストを避けるために、DAはNotifyAtでマルチキャストDAAdvertを送信する前に、均一に0と3秒の間に分布し、時間のランダムな量を、待たなければなりません。この期間中、DAは、新しいサブスクリプションのいずれかと一致NotifyAtメッセージをリッスンする必要があります。マッチングNotifyAtが検出された場合、DAは、マルチキャストはいけません。
When a new SA registers with a DA that has existing subscriptions, the new SA is informed of notifications it should perform using the following procedure. If the service type and scopes in the new SA's SrvReg messages match an existing subscription, a NotifyAt containing the multicast addresses for notification MUST be included in the SrvAck. If the SA doesn't support notification, it simply ignores the extension. If the service type and scopes in the new SA's SrvReg do not match any existing subscriptions, the DA MUST NOT include a NotifyAt.
新しいSAは、既存のサブスクリプションを持っているDAに登録すると、新しいSAは、次の手順を使用して実行する必要があり、通知が通知されます。新しいSAののSrvRegメッセージ内のサービスの種類とスコープは、既存のサブスクリプションと一致した場合は、通知のためのマルチキャストアドレスを含むNotifyAtはSrvAckに含めなければなりません。 SAは通知をサポートしていない場合、それは単に拡張子を無視します。新しいSAののSrvRegでのサービスの種類とスコープは、既存のサブスクリプションと一致しない場合、DAはNotifyAtを含んではいけません。
The DA itself MUST also perform notification, according to the multicast transmit algorithm, when a service advertisement times out. Time-out of a service advertisement results in the DA multicasting a SrvDereg for the deregistered URL. This allows interested UAs to be informed of the service advertisement's demise even if the SA has disappeared without deregistering. A DA MUST NOT perform notification when it receives a SrvReg from an SA, however, that is the job of the SA.
DA自体は、マルチキャスト送信アルゴリズム、サービス広告がタイムアウトに応じて、通知を実行しなければなりません。登録解除URLのためSrvDeregをマルチキャストDAにおけるサービスの広告結果のタイムアウト。これは、SAは登録解除せずに消えてしまった場合にも興味を持ってUAがサービス広告の終焉を知らせることができるようになります。それはSAからのSrvRegを受信したときにDAが通知を行うてはならない、しかし、それはSAの仕事です。
As in small networks, notification is performed primarily by SAs. If an SA receives a DAAdvert or SrvAck with a NotifyAt extension and the following conditions are met:
小規模なネットワークのように、通知は、SASによって主に行われます。 SAはNotifyAt拡張子のDAAdvertまたはSrvAckを受信している場合、以下の条件が満たされています：
2. The SA's service type matches the service type in the NotifyAt extension.
2. SAのサービスタイプがNotifyAt拡張のサービスタイプと一致します。
3. The SA's scopes match one of the scopes of the NotifyAt extension.
3. SAのスコープがNotifyAt拡張子のスコープのいずれかに一致します。
then the SA saves the multicast addresses that correspond to the scopes and service types it supports. The SA MUST perform notification immediately after the SA has performed the SrvReg or SrvDereg with the DA. An SA that has detected a DA in its scopes MUST NOT multicast any notifications unless it receives a NotifyAt extension in a SrvAck with service type and scopes matching the SA's service type and scopes.
その後、SAは、それがサポートするスコープとサービスタイプに対応したマルチキャストアドレスが保存されます。 SAは、SAはDAとのSrvRegまたはSrvDeregを行った直後に通知を行う必要があります。それはサービスタイプとSAのサービスの種類とスコープに一致するスコープとSrvAckにNotifyAt拡張子を受けない限り、そのスコープでDAを検出したSAは、任意の通知をマルチキャストしてはなりません。
The Subscribe extension has the following format:
購読拡張子の形式は次のとおりです。
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 Type = 0x0004 | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ex. Len. (ct) | Abs. Type Fl. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The scope list and service type of the extension are taken from the accompanying SrvRqst. The abstract type flag indicates whether the UA is interested in hearing from all SAs advertising concrete instances of an abstract type [3], and is only of interest if the service type in the SrvRqst is a concrete type. If the flag is 1, the UA is interested in hearing from all SAs advertising concrete types having the same abstract type as the type of the SrvRqst. If the flag is 0, the UA is only interested in hearing from SAs supporting the particular concrete type in the SrvRqst. If the service type in the accompanying SrvRqst is not a concrete type, the flag is ignored.
延長の範囲リストやサービスの種類は、添付のSrvRqstから取得されます。抽象タイプフラグはUAがすべてのSAS広告から抽象型[3]の具体的な事例を聞くことに興味があり、そしてSrvRqstにおけるサービスタイプが具象型である場合にのみ関心があるかどうかを示します。フラグが1の場合、UAはすべてのSA広告からSrvRqstの型と同じ抽象型を有する具体的な種類を聞くことに興味があります。フラグが0である場合、UAはSrvRqstの特定コンクリートタイプをサポートするのSAから聴覚にのみ関心があります。添付SrvRqstでのサービスタイプは、具体的なタイプではない場合、フラグは無視されます。
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 Type = 0x0005 | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext. Len (ct) | Subscription Lifetime |SGL List Len. \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SGL L. Len (ct)| Scope/Group List \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Service Type Name | Service Type Name \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service type name is in the same format as in the SrvRqst. The scope/group list is a list of scope names and multicast group addresses. The following ABNF [5] syntax describes the list:
サービスタイプ名はSrvRqstと同じ形式です。スコープ/グループリストは、スコープ名およびマルチキャストグループアドレスのリストです。以下のABNFは、[5]の構文は、リストについて説明します。
sglist = sgitem / sgitem "," sglist
sgitem = scope-name ":" ip-addr
ip-addr = ipv4-number | ipv6-number
scope-name = ; See RFC 2608 for the format of scope names.
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
ipv6-number = ;See RFC 2373 [9] Section 2.2
An example of a scope/group list for IPv4 is:
IPv4のスコープ/グループリストの一例です。
eng:239.255.255.42,corp:239.255.255.43
ENG：239.255.255.42、CORP：239.255.255.43
An example of a scope/group listfor IPv6 is:
IPv6のlistforスコープ/グループの例を示します。
eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042
ENG：FF02：0：0：0：0：0：1：1042 CORP：FF03：0：0：0：0：0：1：1042
The scope/group list gives the multicast addresses to use for notifications involving the service type for the given scopes.
スコープ/グループリストは、特定のスコープのサービスタイプを含む通知するために使用するマルチキャストアドレスを提供します。
The service type name can be a simple type name, an abstract type name, or a concrete type name. If the name is an abstract type name, all SAs advertising the abstract type MUST notify. If the name is a concrete or simple type name, ONLY those SAs advertising the simple or concrete type MUST notify, others MUST NOT notify. A DA that receives a subscription for a concrete type with the abstract type flag set, MUST include the abstract type name in all the NotifyAt messages it sends. If the DA receives a subscription for a concrete type with the abstract type flag not set, the DA MUST NOT include the abstract type, but rather MUST include the concrete type name.
サービスタイプ名は、単純型名、抽象型名、または具体的なタイプの名前にすることができます。名前は抽象型の名前である場合は、抽象型を広告するすべてのSAを通知しなければなりません。名前は、コンクリートや単純型の名前である場合は、単純または具体的なタイプの広告を出しのみのSAは、他の人が通知してはならない、通知しなければなりません。抽象型フラグを設定して、具体的なタイプのサブスクリプションを受け取るDAは、それが送信するすべてのNotifyAtメッセージに抽象タイプ名を含まなければなりません。 DAは抽象型フラグ設定されていないとの具体的な種類のサブスクリプションを受信した場合、DAは抽象型を含めることはできませんが、むしろ、具体的なタイプ名を含まなければなりません。
There are three cases in which an agent may receive a NotifyAt extension: in a SrvRply returned to a UA, in a multicast DAAdvert, and in a SrvAck returned to an SA. The three subsections below describe the response in each of these cases.
エージェントがNotifyAt拡張を受ける可能性のある3つのケースがあります。SrvRplyにマルチキャストDAAdvertに、UAに戻り、SrvAckにSAに戻りました。次の3つのサブセクションでは、これらの各場合における応答を記述する。
When a UA sends a SrvRqst with a Subscribe extension, the DA responds with a SrvRply including a NotifyAt. The DA MUST NOT unicast a NotifyAt to a UA with any other message and MUST NOT send a NotifyAt unless a SrvRqst with a Subscribe extension was received.
UAが購読拡張子を持つSrvRqstを送信すると、DAはNotifyAt含むSrvRplyで応答します。 DAは、他のメッセージでUAにNotifyAtをユニキャストしてはいけませんと購読拡張子を持つSrvRqstが受信された場合を除きNotifyAtを送ってはいけません。
The UA responds by setting up a multicast listener to the group addresses included in the extension on the SLP notification port 1847. The UA MAY also want to note the expiration lifetime of the subscription assigned by the DA, and reissue a subscription before the lifetime expires.
UAはSLP通知ポート1847上の拡張UAに含まれるグループアドレスにマルチキャストリスナーを設定することで応答も寿命が切れる前にDAによって割り当てられたサブスクリプションの有効期限の寿命を注意して、サブスクリプションを再発行することもできます。
The DA multicasts a NotifyAt with a DAAdvert using the multicast transmit algorithm when a UA has requested notification and the scopes and service type in the subscription were not previously seen. This message informs existing SAs having the service type and scopes in the announcement that they should multicast notifications when they shut down.
DAマルチキャストUAが通知を要求しているサブスクリプションでのスコープとサービスタイプは、以前には見られなかったとき、マルチキャスト送信アルゴリズムを使用してDAAdvertとNotifyAt。このメッセージは、既存のSAは、彼らがシャットダウンしたときに、彼らは通知をマルチキャストすべきであることを発表してサービスの種類とスコープを持つ知らせます。
A receiving SA participating in notification responds by noting the multicast address if the service type and scopes match. When the SA is about to go down, the SA MUST first unicast a SrvDereg without attribute tag list to its DAs (as per standard SLP), then it MUST multicast the same SrvDereg message according to the multicast transmit algorithm. The SA MUST cease performing notification when the subscription lifetime expires, unless a subsequent NotifyAt is received prolonging the subscription.
通知に参加する受信SAは、サービスの種類とスコープが一致した場合、マルチキャストアドレスに注目することによって応答します。 SAがダウンしようとするとき、SAは、第一（標準SLPごとなど）、そのDAをする属性タグリストなしSrvDeregをユニキャストしなければならない、それはマルチキャスト送信アルゴリズムに従って同じSrvDeregメッセージをマルチキャストしなければなりません。その後のNotifyAtは、サブスクリプションを延長受信されない限りSAは、サブスクリプションの有効期間が満了したときに通知を行って停止する必要があります。
A UA that is performing passive DA detection will naturally also receive the extension, but the UA SHOULD ignore the extension.
当然拡張を受信するパッシブDA検出を行っているUAが、UAは、拡張を無視すべきです。
An SA can receive a NotifyAt with a SrvAck when it first comes up and registers itself with a DA. If the DA has any subscriptions from UAs for the service type and scopes represented by the SA, it MUST return a NotifyAt with the SrvAck.
それが最初に来て、DAに自身を登録するときSAがSrvAckでNotifyAtを受け取ることができます。 DAは、SAによって表されるサービスの種類とスコープのためのUAからの任意のサブスクリプションを持っている場合、それはSrvAckでNotifyAtを返さなければなりません。
The SA upon receiving the NotifyAt immediately multicasts the same SrvReg it sent to the DA, according to the multicast transmit algorithm. The SA MUST only perform the multicast algorithm once, even if it registers with more than one DA and receives the NotifyAt in reply from more than one. Prior to its demise and after deregistering with a DA, the SA MUST notify with the same SrvDereg, as described in Section 7.2.
NotifyAtを受信するとSAは直ちにマルチキャスト送信アルゴリズムによれば、DAに送信された同一のSrvRegをマルチキャスト。 SAは、それが複数のDAに登録し、複数の応答にNotifyAtを受けても、一度マルチキャストアルゴリズムを実行しなければなりません。セクション7.2で説明したように、その崩壊およびDAで登録解除した後の前、SAは、同じSrvDeregで通知しなければなりません。
Enterprise networks that allow SLP notification SHOULD deploy the Multicast Address Allocation Architecture (MAAA) including administratively scoped multicast and Multicast Address Dynamic Client Allocation Protocol (MADCAP) [6].
SLP通知は管理用スコープのマルチキャストおよびマルチキャストを含むマルチキャストアドレス配分アーキテクチャ（MAAA）を展開する必要があります許可する企業ネットワークは、動的クライアント割り当てプロトコル（MADCAP）をアドレス[6]。
If it is not possible to obtain a multicast address for use in SLP notifications, the SLP multicast address is used.
それはSLP通知で使用するマルチキャストアドレスを得ることができない場合は、SLPマルチキャストアドレスが使用されています。
If the MAAA infrastructure is deployed, DAs and SAs obtain their scope configuration from MADCAP, because the SLP scopes are the same as the MADCAP scopes. Each SLP scope MUST correspond to a multicast scope name, in the sense of [6]. In such a case, a DA allocates, using MADCAP, a new multicast group address for each new service type/scope pair to which a UA subscribes. The allocation is made by MADCAP from the multicast address range for the scope. In this way, only those UAs interested in the service type and scopes in the subscription receive the multicast notification. The DA sets up the lease on the multicast address to correspond with the duration of the subscription. If the MADCAP server runs out of addresses, the SLP multicast group is used as a last resort.
MAAAインフラストラクチャが配備されている場合、DASおよびSAはSLPスコープはMADCAPスコープと同じであるため、MADCAPからその範囲設定を得ます。各SLPスコープは、[6]の意味では、マルチキャストスコープ名に対応しなければなりません。このような場合に、DAはMADCAP、UAは、加入する各新しいサービスタイプ/スコープのペアのための新たなマルチキャストグループアドレスを使用して、割り当てます。割り当ては、スコープのマルチキャストアドレスの範囲からMADCAPによって行われます。このように、サブスクリプションでのサービスの種類とスコープに興味があるもののみUAはマルチキャスト通知を受け取ります。 DAは、サブスクリプションの期間に対応するマルチキャストアドレスのリースを設定します。 MADCAPサーバーは、アドレスが不足すると、SLPマルチキャストグループは、最後の手段として使用されています。
For example, if the multicast scope has an address range of 239.1.0.0 through 239.1.255.255, the notification group address for service type X in scope A could be 239.1.0.42 and for service type Y in scope B could be 239.1.42.42.
マルチキャストスコープは239.1.255.255を通して239.1.0.0のアドレス範囲を有する場合、例えば、範囲AにおけるサービスタイプXの通知グループアドレス239.1.0.42であるとスコープBにおけるサービスタイプYのための可能性239.1.42.42かもしれません。
The DA and SAs use a multicast transmit algorithm similar to that used for discovering services in SLP, described in RFC 2608 [1], except the agent performing the notification doesn't wait for replies. The agent performing the notification transmits a notification message repeatedly over a period of 15 seconds, backing off exponentially on the duration of the time interval between the multicasts. The rationale for this algorithm is to limit the duration and scope of the multicast announcement while still repeating the announcement enough times to increase the probability that one message gets through.
DA及びSAはRFC 2608に記載さSLPのサービスを発見するために使用されるものと同様のマルチキャスト送信アルゴリズムは、[1]、エージェントは通知を行う以外の応答を待たない使用します。通知を行うエージェントは、マルチキャストとの間の時間間隔の持続時間に指数関数的バックオフ、15秒の期間にわたって繰り返して通知メッセージを送信します。このアルゴリズムの理論的根拠はまだ発表に一つのメッセージを介して取得すること確率を高めるために十分な回数を繰り返しながらマルチキャストアナウンス期間や範囲を制限することです。
For an SA, a notification message is either a SrvReg or a SrvDereg message, depending on whether the SA is registering a new service or deregistering a service. When a new service is registered, the SrvReg message MUST have the fresh bit set in the SLP header. The entire list of attributes for the service SHOULD be included. The SrvDereg message MUST NOT include an attribute tag list. Notifications MUST NOT be transmitted at any other time, to minimize multicast traffic.
SAの場合、通知メッセージは、SAが新しいサービスを登録またはサービス登録を解除されたかどうかに応じて、のSrvRegまたはSrvDeregメッセージのいずれかです。新しいサービスが登録されている場合、のSrvRegメッセージがSLPヘッダ内の新鮮なビットを設定する必要があります。サービスの属性のリスト全体を含める必要があります。 SrvDeregメッセージは、属性タグリストを含んではいけません。通知は、マルチキャストトラフィックを最小限に抑えるために、他のどの時点で送信してはなりません。
Since a SrvReg could contain attribute lists of arbitrary length, the message could potentially overflow the packet MTU for UDP. If an attribute list causes a packet MTU overflow, the SA MUST set the overflow bit in the SLP header. The attribute list in the notification message MUST be formatted so that a UA can use the attributes even if an overflow occurs. If a UA needs more attributes than are transmitted in the notification message, it can contact the SA (if no DA is present) or the DA for the attributes it needs.
SrvRegは、任意の長さの属性リストが含まれている可能性があるため、メッセージは、潜在的にUDPのパケットMTUをオーバーフローする可能性があります。属性リストは、パケットMTUオーバーフローが発生した場合、SAはSLPヘッダ内のオーバーフロービットをセットしなければなりません。 UAは、オーバーフローが発生した場合でも、属性を使用できるように、通知メッセージ内の属性リストをフォーマットする必要があります。 UAは、通知メッセージで送信されるよりも多くの属性を必要とする場合、それは必要な属性のためにSA（何DAが存在しない場合）またはDAと接触することができます。
A DA multicasts a DAAdvert when a subscription comes in containing a service type and scopes that do not match any on the DA's list of known subscriptions. The same algorithm MUST be used. If the combination of the DA attributes and the NotifyAt message cause the DAAdvert to overflow a UDP packet, DA attributes MUST be truncated to allow the NotifyAt to fit and the overflow bit MUST be set in the header. An SA knows that the purpose of the message is to inform it of a new subscription rather than for passive advertisement, because of the extension, and it can therefore ignore the DA attribute list field if the overflow bit is set in the header. A DA also transmits a SrvDereg message when a service advertisement is deregistered due to timeout, following the same rules as for an SA.
DAは、マルチキャストDAAdvertをサブスクリプションは、既知のサブスクリプションのDAのリスト上のいずれにも一致していないサービスの種類とスコープを含むで提供されます。同じアルゴリズムを使用しなければなりません。 DAの組み合わせは属性とNotifyAtメッセージがDAAdvertがUDPパケットをオーバーフローさせた場合、DAはNotifyAtが収まるように切り捨てされなければならない属性およびオーバーフロービットは、ヘッダに設定しなければなりません。 SAは、メッセージの目的があるため拡張のため、新しいサブスクリプションのではなく、受動的な広告のためにそれを知らせるためであることを知っている、とオーバーフロービットがヘッダに設定されている場合は、それゆえDA属性リストのフィールドを無視することができます。 DAは、サービス広告がSAと同じ規則に従って、タイムアウトにより登録解除さSrvDeregメッセージを送信します。
Robustness to DA failure is an important goal of the design. When a DA disappears due to unforeseen circumstances, subscription information from UAs is lost. UAs continue to get notifications from existing SAs. However, new SAs will not be informed of the subscription unless other DAs also have the subscription information. Because a UA may not discover a new DA until it tries to perform an active request, the UA could potentially miss the appearance of new services. For this reason, UAs that are concerned about receiving notification of absolutely every service that appears SHOULD issue subscriptions to every newly discovered DA that supports the scopes it supports. Similarly, if a DA disappears through controlled shutdown, a UA performing passive discovery can detect the shutdown and reissue the subscription to an alternate DA.
DA障害に対する頑健性は、設計の重要な目標です。 DAは、UASからサブスクリプション情報が失われ、不測の事態のために消えます。 UAは、既存のSAからの通知を取得し続けます。他のDASはまた、サブスクリプション情報を持っていない限りしかし、新しいSAはサブスクリプションが通知されることはありません。それはアクティブな要求を実行しようとするまで、UAは、新しいDAを発見できない場合がありますので、UAは、潜在的に新たなサービスの出現を逃すことができます。このため、それがサポートするスコープをサポートするすべての新たに発見されたDAへのサブスクリプションを発行する必要があります表示されます絶対にすべてのサービスの通知を受信する懸念しているのUA。 DAは、制御されたシャットダウンを介して消えた場合、同様に、UA行うパッシブ発見は、シャットダウンを検出し、代替DAへのサブスクリプションを再発行することができます。
On the SA side, when a DA goes down, existing SAs continue to notify until the subscription expires. Before ceasing to notify, an SA MUST determine whether the DA is still active and, if not, verify with another DA whether the subscription has been extended. If no other DA is available, the SA MUST ignore the subscription expiration time and continue notifying until a new DA is discovered. When a new DA is discovered the SA must send a new SrvReg to the DA, according to RFC 2608 [1]. The replying SrvAck contains a NotifyAt extension if the UA has renewed its subscription with the DA. If the SrvAck does not contain a NotifyAt message the SA MUST continue to notify until the subscription expires. If a UA is interested in continuing the notification, it renews the subscription with the new DA prior to the expiration of the old one, and so the SA is informed to continue notifying.
DAがダウンしたときSA側では、既存のSAは、サブスクリプションの有効期限が切れるまでに通知し続けます。 、サブスクリプションが拡張されているかどうかを別のDAを検証していない場合に通知をやめる前に、SAは、DAがまだアクティブであるかどうかを判断し、なければなりません。他のDAが利用できない場合、SAは、サブスクリプションの有効期限を無視しなければなりませんし、新しいDAが発見されるまで、通知を続けます。新しいDAが発見されるとSAは、[1] RFC 2608によると、DAに新規のSrvRegを送信する必要があります。 UAはDAとそのサブスクリプションを更新した場合は返信SrvAckはNotifyAt拡張が含まれています。 SrvAckがNotifyAtメッセージが含まれていない場合はSAは、サブスクリプションの有効期限が切れるまでに通知し続けなければなりません。 UAが通知を続けるに関心がある場合、それは古いものの満了前に新しいDAとサブスクリプションを更新し、そのSAは通知を続けることを知らされます。
Note that this procedure still does not inform SAs that come up between the time a newly booted DA comes up and the time the UA has renewed its subscription with the newly booted DA. If this situation is of concern, multiple DAs can be used to assure that all subscriptions are covered when a DA goes down.
この手順はまだ新しくブートDAが起動する時間とUAは、新たに起動DAとそのサブスクリプションを更新した時間の間で出てくるのSAを通知していないことに注意してください。このような状況が懸念される場合は、複数のDAがDAがダウンしたときにすべてのサブスクリプションがカバーされることを保証するために使用することができます。
In SLP networks with DAs as described in RFC 2608, the only multicast is the SrvRqst for DAAdverts performed during active DA discovery, and unsolicited DAAdverts sent periodically by the DA for passive discovery. There is no multicast involved in UA queries or SA registrations. This allows network administrators to set up DAs for a particular collection of IP subnets and confine all service discovery traffic to unicast between the SA and UA clients and the DA. Administratively scoped multicast can additionally be used to limit the extent of active DA discovery and passive DA advertising. The amount of multicast involved is not high and DHCP DA and scope configuration can be used to limit which DAs a particular UA or SA client sees, or to inhibit multicast entirely so that UAs and SAs only use configured DAs.
RFC 2608に記載されているようにDASとSLPネットワークでは、マルチキャストのみがアクティブDA検出時に実行DAAdverts、及びパッシブ発見のためにDAによって定期的に送信された迷惑DAAdvertsためSrvRqstです。 UAのクエリまたはSAの登録に関わるマルチキャストはありません。これは、ネットワーク管理者は、IPサブネットの特定のコレクションのためにDAを設定し、SAとUAクライアントとDA間でユニキャストするために、すべてのサービス発見トラフィックを制限することができます。管理スコープマルチキャストは、さらに、アクティブDA発見および受動DA広告の範囲を制限するために使用することができます。関与するマルチキャストの量は高くなく、DHCP DAとスコープ設定は、特定のUAまたはSAクライアントが見ているDAを制限するために、またはUAおよびSAのみ構成DAを使用するように完全にマルチキャストを阻害するために使用することができます。
With notification, however, multicast traffic involving events in SAs becomes available. Because DAs request multicast addresses based on scope and service type, the multicast associated with particular events should only propagate to those subnets in which UAs and SAs of the same scope are interacting. Routers should be configured with administrative multicast scoping to limit multicast. If DAs are not deployed (or the MAAA is not deployed), however, the amount of multicast on the SLP multicast address when notifications are being used could quickly become very large. Therefore, it is crucial that DAs supporting notification be deployed in large networks where UA clients are interested in notification.
通知では、しかし、のSA内のイベントを含むマルチキャストトラフィックが利用可能になります。 DASはスコープとサービスタイプに基づいて、マルチキャストアドレスを要求するため、特定のイベントに関連付けられたマルチキャストは、同じスコープのUAとSAが相互作用しているものサブネットに伝播すべきです。ルーターは、マルチキャストを制限するために、管理マルチキャストスコープを使用して設定する必要があります。 DASが展開されていない（またはMAAAが展開されていない）場合は、しかし、通知が使用されているSLPマルチキャストアドレスのマルチキャストの量が急速に大きくなる可能性があります。したがって、DAS支持通知がUAクライアントが通知に興味を持っている大規模なネットワークに配備されていることが重要です。
The SrvReg and SrvDereg messages contain authentication blocks for all SLP SPIs supported by the DAs with which the SA registers. Since these SPIs are necessarily the same as those that UAs can verify, a UA receiving a multicast notification is in a position to verify the notification. It does so by selecting the authentication block or blocks that it can verify. If authentication fails, either due to lack of an authentication block, or lack of the proper SPI, the UA simply discards the notification. In a network without DAs, the SPIs of the UA and SA must also match.
SrvRegとSrvDeregメッセージは、SAが登録されてたDAによってサポートされているすべてのSLPのSPIの認証ブロックを含みます。これらのSPIは、必ずしもUAが確認できているものと同じであるので、マルチキャスト通知を受信UAは、通知を確認する立場にあります。それが検証できることを認証または複数のブロックを選択することで、そうします。認証に失敗した場合は、どちらかによる認証ブロックの不足、または適切なSPIの不足のために、UAは、単に通知を破棄します。 DAをせずにネットワークでは、UAとSAのSPIをも一致している必要があります。
The SLP Notification services use the IANA-assigned port number of 1847. The SLP extension identifiers assigned by IANA are 0x0004 for Subscribe and 0x0005 for NotifyAt.
SLP通知サービスは、IANAによって割り当てられた1847年SLP拡張識別子のIANAによって割り当てられたポート番号を使用して購読してNotifyAtのための0x0005のための0x0004はあります。
The authors would like to thank Charles Perkins, of Nokia, and Erik Guttman and Jonathan Wood, of Sun Microsystems, for their stimulating discussion and suggestions during the initial phases of the subscription/notification design. We would also like to thank Erik for his intense scrutiny of the specification during the later phases. His comments were instrumental in refining the design. Shivaun Albright, of HP, motivated simplification of the protocol to focus on initial registration and deregistration only. Vaishali Mithbaokar implemented the simplified protocol.
著者は、彼らがサブスクリプション/通知設計の初期段階での議論や提案を刺激するために、サン・マイクロシステムズのノキアのチャールズ・パーキンス、そしてエリック・グットマンとジョナサン・ウッドを、感謝したいと思います。また、後の段階の間、仕様の彼の強烈な精査のためにエリックに感謝したいと思います。彼のコメントは、デザインを改良することに尽力しました。 HPのShivaunオルブライト、唯一の初期登録と登録解除に集中するプロトコルのやる気簡素化。ヴァイシャリMithbaokarは簡略化されたプロトコルを実装します。
[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol", RFC 2608, July 1999.
[1]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービス・ロケーション・プロトコル"、RFC 2608、1999年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, July 1999.
[3]ガットマン、E.、パーキンス、C.及びJ.ケンプ、 "サービステンプレートおよびサービス：スキーム"、RFC 2609、1999年7月。
[4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[4]マイヤー、D.、 "管理スコープのIPマルチキャスト"、RFC 2365、1998年7月を。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[6]ハンナ、S.、パテル、B。そして、M.シャー、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、1999年12月。
[7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses
「７」 ｈっｔｐ：／／ｗっｗ。いし。えづ／いんーのてｓ／いあな／あっしｇんめんｔｓ／むｌちかｓｔーあっｄれっせｓ
[8] Guttman, E., "Service Location Protocol Modifications for IPv6", Work in Progress.
[8]グットマン、E.、「IPv6のサービスロケーションプロトコルの変更」が進行中で働いています。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2375, July 1997.
[9] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2375、1997年7月。
James Kempf Sun Microsystems UMPK15-214 901 San Antonio Rd. Palo Alto, CA 94040 USA
ジェームズ・ケンプSun MicrosystemsのUMPK15-214 901サンアントニオRdを。パロアルト、CA 94040 USA
Phone: +1 650 786 5890 EMail: james.kempf@sun.com
電話：+1 650 786 5890 Eメール：james.kempf@sun.com
Jason Goldschmidt Sun Microsystems UMPK17-202 901 San Antonio Rd. Palo Alto, CA 94040 USA
ジェイソン・ゴールドシュミットSun MicrosystemsのUMPK17-202 901サンアントニオRdを。パロアルト、CA 94040 USA
Phone: +1 650 786 3502 EMail: jason.goldschmidt@sun.com
電話：+1 650 786 3502 Eメール：jason.goldschmidt@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。