RFC3859 日本語訳
3859 Common Profile for Presence (CPP). J. Peterson. August 2004. (Format: TXT=30537 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Peterson Request for Comments: 3859 NeuStar Category: Standards Track August 2004
コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 3859年のNeuStarカテゴリ: 標準化過程2004年8月
Common Profile for Presence (CPP)
存在のための一般的なプロフィール(CPP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services.
このドキュメントが書かれたとき、多数の存在プロトコルは使用中でした、そして、(主に商業インスタントメッセージングサービスのコンポーネントとしての)これらのプロトコルに基づくサービスの間の相互運用性はほとんど達成されていません。 存在が存在サービスの間のゲートウェイの創造を容易にするように、この仕様は一般的な意味論とデータ書式を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Abstract Presence Service . . . . . . . . . . . . . . . . . . 4
3.1. Overview of the Presence Service . . . . . . . . . . . . 4
3.2. Identification of PRESENTITIES and WATCHERS . . . . . . 6
3.2.1. Address Resolution . . . . . . . . . . . . . . . 6
3.3. Format of Presence Information . . . . . . . . . . . . . 6
3.4. The Presence Service . . . . . . . . . . . . . . . . . . 7
3.4.1. The Subscribe Operation . . . . . . . . . . . . 7
3.4.2. The Notify Operation . . . . . . . . . . . . . . 8
3.4.3. Subscribe Operation (with Zero Duration) . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. The PRES URI Scheme . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 抽象的な存在サービス. . . . . . . . . . . . . . . . . . 4 3.1。 存在サービス. . . . . . . . . . . . 4 3.2の概観。 PRESENTITIESとウォッチャー. . . . . . 6 3.2.1の識別。 解決. . . . . . . . . . . . . . . 6 3.3を記述してください。 存在情報. . . . . . . . . . . . . 6 3.4の形式。 存在サービス. . . . . . . . . . . . . . . . . . 7 3.4.1。 .2に操作. . . . . . . . . . . . 7 3.4を申し込んでください。 .3に操作. . . . . . . . . . . . . . 8 3.4に通知してください。 操作(持続時間でない).8 4を申し込んでください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 8 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . 9 5.1。 PRES URI計画. . . . . . . . . . . . . . . . . . 9 6。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 10 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1。 引用規格. . . . . . . . . . . . . . . . . . 10 7.2。 有益な参照. . . . . . . . . . . . . . . . . 11
Peterson Standards Track [Page 1] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[1ページ]。
A. PRES URI IANA Registration Template . . . . . . . . . . . . . 12
A.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . 12
A.2. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . 12
A.3. Character Encoding Considerations . . . . . . . . . . . 12
A.4. Intended Usage . . . . . . . . . . . . . . . . . . . . . 12
A.5. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.6. Interoperability Considerations . . . . . . . . . . . . 13
A.7. Security Considerations . . . . . . . . . . . . . . . . 13
A.8. Relevant Publications . . . . . . . . . . . . . . . . . 13
A.9. Person & Email Address to Contact for Further
Information. . . . . . . . . . . . . . . . . . . . . . . 13
A.10. Author/Change Controller . . . . . . . . . . . . . . . . 13
A.11. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . . 13
B.1. Address Mapping . . . . . . . . . . . . . . . . . . . . 13
B.2. Source-Route Mapping . . . . . . . . . . . . . . . . . . 13
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
A.PRES URI IANA登録テンプレート. . . . . . . . . . . . . 12A.1。 URI計画名. . . . . . . . . . . . . . . . . . . . 12のA.2。 URI計画構文. . . . . . . . . . . . . . . . . . . 12A.3。 問題. . . . . . . . . . . 12A.4をコード化するキャラクター。 意図している用法. . . . . . . . . . . . . . . . . . . . . 12A.5。 このURI Scheme Name. . . . . . . . . . . . . . . . . . . . . . . . . . 12A.6を使用するアプリケーション、そして/または、プロトコル。 相互運用性問題. . . . . . . . . . . . 13A.7。 セキュリティ問題. . . . . . . . . . . . . . . . 13A.8。 関連刊行物. . . . . . . . . . . . . . . . . 13A.9。 詳細のために連絡する人とEメールアドレス。 . . . . . . . . . . . . . . . . . . . . . . 13 A.10。 コントローラ.13A.11を書くか、または変えてください。 Interest. . . . . . . . . . . . . . . . . . . . . . 13B.1のこのURI Scheme Name. . . . . . . . . . . . . . . . . . . . . . . . . . 13B.Issuesを使用するアプリケーション、そして/または、プロトコル。 マッピング. . . . . . . . . . . . . . . . . . . . 13B.2を記述してください。 送信元経路マッピング. . . . . . . . . . . . . . . . . . 13C.承認. . . . . . . . . . . . . . . . . . . . . . . 14作者のアドレスの.14の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. 序論
Presence is defined in RFC2778 [5]. At the time this document was written, numerous presence protocols are in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines semantics and data formats for common services of presence to facilitate the creation of gateways between presence services: a common profile for presence (CPP).
存在はRFC2778[5]で定義されます。 このドキュメントが書かれたとき、多数の存在プロトコルは使用中です、そして、(主に商業インスタントメッセージングサービスのコンポーネントとしての)これらのプロトコルに基づくサービスの間の相互運用性はほとんど達成されていません。 存在の共益サービスが存在サービスの間のゲートウェイの創造を容易にするように、この仕様は意味論とデータ書式を定義します: 存在(CPP)のための一般的なプロフィール。
Service behavior is described abstractly in terms of operations invoked between the consumer and provider of a service. Accordingly, each presence service must specify how this behavior is mapped onto its own protocol interactions. The choice of strategy is a local matter, providing that there is a clear relation between the abstract behaviors of the service (as specified in this memo) and how it is faithfully realized by a particular presence service. For example, one strategy might transmit presence information as key/value pairs, another might use a compact binary representation, and a third might use nested containers.
使用挙動はサービスの消費者とプロバイダーの間に呼び出された操作で抽象的に説明されます。 それに従って、それぞれの存在サービスはこの振舞いがどうそれ自身のプロトコル相互作用に写像されるかを指定しなければなりません。 戦略の選択は地域にかかわる事柄です、サービス(このメモで指定されるように)とそれが特定の存在サービスで忠実にどう実感されるかに関する抽象的な振舞いの明確な関係があれば。 例えば、キー/値の組、別のものがコンパクトな2進法表示を使用するかもしれなくて、3分の1が入れ子にされた容器を使用するかもしれないとき、1つの戦略が存在情報を伝えるかもしれません。
The parameters for each operation are defined using an abstract syntax. Although the syntax specifies the range of possible data values, each presence service must specify how well-formed instances of the abstract representation are encoded as a concrete series of bits.
各操作のためのパラメタは、抽象構文を使用することで定義されます。 構文は可能なデータ値の範囲を指定しますが、それぞれの存在サービスは抽象的表現のよく形成された例が具体的なシリーズのビットとしてどうコード化されるかを指定しなければなりません。
Peterson Standards Track [Page 2] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[2ページ]。
In order to provide a means for the preservation of end-to-end features (especially security) to pass through presence interoperability gateways, this specification also provides recommendations for presence document formats that could be employed by presence protocols.
また、終わりから終わりへの機能の保存(特にセキュリティ)が存在相互運用性ゲートウェイを通り抜ける手段を提供するために、この仕様は存在プロトコルで使うことができた存在ドキュメント・フォーマットのための推薦を提供します。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実現のために要件レベルを示すべきであるかをさせましょう。
This memos makes use of the vocabulary defined in RFC 2778 [5]. Terms such as CLOSED, INSTANT INBOX, PRESENCE, and OPEN are used in the same meaning as defined therein.
このメモはRFC2778[5]で定義されたボキャブラリーを利用します。 CLOSEDや、INSTANT INBOXや、PRESENCEや、オープンなどの諸条件はそこに定義されるのと同じ意味で使用されます。
The term 'gateway' used in this document denotes a network element responsible for interworking between diverse presence protocols. Although the presence protocols themselves are diverse, under the model in this document these protocols can carry a common payload that is relayed by the gateway. Whether these interworking intermediaries should be called 'gateways' or 'relays' is therefore somewhat debatable; for the purposes of this document, they are called 'CPP gateways'.
'ゲートウェイ'という本書では使用される用語はさまざまの存在プロトコルの間の織り込むのに原因となるネットワーク要素を指示します。 存在プロトコル自体はさまざまですが、モデルの下では、本書ではこれらのプロトコルはゲートウェイによってリレーされる一般的なペイロードを運ぶことができます。 したがって、仲介者を織り込むこれらが'ゲートウェイ'か'リレー'と呼ばれるべきであるかどうかが、いくらか論争の余地があります。 このドキュメントの目的のために、それらは'CPPゲートウェイ'と呼ばれます。
The term 'presence service' also derives from RFC 2778, but its meaning changes slightly due to the existence of gateways in the CPP model. When a client sends an operation to a presence service, that service might either be an endpoint or an intermediary such as a CPP gateway - in fact, the client should not have to be aware which it is addressing, as responses from either will appear the same.
また、'存在サービス'という用語がRFC2778に由来していますが、わずかにCPPのゲートウェイの存在による意味変化はモデル化されます。 クライアントが存在サービスに操作を送るとき、サービスは、CPPゲートウェイなどの終点か仲介者のどちらかであるかもしれません--事実上、クライアントがそれはアドレシングです、応答としてどれから意識している必要はないはずであるように同じに見えるでしょう。
This document defines operations and attributes of an abstract presence protocol. In order for a compliant protocol to interface with a presence gateway, it must support all of the operations described in this document (i.e., the presence protocol must have some message or capability that provides the function described by all given operations). Similarly, the attributes defined for these operations must correspond to information available in the presence protocol in order for the protocol to interface with gateways defined by this specification. Note that these attributes provide only the minimum possible information that needs to be specified for interoperability - the functions in a presence protocol that correspond to the operations described in this document can contain additional information that will not be mapped by CPP.
このドキュメントは抽象的な存在プロトコルの操作と属性を定義します。 存在ゲートウェイに連結する対応するプロトコルにおいて整然とします、それは本書では説明された操作のすべてを支持しなければなりません(すなわち、存在プロトコルには、操作を考えて、すべてによって説明された機能を提供する何らかのメッセージか能力がなければなりません)。 同様に、プロトコルがこの仕様で定義されるゲートウェイに連結するように、これらの操作のために定義された属性は存在プロトコルで利用可能な情報に対応しなければなりません。 これらの属性が相互運用性に指定される必要がある最小の可能な情報だけを提供することに注意してください--存在プロトコルでの本書では説明された操作に対応する機能はCPPによって写像されない追加情報を含むことができます。
Peterson Standards Track [Page 3] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[3ページ]。
3. Abstract Presence Service
3. 抽象的な存在サービス
3.1. Overview of the Presence Service
3.1. 存在サービスの概観
When an application wants to subscriber to the presence information associated with a PRESENTITY (in order to receive periodic notifications of presence information), it invokes the subscribe operation, e.g.,
アプリケーションがそうしたがっているとき、存在情報への加入者はPRESENTITYと交際しました(存在情報の周期的な通知を受け取るために)、それ、呼び出し、例えば操作を申し込んでください。
+-------+ +-------+
| | | |
| appl. | -- subscribe ----> | pres. |
| | | svc. |
+-------+ +-------+
+-------+ +-------+ | | | | | appl。 | -- 申し込んでください。---->| pres。 | | | | svc。 | +-------+ +-------+
The subscribe operation has the following attributes: watcher, target, duration, SubscriptID and TransID. The 'watcher' and 'target' identify the WATCHER and PRESENTITY, respectively, using the identifiers described in Section 3.2. The duration specifies the maximum number of seconds that the SUBSCRIPTION should be active (which may be zero, in which case this is a one-time request for presence information). The SubscriptID creates a reference to the SUBSCRIPTION that is used when unsubscribing. The TransID is a unique identifier used to correlate the subscribe operation with a response operation. Gateways should be capable of handling TransIDs and SubscriptIDs up to 40 bytes in length.
申し込んでください。操作には、以下の属性があります: ウォッチャー、目標、持続時間、SubscriptID、およびTransID。 'ウォッチャー'と'目標'は、セクション3.2で説明された識別子を使用することでそれぞれWATCHERとPRESENTITYを特定します。 持続時間はSUBSCRIPTIONがアクティブであるべきであることの(これがその場合で存在情報に関する1回の要求であるゼロであるかもしれません)秒の最大数を指定します。 SubscriptIDは外すとき使用されたSUBSCRIPTIONの参照を作成します。 TransIDが関連するのに使用されるユニークな識別子である、応答操作で操作を申し込んでください。 ゲートウェイは取り扱いTransIDsとSubscriptIDsが長さ40バイトまでできるべきです。
Upon receiving a subscribe operation, the service immediately responds by invoking the response operation containing the same TransID, e.g.,
aを受けると、操作を申し込んでください、そして、サービスは、すぐに、例えば同じTransIDを含む応答操作を呼び出すことによって、応じます。
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+
+-------+ +-------+ | | | | | appl。 | <、-、-、-、-- 応答--| pres。 | | | | svc。 | +-------+ +-------+
The response operation has the following attributes: status, TransID, and duration. 'status' indicates whether the subscribe operation has succeeded or failed. The TransID of the response operation corresponds to the TransID of the subscription operation to which it is responding. The 'duration' attribute specifies the number of seconds for which the subscription will be active (which may differ from the value requested in the subscribe operation).
応答操作には、以下の属性があります: 状態、TransID、および持続時間。 '状態'が示す、成功したか、または失敗された操作を申し込んでください。 応答操作のTransIDはそれが応じている購読操作のTransIDに対応しています。 '持続時間'属性が活発である購読がなる秒数を指定する、(どれが中で要求された値と異なるかもしれないか、申し込み、操作)
Peterson Standards Track [Page 4] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[4ページ]。
If the response operation indicates success, the service immediately invokes the notify operation to communicate the presence information to the WATCHER, e.g.,
応答操作がすぐに成功、サービスを示す、呼び出し、操作が例えば存在情報をWATCHERに伝えるように通知してください。
+-------+ +-------+
| | | |
| appl. | <------- notify -- | pres. |
| | | svc. |
+-------+ +-------+
+-------+ +-------+ | | | | | appl。 | <、-、-、-、-、-、-- 通知してください--| pres。 | | | | svc。 | +-------+ +-------+
The notify operation has the following attributes: watcher, target, and TransID. The values of 'watcher' and 'target' are identical to those given in the subscribe operation that triggered this notify operation. The TransID is a unique identifier for this notification.
通知してください。操作には、以下の属性があります: ウォッチャー、目標、およびTransID。 操作を申し込んでください。'ウォッチャー'と'目標'の値が中に与えられたものと同じである、引き起こされて、これは操作に通知します。 TransIDはこの通知のためのユニークな識別子です。
The notify operation also has content, namely PRESENCE INFORMATION. Content details are specified in Section 3.3.
操作に通知してください。また、内容、すなわち、PRESENCE INFORMATIONを持っています。 満足している詳細はセクション3.3で指定されます。
If the duration parameter is non-zero, then for up to the specified duration, the service invokes the notify operation whenever there are any changes to the PRESENTITY's presence information. Otherwise, exactly one notify operation is invoked, achieving a one-time poll of the presence information. Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs) defined in CPP.
持続時間パラメタがサービスがそして指定された持続時間まで呼び出す非ゼロである、PRESENTITYの存在情報へのいくつかの変化があるときはいつも、操作に通知してください。 存在情報の1回の投票を達成して、呼び出されますそうでなければ、そして、ちょうど人が、操作に通知する。 すなわち、アプリケーションは応答操作を呼び出しません。不注意に、アプリケーション応答が全くない、操作に通知してください、(起こるaが操作に通知するいつ) CPPでは、定義されるか。
The application may prematurely cancel a subscription by re-invoking the subscribe operation (as described above) with a duration of 0 and the same SubscriptID as the original subscribe operation , e.g.,
アプリケーションが早まって再呼び出すことによって定期講読契約を取り消すかもしれない、0の持続時間で操作(上で説明されるように)を申し込んでください。そうすれば、オリジナルと同じSubscriptIDは例えば操作を申し込みます。
+-------+ +-------+
| | | |
| appl. | -- subscribe 0 --> | pres. |
| | | svc. |
+-------+ +-------+
+-------+ +-------+ | | | | | appl。 | -- 0を申し込んでください--、>。| pres。 | | | | svc。 | +-------+ +-------+
Note that a notify operation will be invoked when a subscription is prematurely canceled in this fashion; this notification may be discarded by the watcher.
aが購読が早まってこんなやり方で中止されるとき、呼び出されるように操作に通知する注意。 この通知はウォッチャーによって捨てられるかもしれません。
Peterson Standards Track [Page 5] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[5ページ]。
The service immediately responds by invoking the response operation containing the same TransID; e.g.,
サービスはすぐに、同じTransIDを含む応答操作を呼び出すことによって、応じます。 例えば
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+
+-------+ +-------+ | | | | | appl。 | <、-、-、-、-- 応答--| pres。 | | | | svc。 | +-------+ +-------+
Note that this specification assumes that CPP-compliant presence protocols provide reliable message delivery; there are no application-layer message delivery assurance provisions in this specification.
この仕様が、CPP対応することの存在プロトコルが信頼できるメッセージ配送を提供すると仮定することに注意してください。 この仕様による応用層メッセージ配送保証条項が全くありません。
3.2. Identification of PRESENTITIES and WATCHERS
3.2. PRESENTITIESとウォッチャーの識別
A PRESENTITY is specified using the PRES URI scheme, which is further described in Appendix A. An example would be: "pres:fred@example.com"
PRESENTITYは、PRES URI計画(Appendix A.でさらに説明される)を使用することで指定されます。Anの例は以下の通りでしょう。 「pres: fred@example.com 」
WATCHERs identify themselves in the same manner as PRESENTITIES; that is, with a pres URI.
WATCHERsは、同じ方法による自分たちがPRESENTITIESであると認識します。 すなわち、pres URIで。
3.2.1. Address Resolution
3.2.1. アドレス解決
A presence service client determines the next hop to forward an operation to by resolving the domain name portion of the service destination. Compliant implementations SHOULD follow the guidelines for dereferencing URIs given in [2].
存在サービスクライアントは、次のホップが決議するのによるサービスの目的地のドメイン名部分に操作を送ると決心しています。 言いなりになっている実現SHOULDは[2]で与えられたURIに「反-参照をつけ」るためのガイドラインに従います。
3.3. Format of Presence Information
3.3. 存在情報の形式
This specification defines an abstract interoperability mechanism for presence protocols; the message content definition given here pertains to semantics rather than syntax. However, some important properties for interoperability can only be provided if a common end-to-end format for presence is employed by the interoperating presence protocols, especially with respect to security. In order to maintain end-to-end security properties, applications that send notification operations through a CPP gateway MUST support the format defined in PIDF [4]. Applications MAY support other content formats.
この仕様は存在プロトコルのために抽象的な相互運用性メカニズムを定義します。 ここに与えられたメッセージ内容定義は構文よりむしろ意味論に関係します。 しかしながら、共同利用存在プロトコルで存在のための終わりから終わりへの一般的な形式を使う場合にだけ、相互運用性のためのいくつかの重要な資産を提供できます、特にセキュリティに関して。 終わりから終わりへのセキュリティ特性を維持するために、CPPゲートウェイを通して通知操作を送るアプリケーションはPIDF[4]で定義された書式を支持しなければなりません。 アプリケーションは他の満足している形式を支持するかもしれません。
CPP gateways MUST be capable of relaying the body of a notification operation between supported presence protocols without needing to modify or inspect the content.
内容を変更するか、または点検する必要はなくて、CPPゲートウェイは支持された存在プロトコルの間の通知操作のボディーをリレーできなければなりません。
Peterson Standards Track [Page 6] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[6ページ]。
3.4. The Presence Service
3.4. 存在サービス
An implementation of the service must maintain information about both presence information and continual operations (like periodic notification) in persistent storage.
サービスの実現はしつこい格納で存在情報と絶え間ない操作の両方(周期的な通知のような)の情報を保守しなければなりません。
Note that the subscription-identifier attribute used by the subscribe operation is potentially long-lived. Accordingly, the values generated for this parameter should be unique across a significant duration of time. The SubscriptID parameter should be intrinsically globally unique over time, not merely unique among operations sent to or from a particular WATCHER and PRESENTITY.
申し込んでください。購読識別子属性が使用した注意、操作は潜在的に長命です。 それに従って、このパラメタのために発生する値は時間の重要な持続時間の向こう側にユニークであるべきです。 SubscriptIDパラメタはPRESENTITYか特定のWATCHERとPRESENTITYから送られた操作の中で単にユニークであるのではなく、時間がたつにつれて、本質的にグローバルにユニークであるべきです。
3.4.1. The Subscribe Operation
3.4.1. 操作を申し込んでください。
When an application wants to subscribe to the presence information associated with a PRESENTITY, it invokes the subscribe operation.
アプリケーションがいつ存在情報に加入したがっているかがPRESENTITYと交際した、呼び出す、操作を申し込んでください。
When the service is informed of the subscribe operation, it performs these steps:
サービスはいつにおいて知識があるか、操作を申し込んでください、そして、これらのステップを実行します:
1. If the watcher or target parameter does not refer to a valid
PRESENTITY, a response operation having status "failure" is
invoked.
1. ウォッチャーか目標パラメタが有効なPRESENTITYについて言及しないなら、状態「失敗」を持っている応答操作は呼び出されます。
2. If access control does not permit the application to request this
operation, a response operation having status "failure" is
invoked.
2. アクセス管理が、アプリケーションがこの操作を要求することを許可しないなら、状態「失敗」を持っている応答操作は呼び出されます。
3. If the duration parameter is non-zero, and if the watcher and
target parameters refer to an in-progress subscribe operation for
the application, a response operation having status "failure" is
invoked.
3. 持続時間パラメタが非ゼロに合わせて、ウォッチャーと目標パラメタが参照される、進行中では、操作がアプリケーションであることを予約してください、そして、状態「失敗」を持っているa応答操作が呼び出されます。
4. Otherwise, if the service is able to successfully deliver the
message:
4. サービスが別の方法で首尾よくメッセージを送ることができるなら:
A response operation having status "success" is immediately
invoked. (If the service chooses a different duration for the
subscription then it conveys this information in the response
operation.)
状態「成功」を持っている応答操作はすぐに、呼び出されます。 (サービスが購読のための異なった持続時間を選ぶなら、それは応答操作におけるこの情報を伝えます。)
A notify operation, corresponding to the target's presence
information, is immediately invoked for the watcher.
目標の存在情報に対応している、すぐに、ウォッチャーのために呼び出されますAが、操作に通知する。
Peterson Standards Track [Page 7] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[7ページ]。
For up to the amount of time indicated by the duration
parameter of the notify operation (measured from the time that
the subscribe operation was received), if the target's presence
information changes, and if access control allows, a notify
operation is invoked for the watcher.
持続時間パラメタによって示された時間まで操作に通知してください、(時間からそれを測定する、申し込み、操作を受けた、)、目標の存在情報が変化して、コントロールが許すアクセス、aが操作に通知する、ウォッチャーには、呼び出されます。
Note that if the duration parameter is zero-valued, then the subscribe operation is making a one-time poll of the presence information. Accordingly, the final step above (continued notifications for the duration of the subscription) does not occur.
操作を申し込んでください。持続時間パラメタが無評価されているなら、それに注意してください、そして存在情報の1回の投票をしています。 それに従って、(購読の持続時間のための継続的な通知)を超えた最終的なステップは起こりません。
When the service invokes a response operation as a result of this processing, the transID parameter is identical to the value found in the subscribe operation invoked by the application.
いつサービスがこの処理の結果、応答操作を呼び出して、transIDパラメタが見つけられた値と同じであるか、アプリケーションで呼び出された操作を申し込んでください。
3.4.2. The Notify Operation
3.4.2. 操作に通知してください。
The service invokes the notify operation whenever the presence information associated with a PRESENTITY changes and there are subscribers requesting notifications for that PRESENTITY.
サービスが呼び出す、PRESENTITYに関連している存在情報が変化して、そのPRESENTITYのための通知を要求する加入者がいるときはいつも、操作に通知してください。
There is no application response to the notify operation.
アプリケーション応答が全くない、操作に通知してください。
3.4.3. Subscribe Operation (with Zero Duration)
3.4.3. 操作を申し込んでください。(持続時間でない)
When an application wants to terminate a subscription, it issues a SUBSCRIBE 0 with the SubscriptID of an existing subscription. Note that a notify operation will be invoked by the presentity when a subscription is canceled in this fashion; this notification can be discarded by the watcher. There is no independent UNSUBSCRIBE operation.
アプリケーションが購読を終えたがっているとき、それは既存の購読のSubscriptIDと共に登録に0を発行します。 購読がこんなやり方で中止されるとき、呼び出されるaが操作にpresentityが通知する注意。 ウォッチャーはこの通知を捨てることができます。 独立者が全くいない、登録削除、操作。
When an application wants to directly request presence information to be supplied immediately without initiating any persistent subscription, it issues a SUBSCRIBE 0 with a new SubscriptID. There is no independent FETCH operation.
アプリケーションが、すぐどんなしつこい購読も開始しないで供給されるよう直接存在情報に要求したがっているとき、それは新しいSubscriptIDと共に登録に0を発行します。 どんな独立しているFETCH操作もありません。
4. Security Considerations
4. セキュリティ問題
Detailed security considerations for presence protocols given in RFC 2779 [6] (in particular, requirements are given in sections 5.1 through 5.3 with some motivating discussion in 8.2).
RFC2779[6](何かが8.2における議論を動機づけていて、特に、セクション5.1〜5.3で要件を与える)で与えられた存在プロトコルのための詳細なセキュリティ問題。
CPP defines an interoperability function that is employed by gateways between presence protocols. CPP gateways MUST be compliant with the minimum security requirements of the presence protocols with which they interface.
CPPは存在プロトコルの間のゲートウェイによって使われる相互運用性機能を定義します。 CPPゲートウェイはそれらが連結する存在プロトコルの最小のセキュリティ要件で言いなりになっているに違いありません。
Peterson Standards Track [Page 8] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[8ページ]。
The introduction of gateways to the security model of presence in RFC 2779 also introduces some new risks. End-to-end security properties (especially confidentiality and integrity) between presentities and watchers that interface through a CPP gateway can only be provided if a common presence format (such as the format described in [4]) is supported by the protocols interfacing with the CPP gateway.
また、RFC2779での存在の機密保護モデルへのゲートウェイの導入はいくつかの新しい危険を導入します。 一般的な存在形式である場合にだけCPPゲートウェイを通して連結するpresentitiesとウォッチャーの間の終わりから終わりへのセキュリティ資産(特に秘密性と保全)を提供できます。(CPPゲートウェイに連結して、形式が[4])で説明したようにプロトコルはそのようなものを支持します。
When end-to-end security is required, the notify operation MUST use PIDF, and MUST secure the PIDF MIME body with S/MIME [8], with encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS SignedData).
通知してください。終わりから終わりへのセキュリティが必要であるときに操作は、PIDFを使用しなければならなくて、S/MIME[8]でPIDF MIMEボディーを安全にしなければなりません、暗号化(CMS EnvelopeData)、そして/または、S/MIME署名(CMS SignedData)で。
The S/MIME algorithms are set by CMS [9]. The AES [11] algorithm should be preferred, as it is expected that AES best suits the capabilities of many platforms. Implementations MAY use AES as an encryption algorithm, but are REQUIRED to support only the baseline algorithms mandated by S/MIME and CMS.
S/MIMEアルゴリズムはCMS[9]によって設定されます。 AES[11]アルゴリズムは好まれるべきです、AESが多くのプラットホームの能力に最もよく合うと予想されるとき。実現は、暗号化アルゴリズムとしてAESを使用するかもしれませんが、S/MIMEによって強制された基線アルゴリズムだけを支持するREQUIREDとCMSです。
When PRES URIs are used in presence protocols, they convey the identity of watchers and/or presentities. Certificates that are used for S/MIME presence operations SHOULD, for the purposes of reference integrity, contain a subjectAltName field containing the PRES URI of their subject. Note that such certificates may also contain other identifiers, including those specific to particular presence protocols. In order to further facilitate interoperability of secure presence services through CPP gateways, users and service providers are encouraged to employ trust anchors for certificates that are widely accepted rather than trust anchors specific to any particular presence service or provider.
PRES URIが存在プロトコルに使用されるとき、彼らはウォッチャー、そして/または、presentitiesのアイデンティティを伝えます。 S/MIME存在操作SHOULD、参照保全の目的に使用される証明書はそれらの対象のPRES URIを含むsubjectAltName分野を含んでいます。 また、そのような証明書が特定の存在プロトコルに特定のものを含む他の識別子を含むかもしれないことに注意してください。 さらに安全にCPPゲートウェイを通した存在サービスの相互運用性を容易にするために、ユーザとサービスプロバイダーがどんな特定の存在サービスやプロバイダーにも特定であると広く信用アンカーよりむしろ受け入れられる証明書のために信用アンカーを雇うよう奨励されます。
In some cases, anonymous presence services may be desired. Such a capability is beyond the scope of this specification.
いくつかの場合、匿名の存在サービスは望まれるかもしれません。 そのような能力はこの仕様の範囲を超えています。
5. IANA Considerations
5. IANA問題
The IANA has assigned the "pres" URI scheme.
IANAは"pres"URI計画を割り当てました。
5.1. The PRES URI Scheme
5.1. PRES URI計画
The Presence (PRES) URI scheme designates an Internet resource, namely a PRESENTITY or WATCHER.
Presence(PRES)URI計画はすなわち、インターネット資料、PRESENTITYまたはWATCHERを指定します。
The syntax of a PRES URI is given in Appendix A.
Appendix AでPRES URIの構文を与えます。
Peterson Standards Track [Page 9] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[9ページ]。
6. Contributors
6. 貢献者
Dave Crocker edited earlier versions of this document.
デーヴ・クロッカーはこのドキュメントの以前のバージョンを編集しました。
The following individuals made substantial textual contributions to this document:
以下の個人はこのドキュメントへのかなりの原文の貢献をしました:
Athanassios Diacakis (thanos.diacakis@openwave.com)
Athanassios Diacakis( thanos.diacakis@openwave.com )
Florencio Mazzoldi (flo@networkprojects.com)
Florencio Mazzoldi( flo@networkprojects.com )
Christian Huitema (huitema@microsoft.com)
クリスチャンのHuitema( huitema@microsoft.com )
Graham Klyne (gk@ninebynine.org)
グラハムKlyne( gk@ninebynine.org )
Jonathan Rosenberg (jdrosen@dynamicsoft.com)
ジョナサン・ローゼンバーグ( jdrosen@dynamicsoft.com )
Robert Sparks (rsparks@dynamicsoft.com)
ロバートは活気があります。( rsparks@dynamicsoft.com )
Hiroyasu Sugano (suga@flab.fujitsu.co.jp)
菅野寛裕( suga@flab.fujitsu.co.jp )
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[2] Peterson, J., "Address Resolution for Instant Messaging and
Presence", RFC 3861, August 2004.
[2] ピーターソン、J.、「インスタントメッセージングと存在のためのアドレス解決」、RFC3861、2004年8月。
[3] Resnick, P., "Internet Message Format", STD 11, RFC 2822, April
2001.
[3] レズニック、P.、「インターネットメッセージ・フォーマット」、STD11、RFC2822、2001年4月。
[4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004.
[4] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
2000年2月の[5] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[6] 日、M.とAggarwal、S.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、2000年2月。
[7] Allocchio, C., "GSTN Address Element Extensions in Email
Services", RFC 2846, June 2000.
[7]Allocchio、C.、「メールサービスにおけるGSTNアドレス要素拡張子」、RFC2846、2000年6月。
Peterson Standards Track [Page 10] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[10ページ]。
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[8]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[9]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[10]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
7.2. Informative References
7.2. 有益な参照
[11] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm and in Cryptographic Message Syntax (CMS)",
RFC 3565, July 2003.
[11]Schaad、J.、「暗号化アルゴリズムと暗号のメッセージ構文(cm)におけるエー・イー・エス(AES)の使用」、RFC3565(2003年7月)。
Peterson Standards Track [Page 11] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[11ページ]。
Appendix A. PRES URI IANA Registration Template
付録A.PRES URI IANA登録テンプレート
This section provides the information to register the pres: presence URI .
このセクションはpresを登録するために情報を提供します: 存在URI。
A.1. URI Scheme Name
A.1。 URI計画名
pres
pres
A.2. URI Scheme Syntax
A.2。 URI計画構文
The syntax follows the existing mailto: URI syntax specified in RFC 2368. The ABNF is:
構文は既存のmailtoに続きます: URI構文はRFC2368で指定しました。 ABNFは以下の通りです。
PRES-URI = "pres:" [ to ] [ headers ] to = mailbox headers = "?" header *( "&" header ) header = hname "=" hvalue hname = *uric hvalue = *uric
PRES-URI=は「以下をpresします」。 []、“?"*(“&"ヘッダー)ヘッダー=hname「=」hvalue hname=*尿のhvalueヘッダー=メールボックスヘッダー==*への尿の[ヘッダー]
Here the symbol "mailbox" represents an encoded mailbox name as defined in RFC 2822 [3], and the symbol "uric" denotes any character that is valid in a URL (defined in RFC 2396 [10]).
ここで、RFC2822[3]、およびシンボルで「尿」で定義されて、「メールボックス」がコード化されたメールボックス名を表すシンボルはURLで有効な状態でそうするどんなキャラクタも指示します。(RFC2396[10])では、定義されます。
A.3. Character Encoding Considerations
A.3。 問題をコード化するキャラクター
Representation of non-ASCII character sets in local-part strings is limited to the standard methods provided as extensions to RFC 2822 [3].
地方の部分ストリングにおける、非ASCII文字の組の表現は拡大としてRFC2822[3]に提供された標準方法に制限されます。
A.4. Intended Usage
A.4。 意図している用法
Use of the pres: URI follows closely usage of the mailto: URI. That is, invocation of an PRES URI will cause the user's instant messaging application to start, with destination address and message headers fill-in according to the information supplied in the URI.
presの使用: URIは密接にmailtoの使用法に従います: ユリ。 ユーザのインスタントメッセージングアプリケーションはすなわち、PRES URIの実施で始まるでしょう、URIで提供された情報に従った送付先アドレスとメッセージヘッダー代理と共に。
A.5. Applications and/or Protocols which use this URI Scheme Name
A.5。 このURI Scheme Nameを使用するアプリケーション、そして/または、プロトコル
It is anticipated that protocols compliant with RFC 2779, and meeting the interoperability requirements specified here, will make use of this URI scheme name.
RFC2779に伴う対応することのプロトコルと、ここで指定された相互運用性必要条件を満たすとこのURI計画名が利用されると予期されます。
Peterson Standards Track [Page 12] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[12ページ]。
A.6. Interoperability Considerations
A.6。 相互運用性問題
The underlying exchange protocol used to send an instant message may vary from service to service. Therefore complete, Internet-scale interoperability cannot be guaranteed. However, a service conforming to this specification permits gateways to achieve interoperability sufficient to the requirements of RFC 2779.
インスタントメッセージを送るのに使用される基本的な交換プロトコルはサービスに対するサービスと異なるかもしれません。 したがって、完全なインターネットスケール相互運用性を保証できません。 しかしながら、この仕様に従うサービスは、ゲートウェイがRFC2779の要件に十分な相互運用性を達成することを許可します。
A.7. Security Considerations
A.7。 セキュリティ問題
See Section 4.
セクション4を見てください。
A.8. Relevant Publications
A.8。 関連刊行物
RFC 2779, RFC 2778
RFC2779、RFC2778
A.9. Person & Email Address to Contact for Further Information
A.9。 詳細のために連絡する人とEメールアドレス
Jon Peterson [mailto:jon.peterson@neustar.biz]
ジョン・ピーターソン[mailto: jon.peterson@neustar.biz ]
A.10. Author/Change Controller
A.10。 作者/変化コントローラ
This scheme is registered under the IETF tree. As such, IETF maintains change control.
この計画はIETF木の下に登録されます。 そういうものとして、IETFは変化コントロールを維持します。
A.11. Applications and/or Protocols which use this URI Scheme Name
A.11。 このURI Scheme Nameを使用するアプリケーション、そして/または、プロトコル
Instant messaging service; presence service
インスタントメッセージングサービス。 存在サービス
Appendix B. Issues of Interest
興味深い付録B.問題
This appendix briefly discusses issues that may be of interest when designing an interoperation gateway.
この付録は簡潔にinteroperationゲートウェイを設計するとき興味深いかもしれない問題について議論します。
B.1. Address Mapping
B.1。 アドレス・マッピング
When mapping the service described in this memo, mappings that place special information into the im: address local-part MUST use the meta-syntax defined in RFC2846 [7].
サービスを写像するとこのメモ、特別な情報を置くマッピングが中でいつまで説明されたか、不-、: アドレスの地方の一部がRFC2846[7]で定義されたメタ構文を使用しなければなりません。
B.2. Source-Route Mapping
B.2。 送信元経路マッピング
The easiest mapping technique is a form of source-routing and usually is the least friendly to humans having to type the string. Source- routing also has a history of operational problems.
最も簡単なマッピングのテクニックは、ソースルーティングのフォームであり、ストリングをタイプしなければならない人間には、通常、最も好意的ではありません。 また、ソースルーティングには、運転上の問題の歴史があります。
Peterson Standards Track [Page 13] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[13ページ]。
Use of source-routing for exchanges between different services is by a transformation that places the entire, original address string into the im: address local part and names the gateway in the domain part.
ソースルーティングの異なったサービスの間の交換の使用がそれが全体の、そして、オリジナルのアドレスストリングを置く変化である、不-、: そのドメインのゲートウェイが分ける地方の部分と名前を記述してください。
For example, if the destination INSTANT INBOX is "pepp://example.com/ fred", then, after performing the necessary character conversions, the resulting mapping is:
例えば、次に、必要なキャラクタ変換を実行した後に目的地INSTANT INBOXが「pepp://example.com/ fred」であるなら、結果として起こるマッピングは以下の通りです。
im:pepp=example.com/fred@relay-domain
不-、: peppは example.com/fred@relay-domain と等しいです。
where "relay-domain" is derived from local configuration information.
「リレードメイン」がローカルの設定情報から得られるところ。
Experience shows that it is vastly preferable to hide this mapping from end-users - if possible, the underlying software should perform the mapping automatically.
経験は、このマッピングをエンドユーザから隠すのが広大に望ましいのを示します--できれば、基本的なソフトウェアは自動的にマッピングを実行するはずです。
Appendix C. Acknowledgments
付録C.承認
The author would like to acknowledge John Ramsdell for his comments, suggestions and enthusiasm. Thanks to Derek Atkins for editorial fixes.
作者は彼のコメント、提案、および熱意のためにジョンRamsdellを承認したがっています。 編集のフィックスをデリック・アトキンスをありがとうございます。
Author's Address
作者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz
Peterson Standards Track [Page 14] RFC 3859 Common Profile for Presence August 2004
ピーターソンStandardsは2004年8月に存在のためにRFC3859の一般的なプロフィールを追跡します[14ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Peterson Standards Track [Page 15]
ピーターソン標準化過程[15ページ]
一覧
スポンサーリンク
