RFC 8787 - Location Source Parameter for the SIP Geolocation Header Field 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8787.html
タイトル : RFC 8787 - SIPジオロケーションヘッダーフィールドのロケーションソースパラメータ
翻訳編集 : 自動生成

[要約] RFC 8787は、SIP GeolocationヘッダーフィールドのためのLocation Sourceパラメータに関する仕様です。このRFCの目的は、SIPメッセージにおける位置情報のソースを識別するためのパラメータを定義することです。

Internet Engineering Task Force (IETF)                   J. Winterbottom
Request for Comments: 8787                   Winterb Consulting Services
Updates: 6442                                                  R. Jesske
Category: Standards Track                               Deutsche Telekom
ISSN: 2070-1721                                               B. Chatras
                                                             Orange Labs
                                                               A. Hutton
                                                                    Atos
                                                                May 2020

Location Source Parameter for the SIP Geolocation Header Field

SIPジオロケーションヘッダーフィールドのロケーションソースパラメータ

Abstract

概要

There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to the Geolocation header field can identify itself using its hostname. This document updates RFC 6442.

Geolocationヘッダーフィールドに複数のlocationValueが含まれる場合があります。 locationValueを追加するノードのIDを知ることにより、受信者は、locationValuesの順序のみに依存するのではなく、最初に表示する値を選択する際の自由度が高まります。このドキュメントでは、「loc-src」パラメータを定義して、locationValueをGeolocationヘッダーフィールドに追加するエンティティがホスト名を使用して自身を識別できるようにします。このドキュメントはRFC 6442を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8787.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8787で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Rationale
   4.  Mechanism
   5.  Example
   6.  Privacy Considerations
   7.  Security Considerations
   8.  IANA Considerations
     8.1.  Registration of "loc-src" Parameter for Geolocation Header
           Field
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

The SIP Geolocation specification [RFC6442] describes the "Geolocation" SIP header field, which is used to indicate that the SIP message is conveying location information. [RFC6442] specifies that SIP intermediaries should not add locationValues to a SIP request that already contains a locationValue. [RFC6442] also states that if a SIP intermediary adds location, it is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives. However, some communications architectures, such as 3GPP [TS23-167] and ETSI [M493], prefer to use information provided by edge proxies or acquired through the use of core-network nodes before using information provided solely by user equipment (UE). These solutions don't preclude the use of UE-provided location but require a means of being able to distinguish the identity of the node adding the locationValue to the SIP message from that provided by the UE.

SIP Geolocation仕様[RFC6442]は、「Geolocation」SIPヘッダーフィールドについて説明しています。これは、SIPメッセージがロケーション情報を伝達していることを示すために使用されます。 [RFC6442]は、SIP仲介者がすでにlocationValueを含むSIPリクエストにlocationValuesを追加しないことを指定しています。 [RFC6442]はまた、SIP仲介者が場所を追加する場合、それが受信する424（Bad Location Information）SIP応答の懸念に対処する責任は完全にあると述べています。ただし、3GPP [TS23-167]やETSI [M493]などの一部の通信アーキテクチャは、ユーザー機器（UE）のみが提供する情報を使用する前に、エッジプロキシが提供する情報、またはコアネットワークノードを使用して取得した情報を使用することを好みます。これらのソリューションは、UEが提供するロケーションの使用を排除するものではありませんが、SIPメッセージにlocationValueを追加するノードのIDを、UEが提供するものと区別できる手段が必要です。

[RFC6442] stipulates that the order of locationValues in the Geolocation header field is the same as the order in which they were added to the header field. Whilst this order provides guidance to the recipient as to which values were added to the message earlier in the communication chain, it does not identify which node added the locationValue. Knowing the identity of the entity that added the location to the message allows the recipient to choose which location to consider first rather than relying solely on the order of the locationValues in the Geolocation header field.

