Roman, For some reason, I missed your email. I pushed the changes to the git repo: - https://github.com/pubsubhubbub/PubSubHubbub/commit/495bd334bf4fff3631641cbdbe4f65c5fedd9f42 - https://github.com/pubsubhubbub/PubSubHubbub/commit/779a7efb41dece7fad105883acc6269027bea969
Please see the latest version at: http://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html I'd love to have more people's feedback. I have had requests by several people that we should probably make the next version a 1.0. I don't care much about version numbers, but some people may assume the protocol is WIP for as long as it doesn't reach 1.0 Let me know! Julien On Tue, Jul 17, 2012 at 12:44 PM, Roman <[email protected]> wrote: > Hi Julien, > > On Thu, Jul 5, 2012 at 7:34 PM, Julien Genestoux < > [email protected]> wrote: > >> Sorry for the late response; >> > > Now it's my turn to apologize. > >> >>> 1. The hub can't blindly trust the self link from the feed because >>> it might point to a completely different content. Therefore, by default, >>> the hub shouldn't notify the http://*bar.com*/atom.xml subscriber. >>> Although if the hub is certain that http://*bar.com*/atom.xml >>> and http://*foo.com*/atom.xml are the same (security concern), it >>> may notify the subscriber. >>> >>> I disgaree, the hub should 'blindly' trust the self... Subscribers MUST >> subscribe to the self url, publishers MUST ping with the self url, and >> everything will work. If either fails, then things are expected to go wrong. >> > > I was thinking about the right behavior for the hub when either publisher > or subscriber use wrong topic URL; I think I get it now. I agree with your > position on this. > > Permanent subscriptions require retries of subscription verification >>> requests because without retries they can't be relied upon and subscribers >>> will have to issue resubscription requests on their own. So if we allow >>> permanent subscriptions, we also must require the hub to retry subscription >>> verification requests. >>> >> I thought we agreed on forgetting about "permanent" subscriptions. In >> practice, some subscriptions may me infinite, but just because they are >> renewed by the subscriber before they expire. >> > > Sorry for the confusion, I didn't mean to say that permanent subscriptions > should be restored. I agree that they shouldn't be in the spec. > > I also think that section Automatic Subscription Refreshing should be > removed because it makes sense only w.r.t. the permanent subscriptions. > > Subscription protocol A: >>> >>> - Hub receives a subscription request. >>> - It validates the subscription (is this subscriber allowed to >>> subscribe?). If validation fails, it notifies the subscriber. >>> - The hubs issues a subscription verification request to verify the >>> intent of the subscriber. If it fails, the subscription request is >>> ignored. >>> - The subscription is marked as validated. The subscriber starts >>> receiving content updates. >>> >>> Subscription protocol B: >>> >>> - Hub receives a subscription request. >>> - It issues a subscription verification request. If it fails, the >>> subscription request is ignored. >>> - The hub validates the subscription. If validation fails, it >>> notifies the subscriber. >>> - The subscription is marked as validated. The subscriber starts >>> receiving content updates. >>> >>> Both protocols also have a separate background process that can >>> invalidate any subscription at any moment (described at the start of this >>> section). >>> >>> First of all, please note that protocol B is simpler for the subscriber: >>> the subscriber is guaranteed to receive a subscription verification request >>> from the hub after sending a subscription request. >>> >> true. >> >>> In protocol A this is not the case: the subscriber can also receive the >>> deny notification instead. In both protocols the subscriber can receive a >>> deny notification after the verification request. >>> >>> >> >>> Protocol A, while being more complex, doesn't have any advantages that I >>> can see. It may look like it gives the subscriber more information, but >>> it's not actually the case. In both protocols there is a period of time >>> when the hub considers a subscription invalid but the subscriber doesn't >>> know about it yet. >>> >>> *My suggestion*: pick protocol B. >>> >> >> I understand your point better now: in other words, if the subscription >> is not denied, then it is considered as accepted. My only concern with B, >> is that there is a time (between the verification request) and the first >> notification where the subscriber doesn't know if he is going to get data >> or not. >> I think this is bad, because it means that subscribers may do retries >> over and over again as they do not know if things are in place... >> We need a way to tell the subscriber that the subscription is good. >> This is where the protocol A wins (for me at least!), because if the >> verification is successful, then the subscribers _knows_ the state of the >> subscription... >> > > I think I understand your point now. You are talking about applications > with graphical user interface where a user is subscribing to a feed and > wants to immediately see an error message or a confirmation. > > I'm fine with the protocol A described above. Could you update the spec to > reflect that? Section 5.2.2 Subscription Validation needs to be updated -- > the request with hub.mode = "accepted" is not needed. > > Roman. >
