RFC 4481 - Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals 日本語訳

URL : https://tools.ietf.org/html/rfc4481
タイトル : RFC 4481 - 過去と未来の時間間隔のステータス情報を示すために、プレゼンス情報データフォーマットへの時限プレゼンス拡張機能（PIDF）
翻訳編集 : 自動生成

Network Working Group                                     H. Schulzrinne
Request for Comments: 4481                                   Columbia U.
Category: Standards Track                                      July 2006

                    Timed Presence Extensions to the
               Presence Information Data Format (PIDF) to
     Indicate Status Information for Past and Future Time Intervals

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2006）。

Abstract

抽象

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past.

プレゼンス情報データフォーマット（PIDF）は、プレゼンティティのプレゼンス情報を提示するための基本的なXMLフォーマットを定義します。この文書では、プレゼンティティが将来又は過去に完全に時間間隔の間その状態を宣言することを可能にする時限ステータス拡張（<時限ステータス>要素）を添加すること、PIDFを拡張します。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology and Conventions .....................................2
   3. Timed-Status Element ............................................3
   4. Example .........................................................4
   5. The XML Schema Definition .......................................5
   6. IANA Considerations .............................................6
      6.1. URN Sub-Namespace Registration for
           'urn:ietf:params:xml:ns:pidf:timed-status' .................6
      6.2. Schema Registration for Schema
           'urn:ietf:params:xml:ns:pidf:timed-status' .................7
   7. Security Considerations .........................................7
   8. References ......................................................7
      8.1. Normative References .......................................7
      8.2. Informative References .....................................7
   Contributor's Address ..............................................8
   Acknowledgements ...................................................8

1. Introduction

1. はじめに

Traditionally, presence information, e.g., represented as Presence Information Data Format [3] (PIDF) and augmented by Rich Presence Information Data format [9] (RPID), describes the current state of the presentity. However, a watcher can better plan communications if it knows about the presentity's future plans. For example, if a watcher knows that the presentity is about to travel, it might place a phone call earlier.

伝統的には、プレゼンス情報、例えば、プレゼンス情報データフォーマット[3]（PIDF）として表され、リッチプレゼンス情報データフォーマット[9]（RPID）によって増補、プレゼンティティの現在の状態を記述する。それはプレゼンの将来の計画について知っている場合は、ウォッチャーは、より良いコミュニケーションを計画することができます。ウォッチャーがプレゼンを旅行しようとしていることを知っている場合、それは以前に電話をかけるかもしれません。

In this document, we use terms defined in RFC 2778 [7]. In particular, a "presentity", abbreviating presence entity, provides presence information to a presence service. It is typically a uniquely-identified person.

この文書では、我々は、RFC 2778で定義された用語を使用する[7]。具体的には、「プレゼンティティ」、プレゼンスエンティティの省略は、プレゼンスサービスにプレゼンス情報を提供します。それは、典型的には、一意に識別さ人物です。

RPID already allows a presentity to indicate the period when a particular aspect of its presence is valid. However, the <status> element in the PIDF <tuple> does not have this facility, so that it is not possible to indicate that a presentity will be OPEN or CLOSED in the future, for example.

RPIDは、既にその存在の特定の態様が有効である期間を示すためにプレゼンを可能にします。プレゼンが、例えば、OPENまたは将来的に閉鎖されることを指示することはできないように、しかし、PIDF <組>で<状態>要素は、この機能を持っていません。

It is also occasionally useful to represent past information since it may be the only known presence information; it may give watchers an indication of the current status. For example, indicating that the presentity was at an off-site meeting that ended an hour ago indicates that the presentity is likely in transit at the current time.

唯一の既知のプレゼンス情報であってもよいので、過去の情報を表現することも時には有用です。それはウォッチャーに現在の状態の指示を与えることがあります。例えば、プレゼンは時間前に終わったオフサイトミーティングにあったことを示すと、プレゼンは、現在の時点で輸送中の可能性があることを示しています。

It is unfortunately not possible to simply add time range attributes to the PIDF <status> element, as PIDF parsers without this capability would ignore these attributes and thus not be able to distinguish current from future presence status information.

単に、この能力のないPIDFのパーサはこれらの属性を無視するため、将来のプレゼンスステータス情報からの電流を区別することができないとして、PIDF <状態>要素に属性時間範囲を追加するために、残念ながらできません。

