[要約] RFC 7566は、'acct' URIのためのEnumservice登録に関する仕様です。目的は、'acct' URIを使用してアカウント情報を特定するための一貫性のある方法を提供することです。

Independent Submission                                           L. Goix
Request for Comments: 7566                   Econocom-Osiatis Ingenierie
Category: Experimental                                             K. Li
ISSN: 2070-1721                                               Individual
                                                               June 2015
        

Enumservice Registration for 'acct' URI

「アカウント」URIの列挙型サービス登録

Abstract

概要

This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).

このドキュメントは、「acct」URI(Uniform Resource Identifiers)のE.164番号マッピング(ENUM)サービスを登録します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。

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

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

Copyright Notice

著作権表示

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Use Cases .......................................................2
      3.1. Reverse Phone Lookup .......................................2
      3.2. Routing of Mobile Social Communications ....................3
   4. IANA Registration ...............................................4
   5. Examples ........................................................5
   6. DNS Considerations ..............................................5
   7. Security Considerations .........................................6
   8. IANA Considerations .............................................7
   9. References ......................................................7
      9.1. Normative References .......................................7
      9.2. Informative References .....................................8
   Acknowledgements ...................................................8
   Authors' Addresses .................................................8
        
1. Introduction
1. はじめに

ENUM (E.164 Number Mapping, [RFC6116]) is a system that uses DNS (Domain Name Service, [RFC1034]) to translate telephone numbers, such as '+44 1632 960123', into URIs (Uniform Resource Identifiers, [RFC3986]), such as 'acct:user@example.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to identify resources.

ENUM(E.164番号マッピング、[RFC6116])は、DNS(ドメインネームサービス、[RFC1034])を使用して、「+ 44 1632 960123」などの電話番号をURI(Uniform Resource Identifiers、[RFC3986 ])、「acct:user@example.com」など。 ENUMは、主に、電話番号に依存するシステムと、URIを使用してリソースを識別するシステムとの相互接続を容易にするために存在します。

[RFC7565] defines the 'acct' URI scheme as a way to identify a user's account at a service provider.

[RFC7565]は、 'acct' URIスキームを、サービスプロバイダーでユーザーのアカウントを識別する方法として定義しています。

This document registers an Enumservice for advertising 'acct' URI information associated with an E.164 number.

このドキュメントは、E.164番号に関連付けられた「acct」URI情報をアドバタイズするためのEnumserviceを登録します。

2. Terminology
2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

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

3. Use Cases
3. ユースケース
3.1. Reverse Phone Lookup
3.1. 逆電話番号検索

In this example, an address book application could issue ENUM queries looking for 'acct' URIs corresponding to phone numbers. This could be used to display the account identifier as well as an icon based on the host (domain) portion of that URI.

この例では、アドレス帳アプリケーションは、電話番号に対応する「acct」URIを探すENUMクエリを発行できます。これは、URIのホスト(ドメイン)部分に基づいて、アカウント識別子とアイコンを表示するために使用できます。

Similarly, an endpoint could trigger this resolution process during inbound and/or outbound calls to discover an account associated with the remote party.

同様に、エンドポイントは、インバウンドおよび/またはアウトバウンドコール中にこの解決プロセスをトリガーして、リモートパーティに関連付けられているアカウントを検出できます。

In general, the provision of an ENUM record to map a phone number into an account may be useful for businesses or professional workers to identify themselves publicly (in a way similar to vCard ENUM records).

一般に、電話番号をアカウントにマップするためのENUMレコードの提供は、(vCard ENUMレコードと同様に)企業や専門職の労働者が自分自身を公に識別するのに役立ちます。

3.2. Routing of Mobile Social Communications
3.2. モバイルソーシャルコミュニケーションのルーティング

The Open Mobile Alliance (OMA) develops mobile service enabler specifications, which support the creation of interoperable end-to-end mobile services independent of the underlying wireless platforms, such as GSM (Global System for Mobile communications), UMTS (Universal Mobile Telecommunications System), and LTE (Long Term Evolution) mobile networks. The OMA Social Network Web (SNeW) Enabler Release [OMA-SNeW] has introduced a number of social networking functionalities for mobile subscribers identified by their MSISDN (Mobile Subscriber Integrated Services Digital Network number, a number uniquely identifying a subscription in a mobile network), amongst which is the ability to follow each other's social activities across service providers.

