hub vs subscriber in section 8
aaronpk opened this issue · comments
@julien51 I need your help on this one, I'm not entirely sure what this sentence is trying to describe:
A hub MAY use discovery from time to time to detect changes in a topic's canonical URL and Hub URLs. Any such changes will cause changes to the Link headers sent in subsequent content distribution requests.
So, basically, above, we say the the hub "must include at least one Link Header [RFC5988] with rel=hub pointing to a Hub associated with the topic being updated. It must also include one Link Header [RFC5988] with rel=self set to the canonical URL of the topic being updated. [...]. All these URLs are those resulting from the discovery process (Section 3)."
Since the publisher -> relationship is not normalised, it is not obvious that the hub would perform a GET request to pull the data from the publishers (I know Google's hub does that, and I think swicthboard does too... but Superfeedr actually does not always: we also get fact pings from publishers sometimes). This means that it is the hubs's job to check that the values it probably caches for canonical URL and Hub URLs are still correct.
Upon re-reading this section, what's the purpose of the hub sending the Link headers anyway, seeing that the same paragraph says "The subscriber MUST NOT use these Link headers to identify the subscription".
We discussed this on today's call. We came to the conclusion that the sentence "A hub MAY use discovery from time to time..." was causing confusion because it is describing the publisher-to-hub relationship which is out of scope of the spec. We resolved to strike that sentence and replace it with a description of what it's actually trying to say. The section in the editor's draft now reads as follows:
The subscriber MUST NOT use these Link headers to identify the subscription corresponding to the content distribution request, because the Link headers are metadata associated with the topic content, not with any particular subscription. For example, the topic URL in the content distribution request may be different from the topic URL that was originally subscribed to.
Does this read better @mkovatsc, and @julien51 does this still match your intent of what the spec should say?
Works for me!