Alkis, You are perfectly right. I just changed that. https://github.com/pubsubhubbub/PubSubHubbub/blob/master/pubsubhubbub-core-0.4.xml#L176
Thanks for your input! julien On Wed, May 30, 2012 at 10:12 AM, Alkis Evlogimenos <[email protected]>wrote: > Hello Julien. > > In section 4 (discovery), I believe it is best to avoid explicit > mentioning of Atom or RSS and instead mention them indirectly as XML > formats. The way the section is currently worded, suggests that sitemaps > (for example) can only be discovered through link headers, but this is > problematic since link headers are not always an option for webmasters. > > Current text: > >> In the absence of HTTP 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 a Atom or RSS feed, it MAY use embedded link elements as described >> in Appendix B of Web Linking [RFC5988]. Similarly, for HTML pages, it MAY >> use embedded link elements as described in Appendix A of Web Linking >> [RFC5988]. Finally, publishers MAY also use the Well-Known Uniform Resource >> Identifiers [RFC5785] .host-meta to include the <Link> element. > > > Proposal: > >> In the absence of HTTP 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 Web Linking [RFC5988]. Similarly, for HTML >> pages, it MAY use embedded link elements as described in Appendix A of Web >> Linking [RFC5988]. Finally, publishers MAY also use the Well-Known Uniform >> Resource Identifiers [RFC5785] .host-meta to include the <Link> element. > > > Cheers, > > On Thursday, May 3, 2012 7:43:18 PM UTC+2, Julien wrote: >> >> Blaine, >> Not sure what you mean, but I had previously updated the file there : >> http://superfeedr-misc.s3.**amazonaws.com/pubsubhubbub-**core-0.4.html<http://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html> >> >> Feel free to send your changes here, and I'll make sure I reflect them >> there :) >> >> Ju >> >> On Wed, May 2, 2012 at 5:15 PM, Blaine Cook <[email protected]> wrote: >> >>> On 2 May 2012 14:01, Julien Genestoux <[email protected]> >>> wrote: >>> > All, >>> > I just pushed an updated version of this draft. >>> > It now includes the following (minor) points: >>> > - Comments/Fixes by Walter Groix, >>> > - Symetric "accepted" and "denied" when the hubs validates the >>> subscription >>> > - Use of From header (based on Blaine's feedback) >>> > - Use of Location header when "denied" to indicate that another >>> > - Allowing for discovery thru host-meta well known url. >>> > >>> > Please, feel free to review and submit any change that is appropriate. >>> >>> This sounds awesome, Julien! >>> >>> My comments: >>> >>> – I'd suggest the following text for §4❡2 (major change is to use >>> RFC6415 explicitly): >>> >>> "In the absence of HTTP Link headers, subscribers SHOULD fall back to >>> other methods to discover the hub(s) and the canonical URI of the >>> topic. If the topic is a Atom or RSS feed, the publisher MAY provide >>> embedded link elements as described in Appendix B of Web Linking >>> [RFC5988], and the subscriber SHOULD use those links as per Appendix B >>> of [RFC5988]. Similarly, for HTML pages, the publisher MAY use >>> embedded link elements as described in Appendix A of Web Linking >>> [RFC5988], and subscribers SHOULD use those links as per Appendix A of >>> [RFC5988]. Finally, publishers MAY also use Web Host Metadata >>> [RFC6415] to include the <Link> element with a rel-value equal to >>> "hub" as with the other approaches; publishers SHOULD provide the JSON >>> variant of [RFC6415]. Subscribers SHOULD support this method for >>> discovery. >>> >>> OOPS. >>> >>> I started reading the spec at the link you posted and realised that >>> it's not the updated one at all. I don't know if the above comment >>> stands, but I'll hold off until the link is updated. :-) >>> >>> b. >>> >> >>
