Hi Julien, I went through the 0.4 spec and wanted to ask a few questions:
*1.* There are a few 'url' and 'urls' scattered around. I think they should be changed to 'URL' and 'URLs' repectively. *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? *3. Section 5.1.* *Subscriber Sends Subscription Request* What is the rationale behind removing hub.verify request parameter? *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? Also, s/HTTP Query params/request parameters/. *5. Section 5.1.* *This header should indicate on behalf of which user the subscription is being performed.* The use of 'should' here is confusing because it's doesn't say that either party is supposed do something. I would rephrase it as follows: In the context of social web applications, it is considered good practice to include a From HTTP header (as described in section 14.22 of Hypertext Transfer Protocol [RFC2616]) to indicate on behalf of which user the subscription is being performed. *6. Section 5.1.1.* *The topic URL MUST be the one advertised by the publisher in a Hub Link Header Header during the discovery phase.* s/Hub Link/Self Link/ *7. Section 5.1.1.* *The topic URL can otherwise be free-form following the URI spec [RFC3986].* What does free-form mean here? *8. Section 5.2.* *Hub Verifies Intent of the Subscriber* What's the rationale behind removing hub.verify_token request parameter? *9. Section 5.2.1.* *Verification Details* Should the hub retry in case of 404? How about other errors? *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? *11. Section 5.2.2.* *If (and when), the subscription is accepted, the hub will inform the subscriber by sending an HTTP [RFC2616] GET request to the subscriber's callback URL as given in the subscription request.* The verb 'will' is not clear here. Perhaps, MUST? What worries me with this protocol is that hubs will issue two GET requests to the subscribers on each subscription. The alternative is to merge two requests into one: a. Subscriber sends subscription request. b. (optional) Hub validates request. c. If validation was performed and has failed, hub sends subscriber notification with hub.mode = "denied". d. Else, hub sends verification request to the subscriber. 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. 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". What do you think? *12. Section 5.3.* *Automatic Subscription Refreshing* This is the same as in the 0.3 spec, but still. Does this section apply onto to the case of infinite subscriptions? Or must hub also refresh finite submissions? And one more question. How should 404 be handled when renewing subscriptions? Should hub retry? Is it different from the initial verification request? Roman.
