Roman, Sorry for the late response. By the way, will you be at GoogleIO? I'd love to meet you in person! Please see below. I deleted some of the questions on which there was no more comments, for the sake of clarity.
On Tue, Jun 19, 2012 at 5:17 PM, Roman <[email protected]> wrote: > > >>> *2. Section 4.1*. *The subscriber's callback URL SHOULD be unique for >>> each subscription.* >>> >>> Why is it necessary? Why is it a good thing? >>> >> >> So, it's not necessary, (but my english nuances may be off). If it was >> necessary, I'd have put MUST. >> Now, it's good for a lot of reasons, the simplest one is a much better >> ability to debug things out. >> It is generally extremely convenient... >> > > I think it's better to leave it up to subscriber. As far as the hub is > concerned, there is no preference for unique URLs. And I can imagine simple > subscribers that work fine with the same callback for all topics. > Ok, I have removed the SHOULD, but I wanted to add a notice because it really makes everyone's life much easier, so did it. Let me know what you think. > *4. Section 5.1.* *Subscribers MAY also include additional HTTP Query >>> params, as well as HTTP Headers if they are required by the hub, or the >>> publisher.* >>> >>> By the publisher? Should the hub forward the headers and extra query >>> parameters to the publisher? >>> >> Yes, but that's outside of the spec (as the whole publihser <-> hub >> relationship). >> > > I think it's better to remove "or the publisher" because it's confusing. > Fixed. > > >> >>> *8. Section 5.2.* *Hub Verifies Intent of the Subscriber* >>> >>> What's the rationale behind removing hub.verify_token request parameter? >>> >> It's useless. (it was initially introduced to simplify the subscriber's >> ability to map verifications of intent with subscriptions... which can be >> easily done with different callbacks for each subscriptions.) >> > > Makes sense, although I expect most hubs to support hub.verify_token for > backward compatibility. > That's obviously fine. > > *9. Section 5.2.1.* *Verification Details* >>> >>> Should the hub retry in case of 404? How about other errors? >>> >> I don't think the hub should retry. My rationale behind this is that >> subscribers should be the ones to make sure their subscriptions go through >> fine... not the hub. >> > > I'm still not sure what's the best retry strategy here. No-retry policy > makes hub auto retries unreliable and pretty much useless. > Well, I don't think the hub should be the ont retrying, but yes, there should be retry, initiated by the subscriber... to make sure the subscription it wants have been performed. > - A simple subscriber makes a permanent subscription to > http://foo.com/atom.xml. > I thought we'd agreed to get rid of "permanent". > - The hub verifies the subscription and everything is fine. > - A week later hub decides to reverify the subscription, but unfortunately > the subscriber is temporarily down. > - The subscription is removed. > > This means every subscriber MUST resubscribe periodically. Maybe that's > not a bad thing, but the spec gives mixed signals. > I think it's a good thing. Subscribers should care, and not requiring to re-subscribe is a way of telling them they shouldn't care. I have found an incredible amount of garbage in the hubs we host, just because subscribers could subscribe "randomly" to feeds and not later about maintaining that list. That puts the "spam" burden on the hub... > > Also, retrying would cause security issues (it becomes easier to make >> DOS attacks for example). >> > > DOS can be mitigated by limiting the number of retries (for example, 3 > retries over 6 hours). > Agreed. > > *10. Section 5.2.2.* *The subscription may be intentionally 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.* >>> >>> What does 'intentionally denied' mean here? Could you explain? >>> >> Well, the hub should be allowed to deny a previously accepted >> subscription...even if the subscription hasn't issued a (re)subscription. >> The rationale is that the publisher or a hub may decide to ban a >> subscribers. That would happen for example with social applications: a user >> may 'block' another user from following them. >> > > Let's drop 'intentionally' from the spec. > > Also, s/may/MAY/. > > It's not clear what the last sentence means: *The Subscriber SHOULD then > consider that the subscription is not possible anymore.* Does it mean the > subscriber must not try to resubscribe? That would be weird. > Well, they can retry, but it's very likely that they will be denied... I just wanted to indicate that it was probably a waste of time to retry right away... > > >> >>> * >>> * >>> >> Also, it's reasonable to allow hubs to send notifications with hub.mode = >>> "denied" at any point, even after the subscription was set up and working >>> for a while. Then the flow can be simplified: >>> >>> a. Subscriber sends subscription request. >>> b. Hub sends verification request to the subscriber. If it fails, the >>> subscription is ignored. >>> c. (optional) Hub validates request at some point in the future. >>> d. If validation failed, hub sends subscriber notification with hub.mode >>> = "denied". >>> e. If validation succeeded, c-e can repeat. >>> >> >> That works too conceptually. However, in this case, I'm worried about >> 'mixed signals' :) >> As a subscriber may assume that the subscription is accepted, even though >> it was technically >> never accepted by the publisher... >> > >> >>> There doesn't seem to be a reason to notify subscriber with hub.mode = >>> "accepted". The subscriber can assume that the subscription is working >>> properly until it receives hub.mode = "denied". >>> >> I don't like that... because there is a 'silent failure' scenario here. >> If for some reason the hub goes down and never validates >> subscriptions/informs the subscriber of failed subscription, then the >> subscriber assumes that everything is fine. >> > > If you consider the fact that the hub may deny submissions at any point, > this situation isn't any different than this. > > Consider the following scenario: > - Subscriber subscribes to http://foo.com/atom.xml. > - Everything is fine, the subscriber is notified with hub.mode = > "accepted" or hub.mode = "subscribe". > - At some later point, the hub decides to deny the subscription. > [This is done by the hub sending a request to the susbcriber hub.mode=denied... which you seem to forget in your next point, if I understand correctly] > Now the subscriber thinks that everything is fine, although the > subscription is denied. It's exactly the same situation as the one you are > trying to avoid. > Why would the subscriber assume everything is fine since it received an explicit hub.mode=denied request from the hub? In the scenario you described, the hub never tells the subscriber whether the subscription was accepted/denied. I think every acceptance/denial should be explicit and the subscriber should never 'assume' either case. > > Also, hub that follows the second protocol from my suggestion isn't really > violating the first protocol. The hub may do validation after telling the > subscriber that submission is accepted because the hub is allowed to run > validation at any point. > > Does it make sense? > What's the first protocol? you lost me here :) We're slowly getting there I think! May I ask on what team at Google you're working on? Thanks,