Open Mobile Alliance(OMA)は、GSM(Global System for Mobilecommunications)、UMTS(Universal Mobile Telecommunications System)などの基盤となるワイヤレスプラットフォームに依存しない相互運用可能なエンドツーエンドのモバイルサービスの作成をサポートするモバイルサービスイネーブラ仕様を開発しています。 )、およびLTE(Long Term Evolution)モバイルネットワーク。 OMAソーシャルネットワークWeb(SNeW)イネーブラーリリース[OMA-SNeW]は、MSISDN(モバイルサブスクライバ統合サービスデジタルネットワーク番号、モバイルネットワークのサブスクリプションを一意に識別する番号)によって識別されるモバイルサブスクライバ用のソーシャルネットワーキング機能をいくつか導入しています。は、サービスプロバイダー全体でお互いのソーシャルアクティビティをフォローする機能です。

Such functionality requires the global resolution of the MSISDN to the corresponding account and provider, in a way analogous to Multimedia Messaging Service (MMS) routing, to identify the target endpoint for the related messages. Although alternative solutions exist (e.g., based on mobile network operations and/or proprietary lookup techniques), ENUM provides a globally accessible mechanism for enabling resolution from network entities on behalf of an endpoint, or from an endpoint itself.

このような機能では、関連するメッセージのターゲットエンドポイントを識別するために、マルチメディアメッセージングサービス(MMS)ルーティングに類似した方法で、対応するアカウントおよびプロバイダーに対するMSISDNのグローバル解決が必要です。代替ソリューションが存在しますが(たとえば、モバイルネットワーク操作や独自のルックアップ技術に基づく)、ENUMは、エンドポイントに代わってネットワークエンティティから、またはエンドポイント自体からの解決を可能にするグローバルにアクセス可能なメカニズムを提供します。

For example, a user of a service provider could request to follow the social activities of user '+44 1632 960123'. The home SNeW Server of the former user could perform an ENUM query to identify the 'acct' URI corresponding to that phone number. Based on the resulting URI, the server could then identify the SNeW Server of the target user and route the original user's request to the appropriate endpoint.

たとえば、サービスプロバイダーのユーザーは、ユーザー「+44 1632 960123」のソーシャルアクティビティのフォローを要求できます。前のユーザーのホームSNeWサーバーは、ENUMクエリを実行して、その電話番号に対応する「acct」URIを識別できます。結果のURIに基づいて、サーバーはターゲットユーザーのSNeWサーバーを識別し、元のユーザーの要求を適切なエンドポイントにルーティングできます。

A similar mechanism can apply to other types of social networking-related messages or other communications targeted to a mobile subscriber.

同様のメカニズムは、他のタイプのソーシャルネットワーキング関連のメッセージや、モバイルサブスクライバーを対象としたその他の通信に適用できます。

4. IANA Registration
4. IANA登録

As defined in [RFC6117], the following is a template covering information needed for the registration of the Enumservice specified in this document:

[RFC6117]で定義されているとおり、以下は、このドキュメントで指定されているEnumserviceの登録に必要な情報をカバーするテンプレートです。

           <record>
             <class>Application-Based, Ancillary</class>
             <type>acct</type>
             <urischeme>acct</urischeme>
             <functionalspec>
               <paragraph>
                 This Enumservice indicates that the resource
                 can be identified by the associated 'acct' URI
                 <xref target='RFC7565'/>.
               </paragraph>
             </functionalspec>
             <security>
               For DNS considerations in avoiding loops when
               searching for "acct" NAPTRs, see
               <xref type="rfc" data="7566"/>, Section 6.
               For security considerations, see
               <xref type="rfc" data="7566"/>, Section 7.
             </security>
             <usage>COMMON</usage>
             <registrationdocs>
               <xref type="rfc" data="7566"/>
             </registrationdocs>
             <requesters>
               <xref type="person" data="Laurent_Walter_Goix"/>
             </requesters>
           </record>
        
           <people>
             <person id="Laurent_Walter_Goix">
               <name>Laurent-Walter Goix</name>
               <org>Econocom-Osiatis Ingenierie</org>
               <uri>mailto:laurent.goix@econocom-osiatis.com</uri>
               <updated>2014-06-18</updated>
             </person>
           </people>
        

