Late Night PC

Network Working Group J. Schiller Request for Comments ???? CodeDread.com Category Experimental R. Russell LateNightPC.com 1 April 2004 The FTD Protocol Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) 2004, J. Schiller & R. Russell. All Rights Reserved 1. Overview and Rational The internet (in particular the World Wide Web) has grown over the past decade and a half to become a vast, dynamic repository of resources spanning an enormous range of fields of interest. Workers have spent countless hours using the internet to waste time (often called "Feeding The Dog" or less reprintable names). While employees have been, by and large, amazingly successful in this endeavor, the pursuit has always lacked the standards that allow interoperability of so many other uses of the internet. There is a clear need for workers to be able to efficiently share their successful attempts to slack off with their peers at the company, across the city, or across the globe who would otherwise have no choice but to engage in useful work. The FTD Protocol is a protocol designed to fill this need. The protocol has been designed specifically to maximize uselessness of time spent browsing the world wide web. NOTE The FTD acronym stands for "Free Time Distraction". Rumours persist that this is a sanitized alternative to the afore-mentioned expression involving canines and coitus. However, these rumours remain unfounded. 2. Frame Format The FTD protocol runs over plain text email, using URLs to identify the FTD resources in question. [1] Since the FTD protocol runs on top of plain-text email, there are three main sections in the FTD payload the email recipient(s), the email header and the email body. 2.1 Recipient Field The email recipient is a list of all email addresses to which the FTD resource is being shared. This should be a list of all people which will find the resource amusing or of interest. See Section 4 "Safety Considerations" for additional notes about this field. Schiller & Russell [Page 1] RFC ???? The FTD Protocol 1 April 2004 2.2 Header Field The email header contains the timestamp of the FTD resource. This allows recipients and senders of the FTD protocol to easily sort, search and filter FTD resources. The timestamp of the FTD resource has the following format ftd//yyyy.mm.dd/HHMMTZ The "ftd//" is a required identifier in the Header Field for any FTD resource. yyyy is the 4-digit year in which the FTD resource was sent to its recipients. Note that this implies the FTD protocol is Y2K compliant, but not Year-10000 compliant. Valid values for yyyy range from { 0000 ... 9999 }. mm is the 2-digit month in which the FTD resource was sent. All single digit days should be padded with a single zero (0). Valid values for mm range from { 01 ... 12 }. dd is the 2-digit day in which the FTD resource was sent. All single digit days should be padded with a single zero (0). Valid values for dd range from { 01 ... 31 }, but the maximum range of dd is specified by the particular month (mm). HH is the 2-digit hour in which the FTD resource was sent. All single digit hours should be padded with a single 0. The FTD protocol uses a 24-hour clock, so valid values of HH range from { 01, 02, ... 23 }. MM is the 2-digit minute in which the FTD resource was sent. All single digit minutes should be padded with a single 0. Valid values for MM range from { 01 ... 59 }. TZ is a 3-character string identifying the international timezone of the sender of the FTD resource. Examples include "CST" for Central Standard Time. An example of a valid FTD timestamp is ftd//2004.04.01/1157CST 2.3 Body Field The body of the FTD resource contains several subfields. Each subfield is separate by a new-line/carriage return and is identified by a subfield name, a colon, then the value of the subfield. The order of the subfields are not specified. There are two mandatory sub-fields URL and Comment. The URL subfield describes to the users the FTD resource in question and allows the users to access the resource for review. The URL should follow the format as defined in [1]. The Comment subfield allows the sender of the FTD resource to provide some context as to why the FTD resource was sent or how the FTD resource impacted the sender. This field is considered Schiller & Russell [Page 2] RFC ???? The FTD Protocol 1 April 2004 mandatory so that the recipient can determine the personal urgency or relevance of the FTD resource without actually accessing the resource. This field can also be used to warn recipients that the resource is inappropriate for access at work. Any additional sub-fields can be added to the Body field of the FTD resource using a USER-DEFINED-FIELD, as described in RFC-822 [2]. See Section 2.4 "Some FTD Examples" for further examples. 2.4 Some FTD Examples The following are two examples of FTD resources. Since the FTD protocol is sent over email, only the Body of the emails have been included (while the email subjects would hold the FTD timestamp) URL http//www.dymphna.net/randomquotage/lebowskiquotes.shtml Comment Hilarious! X-Related-Link http//www.imdb.com/title/tt0118715/ As another example, if two users have established some type of ratings system (to describe the quality of the company time wasted), the sender may include a subfield and value with the FTD resource such as URL http//www.mindprod.com/unmain.html Comment It's worth getting off-shored to read this! X-Score 7 3. Safety Considerations Since the FTD protocol is used to transmit information about resources which are not considered necessary for day-to-day work, care should be exercised when sending FTD resources to users who have a vested interest in a user's productivity. For example, it is not advised to send FTD resources to your manager. 4. Capacity Considerations Each FTD user is considered to have a virtual queue of incoming FTD resources. The maximum size of this queue is limited only by the user's email account limits. Users engaged in heavy F'ing The D should be considerate of those users who have a limited amount of spare time as the rate of FTD consumption will vary considerably across users. 5. References [1] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, University of Minnesota, December 1994 [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages," RFC 822, Department of Electrical Engineering, University of Delaware, August 1982. 6. Author's Addresses Jeff Schiller Robert Russell www.CodeDread.com www.latenightpc.com Email JEFF_SCHILLER@HOTMAIL.COM ROBERT_RUSSELL@HOTMAIL.COM Schiller & Russell [Page 3]