One document matched: draft-saintandre-acct-uri-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="1"?>
<rfc category="std" docName="draft-saintandre-acct-uri-00" ipr="trust200902">
<front>
<title abbrev="The 'acct' URI Scheme">The 'acct' URI Scheme</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>stpeter@jabber.org</email>
</address>
</author>
<date month="June" day="30" year="2012"/>
<area>APPS</area>
<keyword>Internet-Draft</keyword>
<keyword>URI</keyword>
<keyword>WebFinger</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>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.</t>
</section>
<section title="Rationale" anchor="rationale">
<t>During formalization of the WebFinger protocol <xref target='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 <xref target='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.</t>
</section>
<section title="Definition" anchor="definition">
<t>The syntax of the 'acct' URI scheme is defined under <xref target='iana'/> 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 <xref target="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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>In accordance with the guidelines and registration procedures for new URI schemes <xref target='RFC4395'/>, this section provides the information needed to register the 'acct' URI scheme.</t>
<section title='URI Scheme Name' anchor="iana-name">
<t>acct</t>
</section>
<section title='Status' anchor="iana-status">
<t>permanent</t>
</section>
<section title='URI Scheme Syntax' anchor="iana-syntax">
<t>The 'acct' URI syntax is defined here in Augmented Backus-Naur Form (ABNF) <xref target='RFC5234'/>, borrowing syntax elements from <xref target='RFC3986'/>:</t>
<figure>
<artwork><![CDATA[
acctURI = "acct:" userpart "@" domainpart
userpart = 1*( unreserved / pct-encoded )
domainpart = domainlabel 1*( "." domainlabel)
domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
alphanum = ALPHA / DIGIT
]]></artwork>
</figure>
</section>
<section title='URI Scheme Semantics' anchor="iana-semantics">
<t>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.</t>
</section>
<section title='Encoding Considerations' anchor="iana-encoding">
<t>The 'acct' URI scheme allows any character from the Unicode repertoire <xref target='UNICODE'/> encoded as a UTF-8 <xref target='RFC3629'/> string that is then percent-encoded as necessary into valid ASCII <xref target='RFC20'/>. Note that domain labels need to be encoded as A-labels as defined by <xref target='RFC5890'/> in order to support internationalized domain names (IDNs).</t>
</section>
<section title='Applications/Protocols That Use This URI Scheme Name' anchor="iana-apps">
<t>At present, only the WebFinger protocol uses the 'acct' URI scheme. However, use is not restricted to the WebFinger protocol.</t>
</section>
<section title='Interoperability Considerations' anchor="iana-interop">
<t>There are no known interoperability concerns related to use of the 'acct' URI scheme.</t>
</section>
<section title='Security Considerations' anchor="iana-sec">
<t>See Section 5 of RFC&rfc.number;.</t>
<t>[Note to RFC Editor: please replace &rfc.number; with the number issued to this document.]</t>
</section>
<section title='Contact' anchor="iana-contact">
<t>Peter Saint-Andre, psaintan@cisco.com</t>
</section>
<section title='Author/Change Controller' anchor="iana-control">
<t>This scheme is registered under the IETF tree. As such, the IETF maintains change control.</t>
</section>
<section title='References' anchor="iana-refs">
<t>For use of the 'acct' URI scheme with the WebFinger protocol, see <xref target='I-D.jones-appsawg-webfinger'/>.</t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>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.</t>
</section>
<section title="Acknowledgements" anchor="ack">
<t>Some text in this document was borrowed from <xref target='I-D.jones-appsawg-webfinger'/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC20'>
<front>
<title>ASCII format for network interchange</title>
<author initials='V.' surname='Cerf' fullname='Vint Cerf'>
<organization>University California Los Angeles (UCLA)</organization></author>
<date year='1969' day='16' month='October' />
<abstract>
<t>For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0.</t></abstract></front>
<seriesInfo name='RFC' value='20' />
<format type='TXT' octets='18504' target='http://www.rfc-editor.org/rfc/rfc20.txt' />
</reference>
<reference anchor='RFC3629'>
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'>
<organization /></author>
<date year='2003' month='November' />
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract></front>
<seriesInfo name='STD' value='63' />
<seriesInfo name='RFC' value='3629' />
<format type='TXT' octets='33856' target='http://www.rfc-editor.org/rfc/rfc3629.txt' />
</reference>
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='213584' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
<format type='TXT' octets='26359' target='http://www.rfc-editor.org/rfc/rfc5234.txt' />
</reference>
<reference anchor="UNICODE" target="http://www.unicode.org/versions/Unicode6.1.0/">
<front>
<title>The Unicode Standard, Version 6.1</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="2012" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor='I-D.jones-appsawg-webfinger'>
<front>
<title>WebFinger</title>
<author initials='P' surname='Jones' fullname='Paul Jones'>
<organization />
</author>
<author initials='G' surname='Salgueiro' fullname='Gonzalo Salgueiro'>
<organization />
</author>
<author initials='J' surname='Smarr' fullname='Joseph Smarr'>
<organization />
</author>
<date month='June' day='17' year='2012' />
<abstract><t>This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-jones-appsawg-webfinger-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-06.txt' />
</reference>
<reference anchor='RFC4395'>
<front>
<title>Guidelines and Registration Procedures for New URI Schemes</title>
<author initials='T.' surname='Hansen' fullname='T. Hansen'>
<organization /></author>
<author initials='T.' surname='Hardie' fullname='T. Hardie'>
<organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'>
<organization /></author>
<date year='2006' month='February' />
<abstract>
<t>This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='35' />
<seriesInfo name='RFC' value='4395' />
<format type='TXT' octets='31933' target='http://www.rfc-editor.org/rfc/rfc4395.txt' />
</reference>
<reference anchor='RFC5890'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5890' />
<format type='TXT' octets='54245' target='http://www.rfc-editor.org/rfc/rfc5890.txt' />
</reference>
<reference anchor='RFC5988'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
<organization /></author>
<date year='2010' month='October' />
<abstract>
<t>This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5988' />
<format type='TXT' octets='46834' target='http://www.rfc-editor.org/rfc/rfc5988.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:18 |