--- 1/draft-saintandre-acct-uri-00.txt 2012-07-05 17:14:15.613675726 +0200 +++ 2/draft-saintandre-acct-uri-01.txt 2012-07-05 17:14:15.629675602 +0200 @@ -1,18 +1,18 @@ Network Working Group P. Saint-Andre Internet-Draft Cisco Systems, Inc. -Intended status: Standards Track June 30, 2012 -Expires: January 1, 2013 +Intended status: Standards Track July 2, 2012 +Expires: January 3, 2013 The 'acct' URI Scheme - draft-saintandre-acct-uri-00 + draft-saintandre-acct-uri-01 Abstract This document defines the 'acct' 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 Internet-Draft is submitted in full conformance with the @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 1, 2013. + This Internet-Draft will expire on January 3, 2013. Copyright Notice Copyright (c) 2012 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 @@ -69,53 +69,52 @@ information about a user). However, there exists no URI scheme that generically identifies a user's account at a service provider, in the absence of interaction with the account using a particular application protocol. This specification fills that gap. 2. Rationale During formalization of the WebFinger protocol [I-D.jones-appsawg-webfinger], 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' and 'http' schemes - were proposed, not all service providers support email services or - web interfaces on behalf of user accounts (e.g., a microblogging or - instant messaging provider might not provide email services, or an - enterprise might not provide HTTP interfaces to information about its - employees). Therefore, the discussants recognized that it would be - helpful to define a URI scheme that could be used to generically - identify a user's account at a service provider, irrespective of the - particular services or application protocols that could be used to - interact with the account. The result was the 'acct' URI scheme - defined in this document. + a web link [RFC5988]. Although both the 'mailto' [RFC6068] and + 'http' [RFC2616] schemes were proposed, not all service providers + support email services or web interfaces on behalf of user accounts + (e.g., a microblogging or instant messaging provider might not + provide email services, or an enterprise might not provide HTTP + interfaces to information about its employees). Therefore, the + discussants recognized that it would be helpful to define a URI + scheme that could be used to generically identify a user's account at + a service provider, irrespective of the particular services or + application protocols that could be used to interact with the + account. The result was the 'acct' URI scheme defined in this + document. 3. Definition The syntax of the 'acct' URI scheme is defined under Section 4 of this document. Although 'acct' URIs take the form userpart@domainpart, 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 associated with a DNS domain name. Thus a particular 'acct' URI is formed by setting the userpart portion of the URI to the user's account name at the service provider and by setting the domainpart portion of the URI to the DNS domain name of the service provider. - An 'acct' URI need not be explicitly assigned by the service - provider, and can be inferred if the account name and provider domain - name are known. For example, if a user has an account name of - "foobar" on a microblogging service "status.example.net", it can be - inferred that the user's 'acct' URI at that provider is - acct:foobar@status.example.net even if the provider has not - explicitly assigned such a URI. + For example, if a user has 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". 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. @@ -137,49 +136,48 @@ acct 4.2. Status permanent 4.3. URI Scheme Syntax The 'acct' URI syntax is defined here in Augmented Backus-Naur Form - (ABNF) [RFC5234], borrowing syntax elements from [RFC3986]: + (ABNF) [RFC5234], borrowing the 'pct-encoded', 'sub-delims', and + 'unreserved' rules from that specification and the 'host' rule from + [RFC3986]: - acctURI = "acct:" userpart "@" domainpart - userpart = 1*( unreserved / pct-encoded ) - domainpart = domainlabel 1*( "." domainlabel) - domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum - alphanum = ALPHA / DIGIT + acctURI = "acct:" userpart "@" host + userpart = 1*( unreserved / pct-encoded / sub-delims ) 4.4. URI Scheme Semantics The 'acct' URI scheme is used to identify user accounts hosted at service providers. It is used only for identification, not interaction. A protocol that uses the 'acct' URI scheme is responsible for specifying how an 'acct' URI is to be dereferenced in the context of that protocol. There is no media type associated with the 'acct' URI scheme. 4.5. Encoding Considerations The 'acct' URI scheme allows any character from the Unicode repertoire [UNICODE] encoded as a UTF-8 [RFC3629] string that is then percent-encoded as necessary into valid ASCII [RFC20]. Note that domain labels need to be encoded as A-labels as defined by [RFC5890] in order to support internationalized domain names (IDNs). 4.6. Applications/Protocols That Use This URI Scheme Name - At present, only the WebFinger protocol uses the 'acct' URI scheme. - However, use is not restricted to the WebFinger protocol. + At present, only the WebFinger protocol makes use of the 'acct' URI + scheme. However, use is not restricted to the WebFinger protocol. 4.7. Interoperability Considerations There are no known interoperability concerns related to use of the 'acct' URI scheme. 4.8. Security Considerations See Section 5 of RFCXXXX. @@ -197,29 +195,34 @@ 4.11. References For use of the 'acct' URI scheme with the WebFinger protocol, see [I-D.jones-appsawg-webfinger]. 5. Security Considerations Because the 'acct' URI scheme does not directly enable interaction with a user's account at a service provider, possible security - concerns are minimized (aside from the fact that an 'acct' URI - naturally exposes that a particular account name might exist at the - provider). Protocols that make use of 'acct' URIs are responsible - for defining security considerations related to such usage. + concerns are minimized. + + 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 and the authentication and + authorization methods that could be used to control access to + personally identifying information. 6. Acknowledgements - Some text in this document was borrowed from - [I-D.jones-appsawg-webfinger]. + Some text was borrowed from [I-D.jones-appsawg-webfinger]. + + Thanks to Graham Klyne and Barry Leiba for their substantive + feedback. 7. References 7.1. Normative References [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. @@ -235,29 +238,36 @@ 6.1", 2012, . 7.2. Informative References [I-D.jones-appsawg-webfinger] Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", draft-jones-appsawg-webfinger-06 (work in progress), June 2012. + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. + [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' + URI Scheme", RFC 6068, October 2010. + Author's Address Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA - Email: stpeter@jabber.org + Email: psaintan@cisco.com