Review for Proposed Recommendation
mkovatsc opened this issue · comments
Dear editors and authors
I read your Proposed Recommendation to see how it can be applied in our W3C Web of Things context for eventing. While I have no conclusion on this yet, here some comments -- here because it is easier than subscribing to a mailing first...
2: "Notification"
Throughout the document you only talk about "content distribution request“. Is it the same?
Should be harmonized then...
4.1: “MUST send content distribution requests with a matching content type of the topic URL”
Maybe you can make a short comment about content negotiation here, since that question popped up immediately while reading.
5: “If more than one URL is specified, it is expected that the publisher pings each of these URLs, so the subscriber may subscribe to one or more of these.”
"updates" or "notifies" would be better than "pings".
Why should a subscriber subscribe to "more of these"? It would be more interesting to know how to pick a hub out of this list (always first might not be optimal).
5.1: “mime-type“
Officially, they are called "Media Types" (RFC 6838), in particular when used in HTTP.
6: “Subscribing and Unsubscribing”
In the bullet point list, it is unclear who does what.
6.1.1: “For event notification, the callback URL will be POSTed to including any query string parameters in the URL portion of the request, not as POST body parameters.”
This "will be POSTed to" is very confusing, especially because it already needs creativity to remove the query part from a URL and put it somewhere else...
Proposal: "Event notifications are POST requests to the callback URL, including all query parameters given by the subscriber."
6.2: “MUST inform the subscriber by sending an HTTP [RFC7231] GET request to the subscriber's callback URL”
Suddenly no HTTPS? :)
Why not DELETE? That would make the semantics clearer, does not make REST people cringe, and implementations can still easily detect notification POSTs.
6.2: “to indicate that the subscriber may retry subscribing to a different hub.topic”
For me, it would only make sense to indicate a different hub for same topic if denied.
6.3: “The hub verifies a subscription request by sending an HTTP”
HTTPS? Depends on the callback URL scheme....
6.3: “Hubs MUST supply this parameter for subscription requests”
Subscription verification requests, no? Hubs do not send subscription requests...
7.1: “Subscription Migration”
Unclear how this should work and the text suddenly uses the term "clients". How should a subscriber learn about this? It discovers once on the publisher and then only communicates with the hub.
In 8 you write "A hub MAY use discovery from time to time to detect changes in a topic's canonical URL", which probably should read "A Subscriber MAY". This information is fundamental in 7.1, which itself would be better suited as a section 8.2.
8: "The request MUST include at least one Link Header"
I am surprised by using Web Linking headers in a request. I cannot find a clear rule in RFC 5988 and have not checked other specifications yet that might do this. Is this allowed? I would guess that you at least need the "anchor" parameter, which sets the context to the resource URL. Has someone checked this, e.g., with Mark Nottingham?
8: "A hub MAY use discovery from time to time to detect changes in a topic's canonical URL"
"A Subscriber MAY", no?
Thanks for the notes! I'm going to split these out into separate issues so the discussion will be easier to follow. I'll link them all below and then close this issue when that's done.
These have been broken out into individual issues to be tracked separately. I'm going to close this issue and we will continue the discussion in the individual issues.