Re: Input on request for link relation [ w/ proposed modifications to link draft ]

Responses inline.

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

> Hey Mark,
>
> Thanks for the reply.
>
> On Wed, Sep 16, 2009 at 10:51 PM, Mark Nottingham <mnot@mnot.net>  
> wrote:
>>> 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.
>>
>> 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...
>
> 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:
>>>
>>> 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?
>>
>> 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.
>
> 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.
>
>> 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?
>
> 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).
>
>> 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.
>
> 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


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


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

Received on Monday, 21 September 2009 04:05:28 UTC