RFC 7565 - The 'acct' URI Scheme 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7565
タイトル : RFC 7565 - 「acct」URIスキーム
翻訳編集 : 自動生成

[要約] RFC 7565は、'acct' URIスキームについての仕様を定めており、電子メールアドレスを識別するための新しいURIスキームを提案しています。このRFCの目的は、電子メールアドレスを一意に識別するための標準化と、関連するアプリケーションやプロトコルの開発を促進することです。

Internet Engineering Task Force (IETF)                    P. Saint-Andre
Request for Comments: 7565                                      May 2015
Category: Standards Track
ISSN: 2070-1721

The 'acct' URI Scheme

「acct」URIスキーム

Abstract

概要

This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.

このドキュメントでは、アカウントとのやり取りに使用できる特定のプロトコルに関係なく、サービスプロバイダーでユーザーのアカウントを識別する方法として「acct」Uniform Resource Identifier（URI）スキームを定義しています。

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/rfc7565.

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

著作権表示

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 .....................................................2
   3. Rationale .......................................................2
   4. Definition ......................................................3
   5. Security Considerations .........................................4
   6. Internationalization Considerations .............................5
   7. IANA Considerations .............................................5
   8. References ......................................................6
      8.1. Normative References .......................................6
      8.2. Informative References .....................................7
   Acknowledgements ...................................................8
   Author's Address ...................................................8

1. Introduction

1. はじめに

Existing Uniform Resource Identifier (URI) schemes that enable interaction with, or that identify resources associated with, a user's account at a service provider are tied to particular services or application protocols. Two examples are the 'mailto' scheme (which enables interaction with a user's email account) and the 'http' scheme (which enables retrieval of web files controlled by a user or interaction with interfaces providing information about a user). However, there exists no URI scheme that generically identifies a user's account at a service provider without specifying a particular protocol to use when interacting with the account. This specification fills that gap.

サービスプロバイダーでのユーザーのアカウントとの対話を可能にする、または関連するリソースを識別する既存のUniform Resource Identifier（URI）スキームは、特定のサービスまたはアプリケーションプロトコルに関連付けられています。 2つの例は、 'mailto'スキーム（ユーザーの電子メールアカウントとの対話を可能にする）と 'http'スキーム（ユーザーによって制御されるWebファイルの取得またはユーザーに関する情報を提供するインターフェイスとの対話を可能にする）です。ただし、アカウントと対話するときに使用する特定のプロトコルを指定せずに、サービスプロバイダーでユーザーのアカウントを一般的に識別するURIスキームは存在しません。この仕様はそのギャップを埋めます。

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 [RFC2119].

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

3. Rationale

3. 根拠

During formalization of the WebFinger protocol [RFC7033], much discussion occurred regarding the appropriate URI scheme to include when specifying a user's account as a web link [RFC5988]. Although both the 'mailto' [RFC6068] and 'http' [RFC7230] schemes were proposed, not all service providers offer email services or web interfaces on behalf of user accounts (e.g., a microblogging or instant messaging provider might not offer email services, or an enterprise might not offer HTTP interfaces to information about its employees). Therefore, the participants in the discussion recognized that it would be helpful to define a URI scheme that could be used to generically identify a user's account at a service provider, irrespective of the particular application protocols used to interact with the account. The result was the 'acct' URI scheme defined in this document.

WebFingerプロトコル[RFC7033]の正式化中に、ユーザーのアカウントをWebリンク[RFC5988]として指定するときに含める適切なURIスキームに関して多くの議論が行われました。「mailto」[RFC6068]と「http」[RFC7230]の両方のスキームが提案されましたが、すべてのサービスプロバイダーがユーザーアカウントに代わってメールサービスやウェブインターフェースを提供しているわけではありません（たとえば、マイクロブログやインスタントメッセージングプロバイダーがメールサービスを提供していない場合があります）。または、企業はその従業員に関する情報へのHTTPインターフェイスを提供しない場合があります）。したがって、ディスカッションの参加者は、アカウントとの対話に使用される特定のアプリケーションプロトコルに関係なく、サービスプロバイダーでユーザーのアカウントを一般的に識別するために使用できるURIスキームを定義すると役立つことを認識しました。結果は、このドキュメントで定義された「acct」URIスキームでした。

(Note that a user is not necessarily a human; it could be an automated application such as a bot, a role-based alias, etc. However, an 'acct' URI is always used to identify something that has an account at a service, not the service itself.)

