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.htmlSince 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
smime.p7s
Description: S/MIME Cryptographic Signature
