idnits 2.17.1 draft-ietf-appsawg-acct-uri-00.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 (August 14, 2012) is 4271 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' -- 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 (~~), 1 warning (==), 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 August 14, 2012 5 Expires: February 15, 2013 7 The 'acct' URI Scheme 8 draft-ietf-appsawg-acct-uri-00 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 February 15, 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 . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 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, in the 71 absence of interaction with the account using a particular 72 application protocol. This specification fills that gap. 74 2. Rationale 76 During formalization of the WebFinger protocol 77 [I-D.jones-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 support email services or web interfaces on behalf of user accounts 82 (e.g., a microblogging or instant messaging provider might not 83 provide email services, or an enterprise might not provide HTTP 84 interfaces to information about its employees). Therefore, the 85 discussants recognized that it would be helpful to define a URI 86 scheme that could be used to generically identify a user's account at 87 a service provider, irrespective of the particular services or 88 application protocols that could be used to interact with the 89 account. The result was the 'acct' URI scheme defined in this 90 document. 92 3. Definition 94 The syntax of the 'acct' URI scheme is defined under Section 4 of 95 this document. Although 'acct' URIs take the form 96 userpart@domainpart, the scheme is designed for the purpose of 97 identification instead of interaction (regarding this distinction, 98 see Section 1.2.2 of [RFC3986]). The "Internet resource" identified 99 by an 'acct' URI is a user's account hosted at a service provider, 100 where the service provider is associated with a DNS domain name. 101 Thus a particular 'acct' URI is formed by setting the userpart 102 portion of the URI to the user's account name at the service provider 103 and by setting the domainpart portion of the URI to the DNS domain 104 name of the service provider. 106 For example, if a user has an account name of "foobar" on a 107 microblogging service "status.example.net", it is taken as convention 108 that the string "foobar@status.example.net" designates that account. 109 This is expressed as a URI using the 'acct' scheme as 110 "acct:foobar@status.example.net". 112 It is not assumed that an entity will necessarily be able to interact 113 with a user's account using any particular application protocol, such 114 as email; to enable such interaction, an entity would need to use the 115 appropriate URI scheme for such a protocol, such as the 'mailto' 116 scheme. While it might be true that the 'acct' URI minus the scheme 117 name (e.g., user@example.com derived from acct:user@example.com) can 118 be reached via email or some other application protocol, that fact 119 would be purely contingent and dependent upon the deployment 120 practices of the provider. 122 Because an 'acct' URI enables identification only and not 123 interaction, it cannot be deferenced directly (as can URIs for most 124 application protocols). Any protocol that uses the 'acct' URI 125 scheme, such as the WebFinger protocol, is responsible for specifying 126 how an 'acct' URI is to be dereferenced in the context of that 127 protocol. 129 4. IANA Considerations 131 In accordance with the guidelines and registration procedures for new 132 URI schemes [RFC4395], this section provides the information needed 133 to register the 'acct' URI scheme. 135 4.1. URI Scheme Name 137 acct 139 4.2. Status 141 permanent 143 4.3. URI Scheme Syntax 145 The 'acct' URI syntax is defined here in Augmented Backus-Naur Form 146 (ABNF) [RFC5234], borrowing the 'pct-encoded', 'sub-delims', and 147 'unreserved' rules from that specification and the 'host' rule from 148 [RFC3986]: 150 acctURI = "acct:" userpart "@" host 151 userpart = 1*( unreserved / pct-encoded / sub-delims ) 153 4.4. URI Scheme Semantics 155 The 'acct' URI scheme is used to identify user accounts hosted at 156 service providers. It is used only for identification, not 157 interaction. A protocol that uses the 'acct' URI scheme is 158 responsible for specifying how an 'acct' URI is to be dereferenced in 159 the context of that protocol. There is no media type associated with 160 the 'acct' URI scheme. 162 4.5. Encoding Considerations 164 The 'acct' URI scheme allows any character from the Unicode 165 repertoire [UNICODE] encoded as a UTF-8 [RFC3629] string that is then 166 percent-encoded as necessary into valid ASCII [RFC20]. Note that 167 domain labels need to be encoded as A-labels as defined by [RFC5890] 168 in order to support internationalized domain names (IDNs). 170 4.6. Applications/Protocols That Use This URI Scheme Name 172 At the time of this writing, only the WebFinger protocol makes use of 173 the 'acct' URI scheme. However, use is not restricted to the 174 WebFinger protocol. 176 4.7. Interoperability Considerations 178 There are no known interoperability concerns related to use of the 179 'acct' URI scheme. 181 4.8. Security Considerations 183 See Section 5 of RFCXXXX. 185 [Note to RFC Editor: please replace XXXX with the number issued to 186 this document.] 188 4.9. Contact 190 Peter Saint-Andre, psaintan@cisco.com 192 4.10. Author/Change Controller 194 This scheme is registered under the IETF tree. As such, the IETF 195 maintains change control. 197 4.11. References 199 For use of the 'acct' URI scheme with the WebFinger protocol, see 200 [I-D.jones-appsawg-webfinger]. 202 5. Security Considerations 204 Because the 'acct' URI scheme does not directly enable interaction 205 with a user's account at a service provider, possible security 206 concerns are minimized. 208 Protocols that make use of 'acct' URIs are responsible for defining 209 security considerations related to such usage, e.g., the risks 210 involved in dereferencing an 'acct' URI and the authentication and 211 authorization methods that could be used to control access to 212 personally identifying information. 214 6. Acknowledgements 216 Some text was borrowed from [I-D.jones-appsawg-webfinger]. 218 Thanks to Graham Klyne and Barry Leiba for their substantive 219 feedback. 221 7. References 223 7.1. Normative References 225 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 226 October 1969. 228 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 229 10646", STD 63, RFC 3629, November 2003. 231 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 232 Resource Identifier (URI): Generic Syntax", STD 66, 233 RFC 3986, January 2005. 235 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 236 Specifications: ABNF", STD 68, RFC 5234, January 2008. 238 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 239 6.1", 2012, 240 . 242 7.2. Informative References 244 [I-D.jones-appsawg-webfinger] 245 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", 246 draft-jones-appsawg-webfinger-06 (work in progress), 247 June 2012. 249 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 250 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 251 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 253 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 254 Registration Procedures for New URI Schemes", BCP 35, 255 RFC 4395, February 2006. 257 [RFC5890] Klensin, J., "Internationalized Domain Names for 258 Applications (IDNA): Definitions and Document Framework", 259 RFC 5890, August 2010. 261 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 263 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 264 URI Scheme", RFC 6068, October 2010. 266 Author's Address 268 Peter Saint-Andre 269 Cisco Systems, Inc. 270 1899 Wynkoop Street, Suite 600 271 Denver, CO 80202 272 USA 274 Email: psaintan@cisco.com