RFC5264 日本語訳
5264 Publication of Partial Presence Information. A. Niemi, M.Lonnfors, E. Leppanen. September 2008. (Format: TXT=30594 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Niemi
Request for Comments: 5264 M. Lonnfors
Category: Standards Track Nokia
E. Leppanen
Individual
September 2008
Niemiがコメントのために要求するワーキンググループA.をネットワークでつないでください: 5264年のM.Lonnforsカテゴリ: 規格は個々のノキアE.Leppanen2008年9月を追跡します。
Publication of Partial Presence Information
部分的な存在情報の公表
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information.
Event州PublicationのためのSession Initiationプロトコル(SIP)拡大は存在ユーザエージェントが存在情報を存在エージェントに発表できるメカニズムについて説明します。 Presence情報Data Format(PIDF)を使用して、それぞれの存在公表は完全な状態を含んでいます、前のアップデート以来その情報のどのくらいが実際に変化しているかにかかわらず。 結果として、ばら銭があるかなり大きい存在ドキュメントをアップデートするのは、かなりのオーバーヘッドを負担して、したがって、効率が悪いです。 特に低い帯域幅と高い潜在リンクで、これはかなりの負担をシステムに構成できます。 このメモはそれらの規制の影響を減少させる際に支援して、部分的な存在情報の公表を考慮するメカニズムを紹介するのによる輸送効率を増強するソリューションを定義します。
Niemi, et al. Standards Track [Page 1] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[1ページ]RFC5264
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions and Document Conventions ............................3
3. Overall Operation ...............................................3
3.1. Presence Publication .......................................3
3.2. Partial Presence Publication ...............................4
4. Client and Server Operation .....................................5
4.1. Content-Type for Partial Publications ......................5
4.2. Generation of Partial Publications .........................5
4.3. Processing of Partial Publications .........................7
4.3.1. Processing <pidf-full> ..............................7
4.3.2. Processing <pidf-diff> ..............................7
5. Security Considerations .........................................8
6. Examples ........................................................8
7. Acknowledgements ...............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
1. 序論…2 2. 定義とドキュメントコンベンション…3 3. 総合的な操作…3 3.1. 存在公表…3 3.2. 部分的な存在公表…4 4. クライアントとサーバ操作…5 4.1. 部分的な刊行物のためのコンテントタイプ…5 4.2. 部分的な刊行物の世代…5 4.3. 部分的な刊行物の処理…7 4.3.1. 処理<pidf完全な>…7 4.3.2. 処理<pidf-デフ>…7 5. セキュリティ問題…8 6. 例…8 7. 承認…12 8. 参照…12 8.1. 標準の参照…12 8.2. 有益な参照…13
1. Introduction
1. 序論
The Session Initiation Protocol (SIP) Extension for Event State
Publication [RFC3903] allows Presence User Agents ('PUA') to publish
presence information of a user ('presentity'). The Presence Agent
(PA) collects publications from one or several presence user agents,
and generates the composite event state of the presentity.
Event州Publication[RFC3903]のためのSession Initiationプロトコル(SIP)拡大で、Presence Userエージェント('PUA')はユーザ('presentity')の存在情報を発表できます。 Presenceエージェント(PA)は、1か数人の存在ユーザエージェントから刊行物を集めて、合成イベントがpresentityの状態であることを作ります。
The baseline format for presence information is defined in the Presence Information Data Format (PIDF) [RFC3863] and is by default used in presence publication. The PIDF uses Extensible Markup Language (XML) [W3C.REC-xml], and groups data into elements called tuples. In addition, [RFC4479], [RFC4480], [RFC4481], [RFC4482], and [RFC5196] define extension elements that provide various additional features to PIDF.
存在情報のための基線書式は、Presence情報Data Format(PIDF)[RFC3863]で定義されて、デフォルトで存在公表で使用されます。 PIDFは拡張マークアップ言語(XML)[W3C. REC-xml]を使用して、データをtuplesと呼ばれる要素に分類します。 さらに、[RFC4479]、[RFC4480]、[RFC4481]、[RFC4482]、および[RFC5196]は様々な付加的な機能をPIDFに供給する拡大要素を定義します。
Presence publication by default uses the PIDF document format, and each publication contains full state, regardless of how much of the presence information has actually changed since the previous update. As a consequence, updating a sizeable presence document especially with small changes bears a considerable overhead and is therefore inefficient. Publication of information over low bandwidth and high latency links further exacerbates this inefficiency.
存在公表はデフォルトでPIDFドキュメント・フォーマットを使用します、そして、各公表は完全な状態を含んでいます、前のアップデート以来存在情報のどのくらいが実際に変化しているかにかかわらず。 結果として、特にばら銭があるかなり大きい存在ドキュメントをアップデートするのは、かなりのオーバーヘッドを負担して、したがって、効率が悪いです。 低い帯域幅と高い潜在リンクの上の情報の公表はさらにこの非能率を悪化させます。
This memo specifies a mechanism with which the PUA is after an initial full state publication able to publish only those parts of the presence document that have changed since the previous update. This is accomplished using the partial PIDF [RFC5262] document format
このメモは前のアップデート以来変化している存在ドキュメントのそれらの部分しか発行できない初期の完全な州政府出版物のときに後、PUAがあるメカニズムを指定します。 これは部分的なPIDF[RFC5262]ドキュメント・フォーマットを使用するのに優れています。
Niemi, et al. Standards Track [Page 2] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[2ページ]RFC5264
to communicate a set of presence document changes to the PA, who then applies the changes in sequence to its version of the presence document.
次に連続して存在ドキュメントのバージョンへの変化を適用するPAへの1セットの存在ドキュメント変化を伝えるために。
This memo is structured in the following way: Section 3 gives an overview of the partial publication mechanism, Section 4 includes the detailed specification, Section 5 includes discussion of security considerations, and Section 6 includes examples of partial publication.
このメモは以下の方法で構造化されます: セクション3は部分的な公表メカニズムの概要を与えます、そして、セクション4は仕様詳細を含めます、そして、セクション5はセキュリティ問題の議論を含めます、そして、セクション6は部分的な公表に関する例を含めます。
2. Definitions and Document Conventions
2. 定義とドキュメントコンベンション
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119, BCP 14 [RFC2119], and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTがこと解釈されるのは中でRFC2119について説明しました、BCP14[RFC2119]であり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
This document makes use of the vocabulary defined in the Model for Presence and Instant Messaging [RFC2778], the Event State Publication Extension to SIP [RFC3903], and the PIDF Extension for Partial Presence [RFC5262].
このドキュメントはPresenceとInstant MessagingのためのModel[RFC2778]、SIPへのEvent州Publication Extension[RFC3903]、およびPartial PresenceのためのPIDF Extension[RFC5262]で定義されたボキャブラリーを利用します。
3. Overall Operation
3. 総合的な操作
This section introduces the baseline functionality for presence publication, and gives an overview of the partial publication mechanism. This section is informational in nature. It does not contain any normative statements.
このセクションは、存在公表のための基線の機能性を紹介して、部分的な公表メカニズムの概要を与えます。 このセクションは現実に情報です。 それは少しの規範的陳述も含んでいません。
3.1. Presence Publication
3.1. 存在公表
Event State Publication is specified in [RFC3903].
イベント州Publicationは[RFC3903]で指定されます。
The publication of presence information consists of a presence user agent sending a SIP PUBLISH request [RFC3903] targeted to the address-of-record of the presentity, and serviced by a presence agent or compositor. The body of the PUBLISH request carries full event state in the form of a presence document.
存在情報の公表はpresentityの記録されている住所に狙って、存在エージェントか植字工によって修理されたSIP PUBLISH要求[RFC3903]を送る存在ユーザエージェントから成ります。 PUBLISH要求のボディーは存在ドキュメントの形で完全なイベント状態を運びます。
The compositor processes the PUBLISH request and stores the presence information. It also assigns an entity-tag that is used to identify the publication. This entity-tag is returned to the PUA in the response to the PUBLISH request.
植字工は、PUBLISH要求を処理して、存在情報を保存します。 また、それは公表を特定するのに使用される実体タグを割り当てます。 PUBLISH要求への応答でこの実体タグをPUAに返します。
The PUA uses the entity-tag in the following PUBLISH request for identifying the publication that the request is meant to refresh, modify or remove. Presence information is stored in an initial
PUAは、リフレッシュすることになっているか、変更することになっているか、または要求が取り除くことになっている公表を特定するのに以下のPUBLISH要求で実体タグを使用します。 存在情報はイニシャルで保存されます。
Niemi, et al. Standards Track [Page 3] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[3ページ]RFC5264
publication, and maintained using the refreshing and modifying publications. Presence information disappears either by explicitly removing it or when it meets its expiration time.
公表と、リフレッシュを使用することで維持されて、刊行物を変更すること。 それを取り除くか、または満了時間を達成するとき情報が明らかに見えなくなる存在。
3.2. Partial Presence Publication
3.2. 部分的な存在公表
The partial publication mechanism enables the PUA to update only parts of its presence information, namely those sections of the presence document that have changed. The initial publication always carries full state. However, successive modifying publications to this initial presence state can communicate state deltas, i.e., one or more changes to the presence information since the previous update. Versioning of these partial publications is necessary to guarantee that the changes are applied in the correct order. The PUBLISH method [RFC3903] already accomplishes this using entity-tags and conditional requests, which guarantee correct ordering of publication updates.
部分的な公表メカニズムは、PUAが存在情報、すなわち、変化した存在ドキュメントのそれらのセクションの部分だけをアップデートするのを可能にします。 初期の公表はいつも完全な状態を運びます。 しかしながら、この初期の存在状態への連続した変更刊行物は州のデルタ(すなわち、前のアップデート以来の存在情報への1回以上の変化)を伝えることができます。 これらの部分的な刊行物のVersioningが、変化が正しいオーダーで適用されるのを保証するのに必要です。 PUBLISHメソッド[RFC3903]は、実体タグと条件付き要求(公表最新版の正しい注文を保証する)を使用することで既にこれを達成します。
Note that the partial PIDF format [RFC5262] contains the 'version'
attribute that could be used for versioning as well. However, we
chose not to introduce an additional versioning mechanism to
partial publish, since that would only add ambiguity and a
potentially undefined error case if the two versioning mechanisms
were to somehow contradict.
部分的なPIDF形式[RFC5262]がまた、versioningするのに使用されるかもしれない'バージョン'属性を含むことに注意してください。 しかしながら、私たちは、追加versioningメカニズムを部分的に紹介しないのを選びました。発行してください、それが2つのversioningメカニズムがどうにか反駁するだけことであるならあいまいさと潜在的に未定義の誤り事件を加えるので。
To initialize its publication of presence information, the PUA first publishes a full state initial publication. The consequent modifying publications can carry either state deltas or full state. Both initial and modifying partial presence publications are accomplished using the 'application/pidf-diff+xml' content type [RFC5262], with the former using the <pidf-full> root element, and the latter using the <pidf-diff> or <pidf-full> root elements, respectively.
存在情報の公表を初期化するために、PUAは最初に、完全な州の初期の刊行物を発行します。 刊行物を変更する結果は州のデルタか完全な状態のどちらかを運ぶことができます。 ともに初期と変更の部分的な存在刊行物は'アプリケーション/pidf-デフ+xml'content type[RFC5262]を使用するのに優れています、前者が<pidf完全な>根の要素を使用していて、後者がそれぞれ<pidf-デフ>の、または、<pidf完全な>根の要素を使用していて。
While the <pidf-full> encapsulates a regular PIDF document, the <pidf-diff> can contain one or more operations for adding new elements or attributes (<add> elements), replacing elements or attributes whose content has changed (<replace> elements), or indications of removal of certain elements or attributes (<remove> elements). The PUA is free to decide the granularity by which changes in presence information are communicated to the composer. It may very well happen that there are enough changes to be communicated that it is more efficient to send a full state publication instead of a set of state deltas.
<pidf完全な>が通常のPIDFドキュメントをカプセル化している間、<pidf-デフ>はある要素か属性の取り外しの新しい要素、属性(<は>要素を加える)、内容が変化した(<は>要素を置き換えます)要素か属性を置き換えるか、またはしるしを加えるための1つ以上の操作を含むことができます(<は>要素を取り除きます)。 PUAは自由に、存在情報における変化が作曲家に伝えられる粒状について決めることができます。 完全な州政府出版物を送るのが、より効率的であるコミュニケートできるくらいの変化が1セットの州のデルタの代わりにあるのは非常によく起こるかもしれません。
When the presence compositor receives a partial publication, it applies the included patch operations in sequence. The resulting changed (or patched) presence document is then submitted to the composition logic in the same manner as with a full state presence
存在植字工が部分的な刊行物を受け取るとき、それは連続して含まれているパッチ操作を適用します。 そして、完全な州の存在のように同じ方法で結果として起こる変えられた(または、パッチされる)存在ドキュメントを構成論理に提出します。
Niemi, et al. Standards Track [Page 4] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[4ページ]RFC5264
publication. Similarly, any changes to the publication expiration apply to the full, patched presence publication. In other words, there is no possibility to roll back to an earlier version, except by submitting a full state publication.
公表。 同様に、公表満了へのどんな変化も完全で、パッチしている存在公表に適用されます。 言い換えれば、以前のバージョンに逆行する可能性が全くありません、提出するのによる完全な州政府出版物を除いて。
4. Client and Server Operation
4. クライアントとサーバ操作
Unless otherwise specified in this document, the presence user agent and presence agent behavior are as defined in [RFC3903].
別の方法で本書では指定されない場合、存在ユーザエージェントと存在エージェントの振舞いが[RFC3903]で定義されるようにあります。
4.1. Content-Type for Partial Publications
4.1. 部分的な刊行物のためのコンテントタイプ
The entities supporting the partial publication extension described in this document MUST support the 'application/pidf-diff+xml' content type defined in the partial PIDF format [RFC5262], in addition to the baseline 'application/pidf+xml' content type defined in [RFC3863].
部分的な公表が本書では説明された拡大であるとサポートする実体は、'アプリケーション/pidf-デフ+xml'content typeが部分的なPIDFで書式[RFC5262]を定義しました、基線に加えて'アプリケーション/pidf+xml'が[RFC3863]で定義されたcontent typeであるとサポートしなければなりません。
Listing the partial PIDF content type in the Accept header field of a SIP response is an explicit indication of support for the partial publication mechanism. The PUA can learn server support either as a result of an explicit query, i.e., in a response to an OPTIONS request, or by trial-and-error, i.e., after a 415 error response is returned to an attempted partial publication.
SIP応答のAcceptヘッダーフィールドにおける部分的なPIDF content typeを記載するのは、部分的な公表メカニズムのサポートの明白なしるしです。 PUAはすなわち、OPTIONS要求への応答、または明白な質問の結果、試行錯誤でサーバサポートを学ぶことができます、すなわち、415誤り応答を試みられた部分的な刊行物に返した後に。
4.2. Generation of Partial Publications
4.2. 部分的な刊行物の世代
Whenever a PUA decides to begin publication of partial presence information, it first needs to make an initial publication. This initial publication always carries full state. After the initial publication, presence information can be updated using modifying publications; the modifications can carry state deltas as well as full state. Finally, the publication can be terminated by explicit removal, or by expiration.
PUAが、部分的な存在情報の公表を始めると決めるときはいつも、それは、最初に、初期の刊行物を作る必要があります。 この初期の公表はいつも完全な状態を運びます。 初期の公表の後に、変更刊行物を使用することで存在情報をアップデートできます。 変更は完全な状態と同様に州のデルタを運ぶことができます。 最終的に、明白な取り外し、または満了で公表を終えることができます。
Both the initial and modifying publications make use of the partial presence document format [RFC5262], and all follow the normal rules for creating publications, as defined in RFC 3903 [RFC3903], Section 4.
両方の初期と変更刊行物は部分的な存在ドキュメント・フォーマット[RFC5262]を利用します、そして、すべてが刊行物を作成するための正常な規則に従います、RFC3903[RFC3903]で定義されるように、セクション4。
If the initial PUBLISH request returns a 415 (Unsupported Media Type), it means that the compositor did not understand the partial publication format. In this case, the PUA MUST follow normal procedures for handling a 400-class response, as specified in Section 8.1.3.5 of [RFC3261]. Specifically, the PUA SHOULD retry the publication using the default PIDF content type, namely 'application/ pidf+xml'. In addition, to find out a priori whether a specific presence compositor supports partial presence publication, the PUA MAY use the OPTIONS method, as described in [RFC3261].
初期のPUBLISH要求が415(サポートされないメディアType)を返すなら、それは、植字工が部分的な公表形式を理解していなかったことを意味します。 この場合、プアは400クラスの応答を扱うための正常な手順に従わなければなりません、セクション8.1.3で.5[RFC3261]を指定するので。 明確に、PUA SHOULDは、すなわち、デフォルトPIDF content type、'アプリケーション/pidf+xml'を使用することで公表を再試行します。 さらに、特定の存在植字工が、部分的な存在が公表であるとサポートするかどうか先験的に見つけるのに、PUA MAYはOPTIONSメソッドを使用します、[RFC3261]で説明されるように。
Niemi, et al. Standards Track [Page 5] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[5ページ]RFC5264
To construct a full-state publication, the PUA uses the following process:
完全な州政府出版物を構成するために、PUAは以下のプロセスを使用します:
o The Content-Type header field in the PUBLISH request MUST be set
to the value 'application/pidf-diff+xml'.
o 値の'アプリケーション/pidf-デフ+xml'にPUBLISH要求におけるコンテントタイプヘッダーフィールドを設定しなければなりません。
o The document in the body of the request is populated with a <pidf-
full> root element that includes the 'entity' attribute set to
identify the presentity.
o 要求のボディーのドキュメントはpresentityを特定するために'実体'属性セットを含んでいる<pidf完全な>根の要素で居住されます。
o Under the <pidf-full> root element exists all of the children of a
PIDF [RFC3863] <presence> element. This document contains the
full state of which the PUA is aware, and MAY include elements
from any extension namespace.
o <pidf完全な>根の要素の下では、PIDF[RFC3863]<存在>要素の子供は皆、存在しています。 このドキュメントは、PUAが意識している完全な状態を含んでいて、どんな拡大名前空間からの要素も含むかもしれません。
To construct a partial publication, the following process is followed:
部分的な刊行物を構成するために、以下のプロセスは続かれています:
o The Content-Type header field in the PUBLISH request MUST be set
to the value 'application/pidf-diff+xml'.
o 値の'アプリケーション/pidf-デフ+xml'にPUBLISH要求におけるコンテントタイプヘッダーフィールドを設定しなければなりません。
o The document in the body of the request is populated with a <pidf-
diff> root element that includes the 'entity' attribute
identifying the presentity.
o 要求のボディーのドキュメントは<pidf-デフで居住されて、>がpresentityを特定する'実体'属性を含んでいる要素を根づかせるということです。
o Under the <pidf-diff> root element exists a set of patch
operations that communicate the changes to the presentity's
presence information. These operations MUST be constructed in
sequence, and as defined in the partial PIDF format [RFC5262].
o <のpidfデフの>根の要素の下では、presentityの存在情報への変化を伝える1セットのパッチ操作が存在しています。 系列、部分的なPIDF形式[RFC5262]で定義されるようにこれらの操作を構成しなければなりません。
The PUA is free to decide the granularity by which changes in the presentity's presence information are communicated to the presence compositor. In order to reduce unnecessary network traffic, the PUA SHOULD batch several patch operations in a single PUBLISH request.
PUAは自由に、presentityの存在情報における変化が存在植字工に伝えられる粒状について決めることができます。 独身のPUBLISHでのPUA SHOULDバッチいくつかのパッチ操作が、不要なネットワークが減少するために取引するよう要求します。
A reasonable granularity might be to batch state changes resulting
from related UI events together in a single PUBLISH request. For
example, when the user sets their status to "Away", several things
including freetext notes, service availability, and activities
might change as a result.
ただ一つのPUBLISH要求に関連するUIイベントから一緒に生じるバッチ州の変化には妥当な粒状があるかもしれません。 例えば、ユーザが「遠くへ」それらの状態を設定すると、freetext注意、サービスの有用性、および活動を含む数個のものがその結果変化するかもしれません。
If the size of the delta state becomes more than the size of the full state, the PUA SHOULD instead send a modifying publication carrying full state, unless this size comparison is not possible.
デルタ状態のサイズが完全な状態のサイズより多くなるなら、PUA SHOULDは変更刊行物に代わりに完全な状態を載せさせます、このサイズ比較が可能である場合。
To an implementation that generates state deltas directly out of
its internal events, it may not be trivial to determine the size
of the corresponding full state.
直接内部のイベントから状態がデルタであると生成する実装には、対応する完全な状態のサイズを決定するのは些細でないかもしれません。
Niemi, et al. Standards Track [Page 6] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[6ページ]RFC5264
4.3. Processing of Partial Publications
4.3. 部分的な刊行物の処理
For each resource, the compositor maintains a record for each of the publications. These are indexed using the entity-tag of the publications.
各リソースに関しては、植字工はそれぞれの刊行物のための記録を保守します。 刊行物の実体タグを使用することでこれらは索引をつけられます。
Processing of publications generally follows the guidelines set in [RFC3903]. In addition, processing PUBLISH requests that contain 'application/pidf-diff+xml' require some extra processing that is dependant on whether the request contains full or partial state.
一般に、刊行物の処理は[RFC3903]でガイドラインセットに続きます。 ''アプリケーション/pidf-デフ+xmlを含むPUBLISH要求を処理して、要求が完全であるか部分的な状態を含むかどうかに関してさらに、扶養家族である何らかの付加的な処理を必要としてください。
4.3.1. Processing <pidf-full>
4.3.1. 処理<pidf完全な>。
If the value of the Content-Type header field is 'application/ pidf-diff+xml', and the document therein contains a <pidf-full> root element, the publication contains full presence information, and the next step applies:
コンテントタイプヘッダーフィールドの値が'ドキュメントがそこに<pidf完全な>根の要素に含む'アプリケーション/pidf-デフ+xmlであるなら、公表は完全な存在情報を含んでいます、そして、次のステップは当てはまります:
o The compositor MUST take the received presence document under the
<pidf-full> as the local presence document, replacing any previous
publications.
o どんな前の刊行物も置き換えて、植字工はローカルの存在ドキュメントとして<pidf完全な>の下に受け取られていている存在ドキュメントをみなさなければなりません。
If any errors are encountered before the entire publication is completely processed, the compositor MUST reject the request with a 500 (Server Internal Error) response, and revert back to its original, locally stored presence information.
全体の公表が完全に処理される前に何か誤りが遭遇するなら、植字工は、500(サーバInternal Error)応答で要求を拒絶して、オリジナルの、そして、局所的に保存された存在情報に戻って戻らなければなりません。
4.3.2. Processing <pidf-diff>
4.3.2. 処理<pidf-デフ>。
If the value of the Content-Type header field is 'application/ pidf-diff+xml', and the document in the body contains a <pidf-diff> root element, the publication contains partial presence information (state delta), and the next steps apply:
コンテントタイプヘッダーフィールドの値が'アプリケーション/pidf-デフ+xmlで'、ボディーのドキュメントが<のpidfデフの>根の要素を含んでいるなら、公表は部分的な存在情報(州のデルタ)を含んでいます、そして、次のステップは当てはまります:
o If the publication containing the <pidf-diff> root element is a
modifying publication (i.e., contains an If-Match header field
with a valid entity-tag), the compositor MUST apply the included
patch operations in sequence against its locally stored presence
document.
o <pidf-デフを含む公表であるなら>根の要素が変更刊行物(すなわち、有効な実体タグがあるIf-マッチヘッダーフィールドを含んでいる)である、植字工は連続して局所的に保存された存在ドキュメントに対して含まれているパッチ操作を適用しなければなりません。
o Else, the publication is an initial publication, for which only
<pidf-full> is allowed. Therefore, the publication MUST be
rejected with an appropriate error response, such as a 400
(Invalid Partial Publication).
o ほかに、公表は初期の刊行物です。(<pidf完全な>だけがその刊行物に関して許容されています)。 したがって、400などの適切な誤り応答(無効のPartial Publication)で公表を拒絶しなければなりません。
If a publication carrying partial presence information expires without the PUA refreshing it, the compositor MUST clear the entire, full state publication.
PUAがそれをリフレッシュしないで部分的な存在情報を運ぶ刊行物が期限が切れるなら、植字工は全体の、そして、完全な州政府出版物をクリアしなければなりません。
Niemi, et al. Standards Track [Page 7] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[7ページ]RFC5264
This means that the compositor does not keep a record of the
applied patches, and consequently (unlike some versioning
systems), the compositor does not roll back to an earlier version
if a particular partial publication were to expire.
これは、植字工が適用されたパッチに関する記録をつけないことを意味します、そして、その結果(いくつかのversioningシステムと異なって)、植字工は特定の部分的な刊行物が期限が切れることであったなら以前のバージョンに逆行しません。
If the compositor encounters errors while processing the 'application/pidf-diff+xml' document, it MUST reject the request with a 400 (Bad Request) response. In addition, the compositor MAY include diagnostics information in the body of the response, using an appropriate error condition element defined in Section 5.1. of [RFC5261].
植字工が'アプリケーション/pidf-デフ+xml'文書を処理している間、誤りに遭遇するなら、それは400(悪いRequest)応答で要求を拒絶しなければなりません。 さらに、植字工は病気の特徴を入れるかもしれません。応答のボディーの情報、[RFC5261]のセクション5.1で定義された適切なエラー条件要素を使用すること。
If any other errors are encountered before the entire partial publication is completely processed, including all of the patch operations in the 'application/pidf-diff+xml' body, the compositor MUST reject the request with a 500 (Server Internal Error) response, and revert back to its original, locally stored presence information.
全体の部分的な公表が完全に処理される前に他の誤りが遭遇するなら、'アプリケーション/pidf-デフ+xml'ボディーにパッチ操作のすべてを含んでいる植字工は、500(サーバInternal Error)応答で要求を拒絶して、オリジナルの、そして、局所的に保存された存在情報に戻って戻らなければなりません。
5. Security Considerations
5. セキュリティ問題
This specification relies on protocol behavior defined in [RFC3903]. General security considerations related to Event State Publication are extensively discussed in that specification and all the identified security considerations apply to this document in entirety. In addition, this specification adds no new security considerations.
この仕様は[RFC3903]で定義されたプロトコルの振舞いに依存します。 仕様とすべての特定されたセキュリティ問題が全体でこのドキュメントに適用されるので、手広くEvent州Publicationに関連する総合証券問題について議論します。 さらに、この仕様はどんな新しいセキュリティ問題も加えません。
6. Examples
6. 例
The following message flow (Figure 1) shows an example of a presence system that applies the partial publication mechanism.
以下のメッセージ流動(図1)は部分的な公表メカニズムを当てはまる存在システムに関する例を示しています。
First, the PUA sends an initial publication that contains full state. In return, it receives a 200 OK response containing an entity-tag. This entity-tag serves as a reference with which the initial full state can be updated using partial publications containing state deltas.
まず最初に、PUAは完全な状態を含む初期の刊行物を送ります。 代わりに、それは実体タグを含む200OK応答を受けます。 州のデルタを含む部分的な刊行物を使用することで初期の完全な状態をアップデートできるこの実体タグは参考になります。
Then at some point the resource state changes, and the PUA assembles these changes into a set of patch operations. It then sends a modifying publication containing the patch operations, using the entity-tag as a reference to the publication against which the patches are to be applied. The compositor applies the received patch operations to its local presence document in sequence, and returns a 200 OK, which includes a new entity-tag.
そして、いくつかでは、リソース州の変化を指してください。そうすれば、PUAは1セットのパッチ操作へのこれらの変化を組み立てます。 次に、それはパッチ操作を含む変更刊行物を送ります、適用されているパッチがことである公表の参照として実体タグを使用して。 植字工は、連続して容認されたパッチ操作をローカルの存在ドキュメントに適用して、200OKを返します。(それは、新しい実体タグを含んでいます)。
Niemi, et al. Standards Track [Page 8] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[8ページ]RFC5264
Presence Agent /
PUA Compositor
| (M1) PUBLISH |
|---------------------------->|
| (M2) 200 OK |
|<----------------------------|
| |
| |
| |
| (M3) PUBLISH |
|---------------------------->|
| (M4) 200 OK |
|<----------------------------|
| |
_|_ _|_
存在エージェント/PUA植字工| (M1) 発行してください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| (M2) 200 OK| |<----------------------------| | | | | | | | (M3) 発行してください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| (M4) 200 OK| |<----------------------------| | | _|_ _|_
Figure 1: Partial Publication Message Flow
図1: 部分的な公表メッセージ流動
Message details:
メッセージの詳細:
(M1): PUA -> Compositor
(M1): PUA->植字工
PUBLISH sip:resource@example.com SIP/2.0
...
Event: presence
Expires: 3600
Content-Type: application/pidf-diff+xml
Content-Length: 1457
PUBLISHはちびちび飲みます: resource@example.com SIP/2.0 イベント: 存在Expires: 3600年のコンテントタイプ: pidf-デフ+xml Contentアプリケーション/長さ: 1457
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
entity="pres:someone@example.com">
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ完全..等しい..つぼ..つぼ..デフ..つぼ..つぼ..上限..実体..等しい
<tuple id="sg89ae">
<status>
<basic>open</basic>
<r:relationship>assistant</r:relationship>
</status>
<c:servcaps>
<c:audio>true</c:audio>
<c:video>false</c:video>
<c:message>true</c:message>
</c:servcaps>
<contact priority="0.8">tel:09012345678</contact>
</tuple>
<tupleイド=、「sg89ae、「><状態の>の<の基本的な>は</基礎><r: 関係>アシスタント</r: 関係></状態><c: servcaps><c: オーディオの>の本当の</cを開きます」; オーディオ><c: ビデオの>の誤った</c: ビデオ><c: メッセージの>の本当の</c: メッセージ></c: servcaps><接触優先権は「0.8インチの>tel:09012345678</接触></tuple>」と等しいです。
Niemi, et al. Standards Track [Page 9] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[9ページ]RFC5264
<tuple id="cg231jcr">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">im:pep@example.com</contact>
</tuple>
<tupleイド=、「cg231jcr「>の<の状態の>の<の基本的な>開いている</基本的な></状態><接触優先権=」の1インチの>、不-、: pep@example.com 、lt;、/接触の></tupleな>、」
<tuple id="r1230d">
<status>
<basic>closed</basic>
<r:activity>meeting</r:activity>
</status>
<r:homepage>http://example.com/~pep/</r:homepage>
<r:icon>http://example.com/~pep/icon.gif</r:icon>
<r:card>http://example.com/~pep/card.vcd</r:card>
<contact priority="0.9">sip:pep@example.com</contact>
</tuple>
<tupleイド=、「r1230d、「><状態の>の<の基本的な>は</r: 活動></状態><rに会う</基本的な><r: 活動>を閉じました: ホームページ>のhttp://例」; com/~気力/</r: ホームページ><r: アイコン>http://example.com/~気力/icon.gif</r: アイコン><r: カード>http://example.com/~気力/card.vcd</r: カード><接触優先権が等しい、「0.9インチの>一口: pep@example.com 、lt;、/接触の></tupleな>、」
<note xml:lang="en">Full state presence document</note>
<r:person>
<r:status>
<r:activities>
<r:on-the-phone/>
<r:busy/>
</r:activities>
</r:status>
</r:person>
<注意xml: langが等しい、「アン、「>Fullは存在ドキュメント</注意><r: 人の><r: 状態><r: 活動><r: 電話の/><rを述べます: /></r: 活動></r: 状態></r: 人の>と忙しくしてください」
<r:device id="urn:esn:600b40c7">
<r:status>
<c:devcaps>
<c:mobility>
<c:supported>
<c:mobile/>
</c:supported>
</c:mobility>
</c:devcaps>
</r:status>
</r:device>
<r: デバイスイド=「つぼ:esn:600b40c7"><r: 状態><c: devcaps><c: 移動性><c: サポートしている><c: モバイル/></c: サポートしている></c: 移動性></c: devcaps></r: 状態></r: デバイス>」
</p:pidf-full>
</p: pidf完全な>。
Niemi, et al. Standards Track [Page 10] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[10ページ]RFC5264
(M2): Compositor -> PUA
(M2): 植字工->PUA
SIP/2.0 200 OK
...
SIP-ETag: 61763862389729
Expires: 3600
Content-Length: 0
一口/2.0 200に、OK… 一口ETag: 61763862389729 期限が切れます: 3600年のコンテンツの長さ: 0
(M3): PUA -> Compositor
(M3): PUA->植字工
PUBLISH sip:resource@example.com SIP/2.0
...
Event: presence
SIP-If-Match: 61763862389729
Expires: 3600
Content-Type: application/pidf-diff+xml
Content-Length: 778
PUBLISHはちびちび飲みます: resource@example.com SIP/2.0 イベント: 存在、SIP、マッチである、: 61763862389729 期限が切れます: 3600年のコンテントタイプ: pidf-デフ+xml Contentアプリケーション/長さ: 778
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-diff xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
entity="pres:someone@example.com">
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><p: pidf-デフxmlns=「つぼ:ietf:params:xml:ナノ秒: pidf」xmlns: p=「つぼ:ietf:params:xml:ナノ秒: pidfデフ」「つぼ:ietf:params:xml:ナノ秒:pidf:rpid」xmlns: r=実体=「pres: someone@example.com 」、gt。
<p:add sel="presence/note" pos="before"><tuple id="ert4773">
<status>
<basic>open</basic>
</status>
<contact priority="0.4">mailto:pep@example.com</contact>
<note xml:lang="en">This is a new tuple inserted
between the last tuple and note element</note>
</tuple>
<p: 「存在/注意」pos="before"><tuple sel=イド=を加えてください、「0.4インチのert4773「>の<の状態の>の<の基本的な>開いている</基本的な></状態><接触優先権=」>mailto: pep@example.com 、lt;、/接触><注意xml: langが等しい、「「>Thisは最後のtupleの間に挿入された新しいtupleと注意要素</注意></tuple>アンです」。
</p:add>
<p:replace sel="*/tuple[@id='r1230d']/status/basic/text()"
>open</p:replace>
「</p: ><pを加えてください: 」 */tuple[@idは'r1230d'と等しい]sel=/status/basic/text()を取り替えてください」>戸外</p: >を取り替えてください。
<p:remove sel="*/r:person/r:status/r:activities/r:busy"/>
「<p: sel=を取り外してください」という*/r: 人/r: 状態/r: 活動/r: 」 />と忙しくしてください。
<p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority"
>0.7</p:replace>
「<p: 」 */tuple[@idは'cg231jcr'と等しい]sel= /contact/@priority を取り替えてください」、gt;、0.7</p: >を取り替えてください。
</p:pidf-diff>
</p: pidfデフ>。
Niemi, et al. Standards Track [Page 11] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[11ページ]RFC5264
(M4): Compositor -> PUA
(M4): 植字工->PUA
SIP/2.0 200 OK
...
SIP-ETag: 18764920981476
Expires: 3600
Content-Length: 0
一口/2.0 200に、OK… 一口ETag: 18764920981476 期限が切れます: 3600年のコンテンツの長さ: 0
7. Acknowledgements
7. 承認
The authors would like to thank Atle Monrad, Christian Schmidt, George Foti, Fridy Sharon-Fridman, and Avshalom Houri for review comments.
作者はレビューコメントについてAtle Monrad、クリスチャンのシュミット、ジョージFoti、Fridyシャロン-フリドマン、およびAvshalom Houriに感謝したがっています。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP)
Extension for Event State Publication", RFC 3903,
October 2004.
[RFC3903]Niemi、A.、「イベント州政府出版物のためのセッション開始プロトコル(一口)拡大」、RFC3903、2004年10月。
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A.,
Carr, W., and J. Peterson, "Presence Information Data
Format (PIDF)", RFC 3863, August 2004.
[RFC3863] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC5262] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H.
Khartabil, "Presence Information Data Format (PIDF)
Extension for Partial Presence", RFC 5262, September
2008.
[RFC5262] Lonnfors、M.、コスタ-レケナ、J.、Leppanen、E.、およびH.Khartabil、「存在インフォメーション・データは部分的な存在のために(PIDF)拡大をフォーマットします」、RFC5262、2008年9月。
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML)
Patch Operations Framework Utilizing XML Path Language
(XPath) Selectors", RFC 5261, September 2008.
[RFC5261] Urpalainen、J.、「XML経路言語(XPath)セレクタを利用する拡張マークアップ言語(XML)パッチ操作枠組み」、RFC5261(2008年9月)。
Niemi, et al. Standards Track [Page 12] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[12ページ]RFC5264
8.2. Informative References
8.2. 有益な参照
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778,
February 2000.
2000年2月の[RFC2778]日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC4479] ローゼンバーグ、J.、「存在のためのデータモデル」、RFC4479、2006年7月。
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)", RFC 4480,
July 2006.
[RFC4480] Schulzrinne、H.、Gurbani、V.、Kyzivat、P.、およびJ.ローゼンバーグ、「RPID:」 「存在情報データの形式(PIDF)への豊かな存在拡大」、RFC4480、2006年7月。
[RFC4481] Schulzrinne, H., "Timed Presence Extensions to the
Presence Information Data Format (PIDF) to Indicate
Status Information for Past and Future Time
Intervals", RFC 4481, July 2006.
[RFC4481]Schulzrinne(H.)は「過去の、そして、将来の時間間隔の間の状態情報を示すために存在情報データの形式(PIDF)に存在拡大を調節しました」、RFC4481、2006年7月。
[RFC4482] Schulzrinne, H., "CIPID: Contact Information for the
Presence Information Data Format", RFC 4482,
July 2006.
[RFC4482]Schulzrinne、H.、「CIPID:」 「存在情報データの形式のための問い合わせ先」、RFC4482、2006年7月。
[RFC5196] Lonnfors, M. and K. Kiss, "Session Initiation Protocol
(SIP) User Agent Capability Extension to Presence
Information Data Format (PIDF)", RFC 5196, September
2008.
[RFC5196]Lonnfors、M.とK.キス、「存在情報データの形式(PIDF)へのセッション開始プロトコル(一口)ユーザエージェント能力拡大」RFC5196(2008年9月)。
[W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C., and E.
Maler, "Extensible Markup Language (XML) 1.0 (2nd
ed)", W3C REC-xml, October 2000,
<http://www.w3.org/TR/REC-xml>.
T.、パオリ、J.、Sperberg-マックィーン、C.、およびE.Maler、「拡張マークアップ言語(XML)1.0(2番目の教育)」を[W3C. REC-xml]は、いななかせます、W3C REC-xml、2000年10月、<http://www.w3.org/TR/REC-xml>。
Niemi, et al. Standards Track [Page 13] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[13ページ]RFC5264
Authors' Addresses
作者のアドレス
Aki Niemi Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
アキNiemiノキア私書箱407Nokia Group、FIN00045フィンランド
Phone: +358 71 8008000 EMail: aki.niemi@nokia.com
以下に電話をしてください。 +358 71 8008000はメールされます: aki.niemi@nokia.com
Mikko Lonnfors Nokia Itamerenkatu 11-13 Helsinki Finland
ミッコLonnforsノキアItamerenkatu11-13ヘルシンキフィンランド
Phone: +358 71 8008000 EMail: mikko.lonnfors@nokia.com
以下に電話をしてください。 +358 71 8008000はメールされます: mikko.lonnfors@nokia.com
Eva Leppanen Individual Lempaala Finland
エバLeppanen個人Lempaalaフィンランド
EMail: eva.leppanen@saunalahti.fi
メール: eva.leppanen@saunalahti.fi
Niemi, et al. Standards Track [Page 14] RFC 5264 Partial Publication September 2008
Niemi、他 公表2008年9月に部分的な標準化過程[14ページ]RFC5264
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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.
このドキュメントは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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Niemi, et al. Standards Track [Page 15]
Niemi、他 標準化過程[15ページ]
一覧
スポンサーリンク
