What's at issue is anything beyond a general approach will lead to bias 'in the protocol'. [...] Extending the protocol any more then is done with JEP-95 seems kind of pointless, unless there's some overwhelming need to have something extremely specific.
There is nothing wrong with implementing a very flexible, not-all-that-specific protocol. Then again, when looked at from a users' perspective, there is, indeed, the "overwhelming need" to provide a common technical denominator to ensure that the corresponding functionality that a user sees is interoperable between as many Jabber clients as possible.
Therefore, IMHO, we must require a Jabber AV client to support at least one specified codec to ensure this interoperability.
As long as client programmers are free to choose whatever codec they like, you may end up in the all-too-familiar situation that you cannot use a certain feature because of purely techno-political reasons. Which is fine for geeks who will find some work-around, but it will "spoil the fun" for main stream users.
Consequently, I'd suggest that beyond the technical details in the protocol, Jabber clients and servers will be required to support at least one specified codec, although they'd be free to negotiate a different, possibly higher-quality one if both/all clients involved in the conference support it.
GreetinX,
Jochen.
_______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
