V. Wagner March,2008 Distributed Blog Commenting Protocol 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 aggregator to exchange the comments, made by users to the blog entries either originating on this site or received 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 themselves 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 Requirements 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 similar 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 proprieties Each comment in the system which support this protocol MUST have following proprieties: 2.2.1 Comment text Fragment of the text which MAY contain some XHTML markup, including references to other web resources, including another comments, blogs or blog posts. 2.2.2 Globally unique identifier Globally 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 originating 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 properties 2.2.6 Author URL of verified user identity of user, who submitted this comment. If identity 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 propriety 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. 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 identifier of parent comment SHOULD be recorded as comment propriety. If this propriety is absent, any server, receiving 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 resources: 3.1.1. Blog list Page which lists blogs, which can be commented on this site 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. If this URL is requested with skip=number parameter (i.e. appended with question mark, word "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 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 receiving 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 established, 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 presence 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 received 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 requested 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. Receive list of requested comments as text/plain response 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 received 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