[Social] more summit follow-up

[Peter Saint-Andre]

Leo Dirac, who was at the XMPP Summit, has a helpful post here:

http://www.embracingchaos.com/2008/07/xmpp-pubsub-a-g.html

/psa

[Peter Saint-Andre]

Peter Saint-Andre wrote:
> Leo Dirac, who was at the XMPP Summit, has a helpful post here:
>
> http://www.embracingchaos.com/2008/07/xmpp-pubsub-a-g.html

So I think we have a few things to work on:

1. Define a SHIM header for sequence numbers.

2. Standardize the link rels we discussed.

3. Define an ad-hoc command for making a node of yours subscribe to
another node for lightweight chaining or repeaters.

Then I think we're most of the way there. :)

/psa

[Peter Saint-Andre]

Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
>> Leo Dirac, who was at the XMPP Summit, has a helpful post here:
>>
>> http://www.embracingchaos.com/2008/07/xmpp-pubsub-a-g.html
>
> So I think we have a few things to work on:
>
> 1. Define a SHIM header for sequence numbers.

I don't see anything like this for HTTP, SMTP, NNTP, or SIP (the closest
I see is the CSeq header in SIP) so I think we can add this to XEP-0131.

> 2. Standardize the link rels we discussed.

That is:

1. xmpp.feed -- this is a pointer to your Atom feed, so perhaps it
belongs in the "AtomSub" spec:

http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html

2. xmpp.profile -- this is a pointer to your vCArd, so perhaps it
belongs in the vcard-temp spec:

http://www.xmpp.org/extensions/xep-0054.html

(Could xmpp.profile also be used to point to XEP-0154 data?)

> 3. Define an ad-hoc command for making a node of yours subscribe to
> another node for lightweight chaining or repeaters.

This might belong in XEP-0060 or in a small extension to XEP-0060
(probably the latter).

Thoughts?

Peter

[Ralph Meijer]

Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
>> Peter Saint-Andre wrote:
>>> Leo Dirac, who was at the XMPP Summit, has a helpful post here:
>>>
>>> http://www.embracingchaos.com/2008/07/xmpp-pubsub-a-g.html
>>
>> So I think we have a few things to work on:
>>
>> 1. Define a SHIM header for sequence numbers.
>
> I don't see anything like this for HTTP, SMTP, NNTP, or SIP (the closest
> I see is the CSeq header in SIP) so I think we can add this to XEP-0131.
>
>> 2. Standardize the link rels we discussed.
>
> That is:
>
> 1. xmpp.feed -- this is a pointer to your Atom feed, so perhaps it
> belongs in the "AtomSub" spec:
>
> http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html

Since we now implicitely assume the thing pointed to is a pubsub node,
we can just go ahead and use the 'type' attribute to denote the payload
format: application/atom+xml, application/rdf+xml (for RDF feeds), etc.
Mixed namespaces (for collections?) might just use application/xml, and
maybe we need to think up a couple of mime types for our own extended
presence payload formats (like XEP-0080 User Location). This all might
go in XEP-0240.

> 2. xmpp.profile -- this is a pointer to your vCArd, so perhaps it
> belongs in the vcard-temp spec:
>
> http://www.xmpp.org/extensions/xep-0054.html
>
> (Could xmpp.profile also be used to point to XEP-0154 data?)

I suppose the same thing goes, only need to define a mime type for data
forms, I think?

>> 3. Define an ad-hoc command for making a node of yours subscribe to
>> another node for lightweight chaining or repeaters.
>
> This might belong in XEP-0060 or in a small extension to XEP-0060
> (probably the latter).

Yes, the latter. Should be pretty straight-forward mapping of the
protocol bits for subscription in XEP-0060 to XEP-0050 ad-hoc commands.
I'm not sure how to include subscription configuration options in the
same form, though. Maybe a multiple stage thing?

ralphm

[Peter Saint-Andre]

