One document matched: draft-saintandre-acct-uri-00.txt
Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track June 30, 2012
Expires: January 1, 2013
The 'acct' URI Scheme
draft-saintandre-acct-uri-00
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
provisions of BCP 78 and BCP 79.
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.
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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Saint-Andre Expires January 1, 2013 [Page 1]
Internet-Draft The 'acct' URI Scheme June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Saint-Andre Expires January 1, 2013 [Page 2]
Internet-Draft The 'acct' URI Scheme June 2012
1. Introduction
Existing URI schemes that enable interaction with, or that identify
resources associated with, a user's account at a service provider are
tied to particular services or application protocols. Two examples
are the 'mailto' scheme (which enables interaction with a user's
email account) and the 'http' scheme (which enables retrieval of web
files controlled by a user or interaction with interfaces providing
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.
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
Saint-Andre Expires January 1, 2013 [Page 3]
Internet-Draft The 'acct' URI Scheme June 2012
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.
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.
Because an 'acct' URI enables identification only and not
interaction, it cannot be deferenced directly (as can URIs for most
application protocols). Any protocol that uses the 'acct' URI
scheme, such as the WebFinger protocol, is responsible for specifying
how an 'acct' URI is to be dereferenced in the context of that
protocol.
4. IANA Considerations
In accordance with the guidelines and registration procedures for new
URI schemes [RFC4395], this section provides the information needed
to register the 'acct' URI scheme.
4.1. URI Scheme Name
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]:
acctURI = "acct:" userpart "@" domainpart
userpart = 1*( unreserved / pct-encoded )
domainpart = domainlabel 1*( "." domainlabel)
domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
alphanum = ALPHA / DIGIT
Saint-Andre Expires January 1, 2013 [Page 4]
Internet-Draft The 'acct' URI Scheme June 2012
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.
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.
[Note to RFC Editor: please replace XXXX with the number issued to
this document.]
4.9. Contact
Peter Saint-Andre, psaintan@cisco.com
4.10. Author/Change Controller
This scheme is registered under the IETF tree. As such, the IETF
maintains change control.
4.11. References
For use of the 'acct' URI scheme with the WebFinger protocol, see
[I-D.jones-appsawg-webfinger].
Saint-Andre Expires January 1, 2013 [Page 5]
Internet-Draft The 'acct' URI Scheme June 2012
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.
6. Acknowledgements
Some text in this document was borrowed from
[I-D.jones-appsawg-webfinger].
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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6.1", 2012,
<http://www.unicode.org/versions/Unicode6.1.0/>.
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.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
Saint-Andre Expires January 1, 2013 [Page 6]
Internet-Draft The 'acct' URI Scheme June 2012
[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.
Author's Address
Peter Saint-Andre
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
Email: stpeter@jabber.org
Saint-Andre Expires January 1, 2013 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 01:15:03 |