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