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' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!--
  For editting 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="20" month="June" year="2013" />

    <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.
          In the context of social web applications, it is considered good
          practice to include a From <xref
        target="RFC2616">HTTP</xref> header (as described in section 14.22
          of <xref target="RFC2616">Hypertext Transfer Protocol</xref>) to indicate
          on behalf of which user the subscription is being performed.
          </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 in a Self Link Header
          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>
        </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>
        </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>
        </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>
        </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>
        </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>
          </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>
        </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>