This document defines the <timed-status> element that describes the status of a presentity that is either no longer valid or covers some future time period.

この文書では、どちらかもはや有効ではないか、いくつかの将来の期間をカバーしてプレゼンの状態を記述する<時限状況>要素を定義します。

2. Terminology and Conventions

2.用語と表記

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [1].

キーワード必要があり、必須、、、はならないSHOULD NOTこの文書でもよく、推奨、およびオプションのMUSTはBCP 14、RFC 2119に記載されているように[1]に解釈されるべきです。

3. Timed-Status Element

3.時限-status要素

The <timed-status> element is a child of the <tuple> element and MUST NOT appear as a child of a PIDF <status> element or another <timed-status> element. More than one such element MAY appear within a PIDF <tuple> element.

<時限状況>要素は、<タプル>要素の子であり、PIDF <状態>要素または別の<時限状況>要素の子として現れてはなりません。以上のような要素はPIDF <タプル>要素内に表示されることがあります。

Sources of <timed-status> information should avoid elements that overlap in time, but since overlapping appointments are common in calendars, for example, receivers MUST be able to render such overlapping <timed-status> indications.

<タイミングステータス>情報の源は、時間的に重複要素を避けるべきであるが、重複する予定がカレンダーに共通しているので、例えば、受信機は、このような重複<時限ステータス>表示をレンダリングすることができなければなりません。

The <timed-status> element MUST be qualified with the 'from' attribute and MAY be qualified with an 'until' attribute to describe the time when the status assumed this value and the time until which this element is expected to be valid. If the 'until' attribute is missing, the information is assumed valid until the tuple is explicitly overridden or expires as defined by the publication mechanism used. The time range MUST NOT encompass the present time, i.e., the PIDF <timestamp> value, as that would provide an unnecessary and confusing alternate mechanism to describe presence. Thus, the 'from' attribute for tuples without an 'until' attribute MUST refer to the future.

<時限状況>要素は、「から」属性で修飾する必要があり、ステータスがこの値と、この要素が有効であることが予想されるまでの時間を想定したときの時間を記述するために「まで」属性で修飾されるかもしれません。「まで」属性が指定されていない場合タプルが明示的に上書きまたは使用公表メカニズムによって定義されるように有効期限が切れるされるまで、情報が有効と想定されます。それが存在することを説明するため不要と混乱代替機構を提供するであろうような時間範囲は、現時点、即ち、PIDF <タイムスタンプ>の値を包含してはいけません。このように、「まで」属性のないタプルは「から」属性は、将来を参照しなければなりません。

During composition, a presence agent (PA) may encounter a stored <timed-status> element that covers the present time. The PA MAY either discard that element or MAY convert it to a regular <status> element if it considers that information more credible.

組成物中に、プレゼンスエージェント（PA）は、現在時刻を覆う格納されている<時限ステータス>要素に遭遇する可能性があります。 PAは、その要素を捨てるかもしれいずれか、またはそれはその情報がより信頼できると考える場合、通常の<状態>要素にそれを変換することができます。

The <timed-status> element may contain the <basic> and <note> elements, as well as any other element that is appropriate as a PIDF <status> extension and that has a limited validity period. Examples include the PIDF-LO [8] extensions for location objects.

<タイミングステータス>要素は、<基本>と<注意>要素、ならびにPIDF <状態>拡張として適切であり、それは限られた有効期間を有する任意の他の要素を含んでいてもよいです。例としては、位置オブジェクトのPIDF-LO [8]の拡張機能が含まれます。

This extension chose absolute rather than relative times, since relative times would be too hard to keep properly updated when spacing notifications, for example. Originators of presence information MUST generate time values in the <timed-status> elements that are fully in the past or future relative to local real (wallclock) time and the time information contained in the optional PIDF <timestamp> element.

相対時間は、例えば、適切に更新間隔の通知を維持するにはあまりにも難しいだろうから、この拡張は、絶対的ではなく相対時間を選択しました。プレゼンス情報の発信は、<タイミングステータス>ローカル実（ウォールクロック）時間および任意のPIDF <タイムスタンプ>要素に含まれる時刻情報に過去または将来の相対的で完全な要素の時間値を生成しなければなりません。

4. Example

4.例

An example combining PIDF and timed-status is shown below:

PIDFと時限ステータスを組み合わせた例を以下に示します。

