doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc7565.txt b/doc/rfc/rfc7565.txt
new file mode 100644
index 0000000..273c125
--- /dev/null
+++ b/doc/rfc/rfc7565.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    P. Saint-Andre
+Request for Comments: 7565                                      May 2015
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                         The 'acct' URI Scheme
+
+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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+
+
+
+Saint-Andre                  Standards Track                    [Page 1]
+
+RFC 7565                  The 'acct' URI Scheme                 May 2015
+
+
+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
+
+   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.
+
+2.  Terminology
+
+   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].
+
+3.  Rationale
+
+   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
+
+
+
+Saint-Andre                  Standards Track                    [Page 2]
+
+RFC 7565                  The 'acct' URI Scheme                 May 2015
+
+
+   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.
+
+   (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.)
+
+4.  Definition
+
+   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.
+
+   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".
+
+   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".
+
+   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.
+
+
+
+Saint-Andre                  Standards Track                    [Page 3]
+
+RFC 7565                  The 'acct' URI Scheme                 May 2015
+
+
+   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:
+
+   <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:
+
+   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.
+
+   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].
+
+5.  Security Considerations
+
+   Because the 'acct' URI scheme does not directly enable interaction
+   with a user's account at a service provider, direct security concerns
+   are minimized.
+
+   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.
+
+   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.
+
+
+
+Saint-Andre                  Standards Track                    [Page 4]
+
+RFC 7565                  The 'acct' URI Scheme                 May 2015
+
+
+   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.
+
+6.  Internationalization Considerations
+
+   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:
+
+   o  The userpart consists only of Unicode code points that conform to
+      the PRECIS IdentifierClass specified in [RFC7564].
+
+   o  The host consists only of Unicode code points that conform to the
+      rules specified in [RFC5892].
+
+   o  Internationalized domain name (IDN) labels are encoded as A-labels
+      [RFC5890].
+
+7.  IANA Considerations
+
+   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 Scheme Name:  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]:
+
+      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.
+
+
+
+
+Saint-Andre                  Standards Track                    [Page 5]
+
+RFC 7565                  The 'acct' URI Scheme                 May 2015
+
+
+   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.
+
+   Encoding Considerations:  See Section 6 of this document.
+
+   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.
+
+   Interoperability Considerations:  There are no known interoperability
+      concerns related to use of the 'acct' URI scheme.
+
+   Security Considerations:  See Section 5 of this document.
+
+   Contact:  Peter Saint-Andre, peter@andyet.com
+
+   Author/Change Controller:  This scheme is registered under the IETF
+      tree.  As such, the IETF maintains change control.
+
+   References:  None.
+
+8.  References
+
+8.1.  Normative References
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+Saint-Andre                  Standards Track                    [Page 6]
+
+RFC 7565                  The 'acct' URI Scheme                 May 2015
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [Unicode]  The Unicode Consortium, "The Unicode Standard",
+              <http://www.unicode.org/versions/latest/>.
+
+8.2.  Informative References
+
+   [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>.
+
+   [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>.
+
+   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
+              DOI 10.17487/RFC5988, October 2010,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+Saint-Andre                  Standards Track                    [Page 7]
+
+RFC 7565                  The 'acct' URI Scheme                 May 2015
+
+
+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.
+
+Author's Address
+
+   Peter Saint-Andre
+
+   EMail: peter@andyet.com
+   URI:   https://andyet.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre                  Standards Track                    [Page 8]
+