Roman,
On Thu, Aug 16, 2012 at 5:13 PM, Roman <[email protected]> wrote: > On Tue, Aug 14, 2012 at 4:12 PM, Roman <[email protected]> wrote: > >> On Mon, Aug 13, 2012 at 7:03 PM, Julien Genestoux < >> [email protected]> wrote: >> >>> 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 >>> >> >> Thanks! I'll read the whole spec carefully once again later this week. >> > > Here are a few minor nits. > > There are still some "url"s in the document which should be changed to > "URL"s. > > There is a missing space after one period. Search for ".Hubs". > > *5. Subscribing and Unsubscribing* > *...* > *Receiving an acknowledgement from the hub that the subscription was > accepted (OPTIONAL).* > > > This is no longer correct. This whole section needs to be updated. > Fixed. > > *5. Subscribing and Unsubscribing* > *...* > *Unsubscribing works in the same way, except with a single parameter > changed to indicate the desire to unsubscribe.* > > > It's different for unsubscribing because there is subscription > verification (the hub can't disallowed subscribers from unsubscribing if > they wish to). > Fixed. > > *5.1. Subscriber Sends Subscription Request* > *hub.topic REQUIRED. The topic URL that the subscriber wishes to > subscribe to.* > > > Should be "... to subscribe to or unsubscribe from." > Completed. > > *5.1.2. Subscription Response Details* > * > * > *The hub MUST respond to a subscription request with an HTTP 202 > "Accepted" response to indicate that the request was received and will now > be verified (Section 5.3) and validated (Section 5.2) by the hub. The hub > SHOULD perform the verification of intent as soon as possible.* > > > It's better to swap "verified" and "validated" to match the order in which > these two events will happen. Also the last sentence is misleading because > one might interpret it as a requirement to do verification before > validation. > Agreed... fixed. > > *5.2. Subscription Validation* > * > * > *If (and when), the subscription is denied, the hub MUST inform the > subscriber by sending an HTTP [RFC2616] GET request to the subscriber's > callback URL as given in the subscription request.* > > > GET request doesn't seem right. Should it be POST instead? Although then > it'll be inconsistent with the verification of intend request, which is > GET. What do you think? > I think GET is good and consistent. Technically, we are not posting anything, just indicating a status... > > *5.3.1. Verification Details* > * > * > *Hubs MAY make the hub.lease_seconds equal to the period the subscriber > passed in their subscription request but MAY change the value depending on > the hub's policies. To sustain a temporary subscription, the subscriber > MUST re-request the subscription on the hub before hub.lease_seconds > seconds has elapsed.* > > > s/period/value/ > Fixed. > > I would also remove the word "temporary". > Removed Thanks a bunch! I have started implementing all that on the Superfeedr hubs. Thanks, > Roman. >