<プレゼンスのxmlns =のxmlns "URN：IETF：paramsは：XML：NS PIDF"：TS = "URN：IETF：paramsは：XML：NS：PIDF：時限状態" エンティティ= "PRES：someone@example.com">

<tuple id="c8dqui"> <status> <basic>open</basic> </status> <ts:timed-status from="2005-08-15T10:20:00.000-05:00" until="2005-08-22T19:30:00.000-05:00"> <ts:basic>closed</ts:basic> </ts:timed-status> <contact>sip:someone@example.com</contact> </tuple> <note>I'll be in Tokyo next week</note> </presence>

<タプルID = "c8dqui"> <状態> <基本>開く</塩基性> </状態> <TS：時限ステータス=から "2005-08-15T10：20：00.000から05：00" = "2005まで-08-22T19：30：00.000から05：00" > <TS：>基本的な閉鎖</ TS：基本> </ TS：時限ステータス> <接点> SIP：someone@example.com </接触> </タプル> <私は東京で来週になるだろう>注意</注意> </プレゼンス>

5. The XML Schema Definition

5. XMLスキーマ定義

The XML [4] schema [5][6] is shown below.

XML [4]スキーマ[5] [6]以下に示されています。

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status" xmlns:pidf="urn:ietf:params:xml:ns:pidf" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:pidf:timed-status" elementFormDefault="qualified" attributeFormDefault="unqualified">

<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：のTS = "壷：IETF：のparams：XML：NS：PIDF：時限状態" のxmlns：PIDF = "壷：IETF ：paramsは：XML：NS：PIDF "のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のtargetNamespace = "URN：IETF：paramsは：XML：NS：PIDF：時限状態" のelementFormDefault ="資格の」attributeFormDefault = "非修飾">

<xs:import namespace="urn:ietf:params:xml:ns:pidf"/>

<XS：インポートの名前空間= "壷：IETF：のparams：XML：NS：PIDF" />

<xs:annotation> <xs:documentation> Describes timed-status tuple extensions for PIDF. </xs:documentation> </xs:annotation> <xs:element name="timed-status" type="ts:timed-status"/> <xs:complexType name="timed-status"> <xs:sequence> <xs:element name="basic" type="pidf:basic" minOccurs="0"/> <xs:element name="note" type="pidf:note" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="from" type="xs:dateTime" use="required"/> <xs:attribute name="until" type="xs:dateTime"/> </xs:complexType> </xs:schema>

<XS：注釈> <XS：ドキュメント> PIDFのための時限ステータスタプルの拡張機能について説明します。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：要素名= "時限状態" タイプ= "TS：時限状態" /> <XS：complexTypeの名= "時限状態"> <XS：シーケンス> <XS：要素名= "基本" タイプ= "PIDF：基本" のminOccurs = "0" /> <XS：要素名=タイプ= "PIDFを：注意" "注意" のminOccurs = "0" /> <XS：タイプ= "から" 属性名=任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：：シーケンス> <XS "のxs：dateTimeの" 使用=」必要な "/> <XS：属性名=" になるまで」タイプ= "XS：dateTimeの" /> </ XS：complexTypeの> </ XS：スキーマ>

6. IANA Considerations

6. IANAの考慮事項

This document calls for IANA to register a new XML namespace URN and schema per [2].

IANAは、[2]あたりの新しいXML名前空間のURNとスキーマを登録するためにこの文書では、呼び出します。

6.1. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:pidf:timed-status'

6.1. 以下のためのURNサブ名前空間の登録 '：IETF：のparams：XML：NS：URN PIDF：時限状態'

URI: urn:ietf:params:xml:ns:pidf:timed-status

URI：URN：IETF：のparams：XML：NS：PIDF：時限状態

Description: This is the XML namespace for XML elements defined by RFC 4481 to describe timed-status presence information extensions for the status element in the PIDF presence document format in the application/pidf+xml content type.

説明：これは、アプリケーション/ PIDF + XMLコンテンツタイプPIDFプレゼンス文書フォーマットのステータス要素の時限状況プレゼンス情報の拡張を記述するためにRFC 4481によって定義されたXML要素のXML名前空間です。

Registrant Contact: IETF, SIMPLE working group, simple@ietf.org; Henning Schulzrinne, hgs@cs.columbia.edu

