Subject: Input on request for link relation

From: Lisa Dusseault <[email-masked]>
Date: Thu, 10 Sep 2009 10:30:13 -0700

Comments welcome on the following request

thx,
lisa

---
General Request for Assignments (link-relations)

Contact Name :
Brett Slatkin

Type of Assignment :
I want to add a new Atom Link Relation type for the PubSubHubbub protocol

(http://pubsubhubbub.googlecode.com). The relation type is "hub".

Registry :
http://www.iana.org/assignments/link-relations/link-relations.xhtml

Description :
The new  is used for discovery of Hubs,
which enables real-time notifications of entries in Atom and RSS feeds.
Without making the relation type official, we're not in compliance with the

Atom spec.

Additional Info :
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.1.html

---

From: Robert Sayre <[email-masked]>
Date: Thu, 10 Sep 2009 15:32:49 -0400

> Comments welcome on the following request

Looks good to me.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 10 Sep 2009 21:40:39 +0200

Lisa,

not sure the following it is appropriate to discuss this here, so  
please redirect me to the proper place if so.

Hubs are being discovered by clients by way of the 'hub' link  
relation. I am
concerned that the semantics of a hub resource (provided by the link  
relation
definition) are imposing obligations on the server that are contrary  
what one
would expect to see in the HTTP world.

Or in other words: I think that the assumptions a client makes about  
the behaviour
of a hub are too rigid. If a hub has more subscribers than it knows it  
can handle
it might well decide not to notify them. A situation like this is  
impossible to
prevent by the specification and I think the server should therefore  
explicitly be
given much more freedom regarding its behavior upon a ping.

Especially given the use of Atom which in a sense implies a very  
unconstrained
protocol.

(Sorry if this discussion is already going on elsewhere)

Jan

---

From: John Panzer <[email-masked]>
Date: Thu, 10 Sep 2009 16:31:32 -0700

Without getting into the appropriate discussion form question, what hub
resource semantics (and link relation definition) are you referring to
exactly?  I can't seem to find it, and it's hard to understand your
objection without it.

On Thu, Sep 10, 2009 at 12:40 PM, Jan Algermissen
<[email-masked]>wrote:

>
> Lisa,
>
> not sure the following it is appropriate to discuss this here, so please
> redirect me to the proper place if so.
>
> Hubs are being discovered by clients by way of the 'hub' link relation. I
> am
> definition) are imposing obligations on the server that are contrary what
> one
> Or in other words: I think that the assumptions a client makes about the
> behaviour
> of a hub are too rigid. If a hub has more subscribers than it knows it can
> handle

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 11 Sep 2009 01:57:48 +0200

On Sep 11, 2009, at 1:31 AM, John Panzer wrote:

> Without getting into the appropriate discussion form question, what  
> hub resource semantics (and link relation definition) are you  
> referring to exactly?  I can't seem to find it, and it's hard to  
> understand your objection without it.

Section 7.3 says:

"If, after a content fetch, the hub determines that the topic feed  
content has changed, the hub MUST send information about the changes  
to each of the subscribers to the topic."

I understand this to imply that subscribers expect the hub to  
definitely send the notifications. What if the hub decides not to due  
to the number of subscribers it has? Or to turn this around: how would  
a subscriber ever know whether not receiving notifications means that  
there are not updates or that the hub stopped sending notifications.

Jan

>
> On Thu, Sep 10, 2009 at 12:40 PM, Jan Algermissen <[email-masked] 
> > wrote:
>
> Lisa,
>
> of a hub are too rigid. If a hub has more subscribers than it knows  
> it can handle

---

From: Sam Johnston <[email-masked]>
Date: Fri, 11 Sep 2009 13:45:19 +0200

Jan et al,
In line with comments I've made in other threads I think it makes sense for
us to limit link relation discussions to the generic relation itself rather
than any specific implementation of it. I imagine the
pubsubhubbub<http://groups.google.com/group/pubsubhubbub>Google Group
(blind copied as it requires subscription to post) is the
appropriate forum for your [no doubt legitimate] concerns regarding the
protocol.

In terms of the relation, I think the description could be improved by
dropping references to entries, Atom and RSS. It is conceivable for example
that someone would want to be notified of an update to an HTML page (I'm
thinking about this currently for status updates to HTML renderings of
virtual machine resources) or indeed some other arbitrary resource. If we
[continue to] allow relations to be bound to protocols in spite of the
availability of content types and/or URI relations which are fit for the
purpose we're going to back ourselves into a corner before we know it.

Accordingly I propose the following description:

*Description: A URI for a "hub" that allows clients to register for
real-time updates to the resource.*

The PuSH(?) group may want to consider using a URI relation and/or dedicated
content type in addition to the generic "hub" relation.

Kind regards,

Sam

On Fri, Sep 11, 2009 at 1:57 AM, Jan Algermissen <[email-masked]>wrote:

> "If, after a content fetch, the hub determines that the topic feed content
> has changed, the hub MUST send information about the changes to each of the
> subscribers to the topic."
>
> I understand this to imply that subscribers expect the hub to definitely
> send the notifications. What if the hub decides not to due to the number of
> subscribers it has? Or to turn this around: how would a subscriber ever know
> whether not receiving notifications means that there are not updates or that
> the hub stopped sending notifications.
>
> Jan
>
>
>
>
>
>> On Thu, Sep 10, 2009 at 12:40 PM, Jan Algermissen <
>> [email-masked]> wrote:
>>
>> Lisa,
>>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Sep 2009 14:41:24 +0200

Hadrien Gardeur wrote:
> ...
> I agree. We need a better policy for rel values. Currently, it seems 
> that new rel values are added to the IANA link registry whenever a new 
> RFC is adopted. These relationships could have a much broader scope and 
> shouldn't be bound to particular protocols. 
> ...

<http://tools.ietf.org/html/draft-nottingham-http-link-header-06>.

BR, Julian

---

From: Kris Zyp <[email-masked]>
Date: Fri, 11 Sep 2009 07:04:02 -0600

