[xiph-rtp] Lots of proposals

[David Barrett]

Tor-Einar Jarnbjo wrote:
> David Barrett wrote:
> 
>> Standards are best when they focus on areas of agreement.  The 
>> baseline spec is identical for all situations.  But codebook delivery 
>> depends heavily on the usage model, and thus I think it's reasonable 
>> to split it out and leave it up to the developers to pick the best one. 
> 
> And you don't expect this to end up with servers and clients which are 
> only compatible using a delivery method which is not practically usable 
> for common streaming situations, whereas only the client from vendor X 
> works well together with the server from vendor X, as each vendors 
> developers have different opinions on which alternative is "the best one"?

(I'm assuming you meant to post this to the list; I apologize in advance 
if I assumed wrong.)

I see your concern here, but I don't share it.  Vendor lock-in generally 
happens due to proprietary, non-standard extensions -- and that's not 
what we have here.  (And incidentally, nothing we say prevents vendor 
lock in should a vendor wish it.)

What we have are usage models that call for different codebook delivery 
techniques.  I would imagine that all client/servers targeting the same 
usage model would tend toward the same codebook delivery technique.  For 
example, web radio servers would use the same technique, and thus they 
would all be compatible.  All VoIP techniques would use the same 
technique, and thus they would all be compatible.

Now I'll grant it's possible that VoIP and web-radio would do codebook 
delivery different, but they do *everything* different.  It's not like 
if only they used the same codebook delivery technique they'd be 
compatible -- they'll never be compatible, no matter what we say, 
because they're totally different products.

It's not our goal to make all vorbis-enabled products interchangeable, 
and it shouldn't be.  Rather, I would state our goal as ensuring that 
all products that *want* to be compatible can do so in the easiest 
possible way.  And part of being "easy" is not forcing products to 
support codebook delivery mechanisms that they don't use.

-david