（ユーザーは必ずしも人間ではないことに注意してください。ボットやロールベースのエイリアスなどの自動化されたアプリケーションである可能性があります。ただし、「アカウント」URIは常に、サービスでアカウントを持つものを識別するために使用されます、サービス自体ではありません。）

4. Definition

4. 定義

The syntax of the 'acct' URI scheme is defined under Section 7 of this document. Although 'acct' URIs take the form "user@host", the scheme is designed for the purpose of identification instead of interaction (regarding this distinction, see Section 1.2.2 of [RFC3986]). The "Internet resource" identified by an 'acct' URI is a user's account hosted at a service provider, where the service provider is typically associated with a DNS domain name. Thus, a particular 'acct' URI is formed by setting the "user" portion to the user's account name at the service provider and by setting the "host" portion to the DNS domain name of the service provider.

「acct」URIスキームの構文は、このドキュメントのセクション7で定義されています。「acct」URIは「user @ host」の形式をとりますが、スキームは相互作用ではなく識別を目的として設計されています（この区別に関しては、[RFC3986]のセクション1.2.2を参照してください）。「acct」URIで識別される「インターネットリソース」は、サービスプロバイダーでホストされるユーザーのアカウントです。サービスプロバイダーは通常、DNSドメイン名に関連付けられています。したがって、特定の「acct」URIは、「ユーザー」部分をサービスプロバイダーのユーザーのアカウント名に設定し、「ホスト」部分をサービスプロバイダーのDNSドメイン名に設定することで形成されます。

Consider the case of a user with an account name of "foobar" on a microblogging service "status.example.net". It is taken as convention that the string "foobar@status.example.net" designates that account. This is expressed as a URI using the 'acct' scheme as "acct:foobar@status.example.net".

マイクロブログサービス「status.example.net」で「foobar」のアカウント名を持つユーザーの場合を考えてみます。文字列 "foobar@status.example.net"がそのアカウントを指定することが慣例として採用されています。これは、「acct」スキームを使用した「acct：foobar@status.example.net」のようなURIとして表されます。

A common scenario is for a user to register with a service provider using an identifier (such as an email address) that is associated with some other service provider. For example, a user with the email address "juliet@capulet.example" might register with a commerce website whose domain name is "shoppingsite.example". In order to use her email address as the localpart of the 'acct' URI, the at-sign character (U+0040) needs to be percent-encoded as described in [RFC3986]. Thus, the resulting 'acct' URI would be "acct:juliet%40capulet.example@shoppingsite.example".

一般的なシナリオは、ユーザーが他のサービスプロバイダーに関連付けられている識別子（電子メールアドレスなど）を使用してサービスプロバイダーに登録することです。たとえば、メールアドレスが「juliet@capulet.example」のユーザーは、ドメイン名が「shoppingsite.example」のコマースウェブサイトに登録する場合があります。 [acct] URIのローカル部分として彼女の電子メールアドレスを使用するには、[RFC3986]で説明されているように、アットマーク文字（U + 0040）をパーセントエンコードする必要があります。したがって、結果の「acct」URIは「acct：juliet%40capulet.example@shoppingsite.example」になります。

It is not assumed that an entity will necessarily be able to interact with a user's account using any particular application protocol, such as email; to enable such interaction, an entity would need to use the appropriate URI scheme for such a protocol, such as the 'mailto' scheme. While it might be true that the 'acct' URI minus the scheme name (e.g., "user@example.com" derived from "acct:user@example.com") can be reached via email or some other application protocol, that fact would be purely contingent and dependent upon the deployment practices of the provider.

エンティティが必ずしも電子メールなどの特定のアプリケーションプロトコルを使用してユーザーのアカウントとやり取りできるとは限りません。このような相互作用を可能にするために、エンティティは、「mailto」スキームなど、そのようなプロトコルに適切なURIスキームを使用する必要があります。「acct」URIからスキーム名を除いたもの（たとえば、「acct：user@example.com」から派生した「user@example.com」）は、電子メールまたはその他のアプリケーションプロトコルを介して到達できることは事実ですが、純粋に偶発的であり、プロバイダーの展開方法に依存します。

Because an 'acct' URI enables abstract identification only and not interaction, this specification provides no method for dereferencing an 'acct' URI on its own, e.g., as the value of the 'href' attribute of an HTML anchor element. For example, there is no behavior specified in this document for an 'acct' URI used as follows:

「acct」URIは抽象的識別のみを可能にし、相互作用はできないため、この仕様では、たとえばHTMLアンカー要素の「href」属性の値として、「acct」URIを単独で逆参照する方法は提供されていません。たとえば、このドキュメントでは、次のように使用される「acct」URIの動作は指定されていません。

   <a href='acct:bob@example.com'>find out more</a>

