One document matched: draft-ietf-appsawg-acct-uri-06.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-ietf-appsawg-acct-uri-06" 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>psaintan@cisco.com</email>
</address>
</author>
<date/>
<area>APPS</area>
<keyword>Internet-Draft</keyword>
<keyword>Uniform Resource Identifier</keyword>
<keyword>URI</keyword>
<abstract>
<t>This document defines the 'acct' Uniform Resource Identifier (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 Uniform Resource Identifier (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 without specifying a particular protocol to use when interacting with the account. This specification fills that gap.</t>
</section>
<section title="Terminology" anchor="terms">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target='RFC2119'/>.</t>
</section>
<section title="Rationale" anchor="rationale">
<t>During formalization of the WebFinger protocol <xref target='I-D.ietf-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' <xref target='RFC6068'/> and 'http' <xref target='RFC2616'/> schemes were proposed, not all service providers offer email services or web interfaces on behalf of user accounts (e.g., a microblogging or instant messaging provider might not offer email services, or an enterprise might not offer HTTP interfaces to information about its employees). Therefore, the participants in the discussion 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 application protocols used to interact with the account. The result was the 'acct' URI scheme defined in this document.</t>
<t>(Note that a user is not necessarily a human; it could be an automated application such as a bot, a role-based alias, etc. However, an 'acct' URI is always used to identify something that has an account at a service, not the service itself.)</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 "user@host", 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 typically associated with a DNS domain name. Thus a particular 'acct' URI is formed by setting the "user" portion to the user's account name at the service provider and by setting the "host" portion to the DNS domain name of the service provider.</t>
<t>Consider the case of a user with 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".</t>
<t>A common scenario is for a user to register with a service provider using an identifier (such as an email address) that is associated with some other service provider. For example, a user with the email address "juliet@capulet.example" might register with a commerce website whose domain name is "shoppingsite.example". In order to use her email address as the localpart of the 'acct' URI, the at-sign character (U+0040) needs to be percent-encoded as described in <xref target='RFC3986'/>. Thus the resulting 'acct' URI would be "juliet%40capulet.example@shoppingsite.example.com".</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 abstract identification only and not interaction, this specification provides no method for dereferencing an 'acct' URI on its own, e.g., as the value of the 'href' attribute of an HTML anchor element. For example, there is no behavior specified in this document for an 'acct' URI used as follows:</t>
<figure>
<artwork><![CDATA[
<a href='acct:bob@example.com'>find out more</a>
]]></artwork>
</figure>
<t>Any protocol that uses 'acct' URIs is responsible for specifying how an 'acct' URI is employed in the context of that protocol (in particular, how it is dereferenced or resolved; see <xref target='RFC3986'/>). As a concrete example, an "Account Information" application of the WebFinger protocol <xref target='I-D.ietf-appsawg-webfinger'/> might take an 'acct' URI, resolve the host portion to find a WebFinger server, and then pass the 'acct' URI as a parameter in a WebFinger HTTP request for metadata (i.e., web links <xref target='RFC5988'/>) about the resource. For example:</t>
<figure>
<artwork><![CDATA[
GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1
]]></artwork>
</figure>
<t>The service retrieves the metadata associated with the account identified by that URI and then provides that metadata to the requesting entity in an HTTP response.</t>
<t>If an application needs to compare two 'acct' URIs (e.g., for purposes of authentication and authorization), it MUST do so using case normalization and percent-encoding normalization as specified in Sections 6.2.2.1 and 6.2.2.2 of <xref target='RFC3986'/>.</t>
</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, direct security concerns are minimized.</t>
<t>However, an 'acct' URI does provide proof of existence of the account; this implies that harvesting published 'acct' URIs could prove useful to spammers and similar attackers, for example if they can use an 'acct' URI to leverage more information about the account (e.g., via WebFinger) or if they can interact with protocol-specific URIs (such as 'mailto' URIs) whose user@host portion is the same as that of the 'acct' URI.</t>
<t>In addition, 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, the authentication and authorization methods that could be used to control access to personal data associated with a user’s account at a service, and methods for ensuring the confidentiality of such information.</t>
<t>The use of percent-encoding allows a wider range of characters in account names, but introduces some additional risks. Implementers are advised to disallow percent-encoded characters or sequences that would (1) result in space, null, control, or other characters that are otherwise forbidden, (2) allow unauthorized access to private data, or (3) lead to other security vulnerabilities.</t>
</section>
<section title="Internationalization Considerations" anchor="i18n">
<t>As specified in <xref target='RFC3986'/>, the 'acct' URI scheme allows any character from the Unicode repertoire <xref target='UNICODE'/> encoded as UTF-8 <xref target='RFC3629'/> and then percent-encoded into valid ASCII <xref target='RFC20'/>. Before applying any percent-encoding, an application MUST ensure the following about the string that is used as input to the URI-construction process:</t>
<t>
<list style='symbols'>
<t>The userpart consists only of Unicode code points that conform to the PRECIS IdentifierClass specified in <xref target='I-D.ietf-precis-framework'/>.</t>
<t>The host consists only of Unicode code points that conform to the rules specified in <xref target='RFC5892'/>.</t>
<t>Internationalized domain name (IDN) labels are encoded as A-labels <xref target='RFC5890'/>.</t>
</list>
</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 the 'host', 'pct-encoded', 'sub-delims', 'unreserved' rules from <xref target='RFC3986'/>:</t>
<figure>
<artwork><![CDATA[
acctURI = "acct" ":" userpart "@" host
userpart = unreserved / sub-delims
0*( unreserved / pct-encoded / sub-delims )
]]></artwork>
</figure>
<t>Note that additional rules regarding the strings that are used as input to construction of 'acct' URIs further limit the characters that can be percent-encoded; see the Encoding Considerations as well as Section 6 of RFC XXXX. [Note to RFC Editor: please replace XXXX with the number issued to this document.]</t>
</section>
<section title='URI Scheme Semantics' anchor="iana-semantics">
<t>The 'acct' URI scheme identifies accounts hosted at service providers. It is used only for identification, not interaction. A protocol that employs the 'acct' URI scheme is responsible for specifying how an 'acct' URI is 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>See Section 6 of RFC XXXX. [Note to RFC Editor: please replace XXXX with the number issued to this document.]</t>
</section>
<section title='Applications/Protocols That Use This URI Scheme Name' anchor="iana-apps">
<t>At the time of this writing, only the WebFinger protocol uses the 'acct' URI scheme. However, use is not restricted to the WebFinger protocol, and the scheme might be considered for use in other protocols.</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 XXXX. [Note to RFC Editor: please replace XXXX 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>None.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='I-D.ietf-precis-framework'>
<front>
<title>Precis Framework: Handling Internationalized Strings in Protocols</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization>Cisco</organization>
</author>
<author initials='M' surname='Blanchet' fullname='Marc Blanchet'>
<organization>Viagenie</organization>
</author>
<date month='March' day='26' year='2013' />
<abstract><t>Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to handle various classes of strings in a way that depends on the properties of Unicode code points and that is agile with respect to versions of Unicode; as a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). A specification that reuses this framework can either directly use the base string classes or subclass the base string classes as needed. This framework takes an approach similar to the revised internationalized domain names in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in RFC 4690, albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-precis-framework-08' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-08.txt' />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date month='March' year='1997' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</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='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='RFC5892'>
<front>
<title>The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).</t><t> It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5892' />
<format type='TXT' octets='187370' target='http://www.rfc-editor.org/rfc/rfc5892.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.ietf-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='May' day='26' year='2013' />
<abstract><t>This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-appsawg-webfinger-14' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-14.txt' />
</reference>
<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='RFC2616'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
</t>
<t>
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='http://www.rfc-editor.org/rfc/rfc2616.txt' />
<format type='PS' octets='5529857' target='http://www.rfc-editor.org/rfc/rfc2616.ps' />
<format type='PDF' octets='550558' target='http://www.rfc-editor.org/rfc/rfc2616.pdf' />
<format type='HTML' octets='636125' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</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='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>
<reference anchor='RFC6068'>
<front>
<title>The 'mailto' URI Scheme</title>
<author initials='M.' surname='Duerst' fullname='M. Duerst'>
<organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'>
<organization /></author>
<author initials='J.' surname='Zawinski' fullname='J. Zawinski'>
<organization /></author>
<date year='2010' month='October' />
<abstract>
<t>This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6068' />
<format type='TXT' octets='36683' target='http://www.rfc-editor.org/rfc/rfc6068.txt' />
</reference>
</references>
<section title="Acknowledgements" anchor="ack">
<t>The 'acct' URI scheme was originally proposed during work on the WebFinger protocol; special thanks are due to Blaine Cook, Brad Fitzpatrick, and Eran Hammer-Lahav for their early work on the concept (which in turn was partially inspired by work on Extensible Resource Indentifiers at OASIS). The scheme was first formally specified in <xref target='I-D.ietf-appsawg-webfinger'/>; the authors of that specification (Paul Jones, Gonzalo Salgueiro, and Joseph Smarr) are gratefully acknowledged. Thanks are also due to Melvin Carvalho, Martin Duerst, Graham Klyne, Barry Leiba, Subramanian Moonesamy, Evan Prodromou, James Snell, and other participants in the IETF APPSAWG for their feedback. Meral Shirazipour completed a Gen-ART review. Dave Cridland completed an AppsDir review, and is gratefully acknowledged for providing proposed text that was incorporated into Section 3 and Section 5. IESG comments from Richard Barnes, Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Sean Turner also led to improvements in the specification.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:25:39 |