[Standards] Entity Capabilities Woes

Matt Tucker matt at jivesoftware.com
Wed Mar 14 04:21:00 UTC 2007


Maciek,

> Small detail: some XEPs define more than one feature, so XEP 
> short names may not be the best candidate here.

True, it's really one short name per disco item and not per XEP.

> Let's say a group of friends wants to be able to call 
> emergency meetings via XMPP. They write a simple plugin to 
> their favorite client and it "Run To Me Protocol" and 
> advertise it as "rtmp" extension. Or maybe better use 
> "x-rtmp", not to have conflicts?
> At the same time, Adobe implements their rejected Real Time 
> Messaging Protocol jingle transport. Now even if capabilities 
> registry would be separate from XEPs registry, I don't think 
> that they would bother to register it after their XSF refused 
> to publish their XEP. So they simply advertise "x-rtmp", with 
> "x-" to prevent conflicts.
> Oh, do these two ext strings look the same? ;)

A good hypothetical argument, but I don't think it's a huge practical
issue. A number of reasons:

 * I haven't seen many clients doing a ton of proprietary stuff that
needs caps. In general, not many new extensions are getting created on a
yearly basis.  
 * We could let people put whatever they want in the registry, even some
non-XEP entries. I don't think we'll run out of possible short name
values.
 * The benefits of the simpler protocol far outweigh the hypothetical
problem. If there is a conflict, the client authors would likely resolve
it pretty quickly if it's a practical issue.

> Sorry, but I just like to invent counterarguments ;) More 
> seriously: I really liked your (before it was "your") 
> proposal when it was first discussed here. But then I got 
> convinced that it works so well only on the paper, but not in 
> real life. At least this is my opinion.

Well, we can't take credit for the idea. But, maybe it's a good sign
that it keeps getting proposed. I would submit that the objections are
more hypothetical than practical.

Regards,
Matt



More information about the Standards mailing list