W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

RE: Input on request for link relation

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Wed, 16 Sep 2009 17:51:27 -0700
To: Brett Slatkin <brett@haxor.com>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D57E5C@P3PW5EX1MB01.EX1.SECURESERVER.NET>

> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
> On Behalf Of Brett Slatkin
> Sent: Wednesday, September 16, 2009 7:37 AM

> I understand part of the motivation for mnot's draft
> (http://www.ietf.org/id/draft-nottingham-http-link-header-06.txt), but
> it doesn't remove the need for registered link relations. It seems
> that the litmus test for registration is whether the relation is
> "broadly useful".

I think it puts the burden on you to come up with a broadly useful *definition* to the relation type that will not limit it just for ATOM. Since you also indicated below that there is already talk about such ideas, this would not be a waste of your time.

You spec will then be putting limits on it in the context of specific protocols for clients that chose to adopt it.
> In that regard, it's important to note that PubSubHubbub is live for
> over 100 *million* feeds as of this writing. It is consumed by dozens
> of companies and developers from multiple countries. There are
> implementations of publisher and subscriber clients in many
> programming languages. There are even new companies with private
> investment running hubs. We've had the genie out of the bottle (since
> October 2008) and it's difficult to go back to ask everyone to change
> things now.

While I have sympathy for this argument as I have made it for OAuth (the answer was, compared to say, TCP or HTTP, OAuth is at best slightly adopted...), it both isn't that hard and not a reason for the web to get stuck with a poorly designed link. Now I am not arguing it is poorly design (I wouldn't know - I didn't read it yet), but just that this reason is not enough to formalize protocols when they are poorly design.
> Description: A URI for a "hub" (speaking the PubSubHubbub protocol)
> that enables clients to register for and publish real-time updates to
> the resource.

Why does it have to speak only that protocol? Is that a requirement? Are there other protocols?

Received on Thursday, 17 September 2009 00:53:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:42 UTC