Input on request for link relation

[Lisa Dusseault-3]

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

[Robert Sayre-2]

On Thu, Sep 10, 2009 at 1:30 PM, Lisa Dusseault
<lisa.dusseault@...> wrote:
> 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."

[Jan Algermissen-2]

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


On Sep 10, 2009, at 7:30 PM, Lisa Dusseault wrote:

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

[John Panzer-4]

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 <algermissen1971@...> 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
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

On Sep 10, 2009, at 7:30 PM, Lisa Dusseault wrote:

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

[Jan Algermissen-2]

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 <algermissen1971@...
> > 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
> 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
>
>
>
> On Sep 10, 2009, at 7:30 PM, Lisa Dusseault wrote:
>
>
> 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
>
>
>

[Sam Johnston-4]

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 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 <algermissen1971@...> wrote:

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 <algermissen1971@...> 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
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



On Sep 10, 2009, at 7:30 PM, Lisa Dusseault wrote:


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

[Hadrien Gardeur]

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.

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) ? 

 

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.

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. 

Hadrien

[Julian Reschke]

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

[Kris Zyp-4]

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


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

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
[phone]
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkqqSsIACgkQ9VpNnHc4zAyzrwCcDzMSbgxn3eQbZeK4PoIodlBw
+kcAnRYANmZ4BrAcGkSabnFLiwjVOPLi
=p7gL
-----END PGP SIGNATURE-----

[Sam Johnston-4]

On Fri, Sep 11, 2009 at 2:00 PM, Hadrien Gardeur <hadrien.gardeur@...> 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" 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

   apps-discuss@... 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

[Hadrien Gardeur]

Yes, though I believe Mark's "Web Linking" 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".

[Peter Saint-Andre-2]

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

On 9/11/09 7:04 AM, Kris Zyp 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).

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/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqqeIgACgkQNL8k5A2w/vyPYQCgn7vT0g0gHgn+/BgNBl0iG3M0
3D8AmwbIOuyYDgUGO7JyfgLm3FD4zbfh
=ECAn
-----END PGP SIGNATURE-----

[Kris Zyp-4]

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


Peter Saint-Andre wrote:

> On 9/11/09 7:04 AM, Kris Zyp 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).
>
> 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.

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
[phone]
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkqqexQACgkQ9VpNnHc4zAyxFQCgrWnBMLIq4Qkl+e9EC78e5SfU
f+sAoIrY6DDdyogMRQPMSM7l2WDaMCAP
=OZpi
-----END PGP SIGNATURE-----

[Peter Saint-Andre-2]

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

On 9/11/09 10:30 AM, Kris Zyp wrote:

>
>
> Peter Saint-Andre wrote:
>> On 9/11/09 7:04 AM, Kris Zyp 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).
>> 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.
> 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

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

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqqfW8ACgkQNL8k5A2w/vxX/ACfc+xUQFcjgDwL+7LrR5yKyBEy
jrkAni0zCVK4LrDp/yc+NogQuGf26Sdm
=ykL5
-----END PGP SIGNATURE-----

[Sam Johnston-4]

On Fri, Sep 11, 2009 at 6:30 PM, Kris Zyp <kris@...> wrote:

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

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

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

Well spotted. For me to "monitor" or "watch" something requires conscious, ongoing effort by the client. The dictionary definition 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

[Kris Zyp-4]

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


Sam Johnston wrote:

> On Fri, Sep 11, 2009 at 6:30 PM, Kris Zyp <kris@...
> <mailto:kris@...>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
>> 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.
> 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
>
>
>
> 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
[phone]
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkqqgFMACgkQ9VpNnHc4zAwd9wCgk8JpKoNfqm/llAI6tJHotT8c
z6oAoLiSTo/m8RB9UK9GjsmVFbN9QF1l
=yieY
-----END PGP SIGNATURE-----

[Peter Saint-Andre-2]

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

On 9/11/09 10:52 AM, Kris Zyp wrote:

>
> Sam Johnston wrote:
>
>> 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?

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/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqqh5wACgkQNL8k5A2w/vwo/wCgpeN4bAidIv9zMU0O6Zo/q6P9
O+sAoItSWp5s+xtWkNDNAiD+tJl6nvys
=Pm91
-----END PGP SIGNATURE-----

[Adam Roach-3]

On 9/11/09 11:52 AM, Kris Zyp wrote:
> 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?
>    

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

[John Panzer-3]

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#contentdistribution so 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).

On Thu, Sep 10, 2009 at 4:57 PM, Jan Algermissen <algermissen1971@...> wrote:

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 <algermissen1971@...> 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
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



On Sep 10, 2009, at 7:30 PM, Lisa Dusseault wrote:


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

[Brett Slatkin-2]

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 <samj@...> 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. 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.
> 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.

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.

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

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.

> On Fri, Sep 11, 2009 at 1:57 AM, Jan Algermissen <algermissen1971@...>
> wrote:
>>
>> 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: 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