Ralph Meijer wrote:
> Peter Saint-Andre wrote:
>> Peter Saint-Andre wrote:
>>> Peter Saint-Andre wrote:
>>>
>>> 2. Standardize the link rels we discussed.
>>
>> That is:
>>
>> 1. xmpp.feed -- this is a pointer to your Atom feed, so perhaps it
>> belongs in the "AtomSub" spec:
>>
>> http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html
>>
>
> Since we now implicitely assume the thing pointed to is a pubsub node,
> we can just go ahead and use the 'type' attribute to denote the payload
> format: application/atom+xml, application/rdf+xml (for RDF feeds), etc.
> Mixed namespaces (for collections?) might just use application/xml, and
> maybe we need to think up a couple of mime types for our own extended
> presence payload formats (like XEP-0080 User Location). This all might
> go in XEP-0240.

So we would not define the link rels at all?

>> 2. xmpp.profile -- this is a pointer to your vCArd, so perhaps it
>> belongs in the vcard-temp spec:
>>
>> http://www.xmpp.org/extensions/xep-0054.html
>>
>> (Could xmpp.profile also be used to point to XEP-0154 data?)
>
> I suppose the same thing goes, only need to define a mime type for data
> forms, I think?

Sure. Sounds like fun -- I always love to interact with the IANA. ;-)

>>> 3. Define an ad-hoc command for making a node of yours subscribe to
>>> another node for lightweight chaining or repeaters.
>>
>> This might belong in XEP-0060 or in a small extension to XEP-0060
>> (probably the latter).
>
> Yes, the latter. Should be pretty straight-forward mapping of the
> protocol bits for subscription in XEP-0060 to XEP-0050 ad-hoc commands.
> I'm not sure how to include subscription configuration options in the
> same form, though. Maybe a multiple stage thing?

Possibly, yes. That sounds like the kind of thing I'll work on late in
the evening one of these days. :)

/psa

[Ralph Meijer]

On Thu, Aug 07, 2008 at 03:04:33PM -0600, Peter Saint-Andre wrote:
> Ralph Meijer wrote:
> >Peter Saint-Andre wrote:
> >>Peter Saint-Andre wrote:
> >>>Peter Saint-Andre wrote:
> >>>
> >>>2. Standardize the link rels we discussed.
> >>
> >>That is:
> >>
> >>1. xmpp.feed -- this is a pointer to your Atom feed, so
> >>perhaps it belongs in the "AtomSub" spec:
> >>
> >>http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html
> >>
> >
> >Since we now implicitely assume the thing pointed to is a
> >pubsub node, we can just go ahead and use the 'type'
> >attribute to denote the payload format:
> >application/atom+xml, application/rdf+xml (for RDF feeds),
> >etc. Mixed namespaces (for collections?) might just use
> >application/xml, and maybe we need to think up a couple of
> >mime types for our own extended presence payload formats
> >(like XEP-0080 User Location). This all might go in
> >XEP-0240.
>
> So we would not define the link rels at all?

We still need rels, because we didn't want to depend on Service Discovery. So,
as I see it, xmpp.feed points to a pubsub node.

--
Groetjes,

ralphm

[Peter Saint-Andre]

Ralph Meijer wrote:
> On Thu, Aug 07, 2008 at 03:04:33PM -0600, Peter Saint-Andre wrote:
>> Ralph Meijer wrote:
>>> Peter Saint-Andre wrote:
>>>> Peter Saint-Andre wrote:
>>>>> Peter Saint-Andre wrote:
>>>>>
>>>>> 2. Standardize the link rels we discussed.
>>>> That is:
>>>>
>>>> 1. xmpp.feed -- this is a pointer to your Atom feed, so
>>>> perhaps it belongs in the "AtomSub" spec:
>>>>
>>>> http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html
>>>>
>>> Since we now implicitely assume the thing pointed to is a
>>> pubsub node, we can just go ahead and use the 'type'
>>> attribute to denote the payload format:
>>> application/atom+xml, application/rdf+xml (for RDF feeds),
>>> etc. Mixed namespaces (for collections?) might just use
>>> application/xml, and maybe we need to think up a couple of
>>> mime types for our own extended presence payload formats
>>> (like XEP-0080 User Location). This all might go in
>>> XEP-0240.
>> So we would not define the link rels at all?
>
> We still need rels, because we didn't want to depend on Service Discovery. So,
> as I see it, xmpp.feed points to a pubsub node.

OK, I'll update XEP-0240 along these lines...

/psa