[要約] RFC 7072は、信頼性クエリプロトコルに関する規格であり、信頼性情報の取得と共有を目的としています。このプロトコルは、インターネット上のエンティティの評判情報を効率的に取得するために設計されています。
Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7072 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
A Reputation Query Protocol
レピュテーションクエリプロトコル
Abstract
概要
This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.
このドキュメントでは、ペイロードのメタフォーマットとしてJavaScript Object Notation（JSON）を使用して、ハイパーテキスト転送プロトコル（HTTP）を介してレピュテーション情報のクエリを実行するメカニズムを定義します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、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/rfc7072.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7072で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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. 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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology and Definitions .....................................2
2.1. Key Words ..................................................2
2.2. Other Definitions ..........................................3
3. Description .....................................................3
3.1. Overview ...................................................3
3.2. URI Template ...............................................3
3.3. Syntax .....................................................4
3.4. Response ...................................................6
3.5. Protocol Support ...........................................6
4. IANA Considerations .............................................7
5. Security Considerations .........................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Acknowledgements .......................................9
This document defines a method to query a reputation data service for information about an entity, using the HyperText Transfer Protocol (HTTP) as the transport mechanism and JSON as the payload meta-format.
このドキュメントでは、トランスポートメカニズムとしてハイパーテキスト転送プロトコル（HTTP）を使用し、ペイロードメタ形式としてJSONを使用して、レピュテーションデータサービスにエンティティに関する情報を照会するメソッドを定義します。
The mechanism is a two-stage query:
メカニズムは2段階のクエリです。
1. A client retrieves a template from a server that describes the construction of a Universal Resource Identifier (URI) that will be the actual query;
1. クライアントはサーバーからテンプレートを取得し、実際のクエリとなるURI（Universal Resource Identifier）の構成を記述します。
2. The client then uses the constructed URI to request the reputation data from the server.
2. 次に、クライアントは構築されたURIを使用して、サーバーにレピュテーションデータを要求します。
This section defines terms used in the rest of the document.
このセクションでは、ドキュメントの残りの部分で使用される用語を定義します。
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 [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
Other terms of importance in this document are defined in [RFC7070] and [RFC7071].
このドキュメントの他の重要な用語は、[RFC7070]と[RFC7071]で定義されています。
The components to the question being asked are the following:
質問の構成要素は次のとおりです。
o The subject of the query;
o クエリの件名。
o The name of the host, or the IP address, at which the reputation service is available;
o レピュテーションサービスを利用できるホストの名前またはIPアドレス。
o The name of the reputation application, i.e., the context within which the subject is being evaluated;
o レピュテーションアプリケーションの名前、つまり、サブジェクトが評価されるコンテキスト。
o Optionally, names of the specific reputation assertions or attributes that are being requested.
o オプションで、要求されている特定のレピュテーションアサーションまたは属性の名前。
There is no discovery protocol for finding reputation services. These are typically subscription services, negotiated between operators through some out-of-band method.
レピュテーションサービスを見つけるための検出プロトコルはありません。これらは通常、サブスクリプションサービスであり、帯域外の方法を介してオペレーター間でネゴシエートされます。
Assertions are discussed in [RFC7071].
アサーションは[RFC7071]で議論されています。
The name of the application, if given, is expected to be one registered with IANA in the "Reputation Applications" registry, which is defined in [RFC7071]. A server receiving a query about an application it does not recognize or explicitly support (e.g., by virtue of private agreements or experimental extensions) MUST return a 404 error code.
アプリケーションの名前が指定されている場合、[RFC7071]で定義されている「レピュテーションアプリケーション」レジストリでIANAに登録されていることが予想されます。認識していない、または明示的にサポートしていないアプリケーションに関するクエリを受信したサーバーは（たとえば、プライベートアグリーメントや実験的な拡張機能により）404エラーコードを返す必要があります。
A reputation query made via [HTTP] encodes the question being asked in an HTTP GET method. The specific syntax of the query itself is specified by retrieving a URI template from the reputation service, completing the template, and then issuing the query.
[HTTP]経由で作成されたレピュテーションクエリは、HTTP GETメソッドで尋ねられる質問をエンコードします。クエリ自体の特定の構文は、レピュテーションサービスからURIテンプレートを取得し、テンプレートを完成させてから、クエリを発行することによって指定されます。
The template file is retrieved by requesting the [WELL-KNOWN-URI] "repute-template" from the host providing reputation service, using HTTP. (The registration for this well-known URI is in Section 4.) The server returns the template file in a reply that MUST use the text/plain media type (see [MIME]) and SHOULD include an Expires field (see Section 14.21 of [HTTP]) indicating a duration for which the template is to be considered valid by clients and not re-queried.
テンプレートファイルは、HTTPを使用して、レピュテーションサービスを提供するホストから[WELL-KNOWN-URI]の「repute-template」を要求することによって取得されます。 （この既知のURIの登録はセクション4にあります。）サーバーは、応答でテンプレートファイルを返します。このファイルは、text / plainメディアタイプを使用する必要があります（[MIME]を参照）。また、Expiresフィールドを含める必要があります（セクション14.21を参照）。 [HTTP]）テンプレートがクライアントによって有効であると見なされ、再クエリされない期間を示します。
If an Expires field is present, the client SHOULD NOT send another query to the same server prior to the timestamp in the field. If no Expires field is present, the client SHOULD wait at least one day before sending another query to the same server (i.e., the client assumes a default expiration of one day).
Expiresフィールドが存在する場合、クライアントはフィールドのタイムスタンプの前に同じサーバーに別のクエリを送信してはなりません（SHOULD NOT）。 Expiresフィールドが存在しない場合、クライアントは同じサーバーに別のクエリを送信する前に少なくとも1日待つ必要があります（つまり、クライアントは1日のデフォルトの有効期限を想定しています）。
The template file might contain more than one template. Such a file MUST have each template separated by a carriage return (ASCII 0x0D) and newline (ASCII 0x0A) character, as is typical for most text-based Internet protocols.
テンプレートファイルには、複数のテンプレートが含まれている場合があります。このようなファイルでは、ほとんどのテキストベースのインターネットプロトコルで一般的なように、各テンプレートをキャリッジリターン（ASCII 0x0D）と改行（ASCII 0x0A）で区切る必要があります。
Each template in the file is expanded using the variables that are the parameters to the query. These parameters are either the subject about which reputation information is sought (or details associated with it) or other parameters that are established out-of-band with the reputation service; they are not established by any automated discovery described here. The client then attempts to query each expanded template that uses a URI scheme it is capable of querying, in the order presented in the file, until the client finds one to which it can establish a usable connection and issue the query.
ファイル内の各テンプレートは、クエリのパラメーターである変数を使用して展開されます。これらのパラメーターは、レピュテーション情報を求める対象（またはそれに関連する詳細）、またはレピュテーションサービスを使用して帯域外で確立されるその他のパラメーターです。ここで説明する自動検出では確立されません。次に、クライアントは、クライアントが使用可能な接続を確立してクエリを発行できるテンプレートを見つけるまで、クエリ可能なURIスキームを使用する拡張された各テンプレートに対して、ファイルに示された順序でクエリを試行します。
For example, given the following template:
たとえば、次のテンプレートがあるとします。
http://{service}/{application}/{subject}/{assertion}
A query about the use of the domain "example.org" in the "email-id" application context to a service run at "example.com", where that application declares a required "subject" parameter, requesting the "SPAM" reputation assertion, would be formed as follows:
「example.com」で実行されるサービスへの「email-id」アプリケーションコンテキストでのドメイン「example.org」の使用に関するクエリ。このアプリケーションは、必須の「subject」パラメータを宣言し、「SPAM」レピュテーションを要求します。アサーションは、次のように形成されます。
http://example.com/email-id/example.org/spam
The syntax for the [URI] of the query is constructed using a template as per [URI-TEMPLATE]. (See Section 3.2.) Clients MUST provide the following values in the expansion of the template:
クエリの[URI]の構文は、[URI-TEMPLATE]のテンプレートを使用して構築されます。 （セクション3.2を参照。）クライアントは、テンプレートの展開で次の値を提供する必要があります。
application: The name of the application reputation in whose context the request is being made. These names are registered with IANA, and conform to the ABNF "token" found in [MIME].
application：要求が行われているコンテキストでのアプリケーションレピュテーションの名前。これらの名前はIANAに登録されており、[MIME]にあるABNF "トークン"に準拠しています。
service: The hostname or IP address to which the query is being sent. This MUST be the same as the host to which the template query was issued.
service：クエリの送信先のホスト名またはIPアドレス。これは、テンプレートクエリが発行されたホストと同じである必要があります。
subject: The subject of the query, extracted from some content to be evaluated. The subject portion of the template conforms to the ABNF "value" found in [MIME].
subject：評価されるコンテンツから抽出されたクエリの件名。テンプレートのサブジェクト部分は、[MIME]にあるABNFの「値」に準拠しています。
The following variable can also be provided. It is not mandatory in this model, but a specific application (defined in its own extension document) might declare it mandatory in a specific context:
次の変数も提供できます。このモデルでは必須ではありませんが、特定のアプリケーション（独自の拡張ドキュメントで定義）は、特定のコンテキストで必須と宣言する場合があります。
assertion: The name of the specific assertion of interest to the client. Assertion names conform to the ABNF "token" found in [MIME]. If absent, the client is indicating that it requests all available assertion information.
アサーション：クライアントが関心を持つ特定のアサーションの名前。アサーション名は、[MIME]にあるABNF「トークン」に準拠しています。存在しない場合、クライアントは、利用可能なすべてのアサーション情報を要求することを示しています。
If a template contains a variable that is not required and the client does not have a value to insert, it substitutes the empty string into the template in place of that variable. Service providers crafting templates MUST do so such that a client doing an empty variable expansion will still produce a syntactically and semantically valid and unambiguous URI. For example, given this template:
テンプレートに不要な変数が含まれていて、クライアントに挿入する値がない場合、テンプレートはその変数の代わりに空の文字列をテンプレートに置き換えます。テンプレートを作成するサービスプロバイダーは、空の変数展開を行うクライアントが構文的および意味的に有効で明確なURIを生成するように、そうする必要があります。たとえば、次のテンプレートがあるとします。
http://{service}/{application}/{subject}/{assertion}/{a}/{b}
If "{a}" and "{b}" are optional and "{a}" expands to the empty string, then the resulting URI will have adjacent backslash ("/", ASCII 0x2F) characters and one path component after the assertion. If the server interpreting the URI's path component removes or ignores adjacent backslash characters (such as is done with the UNIX filesystem), the server will be unable to distinguish an empty "{a}" from an empty "{b}", and it could serve the wrong response. Where possible, the template needs to be constructed such that expansion of optional variables yields an unambiguous result. For example, an unambiguous version of the above would be:
「{a}」と「{b}」がオプションで、「{a}」が空の文字列に展開される場合、結果のURIには、アサーション後に隣接するバックスラッシュ（「/」、ASCII 0x2F）文字と1つのパスコンポーネントが含まれます。 。 URIのパスコンポーネントを解釈するサーバーが隣接するバックスラッシュ文字を削除または無視する場合（UNIXファイルシステムで行われるように）、サーバーは空の「{a}」と空の「{b}」を区別できなくなります。間違った応答をする可能性があります。可能な場合、テンプレートは、オプションの変数を展開すると明確な結果が得られるように構成する必要があります。たとえば、上記の明確なバージョンは次のようになります。
http://{service}/{application}/{subject}/{assertion}/a={a}/b={b}
...or, even better, using URI template set expansions:
...または、さらに良いことに、URIテンプレートセットの拡張を使用します。
http://{service}/{application}/{subject}/{assertion}{?a,b}
Every application space has a set of assertions applicable to its own context. [RFC7071] defines a single assertion assumed to exist in any application that does not define its own assertion set.
すべてのアプリケーション空間には、独自のコンテキストに適用できる一連のアサーションがあります。 [RFC7071]は、独自のアサーションセットを定義しないアプリケーションに存在すると想定される単一のアサーションを定義します。
Reputation applications can extend the set of optional or required query parameters as part of their IANA registration actions. The set enumerated above establishes the base set common to all of them. Further, additional required or optional extension query parameters might be defined by specific reputation service providers, though these are private arrangements between client and server and will not be registered with IANA.
レピュテーションアプリケーションは、IANA登録アクションの一部として、オプションまたは必須のクエリパラメータのセットを拡張できます。上記のセットは、それらすべてに共通の基本セットを確立します。さらに、追加の必須またはオプションの拡張クエリパラメーターは、特定のレピュテーションサービスプロバイダーによって定義される場合がありますが、これらはクライアントとサーバー間のプライベートな取り決めであり、IANAに登録されません。
Authentication between reputation client and server is outside the scope of this specification. It could be provided through a variety of available transport-based or object-based mechanisms, including a later extension of this specification.
レピュテーションクライアントとサーバー間の認証は、この仕様の範囲外です。これは、この仕様の今後の拡張を含む、利用可能なさまざまなトランスポートベースまたはオブジェクトベースのメカニズムを通じて提供できます。
The response is expected to be contained in a media type designed to deliver reputons. A media type designed for this purpose, "application/reputon+json", is defined in [RFC7071].
応答は、評判を伝えるように設計されたメディアタイプに含まれることが期待されています。この目的のために設計されたメディアタイプ「application / reputon + json」は、[RFC7071]で定義されています。
If the server generates responses that contain an Expires field (see Section 14.21 of [HTTP]), that timestamp MUST align with the "expires" field within the response, if any. Failing to do so can result in a state where the response has expired, but the HTTP reply has not, and the client would in that case be unable to get a fresh answer from the reputation server.
サーバーがExpiresフィールドを含む応答を生成する場合（[HTTP]のセクション14.21を参照）、そのタイムスタンプは、応答内の「expires」フィールド（存在する場合）に合わせる必要があります。そうしないと、応答の有効期限が切れた状態になる可能性がありますが、HTTP応答は有効期限が切れておらず、その場合、クライアントはレピュテーションサーバーから新しい応答を取得できません。
A client has to implement HTTP in order to retrieve the query template as described in Section 3.2. Accordingly, a server can assume the client will be able to handle a URI template that produces a URI for the query using the "http" URI scheme. The template could yield a query string that uses some other URI scheme, in which case the client could try that URI as well if it supports issuing queries with that URI scheme.
セクション3.2で説明されているように、クライアントはクエリテンプレートを取得するためにHTTPを実装する必要があります。したがって、サーバーは、クライアントが「http」URIスキームを使用してクエリのURIを生成するURIテンプレートを処理できると想定できます。テンプレートは、他のURIスキームを使用するクエリ文字列を生成できます。その場合、クライアントがそのURIスキームを使用したクエリの発行をサポートしている場合、クライアントはそのURIも試すことができます。
A server SHOULD include support for providing service over HTTP, and publish templates indicating support for this, as a baseline for interoperability with arbitrary clients.
サーバーは、HTTPを介してサービスを提供するためのサポートを含み、任意のクライアントとの相互運用性のベースラインとして、このサポートを示すテンプレートを公開する必要があります（SHOULD）。
This document registers the "repute-template" well-known URI in the "Well-Known URI" registry as defined by [WELL-KNOWN-URI], as follows:
このドキュメントは、次のように、[WELL-KNOWN-URI]で定義されている「Well-Known URI」レジストリに「repute-template」の既知のURIを登録します。
URI suffix: repute-template
URIサフィックス：repute-template
Change controller: IETF
コントローラの変更：IETF
Specification document(s): [RFC7072]
仕様書：[RFC7072]
Related information: none
関連情報：なし
This document defines particular uses of existing protocols for a specific application. In particular, the basic protocol used for this service to retrieve a URI template from a well-known location is basic HTTP, which is not secure without certain extensions. Security issues relevant to use of URI templates are discussed in [URI-TEMPLATE], and those relevant to well-known URI definitions and retrieval are discussed in [WELL-KNOWN-URI].
このドキュメントでは、特定のアプリケーションに対する既存のプロトコルの特定の使用法を定義しています。特に、このサービスが既知の場所からURIテンプレートを取得するために使用する基本プロトコルは基本HTTPであり、特定の拡張機能がないと安全ではありません。 URIテンプレートの使用に関連するセキュリティの問題は[URI-TEMPLATE]で説明されており、既知のURI定義と取得に関連するセキュリティの問題は[WELL-KNOWN-URI]で説明されています。
The reputation service itself will use HTTP or other transport methods to issue queries and receive replies. Those protocols have registered URI schemes and, as such, presumably have documented security considerations. The protocol described here operates atop those URI schemes, and does not itself present new security considerations.
レピュテーションサービス自体は、HTTPまたはその他の転送方法を使用して、クエリを発行し、応答を受信します。これらのプロトコルにはURIスキームが登録されているため、おそらくセキュリティに関する考慮事項が文書化されています。ここで説明するプロトコルは、これらのURIスキームの上で動作し、それ自体は新しいセキュリティの考慮事項を提示しません。
Reputation mechanisms represent an obvious security concern, in terms of the validity and use of the reputation information. These issues are beyond the scope of this specification. General information pertaining to using or providing reputation services can be found in [CONSIDERATIONS].
レピュテーションメカニズムは、レピュテーション情報の有効性と使用に関して、セキュリティ上の明らかな懸念事項です。これらの問題は、この仕様の範囲を超えています。レピュテーションサービスの使用または提供に関する一般的な情報については、[考慮事項]を参照してください。
The security considerations applicable to HTTP (see Section 15 of [HTTP] apply, since this query mechanism for reputation uses that protocol. If it is desirable to conceal the content of the query and its response, use of encryption techniques such as HTTP over TLS [HTTPS] can be used.
HTTPに適用されるセキュリティの考慮事項（[HTTP]のセクション15を参照）が適用されます。これは、レピュテーションのためのこのクエリメカニズムがそのプロトコルを使用するためです。クエリの内容とその応答を隠すことが望ましい場合は、HTTP over TLSなどの暗号化技術の使用【HTTPS】が利用できます。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC7070] Borenstein, N., Kucherawy, M., and A. Sullivan, "An Architecture for Reputation Reporting", RFC 7070, November 2013.
[RFC7070] Borenstein、N.、Kucherawy、M.、and A. Sullivan、 "An Architecture for Reputation Reporting"、RFC 7070、2013年11月。
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, November 2013.
[RFC7071] Borenstein、N。およびM. Kucherawy、「評判交換のためのメディアタイプ」、RFC 7071、2013年11月。
[URI-TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012.
[URIテンプレート]グレゴリオJ.、フィールディングR.、ハドリーM.、ノッティンガムM.、D。オーチャード、「URIテンプレート」、RFC 6570、2012年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[WELL-KNOWN-URI] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[WELL-KNOWN-URI]ノッティンガム、M。およびE. Hammer-Lahav、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、2010年4月。
[CONSIDERATIONS] Kucherawy, M., "Operational Considerations Regarding Reputation Services", Work in Progress, May 2013.
[考慮事項] Kucherawy、M。、「評判サービスに関する運用上の考慮事項」、進行中の作業、2013年5月。
[HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTPS] Rescorla、E。、「HTTP Over TLS」、RFC 2818、2000年5月。
The authors would like to thank the following for their contributions to this work: Simon Hunt, Mark Nottingham, David F. Skoll, and Mykyta Yevstifeyev.
著者は、この作品への貢献に対して以下を感謝します：Simon Hunt、Mark Nottingham、David F. Skoll、およびMykyta Yevstifeyev。
Authors' Addresses
著者のアドレス
Nathaniel Borenstein Mimecast 203 Crescent St., Suite 303 Waltham, MA 02453 USA
Nathaniel Borenstein Mimecast 203 Crescent St.、Suite 303 Waltham、MA 02453 USA
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA
マレーS.クチェラウィ270アップランドドライブサンフランシスコ、カリフォルニア94127アメリカ
EMail: superuser@gmail.com