idnits 2.17.1 draft-ietf-appsawg-acct-uri-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 3, 2012) is 4155 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' == Outdated reference: A later version (-18) exists of draft-ietf-appsawg-webfinger-07 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track December 3, 2012 5 Expires: June 6, 2013 7 The 'acct' URI Scheme 8 draft-ietf-appsawg-acct-uri-02 10 Abstract 12 This document defines the 'acct' URI scheme as a way to identify a 13 user's account at a service provider, irrespective of the particular 14 protocols that can be used to interact with the account. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 6, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 57 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 58 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 Existing URI schemes that enable interaction with, or that identify 64 resources associated with, a user's account at a service provider are 65 tied to particular services or application protocols. Two examples 66 are the 'mailto' scheme (which enables interaction with a user's 67 email account) and the 'http' scheme (which enables retrieval of web 68 files controlled by a user or interaction with interfaces providing 69 information about a user). However, there exists no URI scheme that 70 generically identifies a user's account at a service provider without 71 specifying a particular protocol to use when interacting with the 72 account. This specification fills that gap. 74 2. Rationale 76 During formalization of the WebFinger protocol 77 [I-D.ietf-appsawg-webfinger], much discussion occurred regarding the 78 appropriate URI scheme to include when specifying a user's account as 79 a web link [RFC5988]. Although both the 'mailto' [RFC6068] and 80 'http' [RFC2616] schemes were proposed, not all service providers 81 offer email services or web interfaces on behalf of user accounts 82 (e.g., a microblogging or instant messaging provider might not offer 83 email services, or an enterprise might not offer HTTP interfaces to 84 information about its employees). Therefore, the discussants 85 recognized that it would be helpful to define a URI scheme that could 86 be used to generically identify a user's account at a service 87 provider, irrespective of the particular application protocols used 88 to interact with the account. The result was the 'acct' URI scheme 89 defined in this document. 91 3. Definition 93 The syntax of the 'acct' URI scheme is defined under Section 4 of 94 this document. Although 'acct' URIs take the form "user@host", the 95 scheme is designed for the purpose of identification instead of 96 interaction (regarding this distinction, see Section 1.2.2 of 97 [RFC3986]). The "Internet resource" identified by an 'acct' URI is a 98 user's account hosted at a service provider, where the service 99 provider is typically associated with a DNS domain name. Thus a 100 particular 'acct' URI is formed by setting the "user" portion to the 101 user's account name at the service provider and by setting the "host" 102 portion to the DNS domain name of the service provider. 104 Consider the case of a user with an account name of "foobar" on a 105 microblogging service "status.example.net". It is taken as 106 convention that the string "foobar@status.example.net" designates 107 that account. This is expressed as a URI using the 'acct' scheme as 108 "acct:foobar@status.example.net". 110 It is not assumed that an entity will necessarily be able to interact 111 with a user's account using any particular application protocol, such 112 as email; to enable such interaction, an entity would need to use the 113 appropriate URI scheme for such a protocol, such as the 'mailto' 114 scheme. While it might be true that the 'acct' URI minus the scheme 115 name (e.g., "user@example.com" derived from "acct:user@example.com") 116 can be reached via email or some other application protocol, that 117 fact would be purely contingent and dependent upon the deployment 118 practices of the provider. 120 Because an 'acct' URI enables identification only and not 121 interaction, it cannot be deferenced on its own and is not employed 122 directly in a protocol, e.g., as the value of the 'href' attribute of 123 an HTML anchor element. For example, an 'acct' URI would not be used 124 as follows: 126 find out more 128 Instead, an 'acct' URI is employed indirectly and typically is passed 129 around as a parameter in the background within a protocol flow so 130 that an entity can interact with the resource identified by the 131 'acct' URI in a particular way or for a particular purpose. For 132 example, in the WebFinger protocol [I-D.ietf-appsawg-webfinger] an 133 'acct' URI is used to identify the resource about which an entity 134 would like to discover metadata expressed as "web links" [RFC5988]; 135 the relevant HTTP request passes an 'acct' URI (or some other URI) as 136 the value of a "resource" parameter, as shown in the following 137 example: 139 GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1 141 Therefore, any protocol that uses 'acct' URIs, such as the WebFinger 142 protocol [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery 143 protocol [I-D.jones-simple-web-discovery], is responsible for 144 specifying how an 'acct' URI is employed in the context of that 145 protocol (in particular, how it is dereferenced or resolved; see 146 [RFC3986]). As a concrete example, in the WebFinger protocol an 147 'acct' URI is passed as a parameter in an HTTP request for metadata 148 (i.e., web links) about the resource; the service retrieves the 149 metadata associated with the account identified by that URI and then 150 provides that metadata to the requesting entity in an HTTP response 151 (see [I-D.ietf-appsawg-webfinger] for details). Similar 152 functionality is envisioned for other uses of 'acct' URIs. 154 4. IANA Considerations 156 In accordance with the guidelines and registration procedures for new 157 URI schemes [RFC4395], this section provides the information needed 158 to register the 'acct' URI scheme. 160 4.1. URI Scheme Name 162 acct 164 4.2. Status 166 permanent 168 4.3. URI Scheme Syntax 170 The 'acct' URI syntax is defined here in Augmented Backus-Naur Form 171 (ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims', 172 'unreserved' rules from [RFC3986]: 174 acctURI = "acct" ":" userpart "@" host 175 userpart = 1*( unreserved / pct-encoded / sub-delims ) 177 4.4. URI Scheme Semantics 179 The 'acct' URI scheme identifies accounts hosted at service 180 providers. It is used only for identification, not interaction. A 181 protocol that employs the 'acct' URI scheme is responsible for 182 specifying how an 'acct' URI is dereferenced in the context of that 183 protocol. There is no media type associated with the 'acct' URI 184 scheme. 186 4.5. Encoding Considerations 188 The 'acct' URI scheme allows any character from the Unicode 189 repertoire [UNICODE] encoded as UTF-8 [RFC3629] and then percent- 190 encoded into valid ASCII [RFC20] as specified in [RFC3986]. Note 191 that domain labels need to be encoded as A-labels (see [RFC5890]) in 192 order to support internationalized domain names (IDNs). 194 4.6. Applications/Protocols That Use This URI Scheme Name 196 At the time of this writing, only the WebFinger protocol uses the 197 'acct' URI scheme. However, use is not restricted to the WebFinger 198 protocol, and the scheme might be considered for use in other 199 protocols, such as Simple Web Discovery. 201 4.7. Interoperability Considerations 203 There are no known interoperability concerns related to use of the 204 'acct' URI scheme. 206 4.8. Security Considerations 208 See Section 5 of RFCXXXX. [Note to RFC Editor: please replace XXXX 209 with the number issued to this document.] 211 4.9. Contact 213 Peter Saint-Andre, psaintan@cisco.com 215 4.10. Author/Change Controller 217 This scheme is registered under the IETF tree. As such, the IETF 218 maintains change control. 220 4.11. References 222 None. 224 5. Security Considerations 226 Because the 'acct' URI scheme does not directly enable interaction 227 with a user's account at a service provider, possible security 228 concerns are minimized. 230 Protocols that make use of 'acct' URIs are responsible for defining 231 security considerations related to such usage, e.g., the risks 232 involved in dereferencing an 'acct' URI and the authentication and 233 authorization methods that could be used to control access to 234 personally identifying information associated with a user's account 235 at a service. 237 6. References 239 6.1. Normative References 241 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 242 October 1969. 244 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 245 10646", STD 63, RFC 3629, November 2003. 247 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 248 Resource Identifier (URI): Generic Syntax", STD 66, 249 RFC 3986, January 2005. 251 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 252 Specifications: ABNF", STD 68, RFC 5234, January 2008. 254 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 255 6.1", 2012, 256 . 258 6.2. Informative References 260 [I-D.ietf-appsawg-webfinger] 261 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", 262 draft-ietf-appsawg-webfinger-07 (work in progress), 263 December 2012. 265 [I-D.jones-simple-web-discovery] 266 Jones, M. and Y. Goland, "Simple Web Discovery (SWD)", 267 draft-jones-simple-web-discovery-04 (work in progress), 268 November 2012. 270 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 271 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 272 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 274 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 275 Registration Procedures for New URI Schemes", BCP 35, 276 RFC 4395, February 2006. 278 [RFC5890] Klensin, J., "Internationalized Domain Names for 279 Applications (IDNA): Definitions and Document Framework", 280 RFC 5890, August 2010. 282 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 284 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 285 URI Scheme", RFC 6068, October 2010. 287 Appendix A. Acknowledgements 289 The 'acct' URI scheme was originally proposed during work on the 290 WebFinger protocol; special thanks are due to Blaine Cook, Brad 291 Fitzpatrick, and Eran Hammer-Lahav for their early work on the 292 concept (which in turn was partially inspired by work on Extensible 293 Resource Indentifiers at OASIS). The scheme was first formally 294 specified in [I-D.ietf-appsawg-webfinger]; the authors of that 295 specification (Paul Jones, Gonzalo Salgueiro, and Joseph Smarr) are 296 gratefully acknowledged. Thanks are also due to Martin Duerst, 297 Graham Klyne, Barry Leiba, and many other participants in the IETF 298 APPSAWG for their feedback. 300 Author's Address 302 Peter Saint-Andre 303 Cisco Systems, Inc. 304 1899 Wynkoop Street, Suite 600 305 Denver, CO 80202 306 USA 308 Email: psaintan@cisco.com