draft-saintandre-acct-uri-00.txt   draft-saintandre-acct-uri-01.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track June 30, 2012 Intended status: Standards Track July 2, 2012
Expires: January 1, 2013 Expires: January 3, 2013
The 'acct' URI Scheme The 'acct' URI Scheme
draft-saintandre-acct-uri-00 draft-saintandre-acct-uri-01
Abstract Abstract
This document defines the 'acct' URI scheme as a way to identify a This document defines the 'acct' URI scheme as a way to identify a
user's account at a service provider, irrespective of the particular user's account at a service provider, irrespective of the particular
protocols that can be used to interact with the account. protocols that can be used to interact with the account.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 23 skipping to change at page 3, line 23
information about a user). However, there exists no URI scheme that information about a user). However, there exists no URI scheme that
generically identifies a user's account at a service provider, in the generically identifies a user's account at a service provider, in the
absence of interaction with the account using a particular absence of interaction with the account using a particular
application protocol. This specification fills that gap. application protocol. This specification fills that gap.
2. Rationale 2. Rationale
During formalization of the WebFinger protocol During formalization of the WebFinger protocol
[I-D.jones-appsawg-webfinger], much discussion occurred regarding the [I-D.jones-appsawg-webfinger], much discussion occurred regarding the
appropriate URI scheme to include when specifying a user's account as appropriate URI scheme to include when specifying a user's account as
a web link [RFC5988]. Although both the 'mailto' and 'http' schemes a web link [RFC5988]. Although both the 'mailto' [RFC6068] and
were proposed, not all service providers support email services or 'http' [RFC2616] schemes were proposed, not all service providers
web interfaces on behalf of user accounts (e.g., a microblogging or support email services or web interfaces on behalf of user accounts
instant messaging provider might not provide email services, or an (e.g., a microblogging or instant messaging provider might not
enterprise might not provide HTTP interfaces to information about its provide email services, or an enterprise might not provide HTTP
employees). Therefore, the discussants recognized that it would be interfaces to information about its employees). Therefore, the
helpful to define a URI scheme that could be used to generically discussants recognized that it would be helpful to define a URI
identify a user's account at a service provider, irrespective of the scheme that could be used to generically identify a user's account at
particular services or application protocols that could be used to a service provider, irrespective of the particular services or
interact with the account. The result was the 'acct' URI scheme application protocols that could be used to interact with the
defined in this document. account. The result was the 'acct' URI scheme defined in this
document.
3. Definition 3. Definition
The syntax of the 'acct' URI scheme is defined under Section 4 of The syntax of the 'acct' URI scheme is defined under Section 4 of
this document. Although 'acct' URIs take the form this document. Although 'acct' URIs take the form
userpart@domainpart, the scheme is designed for the purpose of userpart@domainpart, the scheme is designed for the purpose of
identification instead of interaction (regarding this distinction, identification instead of interaction (regarding this distinction,
see Section 1.2.2 of [RFC3986]). The "Internet resource" identified 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, 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. where the service provider is associated with a DNS domain name.
Thus a particular 'acct' URI is formed by setting the userpart 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 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 and by setting the domainpart portion of the URI to the DNS domain
name of the service provider. name of the service provider.
An 'acct' URI need not be explicitly assigned by the service For example, if a user has an account name of "foobar" on a
provider, and can be inferred if the account name and provider domain microblogging service "status.example.net", it is taken as convention
name are known. For example, if a user has an account name of that the string "foobar@status.example.net" designates that account.
"foobar" on a microblogging service "status.example.net", it can be This is expressed as a URI using the 'acct' scheme as
inferred that the user's 'acct' URI at that provider is "acct:foobar@status.example.net".
acct:foobar@status.example.net even if the provider has not
explicitly assigned such a URI.
It is not assumed that an entity will necessarily be able to interact It is not assumed that an entity will necessarily be able to interact
with a user's account using any particular application protocol, such with a user's account using any particular application protocol, such
as email; to enable such interaction, an entity would need to use the as email; to enable such interaction, an entity would need to use the
appropriate URI scheme for such a protocol, such as the 'mailto' appropriate URI scheme for such a protocol, such as the 'mailto'
scheme. While it might be true that the 'acct' URI minus the scheme 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 name (e.g., user@example.com derived from acct:user@example.com) can
be reached via email or some other application protocol, that fact be reached via email or some other application protocol, that fact
would be purely contingent and dependent upon the deployment would be purely contingent and dependent upon the deployment
practices of the provider. practices of the provider.
skipping to change at page 4, line 44 skipping to change at page 4, line 43
acct acct
4.2. Status 4.2. Status
permanent permanent
4.3. URI Scheme Syntax 4.3. URI Scheme Syntax
The 'acct' URI syntax is defined here in Augmented Backus-Naur Form 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 acctURI = "acct:" userpart "@" host
userpart = 1*( unreserved / pct-encoded ) userpart = 1*( unreserved / pct-encoded / sub-delims )
domainpart = domainlabel 1*( "." domainlabel)
domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
alphanum = ALPHA / DIGIT
4.4. URI Scheme Semantics 4.4. URI Scheme Semantics
The 'acct' URI scheme is used to identify user accounts hosted at The 'acct' URI scheme is used to identify user accounts hosted at
service providers. It is used only for identification, not service providers. It is used only for identification, not
interaction. A protocol that uses the 'acct' URI scheme is interaction. A protocol that uses the 'acct' URI scheme is
responsible for specifying how an 'acct' URI is to be dereferenced in 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 context of that protocol. There is no media type associated with
the 'acct' URI scheme. the 'acct' URI scheme.
4.5. Encoding Considerations 4.5. Encoding Considerations
The 'acct' URI scheme allows any character from the Unicode The 'acct' URI scheme allows any character from the Unicode
repertoire [UNICODE] encoded as a UTF-8 [RFC3629] string that is then repertoire [UNICODE] encoded as a UTF-8 [RFC3629] string that is then
percent-encoded as necessary into valid ASCII [RFC20]. Note that percent-encoded as necessary into valid ASCII [RFC20]. Note that
domain labels need to be encoded as A-labels as defined by [RFC5890] domain labels need to be encoded as A-labels as defined by [RFC5890]
in order to support internationalized domain names (IDNs). in order to support internationalized domain names (IDNs).
4.6. Applications/Protocols That Use This URI Scheme Name 4.6. Applications/Protocols That Use This URI Scheme Name
At present, only the WebFinger protocol uses the 'acct' URI scheme. At present, only the WebFinger protocol makes use of the 'acct' URI
However, use is not restricted to the WebFinger protocol. scheme. However, use is not restricted to the WebFinger protocol.
4.7. Interoperability Considerations 4.7. Interoperability Considerations
There are no known interoperability concerns related to use of the There are no known interoperability concerns related to use of the
'acct' URI scheme. 'acct' URI scheme.
4.8. Security Considerations 4.8. Security Considerations
See Section 5 of RFCXXXX. See Section 5 of RFCXXXX.
skipping to change at page 6, line 9 skipping to change at page 6, line 9
4.11. References 4.11. References
For use of the 'acct' URI scheme with the WebFinger protocol, see For use of the 'acct' URI scheme with the WebFinger protocol, see
[I-D.jones-appsawg-webfinger]. [I-D.jones-appsawg-webfinger].
5. Security Considerations 5. Security Considerations
Because the 'acct' URI scheme does not directly enable interaction Because the 'acct' URI scheme does not directly enable interaction
with a user's account at a service provider, possible security with a user's account at a service provider, possible security
concerns are minimized (aside from the fact that an 'acct' URI concerns are minimized.
naturally exposes that a particular account name might exist at the
provider). Protocols that make use of 'acct' URIs are responsible Protocols that make use of 'acct' URIs are responsible for defining
for defining security considerations related to such usage. 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 6. Acknowledgements
Some text in this document was borrowed from Some text was borrowed from [I-D.jones-appsawg-webfinger].
[I-D.jones-appsawg-webfinger].
Thanks to Graham Klyne and Barry Leiba for their substantive
feedback.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
skipping to change at page 6, line 47 skipping to change at page 7, line 5
6.1", 2012, 6.1", 2012,
<http://www.unicode.org/versions/Unicode6.1.0/>. <http://www.unicode.org/versions/Unicode6.1.0/>.
7.2. Informative References 7.2. Informative References
[I-D.jones-appsawg-webfinger] [I-D.jones-appsawg-webfinger]
Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", Jones, P., Salgueiro, G., and J. Smarr, "WebFinger",
draft-jones-appsawg-webfinger-06 (work in progress), draft-jones-appsawg-webfinger-06 (work in progress),
June 2012. 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 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006. RFC 4395, February 2006.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 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 Author's Address
Peter Saint-Andre Peter Saint-Andre
Cisco Systems, Inc. Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600 1899 Wynkoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Email: stpeter@jabber.org Email: psaintan@cisco.com
 End of changes. 13 change blocks. 
36 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/