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.
