Pending websub issues

Hello,

I realize I should have sent this earlier but this slipped my mind :/
There are a couple remaining issues/comments about websub that I think the
group can help address (I expect we can discuss these in our dail-in today):

Unilateral unsubscription notifications #16
<https://github.com/w3c/websub/issues/16>
Tony is advocating for the hub to send an "unsubscription" confirmation to
subscribers. His goal here is that he can then implement completely
stateless subscribers by putting all the "burden" of keeping state on the
hub. This is a seducing approach but I also found when running Superfeedr
that we want "responsible" subscribers who also invest in their
subscriptions otherwise it becomes to cheap for them that they can "spam
subscribe" the hubs. I also believe this is against the security recos that
we make because this means the subscriber can never change the pattern they
use for subscriptions. We recommend the use of capability urls where the
'id' as no meaning or semantics. in his approach, the id would be an
encoded version of the secret + all the state required.

Updating previous subscriptions that have a hub.secret #47
<https://github.com/w3c/websub/issues/47>
Aaron will probably do a better job explaining his thoughts, but I think he
asks whether a subscription should be identified with just {topic,
callback} or {topic, callback, secret}. I think it is safer to use the
latter. So that if a hubs gets another request with the same {topic,
callback}, the hub should only map the 2 if the secret is provided and
identical. If not, the hub should consider this as another subscription and
behave as such.

Redirections during (un)subscription POSTs to a hub #73
<https://github.com/w3c/websub/issues/73>
The case exposed here is about a change of hub. A topic previously pointed
to a hub. Subscriptions on that hub exist and the publisher changes its hub
of choice.
I believe the way around it is short lived subscriptions thru leases. This
means that the subscriber has to check the resource 'regularly' (before the
lease expires) to find existing hubs. The recommendation then becomes that
the publisher pings the "old" hub for about 2 lease periods to make sure
that all past subscriptions have been moved to the new hub.

Change Notification versus Content Distribution #84
<https://github.com/w3c/websub/issues/84>
Azaroth is upset but I don't think we should change the behavior to allow
for a change in content-type. His last comment is "As the group has clearly
stated your unwillingness to engage in discussion, I see no reason to keep
the issue open." I think he's right: we should close.

Content-Type requirement and Content Negotiation #86
<https://github.com/w3c/websub/issues/86>
I am fine with Sandro's latest comment about saying rel=self url's MUST NOT
do con-neg in the spec. This leaves things simple.

I think the rest is ok. This is snow day in NYC and I am stuck at home.
Let's chat in 50 minutes!

Julien



--
Julien Genestoux,
http://ouvre-boite.com <http://twitter.com/julien51>

+1 (415) 830 6574
+33 (0)9 70 44 76 29