[RFC6442]は、GeolocationヘッダーフィールドのlocationValuesの順序が、それらがヘッダーフィールドに追加された順序と同じであることを規定しています。この順序は、通信チェーンの早い段階でメッセージに追加された値に関するガイダンスを受信者に提供しますが、locationValueを追加したノードは識別しません。メッセージに場所を追加したエンティティのIDを知っていると、受信者は、GeolocationヘッダーフィールドのlocationValuesの順序のみに依存するのではなく、最初に検討する場所を選択できます。

This document extends the Geolocation header field of [RFC6442] by allowing an entity adding the locationValue to identify itself using a hostname. This is done by defining a new geoloc-param header field parameter, "loc-src". How the entity adding the locationValue to the header field obtains the location information is out of scope of this document. Please note that the "loc-src" parameter field does not alter the subject of the locationValue.

このドキュメントは、[RFC6442]のGeolocationヘッダーフィールドを拡張し、locationValueを追加するエンティティがホスト名を使用して自身を識別できるようにします。これは、新しいgeoloc-paramヘッダーフィールドパラメータ「loc-src」を定義することによって行われます。ヘッダーフィールドにlocationValueを追加するエンティティが位置情報を取得する方法は、このドキュメントの範囲外です。「loc-src」パラメータフィールドは、locationValueの件名を変更しないことに注意してください。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Rationale

3. 根拠

The primary intent of the "loc-src" parameter in this specification is for use in emergency calling. There are various architectures defined for providing emergency calling using SIP-based messaging. Each has its own characteristics with corresponding pros and cons. All of them allow the UE to provide location information; however, many also attach other sources of location information to support veracity checks, to provide backup information, or to be used as the primary location.

この仕様の「loc-src」パラメータの主な目的は、緊急通話で使用することです。 SIPベースのメッセージングを使用して緊急通話を提供するために定義されたさまざまなアーキテクチャがあります。それぞれに、長所と短所に対応する独自の特性があります。それらすべてにより、UEは位置情報を提供できます。ただし、多くは、真偽チェックをサポートするため、バックアップ情報を提供するため、またはプライマリロケーションとして使用するために、ロケーション情報の他のソースをアタッチします。

This document does not comment on these various architectures or on the rationale for including multiple locationValues. It does recognize that these architectures exist and that there is a need to identify the entity adding the location information.

このドキュメントでは、これらのさまざまなアーキテクチャや、複数のlocationValuesを含める理由については触れていません。これらのアーキテクチャが存在すること、およびロケーション情報を追加するエンティティを識別する必要があることは認識しています。

The "loc-src" parameter adds the location source generating the locationValue to allow recipients to make informed decisions about which of the multiple values to use.

"loc-src"パラメーターは、locationValueを生成するロケーションソースを追加して、受信者が複数の値のどれを使用するかについて情報に基づいた決定を行えるようにします。

The "loc-src" parameter is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains. Thus, it is intended to use this parameter only in trust domains where Spec(T) as described in [RFC3325] exists.

「loc-src」パラメーターは、単一のプライベート管理ドメイン内、またはドメイン間に信頼関係がある異なる管理ドメイン間で適用できます。したがって、このパラメータは、[RFC3325]で説明されているSpec（T）が存在する信頼ドメインでのみ使用することを目的としています。

The "loc-src" parameter is not included in a SIP message sent to another network if there is no trust relationship. The "loc-src" parameter is not applicable if the administrative domain manages emergency calls in a way that does not require any generation of the location.

信頼関係がない場合、「loc-src」パラメーターは別のネットワークに送信されるSIPメッセージに含まれません。ロケーションの生成を必要としない方法で管理ドメインが緊急コールを管理する場合、「loc-src」パラメータは適用されません。

The functional architecture to support emergency caller location described within ETSI [M493] is an example of an architecture where it makes sense to use this parameter.

ETSI [M493]内で説明されている緊急発信者の場所をサポートする機能アーキテクチャは、このパラメーターを使用する意味があるアーキテクチャの例です。

4. Mechanism

4. 機構

The mechanism adds a geoloc-param parameter to the locationValue defined in [RFC6442] that identifies the hostname of the entity adding the locationValue to the Geolocation header field. The Augmented BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1.

