| Internet Engineering Task Force | NP. Doty, Ed. |
| Internet-Draft | UC Berkeley |
| Intended status: Experimental | A. Badr |
| Expires: April 28, 2015 | |
| October 25, 2014 |
Protocol for Open Opt-in Online/Offline Friendship (PO4F)
draft-doty-friendship-00
This document defines a mechanism for discovering endpoints for making friends (friendpoints); an HTTP-based, application-layer method for creating friendships; and requirements for friends. These elements constitute the Protocol for Open Opt-in Online/Offline Friendship (POOOOF, or PO4F).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Friendship has gotten pretty complicated in this day and age. Making new friends is lamentably difficult. We, the authors, are sad and lonely people. What with Facebook and all, and are we networking or flirting or what?
To address this problem, we document the following open protocol for making new friends. Users of the Web can discover friendpoints while browsing the Web and direct their user agents to create a new friendship through the method described in the "Making a Friend" section below.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
A server MAY indicate a new friends endpoint (hereafter "friendpoint") with text of a web page describing the results of the action. The following text is RECOMMENDED for English-language servers:
Italics are OPTIONAL. An exclamation point MAY be added, to indicate an imploring, desperate tone through feigned excitement. The text SHOULD use the imperative mode for the human-readable description.
No machine-readable means for friendpoint discovery is provided, because machines cannot have friends, cannot experience love and cannot pick you up from the airport. We MUST NOT be friends with robots.
To create a friendship with the operator of the server, a user MUST submit an HTTP POST request to the friendpoint. The body of the request SHOULD be empty and servers SHOULD ignore the body of the request, except for any tokens for preventing cross-site request forgery. (See Security Considerations, below.)
A server SHOULD respond to the HTTP request with a status code to indicate the success or failure of creating a new friendship between the user and the operator of the server. For success, the server MUST respond with a status code in the 200 series. The following text is RECOMMENDED for the body of the response:
Nick browses to andrewbadr.com with his user agent and sees a link to "+ Add me as a friend". He clicks on the link to submit an HTML form and his user agent sends an HTTP POST request to the friendpoint:
And a successful response from the server indicates that Andrew and Nick are now friends:
In all future interactions after the POST request is completed successfully, the user MUST treat the operator of the server as a friend and the operator of the server MUST treat the user as a friend. A friend MUST say hello and smile when passing you on the street and MUST tell you when there's something stuck to your shirt. A friend SHOULD invite you to social events, stick up for you in arguments with strangers, and visit you if you're in the hospital in the same town.
A friend also MAY pick you up from the airport, listen to you complain about your significant other, and help you move apartments when you were too cheap to hire someone. A friend MAY drive you out to the edge of town, just anywhere, just to get away, when you feel like you've had enough. A friend MAY commit perjury on the witness stand to protect you. A true friend MAY remember your birthday without Facebook or the use of other friendship protocols.
This document includes no request to IANA.
Friendship necessarily involves vulnerability.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |