idnits 2.17.1
draft-jones-appsawg-webfinger-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
does not include the phrase in its RFC 2119 key words list.
-- The document date (March 12, 2012) is 4421 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 5988 (ref. '3') (Obsoleted by RFC 8288)
** Obsolete normative reference: RFC 4627 (ref. '4') (Obsoleted by RFC
7158, RFC 7159)
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
-- Possible downref: Non-RFC (?) normative reference: ref. '10'
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
-- Obsolete informational reference (is this intentional?): RFC 4395 (ref.
'15') (Obsoleted by RFC 7595)
-- Obsolete informational reference (is this intentional?): RFC 2279 (ref.
'19') (Obsoleted by RFC 3629)
Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group Paul E. Jones
3 Internet Draft Gonzalo Salgueiro
4 Intended status: Standards Track Cisco Systems
5 Expires: September 12, 2012 Joseph Smarr
6 Google
7 March 12, 2012
9 Webfinger
10 draft-jones-appsawg-webfinger-01.txt
12 Abstract
14 This specification defines the Webfinger protocol. Webfinger may be
15 used to discover information about people on the Internet, such as a
16 person's personal profile address, identity service, telephone
17 number, or preferred avatar. Webfinger may also be used to learn
18 information about objects on the network, such as the amount of toner
19 in a printer or the physical location of a server.
21 Status of this Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on September 12, 2012.
38 Copyright Notice
40 Copyright (c) 2012 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction...................................................2
56 2. Terminology....................................................3
57 3. Example Uses of Webfinger......................................3
58 3.1. Locating a User's Blog....................................3
59 3.2. Retrieving a Person's Contact Information.................5
60 3.3. Simplifying the Login Process.............................6
61 3.4. Retrieving Device Information.............................7
62 4. Webfinger Protocol.............................................8
63 4.1. Performing a Webfinger Query..............................8
64 4.2. The Web Host Metadata "resource" Parameter................9
65 5. The "acct" URI................................................11
66 5.1. Using the "acct" URI.....................................11
67 5.2. Syntax of "acct" URI.....................................11
68 6. The "acct" Link Relation......................................12
69 7. Cross-Origin Resource Sharing (CORS)..........................13
70 8. Security Considerations.......................................13
71 9. IANA Considerations...........................................14
72 9.1. Registration of the "acct" URI scheme name...............14
73 9.2. Registration of the "acct" Link Relation Type............14
74 10. Acknowledgments..............................................15
75 11. References...................................................15
76 11.1. Normative References....................................15
77 11.2. Informative References..................................16
78 Author's Addresses...............................................17
80 1. Introduction
82 There is a utility found on UNIX systems called "finger" [14] that
83 allows a person to access information about another person. The
84 information being queried might be on a computer anywhere in the
85 world. The information returned via "finger" is simply a plain text
86 file that contains unstructured information provided by the queried
87 user.
89 Webfinger borrows the concept of the legacy finger protocol, but
90 introduces a very different approach to sharing information. Rather
91 than returning a simple unstructured text file, Webfinger uses
92 structured documents that contain link relations. These link
93 relations point to information a user or entity on the Internet
94 wishes to expose. For a person, the kinds of information that might
95 be exposed include a personal profile address, identity service,
96 telephone number, or preferred avatar. Webfinger may also be used to
97 learn information about objects on the network, such as the amount of
98 toner in a printer or the physical location of a server.
100 Information returned via Webfinger might be for direct human
101 consumption (e.g., another user's phone number) or it might be used
102 by systems to help carry out some operation (e.g., facilitate logging
103 into a web site by determining a user's identification service).
105 2. Terminology
107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
109 document are to be interpreted as described in RFC 2119 [1].
111 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are
112 appropriate when valid exceptions to a general requirement are known
113 to exist or appear to exist, and it is infeasible or impractical to
114 enumerate all of them. However, they should not be interpreted as
115 permitting implementors to fail to implement the general requirement
116 when such failure would result in interoperability failure.
118 Webfinger makes heavy use of "Link Relations". Briefly, a Link
119 Relation is an attribute and value pair used on the Internet wherein
120 the attribute identifies the type of link to which the associated
121 value refers. In Hypertext Transfer Protocol (HTTP) [2] and Web
122 Linking [3], the attribute is a "rel" and the value is an "href".
124 3. Example Uses of Webfinger
126 In this section, we describe just a few sample uses for Webfinger and
127 show what the protocol looks like. This is not an exhaustive list of
128 possible uses and the entire section should be considered non-
129 normative. The list of potential use cases is virtually unlimited
130 since a user can share any kind of machine-consumable information via
131 Webfinger.
133 3.1. Locating a User's Blog
135 Assume you receive an email from Bob and he refers to something he
136 posted on his blog, but you do not know where Bob's blog is located.
137 It would be simple to discover the address of Bob's blog if he makes
138 that information available via Webfinger.
140 Let's assume your email client discovers that blog automatically for
141 you. When receive the message from Bob (bob@example.com), your email
142 client performs the following steps behind the scenes.
144 First, it tries to get the host metadata [9] information for the
145 domain example.com. It does this by issuing the following HTTPS
146 query to example.com:
148 GET /.well-known/host-meta HTTP/1.1
149 Host: example.com
151 The server replies with an XRD [8] document:
153 HTTP/1.1 200 OK
154 Access-Control-Allow-Origin: *
155 Content-Type: application/xrd+xml; charset=UTF-8
157
158
159
162
164 The client then processes the received XRD in accordance with the Web
165 Host Metadata [9] procedures. The client will see the LRDD link
166 relation and issue a query with the user's account URI [5]. (The
167 Account URI is discussed in Section 4.2.) The query might look like
168 this:
170 GET /lrdd/?uri=acct%3Abob%40example.com HTTP/1.1
171 Host: example.com
173 The server might then respond with a message like this:
175 HTTP/1.1 200 OK
176 Access-Control-Allow-Origin: *
177 Content-Type: application/xrd+xml; charset=UTF-8
179
180
181 acct:bob@example.com
182
184
186
188
190 The email client might take note of the "blog" link relation in the
191 above XRD document that refers to Bob's blog. This URL would then be
192 presented to you so that you could then visit his blog.
194 The email client might also note that Bob has published an avatar
195 link relation and use that picture to represent Bob inside the email
196 client.
198 3.2. Retrieving a Person's Contact Information
200 Assume you have Alice in your address book, but her phone number
201 appears to be invalid. You could use Webfinger to find her current
202 phone number and update your address book.
204 Let's assume you have a web-based address book that you wish to
205 update. When you instruct the address book to pull Alice's current
206 contact information, the address book might issue a query like this
207 to get host metadata information for example.com:
209 GET /.well-known/host-meta.json HTTP/1.1
210 Host: example.com
212 Note the address book is looking for a JSON [4] representation,
213 whereas we used XML in the previous example.
215 The server might reply with something like this:
217 HTTP/1.1 200 OK
218 Access-Control-Allow-Origin: *
219 Content-Type: application/json; charset=UTF-8
221 {
222 "links" :
223 [
224 {
225 "rel" : "lrdd",
226 "type" : "application/json",
227 "template" :
228 "https://example.com/lrdd/?format=json&uri={uri}"
229 }
230 ]
231 }
233 The client processes the response as described in RFC 6415 [9]. It
234 will process the LRDD link relation using Alice's account URI by
235 issuing this query:
237 GET /lrdd/?format=json&uri=acct%3Aalice%40example.com HTTP/1.1
238 Host: example.com
240 The server might return a response like this:
242 HTTP/1.1 200 OK
243 Access-Control-Allow-Origin: *
244 Content-Type: application/json; charset=UTF-8
246 {
247 "subject" : "acct:alice@example.com",
248 "links" :
249 [
250 {
251 "rel" : "http://webfinger.net/rel/avatar",
252 "href" : "http://example.com/~alice/alice.jpg"
253 },
254 {
255 "rel" : "vcard",
256 "href" : "http://example.com/~alice/alice.vcf"
257 }
258 ]
259 }
261 With this response, the address book might see the vcard [16] link
262 relation and use that file to offer you updated contact information.
264 3.3. Simplifying the Login Process
266 OpenID (http://www.openid.net) is great for allowing users to log
267 into a web site, though one criticism is that it is challenging for
268 users to remember the URI they are assigned. Webfinger can help
269 address this issue by allowing users to use user@domain-style
270 addresses. Using a user's account URI, a web site can perform a
271 query to discover the associated OpenID identifier for a user.
273 Let's assume Carol is trying to use OpenID to log into a blog. The
274 blog server might issue the following query to get the host metadata
275 information:
277 GET /.well-known/host-meta.json HTTP/1.1
278 Host: example.com
280 The response that comes back is similar to the previous example:
282 HTTP/1.1 200 OK
283 Access-Control-Allow-Origin: *
284 Content-Type: application/json; charset=UTF-8
285 {
286 "links" :
287 [
288 {
289 "rel" : "lrdd",
290 "type" : "application/json",
291 "template" :
292 "https://example.com/lrdd/?format=json&uri={uri}"
293 }
294 ]
295 }
297 The blog server processes the response as described in RFC 6415. It
298 will process the LRDD link relation using Carol's account URI by
299 issuing this query:
301 GET /lrdd/?format=json&uri=acct%3Acarol%40example.com HTTP/1.1
303 The server might return a response like this:
305 HTTP/1.1 200 OK
306 Access-Control-Allow-Origin: *
307 Content-Type: application/json; charset=UTF-8
309 {
310 "subject" : "acct:carol@example.com",
311 "links" :
312 [
313 {
314 "rel" : "http://webfinger.net/rel/avatar",
315 "href" : "http://example.com/~alice/alice.jpg"
316 },
317 {
318 "rel" : " http://specs.openid.net/auth/2.0/provider ",
319 "href" : "https://openid.example.com/carol"
320 }
321 ]
322 }
324 At this point, the blog server knows that Carol's OpenID identifier
325 is https://openid.example.com/carol and could then proceed with the
326 login process as usual.
328 3.4. Retrieving Device Information
330 While the examples thus far have been focused on information about
331 humans, Webfinger does not limit queries to only those that use the
332 account URI scheme. Let's suppose there are devices on the network
333 like printers and you would like to check the current toner level for
334 a particular printer identified via the URI device:p1.example.com.
336 Following the procedures similar to those above, a query may be
337 issued to get link relations specific to this URI like this:
339 GET /lrdd/?format=json&uri=device%3Ap1.example.com HTTP/1.1
340 Host: example.com
342 The link relations that are returned may be quite different than
343 those for human users. Perhaps we may see a response like this:
345 HTTP/1.1 200 OK
346 Access-Control-Allow-Origin: *
347 Content-Type: application/json; charset=UTF-8
349 {
350 "subject" : "device:p1.example.com",
351 "links" :
352 [
353 {
354 "rel" : "tipsi",
355 "href" : "http://192.168.1.5/npap/"
356 }
357 ]
358 }
360 While this example is entirely fictitious, you can imagine that
361 perhaps the Transport Independent, Printer/System Interface [18] may
362 be enhanced with a web interface that allows a device that
363 understands the TIP/SI web interface specification to query the
364 printer for toner levels.
366 4. Webfinger Protocol
368 Webfinger does not actually introduce a new protocol, per se.
369 Rather, it builds upon the existing Web Host Metadata [9]
370 specification and leverages the Cross-Origin Resource Sharing (CORS)
371 [7] specification.
373 4.1. Performing a Webfinger Query
375 The first step a client must perform in executing a Webfinger query
376 is to query for the host metadata using HTTPS or HTTP. The
377 procedures are defined in the Web Host Metadata [9] specification.
379 Webfinger clients MUST locate the LRDD link relation, if present, and
380 perform a query for that link relation, if present. All other link
381 templates found must be processed to form a complete resource
382 descriptor. The processing rules in Section 4.2 of RFC 6415 MUST be
383 followed.
385 Webfinger servers MUST accept requests for both XRD [8] and JRD [9]
386 documents. The default representation returned by the server MUST be
387 an XRD document, but a JRD document MUST be returned if the client
388 explicitly requests it by using /.well-known/host-meta.json or
389 includes an Accept header in the HTTP request with a type of
390 "application/json" [4].
392 If the client requests a JRD document when querying for host
393 metadata, the Webfinger server can assume that the client will want a
394 JRD documents when querying the LRDD resource. As such, when the
395 Webfinger server returns a JRD document containing host metadata it
396 should include a URI for an LRDD resource that can return a JRD
397 document and MAY include a URI for an LRDD resource that will return
398 an XRD document.
400 If the client queries the LRDD resource and provides a URI for which
401 the server has no information, the server MUST return a 404 status
402 code. Likewise, any query to a URI in the resource descriptor that
403 is unknown to the server should result in the server returning a 404
404 status code.
406 4.2. The Web Host Metadata "resource" Parameter
408 In addition to the normal processing logic for processing host
409 metadata information, Webfinger defines the "resource" parameter for
410 querying for host metadata and returning all of the link relations
411 from LRDD and other resource-specific link templates in a single
412 query. This resource essentially pushes the work to the server to
413 form a complete resource descriptor for the specified resource.
415 Note that support for the "resource" parameter is optional, but
416 strongly recommended for improved performance. If a server does not
417 implement the "resource" parameter, then the server's host metadata
418 processing logic remains unchanged from RFC 6415.
420 To utilize the host-meta "resource" parameter, a Webfinger client
421 issues a request to /.well-known/host-meta or /.well-known/host-
422 meta.json as usual, but then appends a "resource" parameter as shown
423 in this example:
425 GET /.well-known/host-meta.json?resource=\
426 acct%3Abob%40example.com HTTP/1.1
427 Host: example.com
429 Note that the "\" character shown above is to indicate that the line
430 breaks at this point and continues on the next line. This was shown
431 only to avoid line wrapping in this document and is not a part of the
432 HTTP protocol.
434 When processing this request, the Webfinger server MUST
435 * Return a 404 status code if the URI provided in the resource
436 parameter is unknown to the server; and
438 * Set the "Subject" returned in the response to the value of the
439 "resource" parameter if the URI provided in the resource
440 parameter is known to the server
442 The Webfinger client can verify support for the "resource" parameter
443 by checking the value of the Subject returned in the response. If
444 the Subject matches the value of the "resource" parameter, then the
445 "resource" parameter is supported by the server.
447 For illustrative purposes, the following is an example usage of the
448 "resource" parameter that aligns with the example in Section 1.1.1 of
449 RFC 6415. The Webfinger client would issue this request:
451 GET /.well-known/host-meta.json?resource=\
452 http%3A%2F%2Fexample.com%2Fxy HTTP/1.1
453 Host: example.com
455 The Webfinger server would reply with this response:
457 HTTP/1.1 200 OK
458 Access-Control-Allow-Origin: *
459 Content-Type: application/json; charset=UTF-8
461 {
462 "subject" : "http://example.com/xy",
463 "properties" :
464 {
465 "http://spec.example.net/color" : "red"
466 },
467 "links" :
468 [
469 {
470 "rel" : "hub",
471 "href" : "http://example.com/hub"
472 },
473 {
474 "rel" : "hub",
475 "href" : "http://example.com/another/hub"
476 },
477 {
478 "rel" : "author",
479 "href" : "http://example.com/john"
480 },
481 {
482 "rel" : "author",
483 "template" : "http://example.com/author?\
484 q=http%3A%2F%2Fexample.com%2Fxy"
485 }
486 ]
487 }
489 5. The "acct" URI
491 The Web Host Metadata specification [9] allows for any kind of
492 resource to be queried, but Webfinger defines a specific type of
493 resource in order to query information about a human user.
495 Specifically, Webfinger uses the "acct" URI to refer to a human
496 user's account on the Internet.
498 5.1. Using the "acct" URI
500 The "acct" URI takes a familiar form in looking like an email
501 address. However, the account URI is not an email address and should
502 not be mistaken for one. Quite often, the account URI minus the
503 "acct:" scheme prefix may be exactly the same as the user's email
504 address.
506 A user MUST NOT be required to enter the "acct" URI scheme name along
507 with his account identifier into any Webfinger client. Rather, the
508 Webfinger client MUST accept identifiers that are void of the "acct:"
509 portion of the identifier. Composing a properly formatted "acct" URI
510 is the responsibility of the Webfinger client.
512 A user MAY provide a fully-specified "acct" URI.
514 5.2. Syntax of "acct" URI
516 The "acct" URI syntax is defined here in Augmented Backus-Naur Form
517 (ABNF) [6] and borrows syntax elements from RFC 3986 [5]:
519 acctURI = "acct:" userpart "@" domainpart
520 userpart = 1*( unreserved / pct-encoded )
521 domainpart = domainlabel 1*( "." domainlabel)
522 domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
523 alphanum = ALPHA / DIGIT
525 The "acct" URI scheme allows any character from the Unicode [11]
526 character set encoded as a UTF-8 [19] string that is then percent-
527 encoded as necessary into valid ASCII [20]. Characters in the
528 domainpart must be encoded to support internationalized domain names
529 (IDNs) [12].
531 Characters in the userpart or domainpart that are not unreserved must
532 be percent-encoded when used in a protocol or document that only
533 supports or requires ASCII. When carried in a document (e.g., XRD or
534 JRD) or protocol that supports the Unicode character set (e.g., UTF-8
535 or UTF-16 [21]), the URI strings may appear in the protocol or
536 document's native encoding without percent-encoding. Such usage of a
537 URI is commonly referred to as an Internationalized Resource
538 Identifier (IRI). Conversion between an IRI and URI is described in
539 Section 3 of RFC 3987 [13].
541 6. The "acct" Link Relation
543 Users of some services might have an acct URI that looks
544 significantly different from their email address, perhaps using
545 entirely different domain names. It may be useful to allow the
546 mapping of an assumed account identifier to the correct account
547 identifier.
549 Some users may also hold multiple different accounts and would like
550 to allow users to find information distributed across multiple
551 accounts.
553 To accomplish either of these two objectives, one uses the "acct"
554 link relation. Consider the following example.
556 Suppose Alice receives an email from bob@example.net. While Bob's
557 email identifier might be in the example.net domain, he holds his
558 account with an acct URI in the example.com domain. His email
559 provider may provide Webfinger services to enable redirecting Alice
560 when she queries for acct:bob@example.net.
562 Suppose Alice issues the following request:
564 GET /.well-known/host-meta.json?resource=\
565 acct%3Abob%40example.net HTTP/1.1
566 Host: example.net
568 The response that Alice receives back might be:
570 HTTP/1.1 200 OK
571 Access-Control-Allow-Origin: *
572 Content-Type: application/json; charset=UTF-8
574 {
575 "subject" : "acct:bob@example.net",
576 "links" :
577 [
578 {
579 "rel" : "acct",
580 "href" : "acct:bob@example.com"
581 }
583 ]
584 }
586 Alice's Webfinger client could then perform another query against the
587 URI acct:bob@example.com in order to get the information she is
588 seeking.
590 Webfinger clients need to take steps to avoid getting into loops
591 where two accounts, directly or indirectly, refer the client to each
592 other.
594 There are no limits on the number of acct link relations that might
595 be returned in a Webfinger query.
597 7. Cross-Origin Resource Sharing (CORS)
599 Webfinger is most useful when it is accessible without restrictions
600 on the Internet, and that includes web browsers. Therefore,
601 Webfinger servers MUST support Cross-Origin Resource Sharing (CORS)
602 [7]. Specifically, all queries to /.well-known/host-meta, /.well-
603 known/host-meta.json, and to the LRDD URI must include the following
604 HTTP header in the response:
606 Access-Control-Allow-Origin: *
608 QUESTION: Do we want to require CORS? Do we want to make it a
609 SHOULD? Or, do we want to say nothing about CORS?
611 8. Security Considerations
613 All of the security considerations applicable to Web Host Metadata
614 [9] and Cross-Origin Resource Sharing [7] are also applicable to this
615 specification. Of particular importance is the recommended use of
616 HTTPS to ensure that information is not modified during transit.
617 Clients should verify that the certificate used on an HTTPS
618 connection is valid.
620 When using HTTP to request an XRD document, Webfinger clients SHOULD
621 verify the XRD document's signature, if present, to ensure that the
622 XRD document has not been modified. Webfinger servers SHOULD include
623 a signature for XRD documents.
625 Service providers and users should be aware that placing information
626 on the Internet accessible through Webfinger means that any user can
627 access that information. While Webfinger can be an extremely useful
628 tool for allowing quick and easy access to one's avatar, blog, or
629 other personal information, users should understand the risks, too.
630 If one does not wish to share certain information with the world, do
631 not allow that information to be accessible through Webfinger.
633 The easy access to user information via Webfinger was a design goal
634 of the protocol, not a limitation. If one wishes to limit access to
635 information available via Webfinger, such as a Webfinger server for
636 use inside a corporate network, the network administrator must take
637 measures necessary to limit access from outside the network.
639 9. IANA Considerations
641 RFC Editor: Please replace QQQQ in the following two sub-sections
642 with a reference to this RFC.
644 9.1. Registration of the "acct" URI scheme name
646 This specification requests IANA to register the "acct" URI scheme in
647 the "Permanent URI Schemes" sub-registry in the "Uniform Resource
648 Identifier (URI) Schemes" IANA registry [17]. This registration
649 follows the URI Scheme Registration Template detailed in Section 5.4
650 of RFC 4395 [15].
652 URI scheme name: acct
654 Status: Permanent
656 URI scheme syntax: see Section 4.1 of RFC QQQQ
658 URI scheme semantics: see Section 4.1 of RFC QQQQ
660 Encoding considerations: The "acct" URI scheme allows any character
661 from the Unicode character set encoded as a UTF-8 string that is
662 then percent-encoded as necessary to result in an internal
663 representation in US-ASCII [10]
665 Applications/protocols that use this URI scheme name: Webfinger
667 Security considerations: see Section 7 of RFC QQQQ
669 Contact: Gonzalo Salgueiro
671 Author/Change controller: IETF
673 References: See Section 10 of RFC QQQQ
675 9.2. Registration of the "acct" Link Relation Type
677 Relation Name: acct
679 Description: A link relation that refers to a user's Webfinger
680 account identifier.
682 Reference: RFC QQQQ
684 Notes:
686 Application Data:
688 10. Acknowledgments
690 The authors would like to acknowledge Eran Hammer-Lahav, Blaine Cook,
691 Brad Fitzpatrick, and Laurent-Walter Goix for their invaluable input.
693 11. References
695 11.1. Normative References
697 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
698 Levels", BCP 14, RFC 2119, March 1997.
700 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
701 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
702 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
704 [3] Nottingham, M., "Web Linking", RFC 5988, October 2010.
706 [4] Crockford, D., "The application/json Media Type for
707 JavaScript Object Notation (JSON)", RFC 4627, July 2006.
709 [5] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
710 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
711 January 2005.
713 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
714 Specifications: ABNF", STD 68, RFC 5234, January 2008.
716 [7] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS
717 http://www.w3.org/TR/cors/, July 2010.
719 [8] Hammer-Lahav, E. and W. Norris, "Extensible Resource Descriptor
720 (XRD) Version 1.0", .
723 [9] Hammer-Lahav, E. and Cook, B., "Web Host Metadata", RFC 6415,
724 October 2011.
726 [10] American National Standards Institute, "Coded Character Set -
727 7-bit American Standard Code for Information Interchange", ANSI
728 X3.4, 1986.
730 [11] The Unicode Consortium. The Unicode Standard, Version 6.1.0,
731 (Mountain View, CA: The Unicode Consortium, 2012. ISBN 978-1-
732 936213-02-3) http://www.unicode.org/versions/Unicode6.1.0/.
734 [12] Klensin, J., "Internationalized Domain Names in Applications
735 (IDNA): Protocol", RFC 5891, August 2010.
737 [13] Duerst, M., "Internationalized Resource Identifiers (IRIs)",
738 RFC 3987, January 2005.
740 11.2. Informative References
742 [14] Zimmerman, D., "The Finger User Information Protocol", RFC
743 1288, December 1991.
745 [15] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
746 Registration Procedures for New URI Schemes", BCP 35, RFC 4395,
747 February 2006.
749 [16] Perreault, S., "vCard Format Specification", RFC 6350, August
750 2011.
752 [17] Internet Assigned Numbers Authority (IANA) Registry, "Uniform
753 Resource Identifier (URI) Schemes",
754 .
756 [18] "Transport Independent, Printer/System Interface", IEEE Std
757 1284.1-1997, 1997.
759 [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
760 2279, November 2003.
762 [20] Information Systems -- Coded Character Sets 7-Bit American
763 National Standard Code for Information Interchange (7-Bit
764 ASCII), ANSI X3.4-1986, December 30, 1986.
766 [21] Hoffman, P., Yergeau, F., "UTF-16, an encoding of ISO 10646",
767 RFC 2781, February 2000.
769 Author's Addresses
771 Paul E. Jones
772 Cisco Systems, Inc.
773 7025 Kit Creek Rd.
774 Research Triangle Park, NC 27709
775 USA
777 Phone: +1 919 476 2048
778 Email: paulej@packetizer.com
779 IM: xmpp:paulej@packetizer.com
781 Gonzalo Salgueiro
782 Cisco Systems, Inc.
783 7025 Kit Creek Rd.
784 Research Triangle Park, NC 27709
785 USA
787 Phone: +1 919 392 3266
788 Email: gsalguei@cisco.com
789 IM: xmpp:gsalguei@cisco.com
791 Joseph Smarr
792 Google
794 Email: jsmarr@google.com