Any protocol that uses 'acct' URIs is responsible for specifying how an 'acct' URI is employed in the context of that protocol (in particular, how it is dereferenced or resolved; see [RFC3986]). As a concrete example, an "Account Information" application of the WebFinger protocol [RFC7033] might take an 'acct' URI, resolve the host portion to find a WebFinger server, and then pass the 'acct' URI as a parameter in a WebFinger HTTP request for metadata (i.e., web links [RFC5988]) about the resource. For example:

「acct」URIを使用するプロトコルは、そのプロトコルのコンテキストで「acct」URIがどのように使用されるかを指定する責任があります（特に、それが逆参照または解決される方法。[RFC3986]を参照）。具体的な例として、WebFingerプロトコル[RFC7033]の「アカウント情報」アプリケーションは、「acct」URIを取得し、ホスト部分を解決してWebFingerサーバーを見つけ、「acct」URIをWebFingerのパラメーターとして渡します。リソースに関するメタデータ（つまり、Webリンク[RFC5988]）のHTTPリクエスト。例えば：

   GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1

The service retrieves the metadata associated with the account identified by that URI and then provides that metadata to the requesting entity in an HTTP response.

サービスは、そのURIで識別されるアカウントに関連付けられたメタデータを取得し、そのメタデータをHTTP応答で要求エンティティに提供します。

If an application needs to compare two 'acct' URIs (e.g., for purposes of authentication and authorization), it MUST do so using case normalization and percent-encoding normalization as specified in Sections 6.2.2.1 and 6.2.2.2 of [RFC3986].

アプリケーションが2つの 'acct' URIを比較する必要がある場合（たとえば、認証と承認の目的で）、[RFC3986]のセクション6.2.2.1と6.2.2.2で指定されているように、大文字と小文字の正規化とパーセントエンコーディングの正規化を使用して比較する必要があります。

5. Security Considerations

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

Because the 'acct' URI scheme does not directly enable interaction with a user's account at a service provider, direct security concerns are minimized.

「acct」URIスキームでは、サービスプロバイダーでのユーザーのアカウントとの対話が直接有効にならないため、直接的なセキュリティの懸念が最小限に抑えられます。

However, an 'acct' URI does provide proof of existence of the account; this implies that harvesting published 'acct' URIs could prove useful to spammers and similar attackers -- for example, if they can use an 'acct' URI to leverage more information about the account (e.g., via WebFinger) or if they can interact with protocol-specific URIs (such as 'mailto' URIs) whose user@host portion is the same as that of the 'acct' URI.

ただし、「acct」URIはアカウントの存在の証拠を提供します。これは、公開された「acct」URIの収集がスパマーや類似の攻撃者に役立つ可能性があることを意味します。たとえば、「acct」URIを使用してアカウントに関する詳細情報を利用できる場合（WebFingerなど）、または対話できる場合user @ host部分が「acct」URIと同じプロトコル固有のURI（「mailto」URIなど）。

In addition, protocols that make use of 'acct' URIs are responsible for defining security considerations related to such usage, e.g., the risks involved in dereferencing an 'acct' URI, the authentication and authorization methods that could be used to control access to personal data associated with a user's account at a service, and methods for ensuring the confidentiality of such information.

さらに、「acct」URIを使用するプロトコルは、そのような使用に関連するセキュリティの考慮事項、たとえば「acct」URIの逆参照に関連するリスク、個人へのアクセスを制御するために使用できる認証および承認方法を定義する責任があります。サービスにおけるユーザーのアカウントに関連付けられたデータ、およびそのような情報の機密性を確保する方法。

The use of percent-encoding allows a wider range of characters in account names but introduces some additional risks. Implementers are advised to disallow percent-encoded characters or sequences that would (1) result in space, null, control, or other characters that are otherwise forbidden, (2) allow unauthorized access to private data, or (3) lead to other security vulnerabilities.

パーセントエンコーディングを使用すると、アカウント名に使用できる文字の範囲が広がりますが、いくつかの追加のリスクが生じます。実装者は、（1）スペース、null、制御、またはその他の方法で禁止されているその他の文字が発生する、（2）プライベートデータへの不正アクセスを許可する、または（3）他のセキュリティにつながるパーセントエンコード文字またはシーケンスを禁止することをお勧めします脆弱性。

6. Internationalization Considerations

6. 国際化に関する考慮事項

