V. Wagner March,2008 Distributed Blog Commenting Prototcol Status of this Memo I just write it. If considerable interest appear, we might submit it to the IETF as RFC draft Copyright Copyright (c) by Victor B. Wagner, 2008 Abstract This document describes a protocol which can be used by different blog sites and web-based RSS aggregators to exchange the comments, made by users to the blog entries either originating on this site or recieved from other sites. 1 Introduction 1.1 Purpose of protocol Some blog sites are more like discussion forums. They allow reader to comment on blog entries identifying themselfes using some identity such as OpenID. If it is quite possible to distribute blog entries to other (mirror) sites using protocols like RSS/Atom feeds, to distribute load and improve availability of particular blog, there is no way to allow users to make comments on mirror site and distribute this comments to all other copies of same blog. Proposed protocol closes this gap. 1.2 Requrements Sites participating in this protocol should be able to serve http request [HTTP] and send those. 1.3 Terminology The capitalized 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 BCP 14, RFC 2119 [TERMS]. 2 Protocol overview 2.1 Basic terms definition 2.1.1 BLOG Blog or weblog is a web resource typically consisting of series of messages (POSTS) which appear on the blog web-page starting from most recent one. Each blog post can have separate web page, but it is guaranteed, that by visiting well-known and constant blog URL any HTTP-client would get most recent post first. Typically web page on this URL contain some special links which point to RSS feed of the posts, author information (FOAF) open-id server which confirms blog owner identity etc. For the purposes of this protocol blog is identified by this URL. 2.1.2 User User is an entity which can prove identity to at least to one of the servers. This server can confirm this identity to other servers with OpenID or simular means. So, comments made by the user carry user identity verified by the server either directly or indirectly via another server. 2.1.3 Comment Piece of textual information associated with some post in the particular blog and, may be with another comment to the same post. 2.2 Required comment properties Each comment in the system which support this protocol MUST have following proprerties: 2.2.1 Comment text Fragment of the text which MAY contain some XHTML markup, including references to other web resourses, including another comments, blogs or blog posts. 2.2.2 Globally unique identifier Globaly unique identifier is created by site where comment was originally posted. It MUST contain hostname of the originating site and some string which ensures uniqueness among other comments originatig to this site 2.2.3 Blog, where comment was posted to Original URL of blog where comment belong 2.2.4 Blog post where comment was posted to Permanent URL of blog post on its originating site. This URLs are always included into RSS/Atom feeds, so any mirror site would have no problem determining this URL 2.2.5 Original posting date Timestamp with precision of second when comment is posted Also comments might have following OPTIONAL properities 2.2.6 Author URL of verified user identitity of user, who submitted this comment. If idenitity was provided via OpenID or similar protocol, it MUST have form of URL. If user authenticated on the site, where comment was submitted, directly it SHOULD be OpenID URL which would prove identity of this user to other sites. Sites participating in this protocol MAY allow anonymous comments. If comment is anonymous, Author property MUST be omitted from this comment. 2.2.7 Modification time If comment was changed after its initial submission, it MUST contain additional timestamp specifying last change date. Servers conforming to this protocol SHOULD allow comment author to change comments. There is one special case - deletion of comments. Either comment author or owner of blog, i.e. user with same identity as blog url SHOULD be able to delete any comments in his blog. 2.2.8 Reference to parent comment If site allows to comment on another comment in the blog entry, not only blog entry itself, unique identificator of parent comment SHOULD be recorded as comment property. If this proprerty is absent, any server, recieving this comment, SHOULD assume that it is made on blog entry itself. 3. Comment exchange protocol 3.1 URL structure Any site participating in this protocol should provide following web resouces: 3.1.1. Blog list Page which lists blogs, which can be commented on this site. This page lists all blogs either originated on this site or retrieved and cached from other sites. This page should have content type text/plain and list blog URLs one per line 3.1.2. Comment list If URL consisting of BLOG list URL, slash ("/") and blog URL is requested via HTTP GET method, it should return text/plain list of recent comments (most recent first) in the form timestamp whitespace comment-id one per line, where timestamp is an integer number of seconds since Unix epoch (1-1-1970 00:00 GMT). If this URL is requested with skip=number parameter (i.e. appended with question mark, workd skip equal sign and number), it should return list of more earlier comments. 3.1.3 Comments itself If URL described in 3.1.2 is requested via POST method and POST request body has content type text/plain and consists of list of comment identifiers, separated by newlines, it should return text/xml data containing specified comments using XML schema described in the section 4 of this document. Comments MAY be ordered either earliest first or in order listed in the request. Any conforming implementation sending the request SHOULD send identifiers of requested comments from earliest to latest. 3.1.4 Posting notification Conforming implementation should understand request to the URL 3.1.1 either by POST by or GET method, which contains parameter notify=blog-URL. This request means that site sending this request wants to notify this site that it have new comments on the specified blog. If blog-URL doesn't belong to this site, it MAY respond to this request with 406 (Not Acceptable) HTTP response code. Otherwise it should respond with 200 response and immediately initiate procedure of recieving comment from the site which sent request. Conforming implementation SHOULD send notify requests only if comment was posted on the site to the blog originating on the site where request is sent, unless it is behind firewall or proxy. In this case it MAY send such requests for each blog commented on it to some relay site, if permitted by the relay site administrator. If notifying site is behind NAT or firewall and connection cannot to it cannot be stablished, reverse protocol described in section 3.3.3 could be used. 3.2 Declaring support of this protocol 3.2.1 Declaring support in the protocol on the blog page Each site which supports this protocol SHOULD add link tag to its blog pages with rel="comment-exchange" and href pointing to URL, described in the section 3.1.1. 3.2.2 Declaring protocol URL during comment exchange. Each site which performs comment exchange procedure should provide its peers means to retrieve comments from it. This is done by adding custom HTTP header X-Comment-Exchange-URL to all requests to protocol pages. This header should contain URL of page described in 3.1.1, and host name in this URL MUST resolve to the same IP address request is made from. 3.3. Connect exchange procedure 3.3.1 Procedure initiation. Site supporting this protocol SHOULD check presense of link rel=comment-exchange on all sites it retrieves blog entries via RSS/Atom. If this link is found it MAY periodically initiate comment exchange procedure with these sites. It also MAY initiate this procedure with any site which was known to initiate this protocol with it before. If 404 NOT FOUND HTTP response code is recieved when requesting URL 3.1.1, this site SHOULD be removed from the list of polled sites until either explicit user interaction or first protocol session initiated from that site. 3.3.2 Normal (PULL) procedure 1. Site requests lists of blogs from URL 3.1.1 2. For each blog interesting to this site, list of available comments is requesed from URL 3.1.2. If site has reasonable expectations that it can miss some comments, which are not listed on first page, request page multiple times using skip parameter. 3. Prepare list of missing comments, earliest first and send it to site 4. Repeat steps 2,3 for each blog copy of each is carried on this site. 3.3.3. Reverse (PUSH) procedure 1. Send notify request (3.1.4) using POST method with list of available comments as specified in 3.1.3 in the POST body. 2. Recieve list of requested comments as text/plain resoponse to the POST request. 3. Send XML stream of the comments using POST request to the same URL with content type text/xml 4. Repeat steps 1-4 for each blog comments for which are to be pushed to this site. when using PUSH method X-Comment-Exchange-URL header MAY be omitted. 4. Comment stream XML format 4.1 Comment stream XML document have root node. Contents of this stream is sequence of element. 4.2 Comment element should contain following elements unique-identifier blog-URL post-URL unique-identifier url date date text of comment with optional XHTML markup Some of this elements are OPTIONAL (see section ). 4.3. Comment deletion If comment element contain element and element contains either same URL as original comment with same or URL of blog, comment belongs to, comment with given identifier should be removed from the user's view, but deletion notice retained in the database in case that same comment would be sent from other site which didn't have recieved deletion message yet. 4.4 Banning user from commenting. If comment element contains element identity URL instead of body or along with element, and comment author identity is same as identity of blog it belongs to, it means that user with given identity should no more be allowed to comment in this blog, and any existing comments from this user should not be offered to other sites, requesting comments using this protocol, even if these comments has earlier timestamp than ban notice. 4.5 Removing ban If comment element contain element identity URL than previously set ban should be removed. 5. Full Copyright Statement Would write it if document is to be submitted to the IETF as RFC draft