登録者連絡先：IETF、SIMPLEワーキンググループ、simple@ietf.org。ヘニングSchulzrinneと、hgs@cs.columbia.edu

XML:

XML：

BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals</title> </head> <body> <h1>Namespace for timed-status presence extension</h1> <h2>urn:ietf:params:xml:ns:pidf:timed-status</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc4481.txt"> RFC4481</a>.</p> </body> </html> END

BEGINの<？xml version = "1.0"？> <！DOCTYPE htmlのをPUBLIC！ " - // W3C // DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/xhtml- basic10.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml <HEAD> <メタHTTP-当量= "コンテンツタイプ" コンテンツ= "text / htmlの;のcharset = ISO-8859-1 1" /> <タイトル>時限プレゼンスの拡張プレゼンス情報データフォーマット（PIDF）に時限ステータスプレゼンス拡張のための過去と未来の時間間隔</ TITLE> </ HEAD> <BODY> <H1>名前空間のステータス情報を示すために、 </ H1> <H2> URN：IETF：のparams：XML：NS：PIDF：時限状態</ H2> <P> <のhref = "http://www.rfc-editor.org/rfc/rfc4481を参照してください。 .TXT "> RFC4481 </a>でます。</ p> </ body> </ html>このEND

6.2. Schema Registration for Schema 'urn:ietf:params:xml:ns:pidf:timed-status'

6.2. スキーマのためのスキーマの登録 'URN：IETF：のparams：XML：NS：PIDF：時限状態'

URI: urn:ietf:params:xml:ns:pidf:timed-status

URI：URN：IETF：のparams：XML：NS：PIDF：時限状態

Registrant Contact: IESG

登録者連絡先：IESG

XML: See Section 5

XML：第5節を参照してください。

7. Security Considerations

7.セキュリティの考慮事項

The security issues are similar to those for RPID [9].

セキュリティ上の問題はRPID [9]の場合と同様です。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

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

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[2] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[2] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.

[3]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。

[4] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004.

[4] Yergeau、F.、パオリ、J.、Sperberg-マックィーン、C.、ブレイ、T.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第3版）"、W3C REC REC-XML- 20040204、2004年2月。

[5] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC-xmlschema-1-20041028, October 2004.

[5]マロニー、M.、ブナ、D.、トンプソン、H.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造第二版"、W3C REC REC-XMLSCHEMA-1から20041028、2004年10月。

[6] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.

[6]マルホトラ、A.、およびP.ビロン、 "XMLスキーマパート2：データ型第二版"、W3C REC REC-XMLSCHEMA-2から20041028、2004年10月。

8.2. Informative References

8.2. 参考文献

[7] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.

[7日目、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。

[8] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.

[8]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。

[9] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.

[9] Schulzrinneと、H.、Gurbani、V.、Kyzivat、P.、およびJ.ローゼンバーグが、 "RPID：リッチプレゼンス機能拡張プレゼンス情報データフォーマット（PIDF）に"、RFC 4480、2006年7月。

Contributor's Address

寄稿者の住所

Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054-2711 USA EMail: jdrosen@dynamicsoft.com

ジョナサン・ローゼンバーグdynamicsoft 600 Lanidexプラザパーシッパニー、ニュージャージー州07054から2711 USA電子メール：jdrosen@dynamicsoft.com

Acknowledgements

謝辞

This document is based on the discussions within the IETF SIMPLE working group. Mary Barnes, Avri Doria, Miguel Garcia, Vijay Gurbani, Hisham Khartabil, Paul Kyzivat, Mikko Lonnfors, Yannis Pavlidis and Jon Peterson provided helpful comments.

このドキュメントはIETF SIMPLEワーキンググループ内での議論に基づいています。メアリー・バーンズ、Avriドリア、ミゲル・ガルシア、ビジェイGurbani、ヒシャムKhartabil、ポールKyzivat、ミッコLonnfors、ヤニスPavlidisとジョン・ピーターソンは、役に立つコメントを提供しました。

Author's Address

著者のアドレス

Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US

コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部

Phone: +1 212 939 7004 EMail: hgs+simple@cs.columbia.edu URI: http://www.cs.columbia.edu

電話：+1 212 939 7004 Eメール：hgs+simple@cs.columbia.edu URI：http://www.cs.columbia.edu

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2006）。

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.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

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リポジトリから。

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 provided by the IETF Administrative Support Activity (IASA).

RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。