このメカニズムは、[RFC6442]で定義されているlocationValueにgeoloc-paramパラメータを追加します。これは、locationValueをGeolocationヘッダーフィールドに追加するエンティティのホスト名を識別します。このパラメーターの拡張BNF（ABNF）[RFC5234]を図1に示します。

          location-source = "loc-src" EQUAL hostname
          hostname = <defined in RFC 3261>

Figure 1: Location Source

図1：ロケーションソース

Only a fully qualified host name is valid. The syntax does not support IP addresses, and if an entity conforming to this specification receives a Geolocation header field with a "loc-src" parameter containing an IP address, it MUST remove the parameter.

完全修飾ホスト名のみが有効です。構文はIPアドレスをサポートしていません。この仕様に準拠するエンティティが、IPアドレスを含む「loc-src」パラメーターを持つGeolocationヘッダーフィールドを受け取った場合、パラメーターを削除する必要があります。

A SIP intermediary conformant to this specification adding a locationValue to a Geolocation header field SHOULD also add a "loc-src" header field parameter so that it is clearly identified as the node adding the location. A User Agent (UA) MUST NOT insert a "loc-src" header field parameter. If a SIP intermediary receives a message from an untrusted source with the "loc-src" parameter set, then it MUST remove the "loc-src" parameter before passing the message into a trusted network.

この仕様に準拠したSIP中間子は、location値をGeolocationヘッダーフィールドに追加する必要があります。また、「loc-src」ヘッダーフィールドパラメーターを追加して、位置を追加するノードとして明確に識別されるようにする必要があります。ユーザーエージェント（UA）は、「loc-src」ヘッダーフィールドパラメーターを挿入してはなりません（MUST NOT）。 SIP仲介者が「loc-src」パラメーターセットを使用して信頼できないソースからメッセージを受信した場合、メッセージを信頼済みネットワークに渡す前に「loc-src」パラメーターを削除する必要があります。

5. Example

5. 例

The following example shows a SIP INVITE message containing a Geolocation header field with two locationValues. The first locationValue points to a Presence Information Data Format Location Object (PIDF-LO) in the SIP body using a content-indirection (cid:) URI per [RFC4483], and this is provided by the UE. The second locationValue is an https URI provided by a SIP intermediary, which identifies itself using the "loc-src" parameter.

次の例は、2つのlocationValueを持つGeolocationヘッダーフィールドを含むSIP INVITEメッセージを示しています。最初のlocationValueは、[RFC4483]に従ってコンテンツインダイレクション（cid :) URIを使用して、SIP本体のプレゼンス情報データフォーマットロケーションオブジェクト（PIDF-LO）を指し、これはUEによって提供されます。 2番目のlocationValueは、 "loc-src"パラメータを使用して自身を識別するSIP仲介者によって提供されるhttps URIです。

INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.example.com> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: <cid:target123@atlanta.example.com>, <https://lis.example.com:8222/y77syc7cuecbh>; loc-src=edgeproxy.example.com Geolocation-Routing: yes Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: <sip:alice@atlanta.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...

INVITE sip：bob@biloxi.example.com SIP / 2.0 Via：SIP / 2.0 / TLS pc33.atlanta.example.com; branch = z9hG4bK74bf9 Max-Forwards：70 To：Bob <sip：bob@biloxi.example.com> From：Alice <sip：alice@atlanta.example.com>; tag = 9fxced76sl Call-ID：3848276298220188511@atlanta.example.com Geolocation：<cid：target123@atlanta.example.com>、<https：// lis。 example.com:8222/y77syc7cuecbh>; loc-src = edgeproxy.example.com Geolocation-Routing：yes Accept：application / sdp、application / pidf + xml CSeq：31862 INVITE Contact：<sip：alice@atlanta.example.com> Content-Type：multipart / mixed; border = boundary1 Content-Length：...

Figure 2: Example Location Request (in Trust Domain)

図2：ロケーション要求の例（信頼ドメイン内）

6. Privacy Considerations

6. プライバシーに関する考慮事項

This document doesn't change any of the privacy considerations described in [RFC6442]. While the addition of the "loc-src" parameter identifies the entity that added the location in the signaling path, this addition provides little more exposure than adding a proxy identity to the Record-Route header field (privacy defined in [RFC3323]).

