At 18:46 19/10/2007, Christian Schlatter wrote: >Jiri Kuthan wrote: >>At 17:34 19/10/2007, Christian Schlatter wrote: >> >>>I don't understand why [EMAIL PROTECTED] is not unique enough? >>sometimes it is [EMAIL PROTECTED], sometimes [EMAIL PROTECTED], >>sometimes it is [EMAIL PROTECTED] or even worse you can take your spouses' >>name and from day D you begin to be [EMAIL PROTECTED], and your company >>gets acquired and you become [EMAIL PROTECTED] (Which clients without >>DNS/SRV can try to reach as [EMAIL PROTECTED], and those who pay >>extra respect to you using capital letters as [EMAIL PROTECTED]) >>The implication to sanity of data in usrloc, accounting and other tables is >>immense >>if you don't bring those to a common denominator. Any change to any name >>becomes >>a real pain. The point is names do changes, use of numbers is designed to make >>relations between tables invariable. > >Ok, this makes sense e.g. for foreign key relationships,
yes. >but isn't this more of a database specific thing? Well, I have though of it from SER angle with mysql usage and can't easily relieve myself from that viewpoint and may be a bit confused too -- how do you think a database-centric model would look like? I understand that for example the case-sensitive bit can be set as part of DB scheme definition -- is that the kind of things you have on your mind? In which case a counter-argument would be, that case-sensitiviness is a matter of local policy (i.e. app) which is more dynamic (e.g. per-domain) than schema definition is. How would a DB-specific way of dealing with things handle multiple aliases? (cs|christian|....)? If that's it, what is the division line between app's and databases responsibility? > We are using our university's LDAP based identity management system to manage > SIP accounts, and openser accesses this system directly through H.350. Our > assumption is that the SIP proxy shouldn't care about identity management at > all, so it doesn't care if it is [EMAIL PROTECTED] or [EMAIL PROTECTED] I'm not sure what it means it doesn't care.... who does resolve aliases for users (cristian|cs) and domains (.net|.com) so that whatever comes out of it can be matched to for example accounting data? who take care of case-sensitivness? >You're raising a good point, but I think identity management should not be >done in the SIP proxy. Actually what is "identity managment" -- it became a bit too popular expresssion so that its meaning is a bit fluid to me... anyhow, I will be thankful for any hints. Identity is indeed very important. >>>According to RFC 3261 section 19.1.4, SIP usernames are case sensitive, so >>>you actually shouldn't convert them to upper/lower-case. >>That's a protocol thing. An example implication is that you shall not forward >>SIP request >>to other domains whilst changing the URI. >>However, if you are processing a request for your domain, you own the >>username and the way >>you process it is subject to your policy. You can use an LDAP alias to expand >>to >>other URI, you can do call-forwarding by rewriting the URI to something >>completely >>else, you can expand a speed-dial to a full URI, you can do anything you >>desire >>with the username you own. I personally prefer to ignore case, but the key >>point >>is you are allowed to and should set a coherent policy on how you deal with >>names. > >I had to find out the hard way that asterisk is treating SIP usernames case >sensitive which lead to the decision that it is the safest to handle SIP >usernames case sensitive everywhere. It is actually a reasonable policy (at least from my POV), but a policy should not be hardwired in code. -jiri >Your're right though that this is a matter of local policy. > >/Christian > >>>And user/domain aliases is a different issue since it always involves some >>>kind of alias mapping lookup. >>That's the separate things following the same scheme indeed. If you don't >>want to >>do a data migration story on any name change, use IDs, for example UUIDs. >>-jiri >> >>>/Christian >>> >>>>See above inline for what happens when you do it other ways. In any case >>>>that's how unambiguous behaviour shall be achieved in a "water-proof" way. >>>> >>>>>So, I do not see any fundamental error here, given the subject of the >>>>>discussion. >>>>looking up user data by his username as opposed to by id is just very poor >>>>idea, >>>>let's face it. (those familiar with unix may find too that usernames are >>>>used >>>>as input/output user-interface thing, but the OS actually operates over >>>>numbers) >>>>The funny part is that getting things right is apparently not a big deal in >>>>this >>>>case, but getting it wrong can cause big headaches. >>>>I am not sure though what of it is coding and what of it is configuration >>>>thing in openser, I'm sure some will know. >>>>-jiri >>>> >>>> >>>>-- >>>>Jiri Kuthan http://iptel.org/~jiri/ >>>> >>>>_______________________________________________ >>>>Users mailing list >>>>Users@openser.org >>>>http://openser.org/cgi-bin/mailman/listinfo/users >>> >>> >>>-- >>>Jiri Kuthan http://iptel.org/~jiri/ > > > >-- >Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
