[要約] RFC 3082は、Service Location Protocol（SLP）の通知と購読に関する仕様です。その目的は、ネットワーク上のサービスの変更や利用可能性の通知を効率的に行い、クライアントが必要な情報を購読できるようにすることです。
Network Working Group J. Kempf
Request for Comments: 3082 J. Goldschmidt
Category: Experimental Sun Microsystems
March 2001
Notification and Subscription for SLP
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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.
Service Location Protocol（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）クライアントがそれらを見つけるメカニズムを提供します。メカニズムは需要主導型です。UASは、積極的にクエリすることでサービス情報を取得し、そうしない限り情報を取得しません。この設計はほとんどのアプリケーションの要件を満たしていますが、関心のあるサービスの外観または消失に関するよりタイムリーな情報を必要とするアプリケーションがいくつかあります。
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.
ポーリングは非効率的で無駄なネットワークおよびプロセッサリソースを無駄にするため、これらのアプリケーションに変更を明示的に通知できるメカニズムを提供したいと思います。このドキュメントでは、UASにサービスの可用性の変更を通知できるようにするスケーラブルなメカニズムについて説明します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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と数百のDAを備えた大規模なエンタープライズネットワークと同様に、わずかなSASだけの小さなネットワークで機能する必要があります。通知の利点を受け取るために、DASを展開するために小さなネットワークを必要としないでください。また、大規模なネットワークでの通知により、特定の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は介在するDASの状態に関係なく、そのような通知を受け取る必要があります。SLPは、特定の範囲をサポートするDASに関して透明です。つまり、UAは特定のスコープを持つ任意のDAを使用し、同じサービス広告を取得することを期待できます。通知は同じプロパティを展示する必要があります。UAが通知を受け取るかどうかは、それらがたまたま接続するDAに依存してはなりません。これにより、DASのアイデンティティが純粋なキャッシュとして保存されます。
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.
スケーラビリティをサポートするために、デザインを2つの部分に分割します。ネットワークに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.
DASのないネットワークでは、SAが最初に表示されたとき、およびSAが消えると、UASはSAによって通知されます。これにより、UASはSAがサポートするサービスタイプのリストについて知ることができます。小さなネットワークでは、新しく表示されるSASのサブスクリプションを管理するための集中剤エージェントはありません。これは、UAが特定のサービスタイプの特定のサービスタイプの通知をサブスクライブするあらゆる種類のサブスクリプションデザインを排除します。これは、新しく表示されるSAがそれを伝えるためのサブスクリプションがないかどうかを知らないためです。
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).
その結果、SASは、通知を実行できる場合は、範囲やサービスの種類に関係なく、オンラインになったときに通知を実行します。これは、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.
この設計では、SASがIPマルチキャストによる通知を実行する必要があります（またはマルチキャストが利用できない場合はIPv4でブロードキャスト）SLP SRVREGまたはSRVDEREGメッセージを使用して、セクション9.0で説明したマルチキャスト送信アルゴリズムを使用します。通知のポート番号はデフォルトの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と同じ方法で管理上スコープされています。通知に関心のあるIPv4 UASマルチキャストグループ239.255.255.253に参加し、ポート1847に耳を傾けます。IPv6では、[8]に記載されているように、広告されたサービスタイプのスコープIPv6アドレスにマルチキャストが実行されます。SAは、それがサポートする最大のマルチキャスト範囲を含むすべてのアドレスに広告を掲載しています。通知に関心のあるIPv6 UASポート1847で興味を持ち、聴くマルチキャストスコープとサービスタイプに対応するマルチキャストグループに参加します。たとえば、サイトローカルスコープにアクセスし、ハッシュのあるサービスタイプに興味があるIPv6 UA[8]のアルゴリズムに従って計算されたIS 42は、FF01：0：0：0：0：0：10042からFF05：0：0：0：0：0：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が構成されているスコープで他のDASによって配置されたサブスクリプションを追跡する必要があります。複数のマルチキャスト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自体も、サービス広告が登場するときに、マルチキャスト送信アルゴリズムに従って通知を実行する必要があります。サービス広告のタイムアウトは、DEREGISTRED URLのSRVDEREGをマルチリキャストします。これにより、SAが登録せずに姿を消した場合でも、興味のあるUASにサービス広告の終miseを知らせることができます。DAは、SAからSRVREGを受け取ったときに通知を実行してはなりませんが、それが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を受け取っている場合、次の条件が満たされています。
1. The SA supports notification.
1. SAは通知をサポートしています。
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拡張子のスコープの1つと一致します。
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がSRVREGまたはSRVDEREGをDAで実行した直後に通知を実行する必要があります。スコープでDAを検出したSAは、SAのサービスタイプとスコープに一致するサービスタイプとスコープを備えたSRVACKのnotiyAT拡張機能を受信しない限り、通知をマルチキャストしてはなりません。
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が抽象型[3]のすべてのSAS広告コンクリートインスタンスから聞くことに関心があるかどうかを示し、SRVRQSTのサービスタイプが具体的なタイプである場合にのみ興味があります。フラグが1の場合、UAは、SRVRQSTのタイプと同じ抽象タイプを持つすべてのSAS広告コンクリートタイプから聞くことに興味があります。フラグが0の場合、UAはSRVRQSTの特定のコンクリートタイプをサポートするSASからのみ聞くことに興味があります。付随する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のスコープ/グループリストの例は次のとおりです。
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.
サービスタイプ名は、シンプルなタイプ名、抽象型名、または具体的なタイプ名です。名前が抽象タイプ名の場合、抽象型を宣伝するすべてのSASが通知する必要があります。名前が具体的またはシンプルなタイプ名の場合、SASがシンプルまたはコンクリートタイプを宣伝するSASのみが通知しなければならない場合、他の人は通知してはなりません。抽象型フラグセットを備えたコンクリートタイプのサブスクリプションを受信する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つのケースがあります。SRVRがUAに戻され、マルチキャストDaAdvertで、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を使用して通知をaAdvertします。このメッセージは、既存のSASがサービスタイプとスコープを備えていることを通知します。これは、シャットダウン時に通知をマルチキャストする必要があることを発表します。
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は最初に属性タグリストなしでdas（標準SLPに従って）を使用してSRVDEREGをユニキャストする必要があります。マルチキャスト送信アルゴリズムに従って同じSRVDEREGメッセージをマルチキャストする必要があります。サブスクリプションの寿命が期限切れになると、サブスクリプションを延長する場合を除き、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.
SAは、SRVACKが最初に登場し、DAで登録するときにSRVACKを使用してNotifyATを受信できます。DAがSAで表されるサービスタイプとスコープのUASからのサブスクリプションを持っている場合、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.
SAは、Multicast送信アルゴリズムに従って、notifyATを受信するとすぐにDAに送信された同じsrvregをマルチキャストします。SAは、複数のDAで登録され、複数の回答でNotifyATを受信しても、マルチキャストアルゴリズムを1回だけ実行する必要があります。セクション7.2で説明されているように、SAはその終ofの前とDAとの登録後、同じ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通知を許可するエンタープライズネットワークは、管理上スコープマルチキャストおよびマルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）を含むマルチキャストアドレス割り当てアーキテクチャ（MAAA）を展開する必要があります[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.
SLPスコープがMADCAPスコープと同じであるため、MAAAインフラストラクチャが展開されている場合、DASとSASはMADCAPからスコープ構成を取得します。各SLPスコープは、[6]という意味で、マルチキャストスコープ名に対応する必要があります。そのような場合、DAは、UAがサブスクライブする新しいサービスタイプ/スコープペアごとに新しいマルチキャストグループアドレスであるMADCAPを使用して割り当てます。割り当ては、範囲のマルチキャストアドレス範囲から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.0.0から239.1.255.255の場合、スコープ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とSASは、通知を実行するエージェントが返信を待っていない場合を除き、RFC 2608 [1]で説明されているSLPでのサービスの発見に使用されるものと同様のマルチキャスト送信アルゴリズムを使用します。通知を実行するエージェントは、15秒間にわたって通知メッセージを繰り返し送信し、マルチキャスト間の時間間隔の期間中に指数関数的に後退します。このアルゴリズムの理論的根拠は、マルチキャストの発表の期間と範囲を制限しながら、1つのメッセージが通過する確率を高めるのに十分な回数を繰り返すことです。
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が通知メッセージで送信されるよりも多くの属性を必要とする場合、必要な属性の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マルチキャストは、DAの既知のサブスクリプションのリストには一致しないサービスタイプとスコープを含むサブスクリプションが含まれている場合にダアドバートをマルチキャストします。同じアルゴリズムを使用する必要があります。DA属性とnotifyATメッセージの組み合わせにより、DAADVERTがUDPパケットのオーバーフローを引き起こす場合、notifyATが適合し、オーバーフロービットをヘッダーに設定するためにDA属性を切り捨てる必要があります。SAは、メッセージの目的は、拡張機能のため、パッシブ広告ではなく新しいサブスクリプションを通知することであることを知っているため、オーバーフロービットがヘッダーに設定されている場合、DA属性リストフィールドを無視できます。また、SAと同じルールに従って、タイムアウトのためにサービス広告が登録されている場合、DAは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からのサブスクリプション情報が失われます。UASは引き続き既存のSASから通知を取得しています。ただし、他のDAもサブスクリプション情報を持っていない限り、新しいSASはサブスクリプションを通知されません。UAはアクティブなリクエストを実行しようとするまで新しいDAを発見しない可能性があるため、UAは新しいサービスの外観を見逃す可能性があります。このため、表示されるすべてのサービスの通知を受信することを懸念しているUASは、サポートするスコープをサポートする新たに発見されたすべてのDAにサブスクリプションを発行する必要があります。同様に、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.
SA側では、DAがダウンすると、既存のSASがサブスクリプションの有効期限が切れるまで通知を続けます。通知を中止する前に、SAはDAがまだアクティブであるかどうかを判断し、そうでない場合は別のDAでサブスクリプションが拡張されているかどうかを確認する必要があります。他のDAが利用できない場合、SAはサブスクリプションの有効期間を無視し、新しいDAが発見されるまで通知を続ける必要があります。RFC 2608 [1]によると、新しいDAが発見された場合、SAは新しいSRVREGをDAに送信する必要があります。返信srvackには、UAがDAでサブスクリプションを更新した場合、notifyAT拡張子が含まれています。SRVACKにnotifyATメッセージが含まれていない場合、SAはサブスクリプションの有効期限が切れるまで通知を継続する必要があります。UAが通知を継続することに関心がある場合、古いDAの有効期限の前に新しい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が登場するまでに出てくるSASにまだ通知されないことと、UAが新しく起動されたDAでサブスクリプションを更新するまでには通知されないことに注意してください。この状況が懸念される場合、複数の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のSRVRQSTであり、パッシブ発見のためにDAによって定期的に送られた未承諾のDAADVERTSです。UAクエリやSA登録にはマルチキャストはありません。これにより、ネットワーク管理者はIPサブネットの特定のコレクションのDASをセットアップし、すべてのサービス発見トラフィックをSAとUAクライアントとDAの間のユニキャストに限定することができます。さらに、スコープされたマルチキャストを使用して、アクティブなDA発見とパッシブDA広告の範囲を制限することができます。関係するマルチキャストの量は高くなく、DHCP DAとスコープ構成を使用して、特定のUAまたはSAクライアントが見ているDASを制限するか、UASとSASが構成されたDASのみを使用できるようにマルチキャストを完全に阻害することができます。
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.
ただし、通知により、SASでのイベントを含むマルチキャストトラフィックが利用可能になります。DASは範囲とサービスタイプに基づいてマルチキャストアドレスを要求するため、特定のイベントに関連付けられたマルチキャストは、同じスコープのUASとSASが相互作用しているサブネットにのみ伝播する必要があります。ルーターは、マルチキャストを制限するために管理マルチキャストスコープで構成する必要があります。ただし、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が登録するDASによってサポートされているすべてのSLP SPIの認証ブロックが含まれています。 これらのスピスは必然的にUASが検証できるものと同じであるため、マルチキャスト通知を受け取るUAは通知を検証する立場にあります。 これは、検証できる認証ブロックまたはブロックを選択することにより行います。 認証ブロックが不足しているため、または適切なSPIがないため、認証が失敗した場合、UAは単に通知を破棄します。 DASのないネットワークでは、UAとSAのスピスも一致する必要があります。
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通知サービスは、1847年のIANAが割り当てられたポート番号を使用します。IANAによって割り当てられたSLP拡張識別子は、subscribeの場合は0x0004、notifyatに0x0005です。
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 Albrightは、最初の登録と登録のみに焦点を当てるプロトコルの動機付けの単純化のみを行いました。Vaishali Mithbaokarは、簡素化されたプロトコルを実装しました。
[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol", RFC 2608, July 1999.
[1] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「Service Location Protocol」、RFC 2608、1999年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, July 1999.
[3] Guttman、E.、Perkins、C。and J. Kempf、「サービステンプレートとサービス：スキーム」、RFC 2609、1999年7月。
[4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[4] Meyer、D。、「管理上スコープIPマルチキャスト」、RFC 2365、1998年7月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5] Crocker、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
[7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses
[8] Guttman, E., "Service Location Protocol Modifications for IPv6", Work in Progress.
[8] Guttman、E。、「IPv6のサービスロケーションプロトコル変更」、進行中の作業。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2375, July 1997.
[9] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2375、1997年7月。
James Kempf Sun Microsystems UMPK15-214 901 San Antonio Rd. Palo Alto, CA 94040 USA
James Kempf Sun Microsystems Umpk15-214 901 San Antonio Rd。パロアルト、CA 94040 USA
Phone: +1 650 786 5890
EMail: james.kempf@sun.com
Jason Goldschmidt Sun Microsystems UMPK17-202 901 San Antonio Rd. Palo Alto, CA 94040 USA
Jason Goldschmidt Sun Microsystems Umpk17-202 901 San Antonio Rd。パロアルト、CA 94040 USA
Phone: +1 650 786 3502
EMail: jason.goldschmidt@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。