As specified in [RFC3986], the 'acct' URI scheme allows any character from the Unicode repertoire [Unicode] encoded as UTF-8 [RFC3629] and then percent-encoded into valid ASCII [RFC20]. Before applying any percent-encoding, an application MUST ensure the following about the string that is used as input to the URI-construction process:

[RFC3986]で指定されているように、「acct」URIスキームでは、UTF-8 [RFC3629]としてエンコードされ、有効なASCII [RFC20]にパーセントエンコードされたUnicodeレパートリー[Unicode]の任意の文字を許可します。パーセントエンコーディングを適用する前に、アプリケーションは、URI構築プロセスへの入力として使用される文字列について、以下を確認する必要があります。

o The userpart consists only of Unicode code points that conform to the PRECIS IdentifierClass specified in [RFC7564].

o userpartは、[RFC7564]で指定されているPRECIS IdentifierClassに準拠するUnicodeコードポイントのみで構成されています。

o The host consists only of Unicode code points that conform to the rules specified in [RFC5892].

o ホストは、[RFC5892]で指定されたルールに準拠するUnicodeコードポイントのみで構成されます。

o Internationalized domain name (IDN) labels are encoded as A-labels [RFC5890].

o 国際化ドメイン名（IDN）ラベルは、Aラベル[RFC5890]としてエンコードされます。

7. IANA Considerations

7. IANAに関する考慮事項

In accordance with the guidelines and registration procedures for new URI schemes [RFC4395], this section provides the information needed to register the 'acct' URI scheme.

新しいURIスキーム[RFC4395]のガイドラインと登録手順に従って、このセクションでは「acct」URIスキームを登録するために必要な情報を提供します。

URI Scheme Name: acct

URIスキーム名：acct

Status: permanent

ステータス：永続的