Note that the registry maintained by IANA is definitive. For the most recent version of the registration, please see the online registry <http://www.iana.org/assignments/enum-services>.

IANAによって維持されるレジストリは決定的なものであることに注意してください。登録の最新バージョンについては、オンラインレジストリ<http://www.iana.org/assignments/enum-services>を参照してください。

5. Examples
5. 例

The following is an example of the use of the Enumservice registered by this document in a Naming Authority Pointer (NAPTR) resource record for phone number +44 1632 960123.

以下は、電話番号+44 1632 960123のNaming Authority Pointer(NAPTR)リソースレコードでこのドキュメントによって登録されたEnumserviceの使用例です。

$ORIGIN 3.2.1.0.6.9.2.3.6.1.4.4.e164.arpa.

$ ORIGIN 3.2.1.0.6.9.2.3.6.1.4.4.e164.arpa。

IN NAPTR 10 100 "u" "E2U+acct" "!^.*$!acct:441632960123@foo.com!" .

IN NAPTR 10 100 "u" "E2U + acct" "!^。* $!acct:441632960123@foo.com!" 。

IN NAPTR 10 101 "u" "E2U+acct" "!^.*$!acct:john.doe@example.com!" .

IN NAPTR 10 101 "u" "E2U + acct" "!^。* $!acct:john.doe@example.com!" 。

Note that in the first record, the revealed information is limited to the domain of the service provider serving that user, as the userpart of the 'acct' URI simply replicates the phone number.

最初のレコードでは、「acct」URIのuserpartが電話番号を複製するだけなので、公開される情報はそのユーザーにサービスを提供するサービスプロバイダーのドメインに限定されます。

6. DNS Considerations
6. DNSに関する考慮事項

There may not be any "E2U+acct" NAPTRs returned in response to the original ENUM query on the requested telephone number, but other terminal ENUM NAPTRs that include tel: URLs [RFC3966] (e.g., "voice:tel", "pstn:tel", "sms:tel", or "mms:tel" -- see [RFC6118]) may be present.

