[要約] RFC 4481は、PIDFに過去および将来の時間間隔の状態情報を示すためのタイムドプレゼンス拡張に関するものです。このRFCの目的は、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
存在情報データ形式（PIDF）へのタイミング付きプレゼンス拡張は、過去および将来の時間間隔のステータス情報を示す
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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を拡張し、タイムされたステータス拡張機能（<Timed-Status>要素）を追加して、将来または過去に完全に時間間隔のステータスを宣言できるようにします。
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
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）によって拡張され、現在の現状を説明しています。ただし、Watcherは、プレゼントの将来の計画を知っていれば、コミュニケーションをより適切に計画できます。たとえば、ウォッチャーがプレゼンテーションが旅行しようとしていることを知っている場合、それは早く電話をかけるかもしれません。
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は、存在の特定の側面が有効である期間を示すことが既に紹介されています。ただし、PIDF <tuple>の<status>要素にはこの施設がないため、たとえば、将来的にはプレゼンティが開かれているか閉鎖されることを示すことはできません。
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.
また、唯一の既知の存在情報である可能性があるため、過去の情報を表現することも時々便利です。ウォッチャーに現在のステータスの兆候を与える可能性があります。たとえば、1時間前に終了したオフサイトの会議でのプレゼントがあったことを示していることは、現在の時期に輸送が可能である可能性が高いことを示しています。
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 <status>要素に時間範囲属性を単に追加することはできません。
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.
このドキュメントは、もはや有効でないか、将来の期間をカバーするプレゼンティのステータスを記述する<タイミングステータス>要素を定義します。
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].
キーワードは、このドキュメントでは、BCP 14、RFC 2119 [1]に記載されているように解釈されるように解釈する必要があります。
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.
<Timed-status>要素は<tuple>要素の子であり、pidf <status>要素または別の<timed-status>要素の子として表示されてはなりません。そのような要素は、PIDF <Tuple>要素内に表示される場合があります。
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.
<timed-status>情報のソースは、時間内に重複する要素を回避する必要がありますが、たとえばカレンダーでは上位の予定が一般的であるため、受信者はそのような重複<タイムステータス>表示をレンダリングできる必要があります。
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.
<Timed-status>要素は、「From」属性で適格であり、ステータスがこの値を想定した時間と、この要素が有効になると予想される時間を記述するために、 'till'属性で適格である必要があります。'ut'属性が欠落している場合、タプルが明示的にオーバーライドされるか、使用された出版メカニズムによって定義されているように有効になるまで情報が有効になっています。時間範囲は、現在の時間、つまりPIDF <タイムスタンプ>値を包含してはなりません。したがって、「from」tulpleの「from」属性は、 'till'属性が将来を参照する必要があります。
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は、その要素を廃棄するか、その情報がより信頼できると考える場合、通常の<status>要素に変換する場合があります。
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.
<timed-status>要素には、pidf <status>拡張機能として適切であり、有効期間が限られている他の要素と同様に、<basic> and <mote>要素が含まれる場合があります。例には、ロケーションオブジェクトの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.
たとえば、通知を間隔で適切に更新するのが難しすぎるため、この拡張機能は相対的な時間ではなく絶対的な時間を選択します。存在情報の創始者は、ローカルReal（Wallclock）の時間とオプションのPIDF <Timestamp>要素に含まれる時間情報に比べて、過去または未来に完全にある<タイミングステータス>要素に時間値を生成する必要があります。
An example combining PIDF and timed-status is shown below:
PIDFとタイムステータスを組み合わせた例を以下に示します。
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status"
entity="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>
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">
<xs:import namespace="urn: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>
This document calls for IANA to register a new XML namespace URN and schema per [2].
このドキュメントでは、IANAが新しいXMLネームスペースURNとスキーマを登録することを求めています[2]。
6.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:timed-status'
URI: urn:ietf:params:xml:ns:pidf:timed-status
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.
説明：これは、RFC 4481で定義されたXML要素のXMLネームスペースであり、アプリケーション/PIDF XMLコンテンツタイプのPIDF存在ドキュメント形式のステータス要素のタイムステータス存在情報拡張を記述します。
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org;
Henning 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
6.2. Schema Registration for Schema
'urn:ietf:params:xml:ns:pidf:timed-status'
URI: urn:ietf:params:xml:ns:pidf:timed-status
Registrant Contact: IESG
登録者の連絡先：IESG
XML: See Section 5
XML：セクション5を参照してください
The security issues are similar to those for RPID [9].
セキュリティの問題は、RPID [9]の問題に似ています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（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.、Paoli、J.、Sperberg-Mcqueen、C.、Bray、T.、およびE. Maler、「拡張マークアップ言語（XML）1.0（第3版）」、W3C Rec Rec-XML-20040204、2月2004年。
[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] Maloney、M.、Beech、D.、Thompson、H。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、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] Malhotra、A。およびP. Biron、「XML Schema Part 2：DataTypes Second Edition」、W3C Rec Rec-XMLSchema-20041028、2004年10月。
[7] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[7] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、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. Rosenberg、「rpid：Rich Expentionが存在情報データ形式（PIDF）（PIDF）への拡張」、RFC 4480、2006年7月。
Contributor's Address
貢献者の住所
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054-2711 USA EMail: jdrosen@dynamicsoft.com
Jonathan Rosenberg Dynamicsoft 600 Lanidex Plaza Parsippany、NJ 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ワーキンググループ内の議論に基づいています。メアリー・バーンズ、アヴリ・ドリア、ミゲル・ガルシア、ヴィジェイ・ガルバニ、ヒシャム・ハルタビル、ポール・キジバット、ミッコ・ロンフォース、ヤニス・パブリディス、ジョン・ピーターソンは有益なコメントを提供しました。
Author's Address
著者の連絡先
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs+simple@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。