[Standards] Service discovery for clients
stpeter at stpeter.im
Mon Jul 7 23:01:04 CDT 2008
> with my first thinking about this subject, and your answers, I wrote
> some proposition here:
> I hope this is clear. It uses mostly XEP-0030, XEP-0115 and XEP-0168
> and I propose two main parts:
> 1/ redefining the priority for being a priority only for the standard
> namespace (jabber:client), hence for presence and IM features only. It
> is set by 0 by default and IM can be disabled with a negative priority.
> Each other feature of an extended namespace will have its own separated
> priority settable with the XEP-0168. Each declared functionnality will
> have a default RAP prioriy of 0, and can be disabled by a negative
> 2/ Recommending good behaviour of an entity which should send its
> capabilities to all other entities subscribed to its presence and good
> behaviour of an entity knowing another entity's capabilities and
> processing stanzas destined to this other entity, according to this
> What do you think of it?
I think that's pretty close to a best practice. Your recommendation #1a
is not much different from the intent of negative presence priority in
RFC 3921. #1b doesn't work now because we haven't finalized RAP, but we
need to do so. #2a says that an entity should publish its capabilities
through a combination of caps (XEP-0115) and RAP (XEP-0168), which seems
good to me. #2b recommends mostly server handling of incoming stanzas
based on client caps+RAP, which again seems reasonable (except that
neither clients nor servers support RAP yet, and servers are not yet
smart enough to use caps information in this way).
Perhaps we need to write up a XEP about this? I'd be happy to help.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080707/ac42f210/attachment-0001.bin
More information about the Standards