URI Scheme Syntax: The 'acct' URI syntax is defined here in Augmented Backus-Naur Form (ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims', and 'unreserved' rules from [RFC3986]:

URIスキーム構文：「acct」URI構文は、ここで拡張バッカスナウアフォーム（ABNF）[RFC5234]で定義されており、「host」、「pct-encoded」、「sub-delims」、および「unreserved」のルールを利用しています。 [RFC3986]：

      acctURI      = "acct" ":" userpart "@" host
      userpart     = unreserved / sub-delims
                     0*( unreserved / pct-encoded / sub-delims )

Note that additional rules regarding the strings that are used as input to construction of 'acct' URIs further limit the characters that can be percent-encoded; see the Encoding Considerations as well as Section 6 of this document.

「acct」URIの構築への入力として使用される文字列に関する追加の規則により、パーセントエンコードできる文字がさらに制限されることに注意してください。このドキュメントのセクション6だけでなく、エンコーディングに関する考慮事項も参照してください。

URI Scheme Semantics: The 'acct' URI scheme identifies accounts hosted at service providers. It is used only for identification, not interaction. A protocol that employs the 'acct' URI scheme is responsible for specifying how an 'acct' URI is dereferenced in the context of that protocol. There is no media type associated with the 'acct' URI scheme.

URIスキームセマンティクス： 'acct' URIスキームは、サービスプロバイダーでホストされているアカウントを識別します。相互作用ではなく、識別のためにのみ使用されます。「acct」URIスキームを使用するプロトコルは、そのプロトコルのコンテキストで「acct」URIがどのように逆参照されるかを指定する責任があります。「acct」URIスキームに関連付けられたメディアタイプはありません。

Encoding Considerations: See Section 6 of this document.

エンコーディングに関する考慮事項：このドキュメントのセクション6を参照してください。

Applications/Protocols That Use This URI Scheme Name: At the time of this writing, only the WebFinger protocol uses the 'acct' URI scheme. However, use is not restricted to the WebFinger protocol, and the scheme might be considered for use in other protocols.

このURIスキーム名を使用するアプリケーション/プロトコル：この記事の執筆時点では、WebFingerプロトコルのみが「acct」URIスキームを使用しています。ただし、使用はWebFingerプロトコルに限定されず、このスキームは他のプロトコルでの使用が検討される場合があります。

Interoperability Considerations: There are no known interoperability concerns related to use of the 'acct' URI scheme.

相互運用性に関する考慮事項：「acct」URIスキームの使用に関連する既知の相互運用性の問題はありません。

Security Considerations: See Section 5 of this document.

セキュリティに関する考慮事項：このドキュメントのセクション5を参照してください。

Contact: Peter Saint-Andre, peter@andyet.com

連絡先：Peter Saint-Andre、peter @ andyet.com

Author/Change Controller: This scheme is registered under the IETF tree. As such, the IETF maintains change control.

作成者/変更コントローラ：このスキームはIETFツリーの下に登録されています。そのため、IETFは変更管理を維持します。

References: None.

参照：なし。

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, 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>。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。

[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>。

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

[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。

[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.

[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<http://www.rfc-editor.org/info/ rfc5890>。

[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, <http://www.rfc-editor.org/info/rfc5892>.

[RFC5892] Faltstrom、P。、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、DOI 10.17487 / RFC5892、2010年8月、<http://www.rfc-editor.org / info / rfc5892>。

[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.

[RFC7564] Saint-Andre、P。およびM. Blanchet、「PRECIS Framework：Preparation、Enforcement、and Comparison of Internationalized Strings in Application Protocols」、RFC 7564、DOI 10.17487 / RFC7564、2015年5月、<http：// www。 rfc-editor.org/info/rfc7564>。

[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.

[Unicode] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。

8.2. Informative References

8.2. 参考引用

[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.

[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://www.rfc-editor.org/info/rfc20>。

[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, DOI 10.17487/RFC4395, February 2006, <http://www.rfc-editor.org/info/rfc4395>.

[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、DOI 10.17487 / RFC4395、2006年2月、<http：// www。 rfc-editor.org/info/rfc4395>。

[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, <http://www.rfc-editor.org/info/rfc5988>.

[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、DOI 10.17487 / RFC5988、2010年10月、<http://www.rfc-editor.org/info/rfc5988>。

[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <http://www.rfc-editor.org/info/rfc6068>.

[RFC6068] Duerst、M.、Masinter、L。、およびJ. Zawinski、「The 'mailto' URI Scheme」、RFC 6068、DOI 10.17487 / RFC6068、2010年10月、<http://www.rfc-editor.org / info / rfc6068>。

[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, <http://www.rfc-editor.org/info/rfc7033>.

[RFC7033]ジョーンズ、P。、サルゲイロ、G。、ジョーンズ、M。、およびJ.スマール、「WebFinger」、RFC 7033、DOI 10.17487 / RFC7033、2013年9月、<http://www.rfc-editor.org / info / rfc7033>。

[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<http：/ /www.rfc-editor.org/info/rfc7230>。

Acknowledgements

謝辞

The 'acct' URI scheme was originally proposed during work on the WebFinger protocol; special thanks are due to Blaine Cook, Brad Fitzpatrick, and Eran Hammer-Lahav for their early work on the concept (which in turn was partially inspired by work on Extensible Resource Identifiers at OASIS). The scheme was first formally specified in [RFC7033]; the authors of that specification (Paul Jones, Gonzalo Salgueiro, and Joseph Smarr) are gratefully acknowledged. Thanks are also due to Stephane Bortzmeyer, Melvin Carvalho, Martin Duerst, Graham Klyne, Barry Leiba, Subramanian Moonesamy, Evan Prodromou, James Snell, and various participants in the IETF APPSAWG for their feedback. Meral Shirazipour completed a Gen-ART review. Dave Cridland completed an AppsDir review and is gratefully acknowledged for providing proposed text that was incorporated into Sections 3 and 5. IESG comments from Richard Barnes, Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Sean Turner also led to improvements in the specification.

「acct」URIスキームは、WebFingerプロトコルの作業中に最初に提案されました。 Blaine Cook、Brad Fitzpatrick、およびEran Hammer-Lahavがコンセプトの初期の取り組み（OASISのExtensible Resource Identifiersの取り組みから部分的に着想を得た）に特に感謝します。このスキームは最初に[RFC7033]で正式に指定されました。その仕様の作成者（Paul Jones、Gonzalo Salgueiro、Joseph Smarr）に感謝の意を表します。また、Stephane Bortzmeyer、Melvin Carvalho、Martin Duerst、Graham Klyne、Barry Leiba、Subramanian Moonesamy、Evan Prodromou、James Snell、およびフィードバックのためのIETF APPSAWGのさまざまな参加者にも感謝します。 Meral ShirazipourがGen-ARTレビューを完了しました。 Dave CridlandがAppsDirレビューを完了し、セクション3と5に組み込まれた提案されたテキストを提供してくれたことに感謝します。RichardBarnes、Adrian Farrel、Stephen Farrell、Barry Leiba、Pete Resnick、およびSean TurnerからのIESGコメントも、仕様。

Author's Address

著者のアドレス

Peter Saint-Andre

ピーターサンタンドレ

   EMail: peter@andyet.com
   URI:   https://andyet.com/