このドキュメントは、[RFC6442]で説明されているプライバシーに関する考慮事項を変更しません。「loc-src」パラメータの追加は、シグナリングパスに場所を追加したエンティティを識別しますが、この追加により、プロキシIDをRecord-Routeヘッダーフィールド（[RFC3323]で定義されたプライバシー）に追加する場合よりも多くの情報が提供されます。

7. Security Considerations

7. セキュリティに関する考慮事項

This document introduces the ability of a SIP intermediary to insert a host name indicating that they added the specific locationValue to the Geolocation header field. The intent is for this field to be used by the location recipient in the event that the SIP message contains multiple locationValues. As a consequence, this parameter should only be used by the location recipient in a trusted network. Adding this parameter in an untrusted network serves solely to give location information to untrusted parties and is NOT RECOMMENDED.

このドキュメントでは、SIP仲介者が特定のlocationValueをGeolocationヘッダーフィールドに追加したことを示すホスト名を挿入する機能を紹介します。この目的は、SIPメッセージに複数のlocationValueが含まれている場合に、ロケーション受信者がこのフィールドを使用することです。結果として、このパラメーターは、信頼できるネットワーク内の場所の受信者のみが使用する必要があります。信頼できないネットワークにこのパラメータを追加することは、信頼できない関係者に位置情報を提供することのみを目的としており、推奨されません。

As already stated in [RFC6442], securing the location hop by hop, using TLS, protects the message from eavesdropping and modification in transit but exposes the information to all SIP intermediaries on the path as well as the endpoint. The "loc-src" parameter is applicable within a single private administrative domain or between different administrative domains where there is a relationship between the domains. If such a trust relationship is not given, it is strongly recommended to delete the location information.

[RFC6442]ですでに述べたように、TLSを使用してホップバイホップでロケーションを保護すると、メッセージが転送中に盗聴されたり変更されたりするのを防ぎますが、パス上のすべてのSIP仲介者とエンドポイントに情報を公開します。「loc-src」パラメーターは、単一のプライベート管理ドメイン内、またはドメイン間に関係がある異なる管理ドメイン間に適用できます。そのような信頼関係が与えられていない場合は、ロケーション情報を削除することを強くお勧めします。

The use of this parameter is not restricted to a specific architecture, but using multiple locations and loc-src may end in compatibility issues. [RFC6442] already addresses the issue of multiple locations. To avoid problems of a possible corruption of the location information including the "loc-src" parameter when using an untrusted relationship, it is strongly recommended to delete location information when passed to another domain out of the trust domain.

このパラメーターの使用は特定のアーキテクチャーに限定されていませんが、複数の場所とloc-srcを使用すると互換性の問題が発生する可能性があります。 [RFC6442]はすでに複数の場所の問題に対処しています。信頼されていない関係を使用しているときに「loc-src」パラメータを含む場所情報が破損する可能性があるという問題を回避するには、信頼ドメインから別のドメインに渡されるときに場所情報を削除することを強くお勧めします。

8. IANA Considerations

8. IANAに関する考慮事項

8.1. Registration of "loc-src" Parameter for Geolocation Header Field

8.1. 位置情報ヘッダーフィールドの「loc-src」パラメーターの登録

IANA has added a new SIP header field parameter for the Geolocation header field in the "Header Field Parameters and Parameter Values" subregistry (created by [RFC3968]) of the "Session Initiation Protocol (SIP) Parameters" registry found at <https://www.iana.org/assignments/sip-parameters/>.

IANAは、<https：/にある "Session Initiation Protocol（SIP）Parameters"レジストリの "Header Field Parameters and Parameter Values"サブレジストリ（[RFC3968]によって作成）に、Geolocationヘッダーフィールドの新しいSIPヘッダーフィールドパラメーターを追加しました。 /www.iana.org/assignments/sip-parameters/>。

Header Field: Geolocation

ヘッダーフィールド：地理位置情報

Parameter Name: loc-src

パラメータ名：loc-src

Predefined Values: No

