draft-ietf-appsawg-webfinger-17.txt   draft-ietf-appsawg-webfinger-18.txt 
Network Working Group Paul E. Jones Network Working Group Paul E. Jones
Internet Draft Gonzalo Salgueiro Internet Draft Gonzalo Salgueiro
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: February 9, 2014 Joseph Smarr Expires: February 26, 2014 Michael B. Jones
Microsoft
Joseph Smarr
Google Google
August 9, 2013 August 26, 2013
WebFinger WebFinger
draft-ietf-appsawg-webfinger-17.txt draft-ietf-appsawg-webfinger-18.txt
Abstract Abstract
This specification defines the WebFinger protocol, which can be used This specification defines the WebFinger protocol, which can be used
to discover information about people or other entities on the to discover information about people or other entities on the
Internet using standard HTTP methods. WebFinger discovers Internet using standard HTTP methods. WebFinger discovers
information for a URI that might not be usable as a locator information for a URI that might not be usable as a locator
otherwise, such as account or email URIs. otherwise, such as account or email URIs.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 38
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 February 9, 2014. This Internet-Draft will expire on February 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 31 skipping to change at page 3, line 31
used to return dynamic information like the temperature of a CPU or used to return dynamic information like the temperature of a CPU or
the current toner level in a laser printer. the current toner level in a laser printer.
The WebFinger protocol is designed to be used across many The WebFinger protocol is designed to be used across many
applications. Applications that wish to utilize WebFinger will need applications. Applications that wish to utilize WebFinger will need
to specify properties, titles, and link relation types that are to specify properties, titles, and link relation types that are
appropriate for the application. Further, applications will need to appropriate for the application. Further, applications will need to
define the appropriate URI scheme to utilize for the query target. define the appropriate URI scheme to utilize for the query target.
Use of WebFinger is illustrated in the examples in Section 3 and Use of WebFinger is illustrated in the examples in Section 3 and
described more formally in Section 4. described more formally in Section 4. Section 8 describes how
applications of WebFinger may be defined.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
WebFinger makes heavy use of "Link Relations". A Link Relation is an WebFinger makes heavy use of "Link Relations". A Link Relation is an
attribute-and-value pair in which the attribute identifies the type attribute-and-value pair in which the attribute identifies the type
of relationship between the linked entity or resource and the of relationship between the linked entity or resource and the
skipping to change at page 4, line 12 skipping to change at page 4, line 12
needs to be either a single IANA-registered link relation type [8] or needs to be either a single IANA-registered link relation type [8] or
a URI [6]. a URI [6].
The use of URIs throughout this document refers to URIs following the The use of URIs throughout this document refers to URIs following the
syntax specified in Section 3 of RFC 3986 [6]. Relative URIs, having syntax specified in Section 3 of RFC 3986 [6]. Relative URIs, having
syntax following that of Section 4.2 or RFC 3986, are not used with syntax following that of Section 4.2 or RFC 3986, are not used with
WebFinger. WebFinger.
3. Example Uses of WebFinger 3. Example Uses of WebFinger
This non-normative section shows a few sample uses of WebFinger. This section shows a few sample uses of WebFinger. Any application
of WebFinger would be specified outside of this document, as
described in Section 8. The examples in this section should be
simple enough to understand without having seen the formal
specifications of the applications.
3.1. Identity Provider Discovery for OpenID Connect 3.1. Identity Provider Discovery for OpenID Connect
Suppose Carol wishes to authenticate with a web site she visits using Suppose Carol wishes to authenticate with a web site she visits using
OpenID Connect [15]. She would provide the web site with her OpenID OpenID Connect [15]. She would provide the web site with her OpenID
Connect identifier, say carol@example.com. The visited web site Connect identifier, say carol@example.com. The visited web site
would perform a WebFinger query looking for the OpenID Connect would perform a WebFinger query looking for the OpenID Connect
Provider. Since the site is interested in only one particular link Provider. Since the site is interested in only one particular link
relation, the WebFinger resource might utilize the "rel" parameter as relation, the WebFinger resource might utilize the "rel" parameter as
described in Section 4.3: described in Section 4.3:
skipping to change at page 5, line 7 skipping to change at page 5, line 7
Since the "rel" parameter only serves to filter the link relations Since the "rel" parameter only serves to filter the link relations
returned by the resource, other name/value pairs in the response, returned by the resource, other name/value pairs in the response,
including any aliases or properties, would be returned. Also, since including any aliases or properties, would be returned. Also, since
support for the "rel" parameter is not guaranteed, the client must support for the "rel" parameter is not guaranteed, the client must
not assume the "links" array will contain only the requested link not assume the "links" array will contain only the requested link
relation. relation.
3.2. Getting Author and Copyright Information for a Web Page 3.2. Getting Author and Copyright Information for a Web Page
Suppose an application would like to retrieve metadata information Suppose an application is defined to retrieve metadata information
about a web page URL, such as author and copyright information. To about a web page URL, such as author and copyright information. To
do that, the application can utilize WebFinger to issue a query for retrieve that information, the client can utilize WebFinger to issue
the specific URL. Suppose the URL of interest is a query for the specific URL. Suppose the URL of interest is
http://blog.example.com/article/id/314. The application would issue http://blog.example.com/article/id/314. The client would issue a
a query similar to the following: query similar to the following:
GET /.well-known/webfinger? GET /.well-known/webfinger?
resource=http%3A%2F%2Fblog.example.com%2Farticle%2Fid%2F314 resource=http%3A%2F%2Fblog.example.com%2Farticle%2Fid%2F314
HTTP/1.1 HTTP/1.1
Host: blog.example.com Host: blog.example.com
The server might then reply in this way: The server might then reply in this way:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Access-Control-Allow-Origin: * Access-Control-Allow-Origin: *
skipping to change at page 6, line 41 skipping to change at page 6, line 41
other URI scheme (such as HTTP). other URI scheme (such as HTTP).
A WebFinger resource is always given a query target, which is another A WebFinger resource is always given a query target, which is another
URI that identifies the entity whose information is sought. GET URI that identifies the entity whose information is sought. GET
requests to a WebFinger resource convey the query target in the requests to a WebFinger resource convey the query target in the
"resource" parameter in the WebFinger URI's query string; see Section "resource" parameter in the WebFinger URI's query string; see Section
4.1 for details. 4.1 for details.
The host to which a WebFinger query is issued is significant. If the The host to which a WebFinger query is issued is significant. If the
query target contains a "host" portion (Section 3.2.2 of RFC 3986), query target contains a "host" portion (Section 3.2.2 of RFC 3986),
then the host to which the WebFinger query is issued MUST be the same then the host to which the WebFinger query is issued SHOULD be the
as the "host" portion of the query target, unless the client receives same as the "host" portion of the query target, unless the client
instructions through some out-of-band mechanism to send the query to receives instructions through some out-of-band mechanism to send the
another host. If the query target does not contain a "host" portion, query to another host. If the query target does not contain a "host"
then the client chooses a host to which it directs the query using portion, then the client chooses a host to which it directs the query
additional information it has. using additional information it has.
The path component of a WebFinger URI MUST be the well-known path The path component of a WebFinger URI MUST be the well-known path
"/.well-known/webfinger". A WebFinger URI MUST contain a query "/.well-known/webfinger". A WebFinger URI MUST contain a query
component that encodes the query target and optional link relation component that encodes the query target and optional link relation
types as specified in Section 4.1. types as specified in Section 4.1.
The WebFinger resource returns a JSON Resource Descriptor (JRD) as The WebFinger resource returns a JSON Resource Descriptor (JRD) as
the resource representation to convey information about an entity on the resource representation to convey information about an entity on
the Internet. Also, the Cross-Origin Resource Sharing (CORS) [7] the Internet. Also, the Cross-Origin Resource Sharing (CORS) [7]
specification is utilized to facilitate queries made via a web specification is utilized to facilitate queries made via a web
skipping to change at page 9, line 36 skipping to change at page 9, line 36
Content-Type: application/jrd+json Content-Type: application/jrd+json
{ {
"subject" : "acct:bob@example.com", "subject" : "acct:bob@example.com",
"aliases" : "aliases" :
[ [
"https://www.example.com/~bob/" "https://www.example.com/~bob/"
], ],
"properties" : "properties" :
{ {
"http://example.com/ns/role/" : "employee" "http://example.com/ns/role" : "employee"
}, },
"links" : "links" :
[ [
{ {
"rel" : "http://webfinger.example/rel/profile-page", "rel" : "http://webfinger.example/rel/profile-page",
"href" : "https://www.example.com/~bob/" "href" : "https://www.example.com/~bob/"
}, },
{ {
"rel" : "http://webfinger.example/rel/businesscard", "rel" : "http://webfinger.example/rel/businesscard",
"href" : "https://www.example.com/~bob/bob.vcf" "href" : "https://www.example.com/~bob/bob.vcf"
skipping to change at page 10, line 49 skipping to change at page 10, line 49
4.4.2. aliases 4.4.2. aliases
The "aliases" array is an array of zero or more URI strings that The "aliases" array is an array of zero or more URI strings that
identify the same entity as the "subject" URI. identify the same entity as the "subject" URI.
The "aliases" array is OPTIONAL in the JRD. The "aliases" array is OPTIONAL in the JRD.
4.4.3. properties 4.4.3. properties
The "properties" object comprises zero or more name/value pairs whose The "properties" object comprises zero or more name/value pairs whose
names are URIs and whose values are strings or null. Properties are names are URIs (referred to as "property identifiers") and whose
used to convey additional information about the subject of the JRD. values are strings or null. Properties are used to convey additional
As an example, consider this use of "properties": information about the subject of the JRD. As an example, consider
this use of "properties":
"properties" : { "http://webfinger.example/ns/name" : "Bob Smith" } "properties" : { "http://webfinger.example/ns/name" : "Bob Smith" }
The "properties" member is OPTIONAL in the JRD. The "properties" member is OPTIONAL in the JRD.
4.4.4. links 4.4.4. links
The "links" array has any number of member objects, each of which The "links" array has any number of member objects, each of which
represents a link [4]. Each of these link objects can have the represents a link [4]. Each of these link objects can have the
following members: following members:
skipping to change at page 11, line 24 skipping to change at page 11, line 24
o titles o titles
o properties o properties
The "rel" and "href" members are strings representing the link's The "rel" and "href" members are strings representing the link's
relation type and the target URI, respectively. The context of the relation type and the target URI, respectively. The context of the
link is the "subject" (see Section 4.4.1). link is the "subject" (see Section 4.4.1).
The "type" member is a string indicating what the media type of the The "type" member is a string indicating what the media type of the
result of dereferencing the link ought to be. result of dereferencing the link ought to be.
The order of elements in the "links" array indicates an order of The order of elements in the "links" array MAY be interpreted as
preference. Thus, if there are two or more link relations having the indicating an order of preference. Thus, if there are two or more
same "rel" value, the first link relation would indicate the user's link relations having the same "rel" value, the first link relation
preferred link. would indicate the user's preferred link.
The "links" array is OPTIONAL in the JRD. The "links" array is OPTIONAL in the JRD.
Below, each of the members of the objects found in the "links" array Below, each of the members of the objects found in the "links" array
is described in more detail. Each object in the "links" array, is described in more detail. Each object in the "links" array,
referred to as a "link relation object", is completely independent referred to as a "link relation object", is completely independent
from any other object in the array; any requirement to include a from any other object in the array; any requirement to include a
given member in the link relation object refers only to that given member in the link relation object refers only to that
particular object. particular object.
skipping to change at page 11, line 55 skipping to change at page 11, line 55
The other members of the object have meaning only once the type of The other members of the object have meaning only once the type of
link relation is understood. In some instances, the link relation link relation is understood. In some instances, the link relation
will have associated semantics enabling the client to query for other will have associated semantics enabling the client to query for other
resources on the Internet. In other instances, the link relation resources on the Internet. In other instances, the link relation
will have associated semantics enabling the client to utilize the will have associated semantics enabling the client to utilize the
other members of the link relation object without fetching additional other members of the link relation object without fetching additional
external resources. external resources.
URI link relation type values are compared using the "Simple String URI link relation type values are compared using the "Simple String
Comparison" algorithm of section 6.2.1 of RFC 3986. Comparison" algorithm of Section 6.2.1 of RFC 3986.
The "rel" member MUST be present in the link relation object. The "rel" member MUST be present in the link relation object.
4.4.4.2. type 4.4.4.2. type
The value of the "type" member is a string that indicates the media The value of the "type" member is a string that indicates the media
type [9] of the target resource (see RFC 6838 [10]). type [9] of the target resource (see RFC 6838 [10]).
The "type" member is OPTIONAL in the link relation object. The "type" member is OPTIONAL in the link relation object.
skipping to change at page 12, line 51 skipping to change at page 12, line 51
{ {
"en-us" : "The Magical World of Steve", "en-us" : "The Magical World of Steve",
"fr" : "Le Monde Magique de Steve" "fr" : "Le Monde Magique de Steve"
} }
The "titles" member is OPTIONAL in the link relation object. The "titles" member is OPTIONAL in the link relation object.
4.4.4.5. properties 4.4.4.5. properties
The "properties" object within the link relation object comprises The "properties" object within the link relation object comprises
zero or more name/value pairs whose names are URIs and whose values zero or more name/value pairs whose names are URIs (referred to as
are strings or null. Properties are used to convey additional "property identifiers") and whose values are strings or null.
information about the link relation. As an example, consider this Properties are used to convey additional information about the link
use of "properties": relation. As an example, consider this use of "properties":
"properties" : { "http://webfinger.example/mail/port" : "993" } "properties" : { "http://webfinger.example/mail/port" : "993" }
The "properties" member is OPTIONAL in the link relation object. The "properties" member is OPTIONAL in the link relation object.
4.5. WebFinger and URIs 4.5. WebFinger and URIs
WebFinger requests include a "resource" parameter (see Section 4.1) WebFinger requests include a "resource" parameter (see Section 4.1)
specifying the query target (URI) for which the client requests specifying the query target (URI) for which the client requests
information. WebFinger is neutral regarding the scheme of such a information. WebFinger is neutral regarding the scheme of such a
skipping to change at page 16, line 8 skipping to change at page 16, line 8
However, some URI schemes do not have host portions and there might However, some URI schemes do not have host portions and there might
be some applications of WebFinger for which the host portion of a URI be some applications of WebFinger for which the host portion of a URI
cannot or should not be utilized. In such instances, the application cannot or should not be utilized. In such instances, the application
specification MUST clearly define the host resolution procedures, specification MUST clearly define the host resolution procedures,
which might include provisioning a "default" host within the client which might include provisioning a "default" host within the client
to which queries are directed. to which queries are directed.
8.3. Specification of Properties 8.3. Specification of Properties
WebFinger defines both subject-specific properties (i.e., properties WebFinger defines both subject-specific properties (i.e., properties
related to the URI that for which information is queried) and link- described in Section 4.4.3 that relate to the URI for which
specific properties. This section refers to subject-specific information is queried) and link-specific properties (see Section
properties. 4.4.4.5). This section refers to subject-specific properties.
Properties are name/value pairs whose names are URIs and whose values Applications that utilize subject-specific properties MUST define the
are strings or null. Applications that utilize subject-specific URIs used in identifying those properties, along with valid property
properties MUST define the URIs used in identifying those properties, values.
along with valid property values.
Consider this portion of the JRD found in the example in Section 3.2. Consider this portion of the JRD found in the example in Section 3.2.
"properties" : "properties" :
{ {
"http://blgx.example.net/ns/version" : "1.3", "http://blgx.example.net/ns/version" : "1.3",
"http://blgx.example.net/ns/ext" : null "http://blgx.example.net/ns/ext" : null
} }
Here, two properties are returned in the WebFinger response. Each of Here, two properties are returned in the WebFinger response. Each of
these would be defined in a WebFinger application specification. these would be defined in a WebFinger application specification.
These two properties might be defined in the same WebFinger These two properties might be defined in the same WebFinger
application specification or separately in different specifications. application specification or separately in different specifications.
Since the latter is possible, it is important that WebFinger clients Since the latter is possible, it is important that WebFinger clients
not assume that one property has any specific relationship with not assume that one property has any specific relationship with
another property unless some relationship is explicitly defined in another property unless some relationship is explicitly defined in
the particular WebFinger application specification. the particular WebFinger application specification.
8.4. Specification of Links 8.4. Specification of Links
The links returned in a WebFinger response are each comprised of The links returned in a WebFinger response each comprise several
several pieces of information, some of which are optional (refer to pieces of information, some of which are optional (refer to Section
Section 4.4.4). The WebFinger application specification MUST define 4.4.4). The WebFinger application specification MUST define each
each link and any values associated with a link, including the link link and any values associated with a link, including the link
relation type ("rel"), the expected media type ("type"), properties, relation type ("rel"), the expected media type ("type"), properties,
and titles. and titles.
The target URI to which the link refers (i.e., the "href"), if The target URI to which the link refers (i.e., the "href"), if
present, would not normally be specified in an application present, would not normally be specified in an application
specification. However, the URI scheme or any special specification. However, the URI scheme or any special
characteristics of the URI would usually be specified. If a characteristics of the URI would usually be specified. If a
particular link does not require an external reference, then all of particular link does not require an external reference, then all of
the semantics related to the use of that link MUST be defined within the semantics related to the use of that link MUST be defined within
the application specification. Such links might rely only on the application specification. Such links might rely only on
properties or titles in the link to convey meaning. properties or titles in the link to convey meaning.
8.5. One URI, Multiple Applications 8.5. One URI, Multiple Applications
It is important to be mindful of the fact that different WebFinger It is important to be mindful of the fact that different WebFinger
applications might specify the use of the same URI scheme and, in applications might specify the use of the same URI scheme and, in
effect, the same URI for different purposes. That should not be a effect, the same URI for different purposes. That should not be a
problem, since each of property identifier and link relation type problem, since each of property identifier (see Sections 4.4.3 and
would be uniquely defined for a specific application. 4.4.4.5) and link relation type would be uniquely defined for a
specific application.
It should be noted that when a client requests information about a It should be noted that when a client requests information about a
particular URI and receives a response with a number of different particular URI and receives a response with a number of different
property identifiers or link relation types that the response is property identifiers or link relation types that the response is
providing information about the URI without any particular semantics. providing information about the URI without any particular semantics.
How the client interprets the information SHOULD be in accordance How the client interprets the information SHOULD be in accordance
with the particular application specification or set of with the particular application specification or set of
specifications the client implements. specifications the client implements.
Any syntactically valid properties or links the client receives and Any syntactically valid properties or links the client receives and
that are not fully understood SHOULD be ignored and MUST NOT cause that are not fully understood SHOULD be ignored and SHOULD NOT cause
the client to report an error. the client to report an error.
8.6. Registration of Link Relation Types and Properties 8.6. Registration of Link Relation Types and Properties
Application specifications MAY define a simple token as a link Application specifications MAY define a simple token as a link
relation type for a link. In that case, the link relation type MUST relation type for a link. In that case, the link relation type MUST
be registered with IANA as specified in Sections 10.3. be registered with IANA as specified in Sections 10.3.
Further, any defined properties MUST be registered with IANA as Further, any defined properties MUST be registered with IANA as
described in Section 10.4. described in Section 10.4.
skipping to change at page 20, line 43 skipping to change at page 20, line 43
Subtype name: jrd+json Subtype name: jrd+json
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
In particular, because RFC 4627 already defines the character In particular, because RFC 4627 already defines the character
encoding for JSON, no "charset" parameter is used. encoding for JSON, no "charset" parameter is used.
Encoding considerations: See RFC 6839, section 3.1. Encoding considerations: See RFC 6839, Section 3.1.
Security considerations: Security considerations:
The JSON Resource Descriptor (JRD) is a JavaScript Object Notation The JSON Resource Descriptor (JRD) is a JavaScript Object Notation
(JSON) object. It is a text format that must be parsed by entities (JSON) object. It is a text format that must be parsed by entities
that wish to utilize the format. Depending on the language and that wish to utilize the format. Depending on the language and
mechanism used to parse a JSON object, it is possible for an mechanism used to parse a JSON object, it is possible for an
attacker to inject behavior into a running program. Therefore, attacker to inject behavior into a running program. Therefore,
care must be taken to properly parse a received JRD to ensure that care must be taken to properly parse a received JRD to ensure that
only a valid JSON object is present and that no JavaScript or other only a valid JSON object is present and that no JavaScript or other
skipping to change at page 22, line 20 skipping to change at page 22, line 20
WebFinger utilizes URIs to identify properties of a subject or link WebFinger utilizes URIs to identify properties of a subject or link
and the associated values (see Section 8.3 and Section 8.6). This and the associated values (see Section 8.3 and Section 8.6). This
specification establishes a new "WebFinger Properties" registry to specification establishes a new "WebFinger Properties" registry to
record property identifiers. record property identifiers.
10.4.1. The Registration Template 10.4.1. The Registration Template
The registration template for WebFinger properties is: The registration template for WebFinger properties is:
o Property URI: o Property Identifier:
o Link Type: o Link Type:
o Description: o Description:
o Reference: o Reference:
o Notes: [optional] o Notes: [optional]
The "Property URI" must be a URI that identifies the property being The "Property Identifier" must be a URI that identifies the property
registered. being registered.
The "Link Type" contains the name of a Link Relation Type with which The "Link Type" contains the name of a Link Relation Type with which
this property identifier is used. If the property is a subject- this property identifier is used. If the property is a subject-
specific property, then this field is specified as "N/A". specific property, then this field is specified as "N/A".
The "Description" is intended to explaining the purpose of the The "Description" is intended to explaining the purpose of the
property. property.
The "Reference" field points to the specification that defines the The "Reference" field points to the specification that defines the
registered property. registered property.
skipping to change at page 23, line 6 skipping to change at page 23, line 6
10.4.2. The Registration Procedures 10.4.2. The Registration Procedures
The IETF has created a mailing list, webfinger@ietf.org, which can be The IETF has created a mailing list, webfinger@ietf.org, which can be
used for public discussion of the WebFinger protocol and any used for public discussion of the WebFinger protocol and any
applications that use it. Prior to registration of a WebFinger applications that use it. Prior to registration of a WebFinger
property, discussion on the mailing list is strongly encouraged. The property, discussion on the mailing list is strongly encouraged. The
IESG has appointed Designated Experts who will monitor the IESG has appointed Designated Experts who will monitor the
webfinger@ietf.org mailing list and review registrations. webfinger@ietf.org mailing list and review registrations.
A WebFinger property is registered with a Specification Required (see A WebFinger property is registered with a Specification Required (see
RFC 5226 [13]) after a two-week review period by the Designated RFC 5226 [13]) after a review by the Designated Expert(s). The
Expert(s). However, the Designated Expert(s) may approve a review is normally expected to take on the order of two to four
registration prior to publication of a specification once the weeks. However, the Designated Expert(s) may approve a registration
Designated Expert(s) are satisfied that such a specification will be prior to publication of a specification once the Designated Expert(s)
published. In evaluating registration requests, the Designated are satisfied that such a specification will be published. In
Expert(s) should make an effort to avoid registering two different evaluating registration requests, the Designated Expert(s) should
properties that have the same meaning. Where a proposed property is make an effort to avoid registering two different properties that
similar to an already-defined property, Designated Expert(s) should have the same meaning. Where a proposed property is similar to an
insist that enough text be included in the description or notes already-defined property, Designated Expert(s) should insist that
section of the template to sufficiently differentiate the new enough text be included in the description or notes section of the
property from an existing one. template to sufficiently differentiate the new property from an
existing one.
The registration procedure begins when a completed registration The registration procedure begins when a completed registration
template (as defined above) sent to webfinger@ietf.org and template (as defined above) sent to webfinger@ietf.org and
iana@iana.org. IANA will track the review process and communicate iana@iana.org. IANA will track the review process and communicate
the results to the registrant. The WebFinger mailing list provides the results to the registrant. The WebFinger mailing list provides
an opportunity for community discussion and input, and the Designated an opportunity for community discussion and input, and the Designated
Expert(s) may use that input to inform their review. Denials should Expert(s) may use that input to inform their review. Denials should
include an explanation and, if applicable, suggestions as to how to include an explanation and, if applicable, suggestions as to how to
make the request successful if re-submitted. make the request successful if re-submitted.
The specification registering the WebFinger property MUST include the The specification registering the WebFinger property MUST include the
completed registration template shown above. Once the registration completed registration template shown above. Once the registration
procedure concludes successfully, IANA creates or modifies the procedure concludes successfully, IANA creates or modifies the
corresponding record in the "WebFinger Properties" registry. corresponding record in the "WebFinger Properties" registry.
11. Acknowledgments 11. Acknowledgments
This document has benefited from extensive discussion and review of This document has benefited from extensive discussion and review of
many of the members of the APPSAWG working group. The authors would many of the members of the APPSAWG working group. The authors would
like to especially acknowledge the invaluable input of Eran Hammer- like to especially acknowledge the invaluable input of Eran Hammer-
Lahav, Blaine Cook, Brad Fitzpatrick, Laurent-Walter Goix, Joe Lahav, Blaine Cook, Brad Fitzpatrick, Laurent-Walter Goix, Joe
Clarke, Michael B. Jones, Peter Saint-Andre, Dick Hardt, Tim Bray, Clarke, Peter Saint-Andre, Dick Hardt, Tim Bray, James Snell, Melvin
James Snell, Melvin Carvalho, Evan Prodromou, Mark Nottingham, Barry Carvalho, Evan Prodromou, Mark Nottingham, Elf Pavlik, Bjoern
Leiba, Elf Pavlik, Bjoern Hoehrmann, Subramanian Moonesamy, Joe Hoehrmann, Subramanian Moonesamy, Joe Gregorio, John Bradley, and
Gregorio, John Bradley, Pete Resnick and others that we have others that we have undoubtedly, but inadvertently, missed.
undoubtedly, but inadvertently, missed. Special thanks go to the
chairs of APPSAWG, especially Salvatore Loreto for his assistance in The authors would also like to express their gratitude to the chairs
shepherding this document. of APPSAWG, especially Salvatore Loreto for his assistance in
shepherding this document. We also want to thank Barry Leiba and
Pete Resnick, the Applications Area Directors, for their support and
exhaustive reviews.
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
skipping to change at page 24, line 43 skipping to change at page 24, line 47
[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an, IANA [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an, IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
12.2. Informative References 12.2. Informative References
[14] Perreault, S., "vCard Format Specification", RFC 6350, August [14] Perreault, S., "vCard Format Specification", RFC 6350, August
2011. 2011.
[15] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., [15] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", July
January 2013, http://openid.net/specs/openid-connect-messages- 2013, http://openid.net/specs/openid-connect-messages-1_0.html.
1_0.html.
[16] Hammer-Lahav, E. and Cook, B., "Web Host Metadata", RFC 6415, [16] Hammer-Lahav, E. and Cook, B., "Web Host Metadata", RFC 6415,
October 2011. October 2011.
[17] Hammer-Lahav, E. and W. Norris, "Extensible Resource Descriptor [17] Hammer-Lahav, E. and W. Norris, "Extensible Resource Descriptor
(XRD) Version 1.0", http://docs.oasis- (XRD) Version 1.0", http://docs.oasis-
open.org/xri/xrd/v1.0/xrd-1.0.html. open.org/xri/xrd/v1.0/xrd-1.0.html.
[18] Saint-Andre, P., "The 'acct' URI Scheme", draft-ietf-appsawg- [18] Saint-Andre, P., "The 'acct' URI Scheme", draft-ietf-appsawg-
acct-uri-06, July 2013. acct-uri-06, July 2013.
skipping to change at page 25, line 36 skipping to change at page 25, line 39
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Phone: +1 919 392 3266 Phone: +1 919 392 3266
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
IM: xmpp:gsalguei@cisco.com IM: xmpp:gsalguei@cisco.com
Michael B. Jones
Microsoft
Email: mbj@microsoft.com
URI: http://self-issued.info/
Joseph Smarr Joseph Smarr
Google Google
Email: jsmarr@google.com Email: jsmarr@google.com
 End of changes. 27 change blocks. 
70 lines changed or deleted 87 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/