RFC4079 日本語訳

4079 A Presence Architecture for the Distribution of GEOPRIV LocationObjects. J. Peterson. July 2005. (Format: TXT=16718 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        J. Peterson
Request for Comments: 4079                                       NeuStar
Category: Informational                                        July 2005

コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 4079年のNeuStarカテゴリ: 情報の2005年7月

                    A Presence Architecture for the
                Distribution of GEOPRIV Location Objects

GEOPRIV位置のオブジェクトの分配のための存在アーキテクチャ

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   GEOPRIV defines the concept of a 'using protocol' -- a protocol that
   carries GEOPRIV location objects.  GEOPRIV also defines various
   scenarios for the distribution of location objects that require the
   concepts of subscriptions and asynchronous notifications.  This
   document examines some existing IETF work on the concept of presence,
   shows how presence architectures map onto GEOPRIV architectures, and
   moreover demonstrates that tools already developed for presence could
   be reused to simplify the standardization and implementation of
   GEOPRIV.

GEOPRIVは'使用プロトコル'の概念を定義します--GEOPRIV位置のオブジェクトを運ぶプロトコル。 また、GEOPRIVは購読と非同期な通知の概念を必要とする位置の目的の分配のために様々なシナリオを定義します。 このドキュメントは、IETFが存在の概念を扱ういくつかの存在を調べて、存在アーキテクチャがどうアーキテクチャをGEOPRIVに写像するかを示していて、そのうえ、GEOPRIVの標準化と実装を簡素化するために存在のために既に開発されたツールは再利用できたのを示します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Framework Analysis ..............................................2
   3. Presence Architecture for GEOPRIV ...............................3
   4. GEOPRIV Extensions to PIDF ......................................5
   5. Security Considerations .........................................5
   6. Acknowledgements ................................................5
   7. Informative References ..........................................6

1. 序論…2 2. フレームワーク分析…2 3. GEOPRIVのための存在アーキテクチャ…3 4. PIDFへのGEOPRIV拡張子…5 5. セキュリティ問題…5 6. 承認…5 7. 有益な参照…6

Peterson                     Informational                      [Page 1]

RFC 4079                 GEOPRIV Presence Arch                 July 2005

[1ページ]RFC4079GEOPRIV存在アーチ2005年7月の情報のピーターソン

1.  Introduction

1. 序論

   GEOPRIV is a standard for the transmission of location information
   and privacy policies over the Internet.  Location information is a
   description of a particular spatial location, which may be
   represented as coordinates (via longitude, latitude, and so on), as
   civil addresses (such as postal addresses), or in other ways.
   GEOPRIV focuses on the privacy and security issues, from both a
   technology perspective and a policy perspective, of sharing location
   information over the Internet; it essentially defines a secure
   container class capable of carrying both location information and
   policy data governing the distribution of this information.  GEOPRIV
   also defines the concept of a 'using protocol' -- a protocol that
   carries the GEOPRIV location object.

GEOPRIVは位置情報の伝達の規格とインターネットの上のプライバシーに関する方針です。 位置情報は民間アドレス(郵便の宛先などの)、または他の方法で特定の空間的な位置の記述です。(それは、座標(経度、緯度などを通した)として表されるかもしれません)。 GEOPRIVはプライバシーに焦点を合わせます、そして、セキュリティはインターネットの上で技術見解と共有の方針見解の両方から位置情報を発行します。 それは本質的にはこの情報の分配を治める位置情報と方針データの両方を運ぶことができる安全なコンテナのクラスを定義します。 また、GEOPRIVは'使用プロトコル'の概念を定義します--GEOPRIV位置のオブジェクトを運ぶプロトコル。

   Presence is a service defined in RFC2778 [2] that allows users of a
   communications service to monitor one another's availability and
   disposition in order to make decisions about communicating.  Presence
   information is highly dynamic, and it generally characterizes whether
   a user is online or offline, busy or idle, away from communications
   devices or nearby, and the like.

存在は情報提供サービスのユーザに交信に関する決定をするようにお互いの有用性と気質をモニターさせるRFC2778[2]で定義されたサービスです。 存在情報は非常にダイナミックです、そして、一般に、それはユーザがオンライン、オフライン、忙しいか、活動していないか、コミュニケーションデバイスから遠くにいるまたは近いか、そして、同様のものを特徴付けます。

   This document shows the applicability of presence to GEOPRIV and
   shows that a presence protocol could be a suitable using protocol for
   GEOPRIV.  This document is not intended to demonstrate that presence
   is the only method by which GEOPRIV location objects might be
   distributed.  However, there are numerous applications of GEOPRIV
   that depend on the fundamental subscription/notification architecture
   that also underlies presence.

このドキュメントは、存在プロトコルがGEOPRIVに、適当な使用プロトコルであるかもしれないことを存在の適用性にGEOPRIVとショーに示します。 このドキュメントが、存在がGEOPRIV位置のオブジェクトが分配されるかもしれない唯一のメソッドであることを示すことを意図しません。 しかしながら、また、存在の基礎となる基本的な購読/通知アーキテクチャによるGEOPRIVの頻繁な利用があります。

2.  Framework Analysis

2. フレームワーク分析

   The GEOPRIV framework [1] defines four primary network entities: a
   Location Generator, a Location Server, a Location Recipient, and a
   Rule Holder.  Three interfaces between these entities are defined,
   including a publication interface and a notification interface.

GEOPRIVフレームワーク[1]は4つのプライマリネットワーク実体を定義します: 位置のジェネレータ、位置のサーバ、位置の受取人、および規則所有者。 公表インタフェースと通知インタフェースを含んでいて、これらの実体の間の3つのインタフェースが定義されます。

   GEOPRIV specifies that a 'using protocol' is employed to transport
   location objects from one place to another.  If the publication
   interface and notification interface are network connections, then a
   using protocol would be responsible for the transmission of the
   location object.  Location Recipients may request that a Location
   Server provide them with GEOPRIV location information concerning a
   particular Target.  The Location Generator publishes Location
   Information to a Location Server, which, in coordination with
   policies set by the Rule Maker, distributes the location information
   to Location Recipients as necessary.

GEOPRIVは、'使用プロトコル'が1つの場所から別の場所まで位置のオブジェクトを輸送するのに使われると指定します。 公表インタフェースと通知インタフェースがネットワーク接続であるなら、使用プロトコルは位置のオブジェクトのトランスミッションに原因となるでしょう。 位置のRecipientsは、Location Serverが特定のTargetに関してGEOPRIV位置情報を彼らに提供するよう要求するかもしれません。 Location GeneratorはLocation情報をLocation Serverに発表します。(Rule Makerによって設定された方針があるコーディネートでは、Location Serverは必要に応じてLocation Recipientsに位置情報を分配します)。

Peterson                     Informational                      [Page 2]

RFC 4079                 GEOPRIV Presence Arch                 July 2005

[2ページ]RFC4079GEOPRIV存在アーチ2005年7月の情報のピーターソン

   The GEOPRIV requirements document shows three scenarios for the use
   of the GEOPRIV protocol.  In some of these scenarios (such as the
   third), a Location Recipient sends some kind of message to the
   Location Server to request the periodic transmission of location
   information.  The location of a GEOPRIV Target is likely to vary over
   time (if the Target is a person, or something similarly mobile), and
   consequently the concept of a persistent subscription to the location
   of a Target resulting in periodic notification is valuable to
   GEOPRIV.  In other scenarios, a Location Recipient may request a one-
   time notification of the geographical location of the Target.

GEOPRIV要件ドキュメントはGEOPRIVプロトコルの使用のために3つのシナリオを示しています。 これらのシナリオ(3の番目などものの)のいくつかでは、Location Recipientは、位置情報の周期的な伝達を要求するためにある種のメッセージをLocation Serverに送ります。 GEOPRIV Targetの位置は時間がたつにつれて異なりそうです、そして、(同様にTargetが人、または何かであることモバイルであるものなら)その結果、周期的な通知をもたらすTargetの位置の永続的な購読の概念はGEOPRIVに貴重です。 他のシナリオでは、Location RecipientはTargetの地理的な位置の1つの時間通知を要求するかもしれません。

   GEOPRIV places few requirements on using protocols.  However, it is
   clear from the description above that there must be some mechanism
   allowing Location Recipients to establish a persistent subscription
   in order to receive regular notification of the geographical location
   of a Target as their location changes over time.  There must also be
   a way for Location Generators to publish location information to a
   Location Server that applies further policies for distribution.

GEOPRIVはわずかな要件しかプロトコルを使用するのに置きません。 しかしながら、それの上の記述によって、Location Recipientsが彼らの位置が時間がたつにつれて変化するときTargetの地理的な位置の定期的な通知を受け取るために永続的な購読を確立できる何らかのメカニズムがあるに違いないのは、明確です。 また、Location Generatorsが分配のためのさらなる方針を適用するLocation Serverに位置情報を発表する方法があるに違いありません。

   This document adopts a model in which the using protocol is
   responsible for requesting subscriptions, handling publications, and
   sending notifications.  There are other models for GEOPRIV in which
   these operations might be built into location objects themselves.
   However, there is a significant amount of pre-existing work in the
   IETF related to managing publications, subscriptions, and
   notifications for data sets that vary over time.  In fact, these
   concepts all correspond exactly to architectures for presence that
   have been developed in support of real-time communications
   applications such as instant messaging, voice and video sessions.

このドキュメントは使用プロトコルが購読、取り扱い刊行物、および送付通知を要求するのに原因となるモデルを採用します。 位置のオブジェクト自体がこれらの操作に組み込まれるかもしれないGEOPRIVの他のモデルがあります。 しかしながら、仕事をかなりの量先在させるのが時間がたつにつれて異なるデータセットのための刊行物、購読、および通知を管理すると関連するIETFにあります。 事実上、これらの概念はちょうど存在のためのインスタントメッセージングや、声やビデオセッションなどの瞬時通信応用を支持して開発されたアーキテクチャにすべて対応しています。

   Note that in some GEOPRIV scenarios, the Location Recipient does not
   actively request the location of a Target; rather, it receives an
   unsolicited notification of Target's location.  This document focuses
   on the use of presence only for scenarios in which the Location
   Recipient actively solicits location information.  However, it is
   possible that many of these base operations of the
   subscription/notification framework of presence could be reused for
   cases in which the Location Recipient is passive.

いくつかのGEOPRIVシナリオでは、Location Recipientが活発にTargetの位置を要求しないことに注意してください。 むしろ、それはTargetの位置の求められていない通知を受け取ります。 このドキュメントは存在のLocation Recipientが活発に位置情報に請求するシナリオだけの使用に焦点を合わせます。 しかしながら、Location Recipientが受け身である場合のために存在の購読/通知フレームワークのこれらのベース操作の多くを再利用できたのは可能です。

3.  Presence Architecture for GEOPRIV

3. GEOPRIVのための存在アーキテクチャ

   The Common Profile for Presence [4] (CPP) defines a set of operations
   for delivery of presence information.  These primarily consist of
   subscription operations and notification operations.  A subscription
   creates a persistent connection between a 'watcher' (which
   corresponds to the Location Recipient of GEOPRIV) and a 'presentity'
   (which corresponds roughly to the GEOPRIV target).  When a watcher
   subscribes to a presentity, a persistent connection is created;

Presence[4](CPP)のためのCommon Profileは存在情報の配送のための1セットの操作を定義します。 これらは購読操作と通知操作から主として成ります。 購読は'ウォッチャー'(GEOPRIVのLocation Recipientに対応する)と'presentity'(およそGEOPRIV目標に対応する)の間でパーシステントコネクションを作成します。 ウォッチャーがpresentityに加入すると、パーシステントコネクションは作成されます。

Peterson                     Informational                      [Page 3]

RFC 4079                 GEOPRIV Presence Arch                 July 2005

[3ページ]RFC4079GEOPRIV存在アーチ2005年7月の情報のピーターソン

   notifications of presence information will henceforth be sent to the
   watcher as the presence information changes.  CPP also supports
   unsubscriptions (terminating the persistent subscription) and fetches
   (one-time requests for presence information that do not result in a
   persistent subscription).

存在情報が変化するので、今後は、存在情報の通知をウォッチャーに送るでしょう。 また、CPPは非購読が(永続的な購読を終えます)、フェッチ(永続的な購読をもたらさない存在情報に関する1回の要求)であるとサポートします。

   CPP provides a number of attributes of these operations that flesh
   out the presence system.  There is a system for automatically
   expiring subscriptions if they are not refreshed at user-defined
   intervals (in order to eliminate stale subscriptions).  There are
   transaction and subscription identifiers used to correlate messages,
   and a URI scheme ("pres:") is defined to identify watchers and
   presentities.

CPPは存在システムを太らせるこれらの操作の多くの属性を提供します。 それらがユーザによって定義された間隔で、リフレッシュされないなら(聞き古した購読を排除するために)自動的に購読を吐き出すシステムがあります。 メッセージを関連させるのに使用されるトランザクションと購読識別子があります、そして、URI体系(「以下をpresする」)は、ウォッチャーとpresentitiesを特定するために定義されます。

   The IETF IMPP WG has also defined an XML data format for presence
   information, called the Presence Information Data Format [5] (PIDF).
   PIDF is a body that is carried by presence protocols and that
   contains presence information, including the current state of a
   presentity.  PIDF is discussed in more detail in Section 4.

Presence情報Data Format[5](PIDF)は、また、IETF IMPP WGが存在情報のためにXMLデータの形式を定義したと呼びました。 PIDFは存在プロトコルによって運ばれて、存在情報を含むボディーです、presentityの現状を含んでいて。 さらに詳細にセクション4でPIDFについて議論します。

   At a high level, then, the presence architecture seems to have
   considerable applicability to the problem of delivering GEOPRIV
   information.  However, the CPP framework is an abstract framework:
   it doesn't actually specify a protocol, instead it specifies a
   framework and a set of requirements to which presence protocols must
   conform.  Also, CPP does not define any concept similar to a Location
   Server.

そして、高いレベルでは、存在アーキテクチャは情報をGEOPRIVに提供するという問題にかなりの適用性を持っているように思えます。 しかしながら、CPPフレームワークは抽象的なフレームワークです: それは実際にプロトコルを指定しないで、代わりに、存在プロトコルが従わなければならない要件のフレームワークとセットを指定します。 また、CPPはLocation Serverと同様のどんな概念も定義しません。

   However, the IETF has standardized protocols that instantiate this
   framework, such as SIMPLE [6] and XMPP [7].  XMPP and SIMPLE both
   have architectural elements comparable to a Location Server: points
   where presentities register their availability, and where policies
   for distributing presence can be managed.  The presence community has
   also defined a policy protocol and schema set called XCAP [8] through
   which authorization policies can be provisioned in a presence server.

しかしながら、IETFはSIMPLE[6]やXMPP[7]などのこのフレームワークを例示するプロトコルを標準化しました。 XMPPとSIMPLEはともに建築要素をLocation Serverに匹敵するようにします: presentitiesが彼らの有用性を示して、存在を分配するための方針に対処できるポイント。 また、存在共同体は存在サーバで承認方針に食糧を供給することができるXCAP[8]と呼ばれる方針プロトコルと図式セットを定義しました。

   In summary, like GEOPRIV, presence requires an architecture for
   publication, subscription, and notification for a mutable set of data
   associated with a principal.  Presence has already tackled many of
   the harder issues associated with subscription management, including
   subscription expiration, development of identifiers for principals,
   and defining document formats for presence information.  Rather than
   reinvent work that has been done elsewhere in the IETF, GEOPRIV has
   reused this existing work by specifying presence protocols as GEOPRIV
   using protocols.  Moreover, the existing foundational presence tools
   developed in IMPP, such as PIDF, have immediate applicability to the
   efforts underway in GEOPRIV to develop objects for sharing location
   information.

概要では、GEOPRIVのように、存在は元本に関連しているデータの無常のセットのための公表、購読、および通知のためにアーキテクチャを必要とします。 存在は既に購読管理に関連しているより困難な問題の多くに取り組みました、購読満了と、主体のための識別子の開発と、存在情報のためにドキュメント・フォーマットを定義するのを含んでいて。 むしろ、GEOPRIVは、IETFでほかの場所で行われた仕事を再発明するよりGEOPRIVとしてプロトコルを使用することで存在プロトコルを指定することによって、この既存の仕事を再利用しました。 そのうえ、PIDFなどのIMPPで開発された既存の基礎的な存在ツールは、位置情報を共有するためにオブジェクトを開発するためにGEOPRIVの進行中の取り組みに即座の適用性を持っています。

Peterson                     Informational                      [Page 4]

RFC 4079                 GEOPRIV Presence Arch                 July 2005

[4ページ]RFC4079GEOPRIV存在アーチ2005年7月の情報のピーターソン

4.  GEOPRIV Extensions to PIDF

4. PIDFへのGEOPRIV拡張子

   As was mentioned above, the presence architecture developed in the
   IETF IMPP WG has defined a format for presence information called
   PIDF.  PIDF is an XML format that provides presence information about
   a presentity.  Primarily, this consists of status information, but it
   also optionally includes contact addresses (a way of reaching the
   presentity), timestamps, and textual notes with arbitrary content.

上に言及されたように、IETF IMPP WGで開発された存在アーキテクチャはPIDFと呼ばれる存在情報のために書式を定義しました。 PIDFはpresentityの存在情報を提供するXML形式です。 主として、これは状態情報から成りますが、また、それは任意に任意の内容がある連絡先(presentityに達する方法)、タイムスタンプ、および原文のメモを含んでいます。

   PIDF is an extensible format.  It defines an XML element for
   representing the status of a presentity (the status element), and it
   gives some guidance as to how this element might be extended.
   Although the authors of PIDF viewed geographical location as a
   potential category of presence information, baseline PIDF defines no
   format for location information.

PIDFは広げることができる形式です。 それはpresentity(状態要素)の状態を表すためにXML要素を定義します、そして、この要素がどう敷衍されるかもしれないかに関して何らかの指導を与えます。 PIDFの作者は存在情報の潜在的カテゴリであると地理的な位置をみなしましたが、基線PIDFは位置情報のために書式を全く定義しません。

   PIDF meets the security requirements given in RFC2779 [3] (see
   especially sections 5.1, 5.2, and 5.3), which parallel those of the
   GEOPRIV location object given in the GEOPRIV requirements [1].  CPP
   and PIDF specify mechanisms for mutual authentication of participants
   in a presence exchange as well as for confidentiality and integrity
   properties for presence information.

PIDFはRFC2779[3](特にセクション5.1、5.2、および5.3を見ます)で与えられたセキュリティ必要条件を満たします。RFC2779はGEOPRIV要件[1]で与えられたGEOPRIV位置のオブジェクトのものに沿います。 CPPとPIDFは存在情報として存在交換における、関係者の互いの認証と秘密性と保全の特性にメカニズムを指定します。

   In short, many of the requirements of GEOPRIV objects map well onto
   the capabilities of PIDF.

要するに、GEOPRIVオブジェクトの要件の多くがPIDFの能力に井戸を写像します。

5.  Security Considerations

5. セキュリティ問題

   GEOPRIV information, like presence information, has very sensitive
   security requirements.  The requirements of RFC2779 [3], which are
   instantiated by CPP, PIDF, and XCAP, in addition to the various
   derivative concrete presence protocols, such as XMPP and SIMPLE, map
   well onto the security requirements of the GEOPRIV protocol, as
   defined in the GEOPRIV requirements document and the GEOPRIV threat
   analysis [9] document.  Specifically, the presence security
   requirements call for authentication of watchers, integrity and
   confidentiality properties, and similar measures to prevent abuse of
   presence information.

GEOPRIV情報には、存在情報のように、非常に機密のセキュリティ要件があります。 RFC2779[3]の要件と様々な派生している具体的な存在プロトコルに加えたXMPPやSIMPLEなどのXCAPはGEOPRIVプロトコルのセキュリティ要件に井戸を写像します、GEOPRIV要件ドキュメントとGEOPRIV脅威分析[9]ドキュメントで定義されるように。RFC2779はCPP、PIDFによって例示されます。 明確に、存在セキュリティ要件はウォッチャー、保全、秘密性の特性、および存在情報の乱用を防ぐ同様の測定の認証を求めます。

6.  Acknowledgements

6. 承認

   Thanks to Randall Gellens, John Morris, Hannes Tschofenig, and Behcet
   Sarikaya for their comments.

彼らのコメントをランドルGellens、ジョンモリス、ハンネスTschofenig、およびBehcet Sarikayaをありがとうございます。

Peterson                     Informational                      [Page 5]

RFC 4079                 GEOPRIV Presence Arch                 July 2005

[5ページ]RFC4079GEOPRIV存在アーチ2005年7月の情報のピーターソン

7.  Informative References

7. 有益な参照

   [1]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
         Polk, "GEOPRIV requirements", RFC 3693, February 2004.

[1] クエリャルとJ.とモリスとJ.とMulliganとD.とピーターソン、J.とJ.ポーク、「GEOPRIV要件」、RFC3693、2004年2月。

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

2000年2月の[2] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。

   [3]   Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging /
         Presence Protocol Requirements", RFC 2779, February 2000.

[3] 日、M.とAggarwal、S.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、2000年2月。

   [4]   Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
         August 2004.

[4] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2004年8月。

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

[5] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。

   [6]   Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", RFC 3856, August 2004.

[6] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。

   [7]   Saint-Andre, P., "Extensible Messaging and Presence Protocol
         (XMPP): Instant Messaging and Presence", RFC 3921, October
         2004.

[7] サンアンドレ、P.、「広げることができるメッセージングと存在は以下について議定書の中で述べ(XMPP)」。 「インスタントメッセージングと存在」、RFC3921、10月2004日

   [8]   Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)", Work in Progress,
         February 2004.

[8] ローゼンバーグ、J.、「拡張マークアップ言語(XML)構成アクセス・プロトコル(XCAP)」が進歩、2004年2月に働いています。

   [9]   Danley, M., Morris, J., Mulligan, D., and J. Peterson, "Threat
         Analysis of the GEOPRIV Protocol", RFC 3694, February 2004.

2004年2月の[9]DanleyとM.とモリスとJ.とマリガン、D.とJ.ピーターソン、「GEOPRIVプロトコルの脅威分析」RFC3694。

Author's Address

作者のアドレス

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St., Suite 570
   Concord, CA  94520
   USA

ジョンピーターソンNeuStar Inc.1800サター通り、スイート570一致、カリフォルニア94520米国

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz/

以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/

Peterson                     Informational                      [Page 6]

RFC 4079                 GEOPRIV Presence Arch                 July 2005

[6ページ]RFC4079GEOPRIV存在アーチ2005年7月の情報のピーターソン

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   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 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                     Informational                      [Page 7]

ピーターソンInformationalです。[7ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<>演算子 等しくない

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る