[Standards] Entity Capabilities Woes
matt at jivesoftware.com
Wed Mar 14 04:21:00 UTC 2007
> 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
* 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
* 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.
More information about the Standards