Rfc 2782

[Burnjack]

a short question for the developers:

will teamspeak 3 support RFC 2782 a.k.a. SRV Resource Records in the future ?

More information about RFC 2782:
http://en.wikipedia.org/wiki/SRV_record | http://de.wikipedia.org/wiki/SRV_Resource_Record
http://tools.ietf.org/html/rfc2782
http://www.dns-sd.org/ServiceTypes.html

[dante696]

It would be nice to support this, but we can't say, when this will be supported.
Maybe it will be implemented after the final release of TS3.

[Burnjack]

It would be nice to support this, but we can't say, when this will be supported.
Maybe it will be implemented after the final relasoe of TS3.

thanks for this answer

[ANR Daemon]

Any update on this question? As it seems, the modern TS3 server package is shipped with a very crude and inefficient replacement of the RFC2782 proposed functionality.
I'd rather add a simple

_ts3client._udp.rootdir.org 900 IN SRV 100 10 7998 <my.dyndns.hostname>

record to my master zone, than mess with yet another daemon at my end.

[Peter]

Hey,

there is no update to dantes answer. We would like to do this, but not before 3.0 final. TSDNS has some similarities, but it is not meant to be a replacement (neither is it meant to be either crude or inefficient ).

[ANR Daemon]

Thanks for the answer. Hope it won't get abandoned in process... Like it happened with normal user/group permissions.

[dante696]

What are you talking about? These permissions are still there!
http://forum.teamspeak.com/showthrea...tem-is-missing.

[ANR Daemon]

What I'm talking about? I'm talking about NORMAL user/group permissions. Like...

Let we have a domain of ownership.
And let we have a LDAP server authoritateve and secured properly.
And we tell it: "Look, this is entity. Let it be a group "DomainUsers". So there's other groups, namely "Logistics", "Accounting" and mighty "Directors". And this is another one entity. Let it be a user "Admin". And a handful of another users belonging to different groups, and let each of them belong to "DomainUsers" group as well."
And then we take a logon server and and tell it "See, there's a LDAP server mighty which is authoritative for what we can trust. Shall you have a strange walk into you, and bear the name specific, and uttered a word untold, but comparable to credentials in that LDAP server stored, must you grant that strager a token of authentication, which he would bear proudly to his name attached for his or her lifetime in our domain for authorization purposes."
And then we would take a server capable of voice interaction, and tell it: "Look, there we have that LDAP server omniscient which you may consult for all your needs. And here is the method obscure with results predictable, which you may use to check if the user is truly belong to him or herself as it verified by the logon server of ours. So you take the group of users called DomainUsers and grant them login access, but no more."
And we tell it: "Also you take group "Logistics" and grant it access to your voice services in the General channel and in Logistics channel as well, but no more."
And we tell it: "Also you take group "Accounting" and grant it access to your voice services in the General channel and in Accounting channel as well, but no more."
And we tell it: "Also you take group "Directors" and grant it access to your voice services in the General channel and in Accounting channel as well as in Logistics channel, but handle that group specifically and grant them ability to silence users they do not wish to hear or remove from channels they want for their own silent vigil, but no more beyond that."
And so we tell it: "But one exists between them, a user "Admin" named to which you should grant all the access possible and rights imaginable to handle and prepare you in any measurable way except voice interaction, which is granted by the group rights already."

Easy. Transparent. Manageable and widespread solution, easily incorporated into ANY exsisting structure.

But it was all way too easy and predictable, right? You are not the easy kind of people, obviously not. You shall invent "power" and the way to handle it... Sorry to disappoint you, but that was a complete failure. It's just too cumbersome and unpredictable, even small mistake in power propagation could grant a user access to areas he should not have any access at all, not even know they're exist. And there's no way to separate equal areas between "equally powerful" group of accounts. Neither there's any imaginable way to incorporate it into existing access control schemes. It's just flawed from the root. :/

Though you learned from it, but no. And here you inventing TSDNS in replacement to for five years existing RFC proposal, that is already quite widespread in use. Inventing wheels? Or attaching rocks to the IT industry progress?