pubsubhubbub-core-0.4.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!-- For editing this, see: http://xml.resource.org/public/rfc/html/rfc2629.html
 In a nutshell,
 $ sudo apt-get install xml2rfc
 $ xml2rfc pubsubhubbub-core-0.1.xml pubsubhubbub-core-0.1.html
-->
<rfc category="info" docName="pubsubhubbub-core-0.4.xml" ipr="trust200902">
    <?rfc toc="yes" ?>
    <?rfc tocdepth="2" ?>
    <?rfc symrefs="yes" ?>
    <?rfc sortrefs="yes"?>
    <?rfc strict="no" ?>
    <?rfc iprnotified="no" ?>
    <?rfc private="Draft" ?>
    <front>
        <title>PubSubHubbub Core 0.4 -- Working Draft</title>
        <author fullname="Brad Fitzpatrick" initials="B." surname="Fitzpatrick">
            <organization>Google, Inc</organization>
            <address>
                <email>brad@danga.com</email>
            </address>
        </author>
        <author fullname="Brett Slatkin" initials="B." surname="Slatkin">
            <organization>Google, Inc</organization>
            <address>
                <email>bslatkin@gmail.com</email>
            </address>
        </author>
        <author fullname="Martin Atkins" initials="M." surname="Atkins">
            <organization>Six Apart Ltd.</organization>
            <address>
                <email>mart@degeneration.co.uk</email>
            </address>
        </author>
        <author fullname="Julien Genestoux" initials="J." surname="Genestoux">
            <organization>Notifixious Inc.</organization>
            <address>
                <email>julien@superfeedr.com</email>
            </address>
        </author>
        <date day="4" month="Feb" year="2014" />
        <abstract>
            <t>An open, simple, web-scale and decentralized pubsub protocol. Anybody can play.</t>
            <t>As opposed to more developed (and more complex) pubsub specs like <xref target="XEP-0060">Jabber Publish-Subscribe</xref> this spec's base profile (the barrier-to-entry to speak it) is dead simple. The fancy bits required for high-volume publishers and subscribers are optional. The base profile is HTTP-based, as opposed to XMPP (see more on this below).</t>
            <t>To dramatically simplify this spec in several places where we had to choose between supporting A or B, we took it upon ourselves to say "only A", rather than making it an implementation decision.</t>
            <t>We offer this spec in hopes that it fills a need or at least advances the state of the discussion in the pubsub space. Polling sucks. We think a decentralized pubsub layer is a fundamental, missing layer in the Internet architecture today and its existence, more than just enabling the obvious lower latency feed readers, would enable many cool applications, most of which we can't even imagine. But we're looking forward to decentralized social networking.</t>
        </abstract>
    </front>
    <middle>
        <section title="Notation and Conventions">
            <t>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 <xref target="RFC2119"></xref>. Domain name examples use <xref target="RFC2606"></xref>.</t>
        </section>
        <section title="Definitions">
            <t>
                <list style="hanging">
                    <t hangText="Topic:">An <xref target="RFC2616">HTTP</xref> resource URL. The unit to which one can subscribe to changes. </t>
                    <t hangText="Hub (&quot;the hub&quot;):">The server (<xref target="RFC3986">URL</xref>) which implements both sides of this protocol. Any hub MAY implement its own policies on who can use it.</t>
                    <t hangText="Publisher:">An owner of a topic. Notifies the hub when the topic feed has been updated. As in almost all pubsub systems, the publisher is unaware of the subscribers, if any. Other pubsub systems might call the publisher the "source".</t>
                    <t hangText="Subscriber:">An entity (person or program) that wants to be notified of changes on a topic. The subscriber must be directly network-accessible and is identified by its Subscriber Callback URL.</t>
                    <t hangText="Subscription:">A unique relation to a topic by a subscriber that indicates it should receive updates for that topic. A subscription's unique key is the tuple (Topic URL, Subscriber Callback URL). Subscriptions may (at the hub's decision) have expiration times akin to DHCP leases which must be periodically renewed.</t>
                    <t hangText="Subscriber Callback URL:">The <xref target="RFC3986">URL</xref> at which a subscriber wishes to receive notifications.</t>
                    <t hangText="Event:">An event that causes updates to multiple topics. For each event that happens (e.g. "Brad posted to the Linux Community."), multiple topics could be affected (e.g. "Brad posted." and "Linux community has new post"). Publisher events cause topics to be updated and the hub looks up all subscriptions for affected topics, sending out notifications to subscribers.</t>
                    <t hangText="Notification:">A payload describing how a topic's contents have changed, or the full updated content. Depending on the topic's content type, the difference (or "delta") may be computed by the hub and sent to all subscribers.</t>
                </list>
            </t>
        </section>
        <section title="High-level protocol flow">
            <t>(This section is non-normative.)</t>
            <t>
                <list style="symbols">
                    <t>Publishers notify their hub(s) URLs when their topic(s) change.</t>
                    <t>Subscribers POST to one or more of the advertised hubs for a topic they're interested in. Alternatively, some hubs may offer auto-polling capability, to let {their,any} subscribers subscribe to topics which don't advertise a hub.</t>
                    <t>The hub caches minimal metadata (id, data, entry digest) about each topic's previous state. When the hub re-fetches a topic feed (on its own initiative or as a result of a publisher's ping) and finds a delta, it enqueues a notification to all registered subscribers.</t>
                </list>
            </t>
        </section>
        <section anchor="discovery" title="Discovery">
            <t>A potential subscriber initiates discovery by retrieving (GET or HEAD request) the topic to which it wants to subscribe. The <xref target="RFC2616">HTTP</xref> response from the publisher MUST include at least one <xref target="RFC5988">Link Header</xref> with <spanx style="verb">rel=hub</spanx> (a hub link header) as well as exactly one <xref target="RFC5988">Link Header</xref> with <spanx style="verb">rel=self</spanx> (the self link header). The former MUST indicate the exact URL of a PubSubHubbub hub designated by the publisher. If more than one URL is specified, it is expected that the publisher pings each of these URLs, so the subscriber may subscribe to one or more of these. The latter will point to the permanent URL for the resource being polled.</t>
            <t>In the absence of <xref target="RFC2616">HTTP</xref> Link headers, subscribers MAY fall back to other methods to discover the hub(s) and the canonical URI of the topic. If the topic is an XML based feed, it MAY use embedded link elements as described in Appendix B of <xref target="RFC5988">Web Linking</xref>. Similarly, for HTML pages, it MAY use embedded link elements as described in Appendix A of <xref target="RFC5988">Web Linking</xref>. Finally, publishers MAY also use the <xref target="RFC5785">Well-Known Uniform Resource Identifiers</xref> .host-meta to include the &lt;Link&gt; element with rel="hub".</t>
        </section>
        <section anchor="subscribing" title="Subscribing and Unsubscribing">
            <t>Subscribing to a topic URL consists of four parts that may occur immediately in sequence or have a delay.</t>
            <t>
                <list style="symbols">
                    <t>Requesting a subscription using the hub</t>
                    <t>Validating the subscription with the publisher (OPTIONAL)</t>
                    <t>Confirming the subscription was actually desired by the subscriber</t>
                    <t>Periodically reconfirming the subscription is still active (OPTIONAL)</t>
                </list>
            </t>
            <t>Unsubscribing works in the same way, except with a single parameter changed to indicate the desire to unsubscribe. Also, the Hub will not validate unsubscription requests with the publisher.</t>
            <section title="Subscriber Sends Subscription Request">
                <t>Subscription is initiated by the subscriber making an <xref target="RFC2616">HTTPS</xref> or <xref target="RFC2616">HTTP</xref> POST request to the hub URL. This request has a Content-Type of <spanx style="verb">application/x-www-form-urlencoded</spanx> (described in Section 17.13.4 of <xref target="W3C.REC-html401-19991224" />) and the following parameters in its body:</t>
                <t>
                    <list style="hanging">
                        <t hangText="hub.callback">REQUIRED. The subscriber's callback URL where notifications should be delivered. It is considered good practice to use a unique callback URL for each subscription.</t>
                        <t hangText="hub.mode">REQUIRED. The literal string "subscribe" or "unsubscribe", depending on the goal of the request.</t>
                        <t hangText="hub.topic">REQUIRED. The topic URL that the subscriber wishes to subscribe to or unsubscribe from.</t>
                        <t hangText="hub.lease_seconds">OPTIONAL. Number of seconds for which the subscriber would like to have the subscription active. Hubs MAY choose to respect this value or not, depending on their own policies. This parameter MAY be present for unsubscription requests and MUST be ignored by the hub in that case.</t>
                        <t hangText="hub.secret">OPTIONAL. A subscriber-provided secret string that will be used to compute an HMAC digest for <xref target="authednotify">authorized content distribution</xref>. If not supplied, the HMAC digest will not be present for content distribution requests. This parameter SHOULD only be specified when the request was made over <xref target="RFC2818">HTTPS</xref>. This parameter MUST be less than 200 bytes in length.</t>
                    </list>
                </t>
                <t>Subscribers MAY also include additional <xref target="RFC2616">HTTP</xref> request parameters, as well as <xref target="RFC2616">HTTP</xref> Headers if they are required by the hub.</t>
                <t>Hubs MUST ignore additional request parameters they do not understand.</t>
                <t>Hubs MUST allow subscribers to re-request subscriptions that are already activated. Each subsequent request to a hub to subscribe or unsubscribe MUST override the previous subscription state for a specific topic URL and callback URL combination once the action is verified. Any failures to confirm the subscription action MUST leave the subscription state unchanged. This is required so subscribers can renew their subscriptions before the lease seconds period is over without any interruption.</t>
                <section title="Subscription Parameter Details">
                    <t>The topic and callback URLs MAY use <xref target="RFC2616">HTTP</xref> or <xref target="RFC2818">HTTPS</xref> schemes. The topic URL MUST be the one advertised by the publisher during the discovery phase. (See <xref target="discovery"></xref>). Hubs MAY refuse subscriptions if the topic URL does not correspond to the one advertised by the publisher. The topic URL can otherwise be free-form following <xref target="RFC3986">the URI spec</xref>. Hubs MUST always decode non-reserved characters for these URL parameters; see section 2.4 on <spanx style="emph">"When to Encode or Decode"</spanx> in <xref target="RFC3986">the URI spec</xref>.</t>
                    <t>The callback URL MAY contain arbitrary query string parameters (e.g., <spanx style="verb">?foo=bar&amp;red=fish</spanx>). Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the <spanx style="verb">&amp;</spanx> (ampersand) character to join. Existing parameters with names that overlap with those used by verification requests will not be overwritten. For event notification, the callback URL will be POSTed to including any query-string parameters in the URL portion of the request, not as POST body parameters.</t>
                </section>
                <section title="Subscription Response Details">
                    <t>The hub MUST respond to a subscription request with an <xref target="RFC2616">HTTP</xref> 202 "Accepted" response to indicate that the request was received and will now be verified (<xref target="verifysub"></xref>) and validated (<xref target="validationsub"></xref>) by the hub. The hub SHOULD perform the verification and validation of intent as soon as possible.</t>
                    <t>If a hub finds any errors in the subscription request, an appropriate <xref target="RFC2616">HTTP</xref> error response code (4xx or 5xx) MUST be returned. In the event of an error, hubs SHOULD return a description of the error in the response body as plain text. Hubs MAY decide to reject some callback URLs or topic URLs based on their own policies (e.g., domain authorization, topic URL port numbers).</t>
                </section>
            </section>
            <section title="Subscription Validation" anchor="validationsub">
                <t>Subscriptions MAY be validated by the Hubs who may require more details to accept or refuse a subscription. The Hub MAY also check with the publisher whether the subscription should be accepted.</t>
                <t>If (and when), the subscription is accepted, the hub MUST perform the <xref target="verifysub">verification of intent</xref> of the subscriber. </t>
                <t>If (and when), the subscription is denied, the hub MUST inform the subscriber by sending an <xref target="RFC2616">HTTP</xref> GET request to the subscriber's callback URL as given in the subscription request. This request has the following query string arguments appended (format described in Section 17.13.4 of <xref target="W3C.REC-html401-19991224" />):</t>
                <t>
                    <list style="hanging">
                        <t hangText="hub.mode">REQUIRED. The literal string "denied".</t>
                        <t hangText="hub.topic">REQUIRED. The topic URL given in the corresponding subscription request.</t>
                        <t hangText="hub.reason">OPTIONAL. The hub may include a reason for which the subscription has been denied.</t>
                    </list>
                </t>
                <t>Hubs may provide an additional <xref target="RFC2616">HTTP</xref> Location header (as described in section 14.30 of <xref target="RFC2616">Hypertext Transfer Protocol</xref>) to indicate that the subscriber may retry subscribing to a different hub.topic. This allows for limited distribution to specific groups or users in the context of social web applications.</t>
                <t>The subscription MAY be denied by the hub at any point (even if it was previously accepted). The Subscriber SHOULD then consider that the subscription is not possible anymore.</t>
            </section>
            <section anchor="verifysub" title="Hub Verifies Intent of the Subscriber">
                <t>In order to prevent an attacker from creating unwanted subscriptions on behalf of a subscriber (or unsubscribing desired ones), a hub MUST ensure that the subscriber did indeed send the subscription request.</t>
                <t>The hub verifies a subscription request by sending an <xref target="RFC2616">HTTP</xref> GET request to the subscriber's callback URL as given in the subscription request. This request has the following query string arguments appended (format described in Section 17.13.4 of <xref target="W3C.REC-html401-19991224" />):</t>
                <t>
                    <list style="hanging">
                        <t hangText="hub.mode">REQUIRED. The literal string "subscribe" or "unsubscribe", which matches the original request to the hub from the subscriber.</t>
                        <t hangText="hub.topic">REQUIRED. The topic URL given in the corresponding subscription request.</t>
                        <t hangText="hub.challenge">REQUIRED. A hub-generated, random string that MUST be echoed by the subscriber to verify the subscription.</t>
                        <t hangText="hub.lease_seconds">REQUIRED/OPTIONAL. The hub-determined number of seconds that the subscription will stay active before expiring, measured from the time the verification request was made from the hub to the subscriber. Hubs MUST supply this parameter for subscription requests. This parameter MAY be present for unsubscribe requests and MUST be ignored by subscribers during unsubscription.</t>
                    </list>
                </t>
                <section title="Verification Details">
                    <t>The subscriber MUST confirm that the <spanx style="verb">hub.topic </spanx> corresponds to a pending subscription or unsubscription that it wishes to carry out. If so, the subscriber MUST respond with an HTTP success (2xx) code with a response body equal to the <spanx style="verb">hub.challenge</spanx> parameter. If the subscriber does not agree with the action, the subscriber MUST respond with a 404 "Not Found" response.</t>
                    <t>The hub MUST consider other server response codes (3xx, 4xx, 5xx) to mean that the verification request has failed. If the subscriber returns an <xref target="RFC2616">HTTP</xref> success (2xx) but the content body does not match the <spanx style="verb">hub.challenge</spanx> parameter, the hub MUST also consider verification to have failed.</t>
                    <t>Hubs MAY make the <spanx style="verb">hub.lease_seconds</spanx> equal to the value the subscriber passed in their subscription request but MAY change the value depending on the hub's policies. To sustain a subscription, the subscriber MUST re-request the subscription on the hub before <spanx style="verb">hub.lease_seconds</spanx> seconds has elapsed.</t>
                </section>
            </section>
        </section>
        <section anchor="publishing" title="Publishing">
            <t>The publisher MUST inform the hubs it previously designated when a topic has been updated. The hub and the publisher can agree on any mechanism, as long as the hub is eventually able send the updated payload to the subscribers.</t>
        </section>
        <section anchor="contentdistribution" title="Content Distribution">
            <t>A content distribution request is an <xref target="RFC2616">HTTP</xref> POST request from hub to the subscriber's callback URL with the payload of the notification. This request MUST have a <spanx style="verb">Content-Type</spanx> corresponding to the type of the topic. The hub MAY reduce the payload to a diff between two consecutive versions if its format allows it.</t>
            <t>The request MUST include a <xref target="RFC5988">Link Header</xref> with rel=hub pointing to the Hub as well as a <xref target="RFC5988">Link Header</xref> with rel=self set to the topic that's being updated. The Hub SHOULD combine both headers into a single <xref target="RFC5988">Link Header</xref>.</t>
            <t>The successful response from the subscriber's callback URL MUST be an <xref target="RFC2616">HTTP</xref> success (2xx) code. The hub MUST consider all other subscriber response codes as failures; that means subscribers MUST NOT use HTTP redirects for moving subscriptions. The response body from the subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications repeatedly until successful (up to some reasonable maximum over a reasonable time period). Subscribers SHOULD respond to notifications as quickly as possible; their success response code SHOULD only indicate receipt of the message, not acknowledgment that it was successfully processed by the subscriber.</t>
        </section>
        <section anchor="authednotify" title="Authenticated Content Distribution">
            <t>If the subscriber supplied a value for <spanx style="verb">hub.secret</spanx> in their subscription request, the hub MUST generate an HMAC signature of the payload and include that signature in the request headers of the content distribution request. The <spanx style="verb">X-Hub-Signature</spanx> header's value MUST be in the form <spanx style="verb">sha1=signature</spanx> where <spanx style="verb">signature</spanx> is a 40-byte, hexadecimal representation of a <xref target="RFC3174">SHA1 signature</xref>. The signature MUST be computed using the <xref target="RFC2104">HMAC algorithm</xref> with the request body as the data and the <spanx style="verb">hub.secret</spanx> as the key.</t>
            <t>When subscribers receive a content distribution request with the <spanx style="verb">X-Hub-Signature</spanx> header specified, they SHOULD recompute the SHA1 signature with the shared secret using the same method as the hub. If the signature does not match, subscribers MUST still return a 2xx success response to acknowledge receipt, but locally ignore the message as invalid. Using this technique along with <xref target="RFC2818">HTTPS</xref> for subscription requests enables simple subscribers to receive authenticated notifications from hubs without the need for subscribers to run an <xref target="RFC2818">HTTPS</xref> server.</t>
            <t>Please note however that this signature only ensures that the payload was not forged. Since the notification also includes headers, these should not be considered as safe by the subscriber, unless of course the subscriber uses <xref target="RFC2818">HTTPS</xref> callbacks.</t>
        </section>
    </middle>
    <back>
        <references title="References">
            <reference anchor="RFC2104">
                <front>
                    <title abbrev="HMAC">HMAC: Keyed-Hashing for Message Authentication</title>
                    <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
                        <organization>IBM, T.J. Watson Research Center</organization>
                    </author>
                    <author initials="M." surname="Bellare" fullname="Mihir Bellare">
                        <organization>University of California at San Diego, Dept of Computer Science and Engineering</organization>
                    </author>
                    <author initials="R." surname="Canetti" fullname="Ran Canetti">
                        <organization>IBM T.J. Watson Research Center</organization>
                    </author>
                    <date month="Feb" year="1997" />
                </front>
                <seriesInfo name="RFC" value="2104" />
            </reference>
            <reference anchor="RFC2606">
                <front>
                    <title>Reserved Top Level DNS Names</title>
                    <author fullname="D. Eastlake" initials="D.E" surname="Eastlake">
                        <organization />
                    </author>
                    <author fullname="A. Panitz" initials="A.P" surname="Panitz">
                        <organization />
                    </author>
                    <date month="Jun" year="1999" />
                </front>
                <seriesInfo name="RFC" value="2606" />
            </reference>
            <reference anchor="RFC2119">
                <front>
                    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
                    <author fullname="Scott Bradner" initials="B.S" surname="Bradner">
                        <organization>Alis Technologies</organization>
                    </author>
                    <date month="Mar" year="1997" />
                </front>
                <seriesInfo name="RFC" value="2119" />
            </reference>
            <reference anchor="RFC2616">
                <front>
                    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
                    <author fullname="R. Fielding" initials="R.F" surname="Fielding">
                        <organization>UC Irvine</organization>
                    </author>
                    <author fullname="J. Gettys" initials="J.G" surname="Gettys">
                        <organization>Compaq/W3C</organization>
                    </author>
                    <author fullname="J. Mogul" initials="J.M" surname="Mogul">
                        <organization>Compaq</organization>
                    </author>
                    <author fullname="H. Frystyk" initials="H.F" surname="Frystyk">
                        <organization>W3C/MIT</organization>
                    </author>
                    <author fullname="L. Masinter" initials="L.M" surname="Masinter">
                        <organization>Xerox</organization>
                    </author>
                    <author fullname="P. Leach" initials="P.L" surname="Leach">
                        <organization>Microsoft</organization>
                    </author>
                    <author fullname="T. Berners-Lee" initials="T.L" surname="Berners-Lee">
                        <organization>W3C/MIT</organization>
                    </author>
                    <date month="Jun" year="1999" />
                </front>
                <seriesInfo name="RFC" value="2616" />
            </reference>
            <reference anchor="RFC2818">
                <front>
                    <title>HTTP Over TLS</title>
                    <author initials="E." surname="Rescorla" fullname="E. Rescorla">
                        <organization />
                    </author>
                    <date year="2000" month="May" />
                    <abstract>
                        <t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.This memo provides information for the Internet community.</t>
                    </abstract>
                </front>
                <seriesInfo name="RFC" value="2818" />
                <format type="TXT" octets="15170" target="ftp://ftp.isi.edu/in-notes/rfc2818.txt" />
            </reference>
            <reference anchor="RFC5988">
                <front>
                    <title>Web Linking</title>
                    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
                        <organization />
                    </author>
                    <date year="2010" month="October" />
                    <abstract>
                        <t>This document specifies relation types for Web links, and defines a registry for them.It also defines the use of such links in HTTP headers with the Link header field.</t>
                    </abstract>
                </front>
                <seriesInfo name="RFC" value="5988" />
                <format type="TXT" target="http://tools.ietf.org/rfc/rfc5988.txt" />
            </reference>
            <reference anchor="RFC3174">
                <front>
                    <title>US Secure Hash Algorithm 1 (SHA1)</title>
                    <author initials="D." surname="Eastlake" fullname="D. Eastlake">
                        <organization />
                    </author>
                    <author initials="P." surname="Jones" fullname="P. Jones">
                        <organization />
                    </author>
                    <date year="2001" month="September" />
                    <abstract>
                        <t>The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community.This memo provides information for the Internet community.</t>
                    </abstract>
                </front>
                <seriesInfo name="RFC" value="3174" />
                <format type="TXT" octets="35525" target="ftp://ftp.isi.edu/in-notes/rfc3174.txt" />
            </reference>
            <reference anchor="RFC3986">
                <front>
                    <title>Uniform Resource Identifiers (URI): Generic Syntax</title>
                    <author fullname="T. Berners-Lee" initials="T.L" surname="Berners-Lee">
                        <organization />
                    </author>
                    <date year="2005" month="Jan" />
                </front>
                <seriesInfo name="RFC" value="3986" />
            </reference>
            <reference anchor="RFC5785">
                <front>
                    <title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
                    <author fullname="M. Nottingham" initials="M.N" surname="Nottingham">
                        <organization />
                    </author>
                    <author fullname="E. Hammer-Lahav" initials="E.H.L" surname="Hammer-Lahav">
                        <organization />
                    </author>
                    <date year="2010" month="Apr" />
                </front>
                <seriesInfo name="RFC" value="5785" />
            </reference>
            <reference anchor="W3C.REC-html401-19991224" target="http://www.w3.org/TR/1999/REC-html401-19991224">
                <front>
                    <title>HTML 4.01 Specification</title>
                    <author initials="D." surname="Raggett" fullname="David Raggett">
                        <organization />
                    </author>
                    <author initials="A." surname="Hors" fullname="Arnaud Le Hors">
                        <organization />
                    </author>
                    <author initials="I." surname="Jacobs" fullname="Ian Jacobs">
                        <organization />
                    </author>
                    <date month="December" day="24" year="1999" />
                </front>
                <seriesInfo name="World Wide Web Consortium Recommendation" value="REC-html401-19991224" />
                <format type="HTML" target="http://www.w3.org/TR/1999/REC-html401-19991224" />
            </reference>
            <reference anchor="XEP-0060">
                <front>
                    <title>Publish-Subscribe</title>
                    <author initials="P." surname="Millard" fullname="Peter Millard">
                        <organization />
                    </author>
                    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
                        <organization />
                    </author>
                    <author initials="R." surname="Meijer" fullname="Ralph Meijer">
                        <organization />
                    </author>
                    <date month="Jul" day="12" year="2010" />
                </front>
                <seriesInfo name="XSF XEP" value="0060" />
                <format type="HTML" target="http://www.xmpp.org/extensions/xep-0060.html" />
            </reference>
        </references>
        <section title="Specification Feedback">
            <t>Feedback on this specification is welcomed via the PubSubHubbub W3C Community Group.For more information, see <eref target="http://www.w3.org/community/pubsub/">the W3C PubSubHubbub Community Group</eref>. </t>
        </section>
    </back>
</rfc>