Sam Johnston wrote:
> Jan et al,
>
> In line with comments I've made in other threads I think it makes
> sense for us to limit link relation discussions to the generic
> relation itself rather than any specific implementation of it. I
> imagine the pubsubhubbub
> <http://groups.google.com/group/pubsubhubbub> Google Group (blind
> copied as it requires subscription to post) is the appropriate forum
> for your [no doubt legitimate] concerns regarding the protocol.
>
> In terms of the relation, I think the description could be improved
> by dropping references to entries, Atom and RSS. It is conceivable
> for example that someone would want to be notified of an update to
> an HTML page (I'm thinking about this currently for status updates
> to HTML renderings of virtual machine resources) or indeed some
> other arbitrary resource. If we [continue to] allow relations to be
> bound to protocols in spite of the availability of content types
> and/or URI relations which are fit for the purpose we're going to
> back ourselves into a corner before we know it.
>
> /Description: A URI for a "hub" that allows clients to register for
> real-time updates to the resource./
>
> The PuSH(?) group may want to consider using a URI relation and/or
> dedicated content type in addition to the generic "hub" relation.
>
We (Dojo toolkit) have been using REST Channels [1] for clients to
receive real-time notifications of resource updates. Could/should we
use the "hub" relation for resources to reference the URI that
Dojo/clients connect to for updates? And if so it seems like "updates"
or "notifications" would be a more generic, fitting term than "hub"
(but "hub" isn't bad).

[1] http://cometdaily.com/2008/11/12/using-rest-channels-in-dojo/
Thanks,

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com

---

From: Sam Johnston <[email-masked]>
Date: Fri, 11 Sep 2009 15:17:46 +0200

On Fri, Sep 11, 2009 at 2:00 PM, Hadrien Gardeur <
[email-masked]> wrote:
>> In line with comments I've made in other threads I think it makes sense
>> for us to limit link relation discussions to the generic relation itself
>> rather than any specific implementation of it.
>
> Several relations would need a similar treatment.

Yes, though I believe Mark's "Web
Linking<http://tools.ietf.org/html/draft-nottingham-http-link-header>"
draft does this already.

> For example:
>>
>> edit: An IRI of an editable Member Entry. When appearing within an
>> atom:entry, the href IRI can be used to retrieve, update and delete the
>> Resource represented by that Entry.
>
> BTW, what would be the generic link relation to indicate an AtomPub
> collection (only the service document is registered at IANA) ?

I started thinking about this earlier in the week with a view to having e.g.
a representation of a bookshelf referring to a collection/feed/url-list/etc.
of books using rel="collection". I then started looking at
parent/child/sibling relationships which are currently being discussed in a
separate thread (my preference is for something like e.g. "rel=descendant
level=2" for grandchildren as I subsequently realised that suggested
abbreviations "asc" for ascendant and "desc" for descendant can be confused
with item ordering). Do you think these "family" relations serve all the use
cases for a "collection" relation?

> I agree. We need a better policy for rel values. Currently, it seems that
> new rel values are added to the IANA link registry whenever a new RFC is
> adopted. These relationships could have a much broader scope and shouldn't
> be bound to particular protocols.

Great. I don't think there's much contention over this point (at least I've
not yet seen any) and the draft spells out the requirements (which can be
summarised as "broadly useful") reasonably well:

> Commonly-used relation types with a clear meaning that are shared

across applications can be registered as tokens for convenience and

to promote reuse.  For example, "self" and "alternate" are registered

relation types, because they are broadly useful.

The registry also outlines the process which involves a dedicated expert and
public comment period:

6.2.  Link Relation Type Registry

>    This specification establishes the Link Relation Type Registry, and

   updates Atom [RFC4287] to refer to it in place of the "Registry of

   Link Relations".

>    The requirements for registered relation types are described in

   Section 4.1.

>    Relation types are registered on the advice of a Designated Expert

   (appointed by the IESG or their delegate), with a Specification

   Required (using terminology from [RFC5226]).

>    Registration requests consist of the completed registration template

   below, typically published in an RFC or Open Standard (in the sense

   described by [RFC2026], Section 7).  However, to allow for the

   allocation of values prior to publication, the Designated Expert may

   approve registration once they are satisfied that an RFC (or other

   Open Standard) will be published.

>    The registration template is:

>    o  Relation Name:

   o  Description:

   o  Reference:

   o  Notes: [optional]

>    Upon receiving a registration request (usually via IANA), the

   Designated Expert should request review and comment from the

   [email-masked] mailing list (or a successor designated by the

   APPS Area Directors).  Before a period of 30 days has passed, the

   Designated Expert will either approve or deny the registration

   request, communicating this decision both to the review list and to

   IANA.  Denials should include an explanation and, if applicable,

   suggestions as to how to make the request successful.

Ironically the apps-discuss list wasn't included so I am adding them now.
One nitpick about the process is that it seems a request can be denied with
a suggestion for another relation (for example we might prefer to use
something like "push" or "notif[y|ier|ication|ications" rather than "hub"
for this one) but then that would require restarting the process where it
should proceed to registration immediately if the change is accepted by the
applicant.

I also question the relevance of the "reference" field in the registry as
this links relations to implementations which I think we agree is a bad
thing - the registry should capture all the necessary semantics without
reliance on external references. It may be interesting to list zero or more
implementations of the relation (that is, make the "reference" field
optional as well and allow others to add themselves to it), however I'm not
sure the maintenance load is worth the effort.

Sam

---

From: Hadrien Gardeur <[email-masked]>
Date: Fri, 11 Sep 2009 12:01:37 +0000

> than any specific implementation of it.
>

For example:

*edit:* An IRI of an editable Member Entry. When appearing within an

Hadrien

---

From: Hadrien Gardeur <[email-masked]>
Date: Fri, 11 Sep 2009 13:43:00 +0000

>
> Yes, though I believe Mark's "Web Linking<http://tools.ietf.org/html/draft-nottingham-http-link-header>"
> draft does this already.

It does (Section 6.2).

> I started thinking about this earlier in the week with a view to having
> e.g. a representation of a bookshelf referring to a
> collection/feed/url-list/etc. of books using rel="collection". I then
> started looking at parent/child/sibling relationships which are currently
> being discussed in a separate thread (my preference is for something like
> e.g. "rel=descendant level=2" for grandchildren as I subsequently realised
> that suggested abbreviations "asc" for ascendant and "desc" for descendant
> can be confused with item ordering). Do you think these "family" relations
> serve all the use cases for a "collection" relation?
>

In AtomPub, a collection is defined as:

> A Resource that contains a set of Member Resources. Collections are
> represented as Atom Feeds.

Collections are used to indicate where you can POST a new entry in a Service
document, and what you can post is defined in app:accept:

> The content of an "app:accept" element value is a media range as defined in
> [RFC2616]. The media range specifies a type of representation that can be
> POSTed to a Collection.

In the current Web Linking draft, the edit relation is redefined (Refers to
a resource that can be used to edit the link's context.) but we still lack a
relation type for links where we can POST things (and we shouldn't use
"collection" for this purpose).
Since we can't use more than a single relation type for a link, it might be
complex to define something that is both a "collection" and a resource where
you can "post".

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Sep 2009 10:19:20 -0600

> or "notifications" would be a more generic, fitting term than "hub"

I like "updates" or "notifications" -- "hub" seems specific to
pubsubhubbub, whereas the pointer might be to a SIP notifications
service, an XMPP PubSub service, or who knows what.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Kris Zyp <[email-masked]>
Date: Fri, 11 Sep 2009 10:30:13 -0600

Peter Saint-Andre wrote:
>> We (Dojo toolkit) have been using REST Channels [1] for clients
>> to receive real-time notifications of resource updates.
>> Could/should we use the "hub" relation for resources to reference
>> the URI that Dojo/clients connect to for updates? And if so it
>> seems like "updates" or "notifications" would be a more generic,
>> fitting term than "hub" (but "hub" isn't bad).
>
Actually, didn't SIP already define a relation name of "monitor" (and
"monitor-group" for notification of resource changes [1]? Why wouldn't
we follow that precedent (pubsubhubbub could use "monitor" that
couldn't they?). Or does monitor/monitor-group imply something different?
[1]
http://tools.ietf.org/html/draft-roach-sip-http-subscribe-02#section-5.1

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Sep 2009 10:40:15 -0600

> http://tools.ietf.org/html/draft-roach-sip-http-subscribe-02#section-5.1

Good point, I had forgotten about that. We might as well re-use that.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Sam Johnston <[email-masked]>
Date: Fri, 11 Sep 2009 18:44:35 +0200

On Fri, Sep 11, 2009 at 6:30 PM, Kris Zyp <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Well spotted. For me to "monitor" or "watch" something requires conscious,
ongoing effort by the client. The dictionary
definition<http://www.google.fr/search?q=define:monitor>supports this:
'
*keep tabs on; keep an eye on; keep under surveillance; "we are monitoring
the air quality"; "the police monitor the suspect's moves"*'. It's a nitpick
but I wonder if there are use cases for a "monitoring" interface (e.g. for
polling) - for example a site offering a link that an uptime monitoring
service could use to to test the various subsystems, or an actual monitoring
service?

OTOH terms like "notify" and "push" imply a passive rather than active role
for the client ("update" is out because it can be confused with "edit" - in
that the resource itself is being updated).

Sam

---

From: Kris Zyp <[email-masked]>
Date: Fri, 11 Sep 2009 10:52:35 -0600

Sam Johnston wrote:
> On Fri, Sep 11, 2009 at 6:30 PM, Kris Zyp <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
> Actually, didn't SIP already define a relation name of "monitor"
> (and "monitor-group" for notification of resource changes [1]? Why
> wouldn't we follow that precedent (pubsubhubbub could use "monitor"
> that couldn't they?). Or does monitor/monitor-group imply something
>  different? [1]
> Well spotted. For me to "monitor" or "watch" something requires
> conscious, ongoing effort by the client. The dictionary definition
> <http://www.google.fr/search?q=define:monitor> supports this:
> '/keep tabs on; keep an eye on; keep under surveillance; "we are
> monitoring the air quality"; "the police monitor the suspect's
> moves"/'. It's a nitpick but I wonder if there are use cases for a
> "monitoring" interface (e.g. for polling) - for example a site
> offering a link that an uptime monitoring service could use to to
> test the various subsystems, or an actual monitoring service?
>
> OTOH terms like "notify" and "push" imply a passive rather than
> active role for the client ("update" is out because it can be
> confused with "edit" - in that the resource itself is being
> updated).
But SIP is not a polling protocol is it? Is there something about SIP
that is more "monitor-ish" than pubsubhubbub that necessitates a new
relation name? And if so, how do I determine which relation name
should be used for servers that connect to Dojo clients to send
notifications?

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Sep 2009 11:23:40 -0600

> should be used for servers that connect to Dojo clients to send

The 'rel' says only "this is the kind of place where you can receive
notifications about changes to the resource". That doesn't say *how* you
receive those notifications. If the URI is sip:foo then perhaps you need
to poll. If it's xmpp:bar then perhaps you receive pushes. But the "how"
doesn't change the fact that this is where you can get notifications.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Roach <[email-masked]>
Date: Fri, 11 Sep 2009 13:26:47 -0500

> should be used for servers that connect to Dojo clients to send

SIP uses RFC 3265 for these kinds of things. RFC 3265 allows for both 
polling and long-running subscriptions (although the polling isn't used 
anywhere near as often as the long-running subscriptions).

The intention of draft-roach-sip-http-subscribe-02 was that the 
"monitor" link relation was to be used for both polling *and* passive 
mechanisms. I don't want to get hung up too much on the term "monitor" 
and what it may or may not imply about who initiates the transaction 
that results in someone knowing about a change.

/a

---

From: John Panzer <[email-masked]>
Date: Fri, 11 Sep 2009 11:34:11 -0700

Jan -- The text you're concerned about is part of the draft protocol at
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#contentdistributionso
I think this is a (legitimate) question/critique of the draft spec and
should be taken up over at http://groups.google.com/group/pubsubhubbub.
(+Brett).

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Sep 2009 11:21:42 +1000

On 11/09/2009, at 11:17 PM, Sam Johnston wrote:

> One nitpick about the process is that it seems a request can be  
> denied with a suggestion for another relation (for example we might  
> prefer to use something like "push" or "notif[y|ier|ication| 
> ications" rather than "hub" for this one) but then that would  
> require restarting the process where it should proceed to  
> registration immediately if the change is accepted by the applicant.

Yes, but is the overhead really that onerous?

> I also question the relevance of the "reference" field in the  
> registry as this links relations to implementations which I think we  
> agree is a bad thing - the registry should capture all the necessary  
> semantics without reliance on external references. It may be  
> interesting to list zero or more implementations of the relation  
> (that is, make the "reference" field optional as well and allow  
> others to add themselves to it), however I'm not sure the  
> maintenance load is worth the effort.

Not to implementations, to the source documents for the registrations  
(which IANA likes to see in registries, AIUI, for paper trail etc).

It's true that the pre-populated entries have a lot of references to  
formats, but that's an artefact of history, not the direction we'll  
move in going forward.

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Sep 2009 16:15:58 +1000

In the current link draft, relations shouldn't have dependencies on  
the media types of what's linked to, and it looks like both the  
request and response content is constrained in this proposal.

Why not use an extension relation type (i.e., unregistered URL)  
instead of a registered one? That allows the protocol to define things  
much more closely, because it will "own" the relation type.

Cheers,

---

From: Sam Johnston <[email-masked]>
Date: Wed, 16 Sep 2009 11:46:47 +0200

On Wed, Sep 16, 2009 at 3:21 AM, Mark Nottingham <[email-masked]> wrote:

>  One nitpick about the process is that it seems a request can be denied
>> with a suggestion for another relation (for example we might prefer to use

Perhaps not, and there could well be some delay in acceptance if committees
are involved. My worry is that if we don't streamline our processes as much
as possible (see Ian's suggestion about IANA maintaining a
RelExtensions<http://wiki.whatwg.org/wiki/RelExtensions>style wiki)
then people will do as they please anyway - see rel="hub",
rev="canonical", etc.

> (which IANA likes to see in registries, AIUI, for paper trail etc).

Would it be possible then to support multiple references so that people can
see at a glance that a given relation is implemented as described in
multiple formats (rather than just the first format that happened to
register it)? May well not be worth the maintenance effort.

> formats, but that's an artefact of history, not the direction we'll move in
> going forward.

That being the case would it be worth proactively populating the registry
with common/obvious relations with a view to avoiding e.g. this "monitor" vs
"hub" duplication (which is presumably burnt into various implementations on
both sides)?

I'm specifically thinking here about a thread from a few months ago in which
we discussed different types of references to resources, with a view to
getting relations like 'canonical', 'latest', 'permalink' and 'shortlink'
into the registry. Perhaps a separate I-D is the best way to achieve this,

Sam

---

From: Sam Johnston <[email-masked]>
Date: Wed, 16 Sep 2009 12:13:35 +0200

On Wed, Sep 16, 2009 at 8:15 AM, Mark Nottingham <[email-masked]> wrote:

> In the current link draft, relations shouldn't have dependencies on the
> media types of what's linked to, and it looks like both the request and
> response content is constrained in this proposal.
>
> Why not use an extension relation type (i.e., unregistered URL) instead of
> a registered one? That allows the protocol to define things much more
> closely, because it will "own" the relation type.
>

I tend to agree that such standards should be strongly encouraged to use URI
relations (at least while waiting for approval, but perhaps also on an
ongoing basis) and that clients should accept both. One way to precipitate
this would be to reject this application, giving reference to the existing
'monitor' relation (which per Adam Roach above "was to be used for both
polling *and* passive mechanisms").

I see that the applicant (copied) owns http://pubsubhubbub.org/ which would
be as good a URI as any to use, but they could also use the Google Code site
or a PURL. Being able to resolve directly back to the specification rather
than going via the registry would presumably be advantageous too. In any
case it's not clear to me how this registration will help interoperability
given the constraints Mark referred to above and Brett in this
thread<http://groups.google.com/group/pubsubhubbub/browse_thread/thread/e24797ef477ecddd/a6ed35a34ad1421b#a6ed35a34ad1421b>
:

The protocol-specific nature of the "hub" relation is extremely important.
> Like the AtomPub "edit-media" relation, the "hub" link is a machine-readable
> declaration that enables software to take a specific action on discovery
> (via the PubSubHubbub protocol). Without being bound to a specific protocol
> this discovery mechanism becomes useless.

Indeed if competitive standards like PubSubHubbub and rssCloud were to share
the relation (at least without clarifying with a content type) then it could
ironically cause interoperability problems. Note also that the motivation
for the application was Atom compliance which would be achieved with a URI
relation. That's not to say it's any less of a standard, just that the
relations registry is intended for generic relations (at least going
forward).

Sam

---

From: Brett Slatkin <[email-masked]>
Date: Wed, 16 Sep 2009 14:36:38 +0000

Hi Sam,

On Wed, Sep 16, 2009 at 3:13 AM, Sam Johnston <[email-masked]> wrote:
> given the constraints Mark referred to above and Brett in this thread:
>>

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".

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.

Also, on second thought, I should have pointed out that others
(namely, Jeff Lindsay) advocate making PubSubHubbub a generic protocol
that's not specific to any particular content type. This would enable
the protocol to push event-based Atom, RSS, text, arbitrary XML, HTML,
raw bytes, etc. I've pushed back on this because I don't want to lose
focus on the use-case of feeds (because it's immediately useful), but
I think making this protocol more generic in the future is a good
idea.

So, this is how I would modify your description from before to be more generic:

Description: A URI for a "hub" (speaking the PubSubHubbub protocol)
that enables clients to register for and publish real-time updates to
the resource.

How does that sound?

-Brett

---

From: Brett Slatkin <[email-masked]>
Date: Tue, 15 Sep 2009 21:00:31 +0000

Hey Sam,

Sorry for the delay in my response, I've been on vacation.

On Fri, Sep 11, 2009 at 4:45 AM, Sam Johnston <[email-masked]> wrote:
> than any specific implementation of it. I imagine the pubsubhubbub Google
> Group (blind copied as it requires subscription to post) is the appropriate
> forum for your [no doubt legitimate] concerns regarding the protocol.

The proposal I submitted (for
http://www.iana.org/assignments/link-relations/link-relations.xhtml)
is to add the "hub" link relation as valid *only* for Atom documents.
Your concerns about HTML are valid in general, but not relevant in
this context as I understand things.

The protocol-specific nature of the "hub" relation is extremely
important. Like the AtomPub "edit-media" relation, the "hub" link is a
machine-readable declaration that enables software to take a specific
action on discovery (via the PubSubHubbub protocol). Without being
bound to a specific protocol this discovery mechanism becomes useless.

> Description: A URI for a "hub" that allows clients to register for real-time
> updates to the resource.

Such an amorphous definition doesn't accomplish anything, in my view.
Hopefully what I said above makes sense. Many of the other relation
types specifically reference an RFC with the protocol definition.
PubSubHubbub is moving in that direction, and hopefully will be a real
RFC after the draft stage.

Otherwise, this is my first time interacting with any of these
standards or standards bodies, so please forgive me if I'm
misunderstanding anything or being thick-headed.

>> the hub stopped sending notifications.

Jan: This is some extremely useful feedback. Could you please follow
up on the mailing list (http://groups.google.com/group/pubsubhubbub)
about this? We should be able to investigate and address your concerns
in an update to the PubSubHubbub spec!

-Brett

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Sep 2009 17:51:27 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Brett Slatkin
> Sent: Wednesday, September 16, 2009 7:37 AM

> that the litmus test for registration is whether the relation is

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.
 
> October 2008) and it's difficult to go back to ask everyone to change

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.
 
> that enables clients to register for and publish real-time updates to

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

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Sep 2009 19:19:29 -0700

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Sam Johnston
> Sent: Wednesday, September 16, 2009 2:47 AM
> To: Mark Nottingham
> Cc: atom-syntax Syntax; Hadrien Gardeur; HTTP Working Group; apps-
> [email-masked]
> Subject: Re: Input on request for link relation
> 
> with a suggestion for another relation (for example we might prefer to
> use something like "push" or "notif[y|ier|ication|ications" rather than
> "hub" for this one) but then that would require restarting the process
> where it should proceed to registration immediately if the change is
> accepted by the applicant.
> 
> Perhaps not, and there could well be some delay in acceptance if
> committees are involved. My worry is that if we don't streamline our
> processes as much as possible (see Ian's suggestion about IANA
> maintaining a RelExtensions style wiki) then people will do as they
> please anyway - see rel="hub", rev="canonical", etc.

I am sure there will be those that even something as "simple" as wiki will be deemed too much effort. The delay is usually not with the registry but with getting consensus. The longer it take to build consensus is usually an indication of issues with the request to take a common term and assign it to a particular use case.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Sep 2009 19:02:47 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brett
> Slatkin
> Sent: Wednesday, September 16, 2009 6:03 PM

> My concern is discovery. The link relation declares to machines that
> the PubSubHubbub protocol may be used with the resource and indicates
> that the publisher of the resource has delegated publish/subscribe
> responsibility to another URI (the Hub in the href).
> 
> If "hub" does not indicate the protocol, then how will machines
> determine if PubSubHubbub is supported? Probing the URI endpoint to
> see what it returns? Doing some kind of XRD lookup? All of these
> solutions *could* work, but they are vastly more complex than the
> simplicity of declaring the endpoint outright. This is why we have
> links in the first place!

I (obviously) share your concerns. I have recently spent months looking into the use of 'describedby' vs. other protocol-specific relation types for WebFinger, OpenID, generic resource descriptor discovery, etc. If you are looking for a simple and predictable solution, a URI extension relation type is the best solution.

But it is also worth asking:

* Is anything bad will happen if someone tries to talk PSHB to an endpoint linked as 'hub', which doesn't support it?
* Are there currently other protocols likely to use this? Are they likely to operate side by side for the same feed?
* How often does the protocol requires the processing of hub links? What would be the comparative cost of an additional discovery roundtrip?

I also want to point out that we really need to work on our messaging and perception that URI extension relation type are in any way inferior or "less cool" than the short registered ones. The sooner protocol authors accept this as a perfectly valid choice for their protocol needs, the better the link framework will be.

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Sep 2009 15:51:15 +1000

> that the litmus test for registration is whether the relation is

The litmus test is that:

* It's broadly applicable (which currently isn't true, because you're  
specific to Atom feeds)
* It has an existing, stable specification (which it looks like you're  
approaching, if you submit as an Internet-Draft), and
* It not be specific to a particular media type (which you are, at  
least for requests).

So there's probably room for getting it in, especially since you're  
effectively "grandfathered". See below for more.

> October 2008) and it's difficult to go back to ask everyone to change

Then why are you only bringing it to the attention of the wider world  
now? I don't mean to pick on you, but it seems like there are lots of  
developers these days who are writing protocols in secret, and then  
expecting the world to come along for the ride, no matter how badly  
they interact with the infrastructure. Pubsubhubbub (PLEASE come up  
with a shorter name!) isn't the worst in this respect by far, but  
still...

> that enables clients to register for and publish real-time updates to

That's a start. To my mind, you need to:

1. Accommodate things other than Atom feeds in your protocol, if only  
by leaving appropriate extension points for addressing it in a future  
(hopefully soon; lots of people are interested in this, from what I've  
seen) revision.

2. Publish as an Internet-Draft.

The question that this brings to mind for me about the Link draft is  
whether this text about registered relations is appropriate:

"Relation types that constrain the target IRI or context IRI (e.g., to  
a specific media type) MUST NOT be registered."

Obviously, that's pretty open-ended, and generally link relation types  
shouldn't specify a media type, if they're to be broadly applicable,  
but relations like "hub" that constrain things to specific input and  
output formats for *generic* protocols (here, pub/sub) could be an  
exception. Read too broadly, and this requirement could even disallow  
"duplicate" as we've been discussing on a separate thread.

My inclination at this point is to rewrite this as something like:

"Registered relation types MUST NOT constrain the media type of the  
context IRI, and MUST NOT constrain the available representation media  
types of the target IRI. However, they MAY specify the behaviours  
(e.g., allowable methods, request media types) and constrain the  
representations of target resources in other ways."

Thoughts?

Regarding "hub" vs. "monitor" -- this is interesting to me, if not  
just because people have been talking about this sort of protocol for  
easily more than a decade, and many proposals have already been made*.  
As such, I think there's more value in something more capable than  
specific, lest we all drown in a sea of special-purpose, needlessly  
application-specific protocols.

That said, I don't think you can use one link relation for both  
purposes, because even if they both took the same POST payloads, the  
further interactions beyond that (the callback to you) would also need  
to be compatible. While you could use the type attribute to  
distinguish between which protocol is in use, that's not really what  
it's for; the representation returned wouldn't be describing the  
protocol that was going to commence.

Cheers,

* I'm purposefully limiting my comments here to the impact on the link  
relations draft and registry. I have many other thoughts about  
pubsubhubbub and how suitable it is to general use; hopefully I'll  
have time to convey them separately.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Sep 2009 16:26:11 +1000

> please anyway - see rel="hub", rev="canonical", etc.

Interesting examples; the "hub" people are actively engaging  
(finally), and I've already talked to some of the "canonical" folks  
about doing an I-D once the Link draft is an RFC.

> Would it be possible then to support multiple references so that  
> people can see at a glance that a given relation is implemented as  
> described in multiple formats (rather than just the first format  
> that happened to register it)? May well not be worth the maintenance  
> effort.

How about adding a new field for references to more information about  
how a relation is used in a particular context (scoped by context  
media type)?

E.g.,

References regarding use in specific contexts:
     text/html: [HTML5]
     application/atom+xml: [RFC4287]

One concern here is that there are going to be questions about  
authority; while it's fine for the HTML5 crowd to dictate what happens  
when you see a particular relation in an HTML context, what happens  
when someone comes along and defines a spec for a media type they  
don't own? We'd need some additional guidance about amending  
registrations, I think, which is doable, but it'll make things more  
complex.

What do people think about this generally? Ian, would this help you at  
all?

We'd still need a generic 'reference' field for the defining document  
of the relation itself, but in some cases the current references would  
change to be context references; e.g.,

             Relation Name: chapter
             Description: Refers to a chapter in a collection of  
resources.
             Reference: [this specification]
             References regarding use in specific contexts:
                   text/html: [W3C.REC-html401-19991224]

---

From: Brett Slatkin <[email-masked]>
Date: Thu, 17 Sep 2009 01:03:47 +0000

Hey Eran,

> You spec will then be putting limits on it in the context of specific protocols for clients that chose to adopt it.

Yeah, I think that's a fair assessment.

> 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 fo…

I agree with you. The spec has been receiving peer review for almost a
year now. More feedback would be great
(http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html).

Long-term, I would like to consider that PubSubHubbub could move in
the direction of being a standard way of doing publish/subscribe for
all resources available via HTTP. We're just not there yet. We could
use everyone's help in making sure the specification can/will support
this in the future.

-Brett

---

From: Sam Johnston <[email-masked]>
Date: Thu, 17 Sep 2009 15:10:13 +0200

On Thu, Sep 17, 2009 at 4:02 AM, Eran Hammer-Lahav <[email-masked]>wrote:

>
> I also want to point out that we really need to work on our messaging and
> perception that URI extension relation type are in any way inferior or "less
> cool" than the short registered ones. The sooner protocol authors accept
> this as a perfectly valid choice for their protocol needs, the better the
> link framework will be.

I couldn't have said it better myself. Basically what you are saying by
requesting a short relation is that you actively intend to share the
relation with others with a view to improving interoperability. By using a
URI you control you're saying you want it to have a specific, concrete
meaning (while retaining the option of sharing). The more I hear the more it
sounds like PubSubHubbub wants the latter and with that in mind I would
suggest that http://pubsubhubbub.org/ is as good an identifier as any.

Imagine a feed advertising both rssCloud and PuSH - without clarification of
the "hub" relation (for example by way of dedicated content types) clients
will have to use protocol discovery or trial and error to work out what to
use. It doesn't help that it's not so much a content type we're talking
about but a protocol, in which case a [registered] service name would be a
better fit (and even then registered service names are generally used in
conjunction with well-known port assignments rather than "everything over
HTTP").

I have a similar problem with OCCI <http://www.occi-wg.org/> whereby I want
to advertise console access to virtual machines via ssh, vnc-server
or ms-wbt-server - I guess we'll have to assign a separate link relation
(like  http://purl.org/occi/console#ssh) for each protocol, which is a bit
of a hack when e.g. a "service=ssh" attribute would accomplish the same.
Conversely content types work fine for advertising console screenshots in
e.g. PNG or JPEG.

Mark: perhaps you could consider including some wording like Eran's and/or
mine above into the Web Linking draft so we can point at it later? I would
also suggest that the "broadly useful" test needs some refinement - the
implication in rejecting applications is that the applicant's work is not
"broadly useful" while what we mean by this is that it is useful for
multiple/many standards.

Sam

---

From: John Panzer <[email-masked]>
Date: Thu, 17 Sep 2009 15:13:50 -0700

> * It's broadly applicable (which currently isn't true, because you're

Important nit: Also, RSS feeds.

> * It not be specific to a particular media type (which you are, at least
> for requests).
>
> Then why are you only bringing it to the attention of the wider world now?
> I don't mean to pick on you, but it seems like there are lots of developers
> these days who are writing protocols in secret, and then expecting the world
> to come along for the ride, no matter how badly they interact with the
> infrastructure. Pubsubhubbub (PLEASE come up with a shorter name!) isn't the
> worst in this respect by far, but still...
>
>
> 1. Accommodate things other than Atom feeds in your protocol, if only by
> leaving appropriate extension points for addressing it in a future
> (hopefully soon; lots of people are interested in this, from what I've seen)
> revision.
>
> "Relation types that constrain the target IRI or context IRI (e.g., to a
> specific media type) MUST NOT be registered."
>
> shouldn't specify a media type, if they're to be broadly applicable, but
> relations like "hub" that constrain things to specific input and output
> formats for *generic* protocols (here, pub/sub) could be an exception. Read
> too broadly, and this requirement could even disallow "duplicate" as we've
> been discussing on a separate thread.
>
> "Registered relation types MUST NOT constrain the media type of the context
> IRI, and MUST NOT constrain the available representation media types of the
> target IRI. However, they MAY specify the behaviours (e.g., allowable
> methods, request media types) and constrain the representations of target
> resources in other ways."
>
> Thoughts?
>
> Regarding "hub" vs. "monitor" -- this is interesting to me, if not just
> because people have been talking about this sort of protocol for easily more
> than a decade, and many proposals have already been made*. As such, I think
> there's more value in something more capable than specific, lest we all
> drown in a sea of special-purpose, needlessly application-specific
> protocols.
>
> That said, I don't think you can use one link relation for both purposes,
> because even if they both took the same POST payloads, the further
> interactions beyond that (the callback to you) would also need to be
> compatible. While you could use the type attribute to distinguish between
> which protocol is in use, that's not really what it's for; the
> representation returned wouldn't be describing the protocol that was going
> to commence.
>
> Cheers,
>
>
> relations draft and registry. I have many other thoughts about pubsubhubbub
> and how suitable it is to general use; hopefully I'll have time to convey
> them separately.
>
>
> --

---

From: Martin Atkins <[email-masked]>
Date: Fri, 18 Sep 2009 10:33:34 -0700

Sam Johnston wrote:
> On Thu, Sep 17, 2009 at 4:02 AM, Eran Hammer-Lahav <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     I also want to point out that we really need to work on our
>     messaging and perception that URI extension relation type are in any
>     way inferior or "less cool" than the short registered ones. The
>     sooner protocol authors accept this as a perfectly valid choice for
>     their protocol needs, the better the link framework will be.
> 
> 
> relation with others with a view to improving interoperability. By using 
> a URI you control you're saying you want it to have a specific, concrete 
> meaning (while retaining the option of sharing). The more I hear the 
> more it sounds like PubSubHubbub wants the latter and with that in mind 
> I would suggest that http://pubsubhubbub.org/ is as good an identifier 
> as any.
> 

I think the main beef that folks have with the URI-shaped rels is that 
they're long and awkward. Why is all that "http://" and "/" noise in 
there? That's only useful if you want to dereference the URI. 
pubsubhubbub.org is enough information for an identifier.

Here are some other examples that would probably be less objectionable:

  * hubbub.hub (OpenID-style protocol.rel naming)
  * org.pubsubhubbub.hub (Java-style .. but I personally find it award 
that these are "backwards" compared to DNS.
  * pubsubhubbub.org:hub (like a tag: URI without the scheme and date)

These things are much less likely to be considered second-class citizens 
if they don't look so daft.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 18 Sep 2009 11:07:46 -0700

(This is not aimed at Martin personally)

> On Behalf Of Martin Atkins
> Sent: Friday, September 18, 2009 10:34 AM

> pubsubhubbub.org is enough information for an identifier.

Using URIs as a syntax for namespaces is well established practice. This argument is silly because these values, *especially* the one proposed by PSHB are meant for machine use only (and I am sure those machines don't share this feeling or feel like second class citizens). URIs provide a simple mechanism for namespacing the relation type value, avoiding the obvious problem of name 'land grab'. If you don't like using an http:// URI, you are free to use URNs (which I am sure others will find more awkward).

If this was a value we were presenting to people or asking them to input manually I would agree. This is why we are working on projects like WebFinger to improve the usability of web identifiers for people. But for engineers to make this argument about machine-only patterns, is really just plain silly.

If a short relation type is what makes someone feel better about their protocol, well, I don't think we can help.

EHL

---

From: Robert Sayre <[email-masked]>
Date: Sun, 20 Sep 2009 12:30:30 -0400

> I don't mean to pick on you, but it seems like there are lots of developers these days
> who are writing protocols in secret, and then expecting the world to come along for the ride,
> no matter how badly they interact with the infrastructure.

I don't think these developers, or anyone else, are under an
obligation to share a proposal with the world before they think it's
ready. It can feel a little like taking dictation when something
rather fully-formed emerges from some company's intranet, but
successful protocols can emerge in many ways, and these developers
appear quite willing to make reasonable changes to their spec (they
had already added RSS before this thread began, iirc).

> As such, I think there's more value in something more capable than specific,
> lest we all drown in a sea of special-purpose, needlessly application-specific protocols.

One example of an unreasonable request would be to suggest that
developers are required to solve a much bigger problem then they've
set out to. In this case, I don't see a reason to apply stop energy.
The PubSubHubbub effort is clearly not going to hurt the Web or the
Internet in general, the link relation namespace is not especially
crowded, and the IETF is free to modify or expand the definition of
the hub relation over time. With that in mind, I don't think the text
of the registration should or will stop people if the proposed
relation turns out to be useful for non-feed media types.

-- 

Robert Sayre

---

From: Kris Zyp <[email-masked]>
Date: Sun, 20 Sep 2009 17:41:18 -0600

Robert Sayre wrote:
>> As such, I think there's more value in something more capable
>> than specific, lest we all drown in a sea of special-purpose,
>> needlessly application-specific protocols.
>
>  set out to. In this case, I don't see a reason to apply stop
> energy. The PubSubHubbub effort is clearly not going to hurt the
> Web or the Internet in general, the link relation namespace is not
> especially crowded, and the IETF is free to modify or expand the
> definition of the hub relation over time. With that in mind, I
> don't think the text of the registration should or will stop people
> if the proposed relation turns out to be useful for non-feed media
> types.
I am not necessarily opposed to the addition of a
simple/non-namespaced relation, but it still seems like it should be
necessary to have some the relationship clearly articulated enough to
delineate between "hub" (or whatever relation name that is used) and
the existing "monitor" relation. A developer (like me) should be able
to make an informed selection between the two for other notification
formats.

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com

---

From: Sam Johnston <[email-masked]>
Date: Mon, 21 Sep 2009 01:54:47 +0200

> to make an informed selection between the two for other notification

At the very least, where there are overlapping relations (e.g. prev vs
previous, hub vs monitor, etc.) we should indicate which one is preferred,
perhaps by deprecating the other(s).

I appreciate Robert's concerns however and you can be quite sure that we'll
see more rather than less specs developed behind closed doors before being
unleashed on the world (Google Wave comes to mind). In that case I would
suggest that they supply a URI relation in addition to the proposed short
relation - reference implementations can send the URI and clients can accept
both in the interim.

Whatever we decide the Web Linking draft needs to reflect it (and probably
needs to go to some lengths to explain that URI relations are not evil).

Sam

---

From: Robert Sayre <[email-masked]>
Date: Sun, 20 Sep 2009 22:07:31 -0400

> to make an informed selection between the two for other notification

It looks like the "hub" relation might see substantial running code as
well as rough consensus.

At least, that's supposedly one of the good parts of the IETF. The
main bad part is an amoral attitude regarding software patents, to the
point that some Areas operate on the assumption that every participant
has cross-licensed everyone else's patents, so that the industry
status quo is preserved. In the Applications Area, I think an upfront
royalty-free policy should be required (I would be surprised to find
my employer, Mozilla Corporation, disagreeing). When I see patents
filed on penetrating glimpses into the obvious[1], my sympathy for
those suffering tedious namespace arguments suddenly evaporates.

I've changed my position, and I do not support the "hub" relation. If
all of this technology were part of an RF Internet, in letter and
spirit, I feel this group could have a more productive conversation.

[1] http://www.scripting.com/stories/2009/09/17/googleGetsAPatentOnReading.html

-- 

Robert Sayre

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Sep 2009 14:04:38 +1000

Responses inline.

On 21/09/2009, at 1:43 PM, Brett Slatkin wrote:

> Hey Mark,
> Thanks for the reply.
>> Then why are you only bringing it to the attention of the wider  
>> world now? I
>> don't mean to pick on you, but it seems like there are lots of  
>> developers
> Brad and I have been showing this protocol around for a while. We
> showed it off at an XMPP users group meeting in February
> (http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/ 
> )
> and multiple blog posts were written about it in the beginning of this
> year (http://tinyurl.com/mjvgy6) around Social Web Foo 2009. I'm not
> hooked into any standards bodies at all; is there some
> protocol-announce mailing list I should have used?

Obviously, I don't read the right blogs. :) Ideally people would have  
communicated this internally inside the IETF as well as in various  
companies that were working on it, but we don't live in that ideal  
world. Ah, well.

The best place to socialise this sort of thing in the IETF is probably  
the apps-discuss list; <https://www.ietf.org/mailman/listinfo/apps-discuss 
 >. In the W3C, it's probably www-talk; <http://lists.w3.org/Archives/Public/www-talk/ 
 >.

>>> So, this is how I would modify your description from before to be  
>>> more
>>> generic:
>>>
> I've opened this bug to track leaving open extensions for future  
> content types:
> http://code.google.com/p/pubsubhubbub/issues/detail?id=71
>
> We need to figure out how discovery will work (possibly XRD?) but I
> think it's doable.
>
>> The question that this brings to mind for me about the Link draft  
>> is whether
>> this text about registered relations is appropriate:
>>
>> context
> I like the second description here much more. It's a nice improvement
> on the original language.

Good, I think so too.

> Before PubSubHubbub is made into a
> legitimate internet draft, we'll need a better story for all content
> types (issue 71 filed above).
>
>> just
>> purposes,
> I can't seem to find any reference to the "monitor" relation type
> anywhere. Could you pass me a link to it?

See:
   http://tools.ietf.org/html/draft-roach-sip-http-subscribe
with a mailing list at:
   https://www.ietf.org/mailman/listinfo/sip-http-events

>> pubsubhubbub
> I would really appreciate if you could find the time. I could really
> use some help from you and others who are familiar with the
> standardization process. This is all new to me.

Will do.

Cheers,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 20 Sep 2009 23:44:46 -0700

I'll comment in reverse order...

> Sent: Sunday, September 20, 2009 11:16 PM

> So far, the amount of push-back I've received trying to get into the
> registry has reinforced the idea that links with the URI extension
> relation aren't good enough to be accepted as standards.

I am not sure what you mean by this. The pushback here has been mostly about reserving the general term 'hub' to be used exclusively for a single protocol. Can you point me to where statements were made that indicated URI extension relations are not good enough for standards?

In the current working draft for XRD (an OASIS standard proposal) we include a URI extension relation which has specific processing meaning because we felt it was more appropriate than registering something so specific. In WebFinger we decided to use the relation type 'describedby' for resolving (the proposed) acct: URIs but also included an URI extension relation to allow servers to explicitly indicate their support of the protocol. These are two examples (at least one is a proposed standard) for using URI extension relations.

> > * Is anything bad going to happen if someone tries to talk PSHB to an
> endpoint linked as 'hub', which doesn't support it?
> 
> Probably not.
> 
> > * Are there currently other protocols likely to use this? Are they
> likely to operate side by side for the same feed?
> 
> Hopefully there will be a bunch of companion/extension protocols to
> the core PubSubHubbub spec that make it function efficiently for all
> content types. But no, there aren't any other protocols I know of, at
> this point that would also use this <link> relation. The only other
> one that comes close is rssCloud, which has its own element in the RSS
> namespace.

Given these answers, I don't think there is a problem with registering 'hub' as a relation type (if you can provide a description that does not limit it for a single protocol in a single document type). You can then define in your protocol how clients should behave when they encounter such links.

But again, I just don't understand why rel='http://pubsubhubbub.net' is any lesser than rel='hub'.

EHL

---

From: Brett Slatkin <[email-masked]>
Date: Mon, 21 Sep 2009 07:00:15 +0000

Hi Eran,

Probably not.

> * How often does the protocol requires the processing of hub links? What would be the comparative cost of an additional discovery roundtrip?

Each time a feed event is delivered, the Hub link will be delivered
with it. This is necessary to handle hub moves (especially at a high
rate, which may be useful for load balancing). I think a discovery
round trip would slow things down and vastly complicate subscriber
implementations. The primary purpose of this spec is to be easy to use
for everyone; I don't want to undermine that.

-Brett

---

From: Brett Slatkin <[email-masked]>
Date: Mon, 21 Sep 2009 03:43:56 +0000

Hey Mark,

Thanks for the reply.

On Wed, Sep 16, 2009 at 10:51 PM, Mark Nottingham <[email-masked]> wrote:
> Then why are you only bringing it to the attention of the wider world now? I
> don't mean to pick on you, but it seems like there are lots of developers

(http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/)

> (hopefully soon; lots of people are interested in this, from what I've seen)

I've opened this bug to track leaving open extensions for future content types:
http://code.google.com/p/pubsubhubbub/issues/detail?id=71

> The question that this brings to mind for me about the Link draft is whether

I like the second description here much more. It's a nice improvement
on the original language. Before PubSubHubbub is made into a
legitimate internet draft, we'll need a better story for all content
types (issue 71 filed above).

-Brett

---

From: Brett Slatkin <[email-masked]>
Date: Mon, 21 Sep 2009 04:33:56 +0000

Robert:

I'm in no position to speak on behalf of Google regarding the patent
you referred to, but I will say a few things:

The whole point of PubSubHubbub is to be an open protocol, free of
patents, that anyone can use. We're going to release it under the
license coming out of the Open Web Foundation
(http://openwebfoundation.org/) once that's ready (I hear drafts are
very far along).

If you read the PubSubHubbub spec, your mind will overflow with absurd
amounts of prior art on which we've built things. It's obvious that
any patent on this technology is invalid or long expired. Please read
it if you haven't and you'll see what I mean.

I find it frustrating that you're lumping me, Brad, Martin, and this
spec together with some patent we had nothing to do with. We're trying
to do good here and help the web. I'd appreciate it if you could
recognize the level of effort we're putting into this, into being
open, and into reaching a consensus.

-Brett

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Sep 2009 18:42:54 +1000

Also, I think the mitigating factor here is that the hub folks have  
been working on this for a while, and Link isn't approved or an RFC yet.

Cheers,

On 21/09/2009, at 4:44 PM, Eran Hammer-Lahav wrote:

> I am not sure what you mean by this. The pushback here has been  
> mostly about reserving the general term 'hub' to be used exclusively  
> for a single protocol. Can you point me to where statements were  
> made that indicated URI extension relations are not good enough for  
> standards?
>
> In the current working draft for XRD (an OASIS standard proposal) we  
> include a URI extension relation which has specific processing  
> meaning because we felt it was more appropriate than registering  
> something so specific. In WebFinger we decided to use the relation  
> type 'describedby' for resolving (the proposed) acct: URIs but also  
> included an URI extension relation to allow servers to explicitly  
> indicate their support of the protocol. These are two examples (at  
> least one is a proposed standard) for using URI extension relations.
>
> Given these answers, I don't think there is a problem with  
> registering 'hub' as a relation type (if you can provide a  
> description that does not limit it for a single protocol in a single  
> document type). You can then define in your protocol how clients  
> should behave when they encounter such links.
>

---

From: Brett Slatkin <[email-masked]>
Date: Mon, 21 Sep 2009 05:33:53 +0000

>  https://www.ietf.org/mailman/listinfo/sip-http-events

Ah okay, that's helpful. That SIP subscription spec does have some
similar elements to PubSubHubbub (e.g., fat pings), but it's heavily
reliant on SIP for its mechanics. I'd like to think that what we're
trying to define here with PSHB is a simpler, more stand-alone
publish/subscribe protocol over simple HTTP. PSHB's current reliance
on Atom/RSS is to promote bootstrapping of a common use-case, but
isn't necessary long-term.

-Brett

---

From: Sam Johnston <[email-masked]>
Date: Mon, 21 Sep 2009 13:04:45 +0200

On Mon, Sep 21, 2009 at 10:42 AM, Mark Nottingham <[email-masked]> wrote:

> Also, I think the mitigating factor here is that the hub folks have been
> working on this for a while, and Link isn't approved or an RFC yet.

Which reminds me... a number of drafts have already resulted in the creation
of IANA registries <http://www.iana.org/protocols/>. Perhaps it would be
sensible to do the same while we refine the Web Linking draft? Is it still
possible?

Sam

On 21/09/2009, at 4:44 PM, Eran Hammer-Lahav wrote:
>> I am not sure what you mean by this. The pushback here has been mostly
>> about reserving the general term 'hub' to be used exclusively for a single
>> protocol. Can you point me to where statements were made that indicated URI
>> extension relations are not good enough for standards?
>>
>> include a URI extension relation which has specific processing meaning
>> because we felt it was more appropriate than registering something so
>> specific. In WebFinger we decided to use the relation type 'describedby' for
>> resolving (the proposed) acct: URIs but also included an URI extension
>> relation to allow servers to explicitly indicate their support of the
>> protocol. These are two examples (at least one is a proposed standard) for
>> using URI extension relations.
>>
>> Given these answers, I don't think there is a problem with registering
>> 'hub' as a relation type (if you can provide a description that does not
>> limit it for a single protocol in a single document type). You can then
>> define in your protocol how clients should behave when they encounter such
>> links.
>>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 21 Sep 2009 12:54:33 -0400

> (http://openwebfoundation.org/) once that's ready (I hear drafts are

Then it sounds like my objection will be moot, once the license is
ready. It is only my objection--the IETF is totally patent agnostic.
Perhaps you can get enough support anyway. The technical bits seem
reasonable, and the SIP thing looks like a sideshow to me. :)

> It's obvious that any patent on this technology is invalid

It's not prudent to assume that obviousness will stop the patent
process, unfortunately.

> open, and into reaching a consensus.

It's not personal--I don't think you guys have anything to do with
filing patents. However, I want a Web free from the toxic legal
environment that plagues other parts of the IETF and standards bodies
in general. That environment stifles innovation and privileges the
status quo. If the OWF turns out well, then there is no objection from
me. It's too bad that IPR behavior in this space has forced me to side
with those making what I think are otherwise unfair criticisms.

-- 

Robert Sayre

---

From: Ian Hickson <[email-masked]>
Date: Thu, 24 Sep 2009 09:37:18 +0000 (UTC)

On Thu, 17 Sep 2009, Mark Nottingham wrote:
> how a relation is used in a particular context (scoped by context media 
> type)?
> 
> E.g.,
> 
> when you see a particular relation in an HTML context, what happens when 
> someone comes along and defines a spec for a media type they don't own? 
> We'd need some additional guidance about amending registrations, I 
> think, which is doable, but it'll make things more complex.
> 

It would certainly be an improvement, though I'm still unconvinced that we 
want different definitions for the same link type for different MIME 
types. Difference conformance classes, sure, but that's another issue.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 27 Sep 2009 10:18:52 +1000

> types. Difference conformance classes, sure, but that's another issue.

Yes, that's the tricky part; there would be a tendency to define  
different meanings for different mime types, no matter how clearly  
it's stated that the additional information was restricted to the  
interpretation/implementation of the relations.