定義済みの値：いいえ

Reference: RFC 8787

リファレンス：RFC 8787

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.

[RFC3323] Peterson、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、DOI 10.17487 / RFC3323、2002年11月、<https://www.rfc-editor.org/info/rfc3323> 。

[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.

[RFC3325]ジェニングス、C。、ピーターソン、J。、およびM.ワトソン、「信頼されたネットワーク内のアサートされたIDのためのセッション開始プロトコル（SIP）のプライベート拡張」、RFC 3325、DOI 10.17487 / RFC3325、2002年11月、<https ：//www.rfc-editor.org/info/rfc3325>。

[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <https://www.rfc-editor.org/info/rfc3968>.

[RFC3968] Camarillo、G。、「Session Initiation Protocol（SIP）のInternet Assigned Number Authority（IANA）ヘッダーフィールドパラメータレジストリ」、BCP 98、RFC 3968、DOI 10.17487 / RFC3968、2004年12月、<https：// www.rfc-editor.org/info/rfc3968>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。

[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, DOI 10.17487/RFC6442, December 2011, <https://www.rfc-editor.org/info/rfc6442>.

[RFC6442] Polk、J.、Rosen、B。、およびJ. Peterson、「セッション開始プロトコルのロケーション伝達」、RFC 6442、DOI 10.17487 / RFC6442、2011年12月、<https：//www.rfc-editor。 org / info / rfc6442>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

9.2. Informative References

9.2. 参考引用

[M493] European Telecommunications Standards Institute, "Functional architecture to support European requirements on emergency caller location determination and transport", ES 203 178, V 1.1.1, February 2015.

[M493] European Telecommunications Standards Institute、「緊急発信者の場所の特定と転送に関するヨーロッパの要件をサポートする機能アーキテクチャ」、ES 203 178、V 1.1.1、2015年2月。

[RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, DOI 10.17487/RFC4483, May 2006, <https://www.rfc-editor.org/info/rfc4483>.

[RFC4483]バーガー、E、編、「セッション開始プロトコル（SIP）メッセージのコンテンツ間接化のメカニズム」、RFC 4483、DOI 10.17487 / RFC4483、2006年5月、<https://www.rfc-editor.org / info / rfc4483>。

[TS23-167] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions", TS 23.167, V12.1.0, March 2015.

[TS23-167]第3世代パートナーシッププロジェクト、「技術仕様グループサービスとシステムの側面、IPマルチメディアサブシステム（IMS）緊急セッション」、TS 23.167、V12.1.0、2015年3月。

Acknowledgements

謝辞

The authors would like to thank Dale Worley, Christer Holmberg, and Jean Mahoney for their extensive review of this document. The authors would like to acknowledge the constructive feedback provided by Paul Kyzivat and Robert Sparks.

著者は、この文書の広範なレビューを提供してくれたDale Worley、Christer Holmberg、およびJean Mahoneyに感謝します。著者は、Paul KyzivatとRobert Sparksによって提供された建設的なフィードバックを認めたいと思います。

Authors' Addresses

著者のアドレス

James Winterbottom Winterb Consulting Services Gwynneville NSW 2500 Australia

James Winterbottom WinterbコンサルティングサービスGwynneville NSW 2500オーストラリア

   Phone: +61 448 266004
   Email: a.james.winterbottom@gmail.com

Roland Jesske Deutsche Telekom Heinrich-Hertz Str, 3-7 64295 Darmstadt Germany

Roland Jesske Deutsche Telekom Heinrich-Hertz Str、3-7 64295ダルムシュタット

   Email: r.jesske@telekom.de
   URI:   www.telekom.de

Bruno Chatras Orange Labs 44, avenue de la Republique F-92320 Chatillon France

Bruno Chatras Orange Labs 44、レピュブリック大通りF-92320シャティヨンフランス

   Email: bruno.chatras@orange.com

Andrew Hutton Atos Mid City Place London WC1V 6EA United Kingdom

アンドリューハットンアトスミッドシティプレイスロンドンWC1V 6EAイギリス

   Email: andrew.hutton@atos.net