Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7565 May 2015
Category: Standards Track
ISSN: 2070-1721
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”统一资源标识符（URI）方案定义为在服务提供商处识别用户帐户的一种方式，而不考虑可用于与帐户交互的特定协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
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.
现有的统一资源标识符（URI）方案支持与服务提供商的用户帐户进行交互，或者标识与用户帐户相关联的资源，这些方案与特定的服务或应用程序协议相关联。两个示例是“mailto”方案（允许与用户的电子邮件帐户交互）和“http”方案（允许检索用户控制的web文件或与提供用户信息的界面交互）。但是，不存在一种URI方案，它可以在服务提供商处通用地标识用户的帐户，而不指定与帐户交互时要使用的特定协议。本规范填补了这一空白。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
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
在WebFinger协议[RFC7033]的形式化过程中，关于在将用户帐户指定为web链接[RFC5988]时要包含的适当URI方案，进行了大量讨论。尽管提出了“mailto”[RFC6068]和“http”[RFC7230]方案，但并非所有服务提供商都代表用户帐户提供电子邮件服务或web界面（例如，微博或即时消息提供商可能不提供电子邮件服务，或者企业可能不提供员工信息的http界面）。因此，讨论的参与者认识到，定义一个可用于
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.
通常在服务提供商处标识用户的帐户，而不考虑用于与帐户交互的特定应用程序协议。结果是本文档中定义的“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.)
（请注意，用户不一定是人；它可以是自动应用程序，如bot、基于角色的别名等。但是，“acct”URI始终用于标识在服务中拥有帐户的对象，而不是服务本身。）
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节中定义。尽管“账户”URI采用以下形式：user@host“，该方案设计用于识别而非交互（关于此区别，请参见[RFC3986]第1.2.2节）。“acct”URI标识的“Internet资源”是托管在服务提供商上的用户帐户，其中服务提供商通常与DNS域名相关联。因此，通过将“用户”部分设置为服务提供商的用户帐户名，并将“主机”部分设置为服务提供商的DNS域名，形成特定的“账户”URI。
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".
考虑在微博服务“Stase.NET.NET”上有“FooBar”帐户名的用户的情况。按照惯例，字符串“”foobar@status.example.net“指定该帐户。这表示为URI，使用“acct”方案作为“acct:foobar@status.example.net".
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的本地部分，at符号字符（U+0040）需要按照[RFC3986]中的说明进行百分比编码。因此，生成的“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.
假设实体不一定能够使用任何特定的应用协议（如电子邮件）与用户的帐户进行交互；为了实现这种交互，实体需要为这种协议使用适当的URI方案，例如“mailto”方案。虽然“acct”URI减去方案名称可能是真的（例如“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只支持抽象标识而不支持交互，因此本规范不提供单独取消引用“acct”URI的方法，例如作为HTML锚元素的“href”属性的值。例如，本文档中没有为如下使用的“acct”URI指定任何行为：
<a href='acct:bob@example.com'>find out more</a>
<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作为有关资源的元数据（即web链接[RFC5988]）的WebFinger HTTP请求中的参数传递。例如：
GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1
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].
如果应用程序需要比较两个“acct”URI（例如，出于身份验证和授权的目的），则必须使用[RFC3986]第6.2.2.1节和第6.2.2.2节中规定的大小写规范化和百分比编码规范化进行比较。
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.
然而，“账户”URI确实提供了账户存在的证据；这意味着获取已发布的“acct”URI可能对垃圾邮件发送者和类似攻击者有用——例如，如果他们可以使用“acct”URI来利用有关帐户的更多信息（例如，通过WebFinger），或者如果他们可以与特定于协议的URI（例如“mailto”URI）交互谁的user@host部分与“acct”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）导致其他安全漏洞。
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方案允许Unicode指令库[Unicode]中的任何字符编码为UTF-8[RFC3629]，然后百分比编码为有效的ASCII[RFC20]。在应用任何百分比编码之前，应用程序必须确保以下关于用作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]。
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语法在此处以扩充的Backus Naur形式（ABNF）[RFC5234]定义，借用[RFC3986]中的“主机”、“pct编码”、“子delims”和“未保留”规则：
acctURI = "acct" ":" userpart "@" host
userpart = unreserved / sub-delims
0*( unreserved / pct-encoded / sub-delims )
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@andyet.com
Author/Change Controller: This scheme is registered under the IETF tree. As such, the IETF maintains change control.
作者/变更控制者：该方案在IETF树下注册。因此，IETF保持变更控制。
References: None.
参考文献：无。
[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，“统一资源标识符（URI）：通用语法”，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.，“应用程序的国际化域名（IDNA）：定义和文档框架”，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.，Ed.“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框架：应用协议中国际化字符串的准备、实施和比较”，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联盟，“Unicode标准”<http://www.unicode.org/versions/latest/>.
[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.，“网络链接”，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，“mailto”URI方案”，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]Jones，P.，Salgueiro，G.，Jones，M.，和J.Smarr，“网络手指”，RFC 7033，DOI 10.17487/RFC70332013年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.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<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关于可扩展资源标识符的工作）。该方案首次在[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艺术评论。Dave Cridland完成了AppsDir审查，感谢他提供了纳入第3节和第5节的建议文本。来自Richard Barnes、Adrian Farrell、Stephen Farrell、Barry Leiba、Pete Resnick和Sean Turner的IESG评论也导致了规范的改进。
Author's Address
作者地址
Peter Saint-Andre
彼得·圣安德烈
EMail: peter@andyet.com
URI: https://andyet.com/
EMail: peter@andyet.com
URI: https://andyet.com/