Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Results 1 to 8 of 8

Thread: Rfc 2782

  1. #1
    Join Date
    August 2007
    Location
    Germany
    Posts
    24

    Question Rfc 2782

    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

  2. #2
    Join Date
    June 2008
    Posts
    18,513
    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.
    Last edited by dante696; May 23rd, 2011 at 03:40 PM. Reason: dante needs an overhaul

  3. #3
    Join Date
    August 2007
    Location
    Germany
    Posts
    24
    Quote Originally Posted by dante696 View Post
    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

  4. #4
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    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

    Code:
    _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.

  5. #5
    Join Date
    July 2002
    Location
    Germany
    Posts
    2,191
    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 ).

  6. #6
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    Thanks for the answer. Hope it won't get abandoned in process... Like it happened with normal user/group permissions.

  7. #7
    Join Date
    June 2008
    Posts
    18,513
    What are you talking about? These permissions are still there!
    http://forum.teamspeak.com/showthrea...tem-is-missing.
    When sending me private messages: Please make sure to include reference link to your forum thread or post.

    TeamSpeak FAQ || What should i report, when i open a client thread?

  8. #8
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    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?

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •