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