idnits 2.17.1 draft-saintandre-acct-uri-01.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 (July 2, 2012) is 4316 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 July 2, 2012 5 Expires: January 3, 2013 7 The 'acct' URI Scheme 8 draft-saintandre-acct-uri-01 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 January 3, 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 present, only the WebFinger protocol makes use of the 'acct' URI 173 scheme. However, use is not restricted to the WebFinger protocol. 175 4.7. Interoperability Considerations 177 There are no known interoperability concerns related to use of the 178 'acct' URI scheme. 180 4.8. Security Considerations 182 See Section 5 of RFCXXXX. 184 [Note to RFC Editor: please replace XXXX with the number issued to 185 this document.] 187 4.9. Contact 189 Peter Saint-Andre, psaintan@cisco.com 191 4.10. Author/Change Controller 193 This scheme is registered under the IETF tree. As such, the IETF 194 maintains change control. 196 4.11. References 198 For use of the 'acct' URI scheme with the WebFinger protocol, see 199 [I-D.jones-appsawg-webfinger]. 201 5. Security Considerations 203 Because the 'acct' URI scheme does not directly enable interaction 204 with a user's account at a service provider, possible security 205 concerns are minimized. 207 Protocols that make use of 'acct' URIs are responsible for defining 208 security considerations related to such usage, e.g., the risks 209 involved in dereferencing an 'acct' URI and the authentication and 210 authorization methods that could be used to control access to 211 personally identifying information. 213 6. Acknowledgements 215 Some text was borrowed from [I-D.jones-appsawg-webfinger]. 217 Thanks to Graham Klyne and Barry Leiba for their substantive 218 feedback. 220 7. References 222 7.1. Normative References 224 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 225 October 1969. 227 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 228 10646", STD 63, RFC 3629, November 2003. 230 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 231 Resource Identifier (URI): Generic Syntax", STD 66, 232 RFC 3986, January 2005. 234 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 235 Specifications: ABNF", STD 68, RFC 5234, January 2008. 237 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 238 6.1", 2012, 239 . 241 7.2. Informative References 243 [I-D.jones-appsawg-webfinger] 244 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", 245 draft-jones-appsawg-webfinger-06 (work in progress), 246 June 2012. 248 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 249 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 250 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 252 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 253 Registration Procedures for New URI Schemes", BCP 35, 254 RFC 4395, February 2006. 256 [RFC5890] Klensin, J., "Internationalized Domain Names for 257 Applications (IDNA): Definitions and Document Framework", 258 RFC 5890, August 2010. 260 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 262 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 263 URI Scheme", RFC 6068, October 2010. 265 Author's Address 267 Peter Saint-Andre 268 Cisco Systems, Inc. 269 1899 Wynkoop Street, Suite 600 270 Denver, CO 80202 271 USA 273 Email: psaintan@cisco.com