要求された電話番号に対する元のENUMクエリへの応答として返される「E2U + acct」NAPTRはない可能性がありますが、tel:URL [RFC3966](たとえば、「voice:tel」、「pstn: tel "、" sms:tel "、または" mms:tel "-[RFC6118]を参照)が存在する場合があります。

The application that made that ENUM query may choose to resubmit ENUM queries for any E.164 numbers included in those returned terminal NAPTRs. Doing so may cause a query loop (e.g., the ENUM records returned from subsequent queries may refer to the telephone number already considered). If applications choose to perform subsequent ENUM queries using telephone numbers retrieved from earlier queries, these applications MUST be aware of the potential for query loops and MUST be prepared to abort the set of queries if such a loop is detected.

そのENUMクエリを作成したアプリケーションは、返された端末NAPTRに含まれるE.164番号のENUMクエリを再送信することを選択できます。これを行うと、クエリループが発生する可能性があります(たとえば、後続のクエリから返されるENUMレコードが、すでに検討されている電話番号を参照する場合があります)。アプリケーションが以前のクエリから取得した電話番号を使用して後続のENUMクエリを実行することを選択した場合、これらのアプリケーションはクエリループの可能性を認識し、そのようなループが検出された場合にクエリのセットを中止する準備をしなければなりません。

This issue is similar to the referential loop issue caused by processing non-terminal NAPTR queries, as mentioned in Section 5.2.1 of [RFC6116], and a similar technique to mitigate this issue can be used; an application searching for records with "acct" Enumservice may consider that submitting a chain of more than 5 ENUM queries without finding such a record indicates that a referential loop has been entered, and the chain of queries SHOULD be abandoned.

この問題は、[RFC6116]のセクション5.2.1で説明されているように、非ターミナルNAPTRクエリの処理によって発生する参照ループの問題に類似しており、この問題を軽減するための同様の手法を使用できます。 "acct" Enumserviceを使用してレコードを検索するアプリケーションは、そのようなレコードが見つからずに5つを超えるENUMクエリのチェーンを送信すると、参照ループに入ったことを示し、クエリのチェーンを破棄する必要があると見なす場合があります。

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

DNS, as used by ENUM, is a global, distributed database. Should implementers of this specification use e164.arpa or any other publicly available domain as the tree for maintaining Public Switched Telephone Network (PSTN) Enumservice data, this information would be visible to anyone anonymously.

ENUMで使用されるDNSは、グローバルな分散データベースです。この仕様の実装者が、公衆交換電話網(PSTN)Enumserviceデータを維持するためのツリーとしてe164.arpaまたはその他の公的に利用可能なドメインを使用する場合、この情報は誰でも匿名で見ることができます。

Carriers, service providers, and other users may choose not to publish such information in the public e164.arpa tree. They may instead simply publish this in an internal ENUM infrastructure that is only able to be queried by trusted elements of their network, thus limiting threats.

キャリア、サービスプロバイダー、およびその他のユーザーは、このような情報を公開e164.arpaツリーで公開しないことを選択できます。代わりに、ネットワークの信頼された要素からのみ照会できる内部ENUMインフラストラクチャにこれを公開するだけで、脅威を制限できます。

For security considerations that apply to all Enumservices, please refer to [RFC6116], Section 7.

すべてのEnumservicesに適用されるセキュリティの考慮事項については、[RFC6116]のセクション7を参照してください。

It is important to note that the ENUM record itself does not need to contain any personal information but only contains a pointer to an account identifier. This identifier may be queried to discover pointers to personal information (e.g., social-network information) endpoints, and an authorization mechanism may be in place in that context with any level of granularity; these topics are out of scope for this document.

ENUMレコード自体に個人情報を含める必要はなく、アカウント識別子へのポインタのみを含めることに注意することが重要です。この識別子は、個人情報(ソーシャルネットワーク情報など)のエンドポイントへのポインターを発見するためにクエリを実行することができ、そのコンテキストで、任意のレベルの粒度で承認メカニズムを設定できます。これらのトピックは、このドキュメントの範囲外です。

Technically, ENUM records themselves could contain pointers to the same endpoints. However, the visibility of ENUM records cannot be controlled based on the requesting entity. In that context, the simple mapping of the phone number to the account identifier, notwithstanding the disclosure of the association itself, still enables the reuse of more advanced access policies.

技術的には、ENUMレコード自体に同じエンドポイントへのポインターを含めることができます。ただし、ENUMレコードの可視性は、要求元エンティティに基づいて制御することはできません。そのコンテキストでは、関連付け自体の開示にもかかわらず、電話番号とアカウント識別子の単純なマッピングにより、より高度なアクセスポリシーの再利用が可能になります。

Revealing an 'acct' URI by itself is unlikely to introduce many privacy concerns, although, depending on the structure of the URI, it might reveal the full name or employer of the target. The use of anonymous URIs mitigates this risk.

URIの構造によっては、URIの構造に応じて、ターゲットの完全な名前または雇用者を明らかにする可能性がありますが、 'acct' URIを明らかにするだけでは多くのプライバシー問題が発生する可能性は低くなります。匿名URIを使用すると、このリスクが軽減されます。

Unlike a traditional telephone number, the endpoint identified by an 'acct' URI may require that requesting entities provide cryptographic credentials for authentication and authorization before messages are exchanged. ENUM can actually provide far greater protection from unwanted requesting entities than does the existing PSTN, despite the public availability of ENUM records.

従来の電話番号とは異なり、「acct」URIで識別されるエンドポイントでは、メッセージを交換する前に、要求元のエンティティが認証と承認のための暗号化された資格情報を提供する必要があります。 ENUMレコードは一般に公開されていますが、ENUMは、既存のPSTNよりも不要な要求エンティティからの保護を実際にはるかに提供できます。

More serious security concerns are associated with potential attacks against an underlying system (for example, a social-network system) using the 'acct' URI. For this reason, the underlying system should have a number of security requirements that call for authentication, integrity, and confidentiality properties, and similar measures to prevent such attacks. This is out of scope for this document.

より深刻なセキュリティの懸念は、「acct」URIを使用した、基盤となるシステム(たとえば、ソーシャルネットワークシステム)に対する潜在的な攻撃に関連しています。このため、基盤となるシステムには、認証、整合性、機密性のプロパティ、およびこのような攻撃を防止するための同様の対策を必要とする多くのセキュリティ要件が必要です。これはこのドキュメントの範囲外です。

8. IANA Considerations
8. IANAに関する考慮事項

Per this document, IANA has registered the Enumservice with Type "acct" according to the definitions in this document, [RFC6116], and [RFC6117].

このドキュメントに従って、IANAはこのドキュメント、[RFC6116]、および[RFC6117]の定義に従って、タイプ "acct"のEnumserviceを登録しました。

Details of the registration are given in Section 4.

登録の詳細はセクション4に記載されています。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.

[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。

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

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

[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.

[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、DOI 10.17487 / RFC3966、2004年12月、<http://www.rfc-editor.org/info/rfc3966>。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier(URI):Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http:/ /www.rfc-editor.org/info/rfc3986>。

[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, DOI 10.17487/RFC6116, March 2011, <http://www.rfc-editor.org/info/rfc6116>.

[RFC6116] Bradner、S.、Conroy、L。、およびK.藤原、「E.164からURI(Uniform Resource Identifiers)Dynamic Delegation Discovery System(DDDS)Application(ENUM)」、RFC 6116、DOI 10.17487 / RFC6116 、2011年3月、<http://www.rfc-editor.org/info/rfc6116>。

[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations", RFC 6117, DOI 10.17487/RFC6117, March 2011, <http://www.rfc-editor.org/info/rfc6117>.

[RFC6117] Hoeneisen、B.、Mayrhofer、A.、J。Livingood、「IANA Registration of Enumservices:Guide、Template、and IANA Considerations」、RFC 6117、DOI 10.17487 / RFC6117、2011年3月、<http:// www .rfc-editor.org / info / rfc6117>。

[RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA Registrations of Enumservices", RFC 6118, DOI 10.17487/RFC6118, March 2011, <http://www.rfc-editor.org/info/rfc6118>.

[RFC6118] Hoeneisen、B。およびA. Mayrhofer、「Update of Legacy IANA Registrations of Enumservices」、RFC 6118、DOI 10.17487 / RFC6118、2011年3月、<http://www.rfc-editor.org/info/rfc6118> 。

[RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, DOI 10.17487/RFC7565, May 2015, <http://www.rfc-editor.org/info/rfc7565>.

[RFC7565] Saint-Andre、P。、「The 'acct' URI Scheme」、RFC 7565、DOI 10.17487 / RFC7565、2015年5月、<http://www.rfc-editor.org/info/rfc7565>。

9.2. Informative References
9.2. 参考引用

[OMA-SNeW] Open Mobile Alliance, OMA-ER-SNeW-V1_0, "Social Network Web Enabler", August 2013, <http://technical.openmobilealliance.org/Technical/ release_program/snew_v1_0.aspx>.

[OMA-SNeW] Open Mobile Alliance、OMA-ER-SNeW-V1_0、「Social Network Web Enabler」、2013年8月、<http://technical.openmobilealliance.org/Technical/ release_program / snew_v1_0.aspx>。

Acknowledgements

謝辞

The authors would like to thank Gonzalo Salgueiro, Paul Jones, Lawrence Conroy, Enrico Marocco, Bert Greevenbosch, and Bernie Hoeneisen for their valuable feedback to improve this document.

このドキュメントを改善するための貴重なフィードバックを提供してくれたGonzalo Salgueiro、Paul Jones、Lawrence Conroy、Enrico Marocco、Bert Greevenbosch、およびBernie Hoeneisenに感謝します。

Authors' Addresses

著者のアドレス

Laurent-Walter Goix Econocom-Osiatis Ingenierie 75 cours Albert Thomas 69003 Lyon France

Laurent-Walter Goix Econocom-Osiatis Ingenierie 75コースAlbert Thomas 69003リヨンフランス

   EMail: laurent.goix@econocom-osiatis.com
        

Kepeng Li Individual 969 Wenyixi Road 311121 Hangzhou China

KE Peng l i個別969 wen Yixiu道路311121中国杭州

   EMail: kepeng.likp@gmail.com