On 10/11/07, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > Elaborating on my earlier reply... > > I question whether what you are trying to achieve even makes sense to > attempt, at least in the form you have framed the problem. And I sense > the same feeling from some of the other people, though that is only my > impression. > > Increasingly, people have multiple identifier (pseudonyms?) that they > are known by in various contexts. Some of these are unique, in that > there is a well defined relationship between the identifier and a > specific human being. In other cases the relationship between the > identifier and a human is non-unique, and other information must be used > to resolve the ambiguity. Person names are of the non-unique form. URIs > used for various forms of communication, including SIP and TEL, are > often unique. > > Just as it is increasingly common for people to use multiple identities, > it is often the case that they don't desire the association between one > of these identities and their person or other identities to be known. > However this isn't always the case. Sometimes the distinct identifiers > are simply an artifact of technology, and associations between them are > willingly exposed. > > (E.g. on some online forums I use a pseudonym. The operator of the list > knows the mapping to my email address and name, but this kept private. I > may choose to include my name, email address, or phone number in a > message on this forum - exposing the relationship - or I may carefully > refrain from doing so.) > > I think you have two problems to solve here, and they probably need > different solutions: > > 1) mapping from an ambiguous identifier for a person to an unambiguous > identifier. > > 2) given one unambiguous identifier, obtain a different unambiguous > identifier which enables a particular form of communication. > > For (1) I think the best you can expect to do is have some kind of > voluntary registry (roughly akin to the phone book) that lists the names > of people and whatever information they choose to make public that might > help disambiguate them from other people, and then a corresponding > unambiguous identifier. There doesn't have to be just one such registry. > Google does an admirable job of federating many sources of such > information. > > For (2) the solution is straightforward if the association between the > identify you have and the one you want is public. If it is not public, > then you must make a request and have it granted. If the identifier you > have enables a communication path where you can make a query then the > solution is straightforward - you just ask. If the identifier you have > (say a Social Security number) doesn't enable communication, then you > must delegate your request to some entity that knows the mapping you > desire, and the policy for determining whether to grant it to you. (This > could involve communicating with the target.)
Thanks for your input. I respect your requirements. I still hope we can talk more in detail. Can we add more levels to these privacy requirements? We can assume that young users (living mostly in a cyberspace :-) know each other's pseudonyms for example? Or, I can tell you my pseudonym when we meet (and use this info for easily pairing our phones). If later you lose contact(*) you can re-initiate pairing if you remember the pseudonym. *: your phone has lost state, or you have new phone, or I changed my phone number etc. I mean the association between human name and pseudonym may not be necessarily made public. What seem like a bad idea to me is trying to combine (1) and (2) when > you don't have enough information to disambiguate. And IIUC that is what > you are proposing - to have an agent that knows the mapping from names > to phone numbers make queries to all people with matching names. IMO > there will be widespread objection to that, even if requests are > restricted to those requesters who have solved a CAPCHA. I respect your objections, but this is also an approach for another type of user IMHO. If I desperately need to talk and I have 10 candidate target users (with the same name), then I can call all of them one by one, until I find the person. Note also that, when we talk about name collisions, we should talk about a "double name collision". The querier's name appears on the target phone's screen. So, if the target user doesn't know me they will probably reject my request. Hoping that my friend didn't reject my query I can try the next one. If there are 100 candidate users, this is bad luck. But the service still works for millions of others. Thanks, pars PS: Without comment, hoping that this would give some ideas: http://www.intelius.com/phone-search-name.html Paul > > Paul Kyzivat wrote: > > > > > > Pars Mutaf wrote: > >> > >> > >> On 10/9/07, *Joel M. Halpern* <[EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> At 08:58 AM 10/9/2007, you wrote: > >> >Where did you get this information. It is private. > >> > >> Presumably, the "this" refers to the SIP URI. > >> If you don't have the SIP URI, what string do you think you > >> have? Human names are utterly useless for this, due to collision, > >> misspelling, and many other problems. > >> > >> > >> To my knowledge, phonebook users never complained about that. > > > > Phone books worked reasonably well in a different age. And they depended > > > on people being willing to advertise certain context information to the > > public at large: their phone number and an address. I think today that > > people are not so willing to disclose that information publicly. > > > > Today we often want to talk to people whose addresses we often don't > > know. Instead we may know their email address, or an IM address, etc. > > And those things are at least unique. > > > > So there are two problems here: > > - trying to find a unique address for someone given only > > some human name you have for them, and to disambiguate > > them from all the other people with similar names based > > on whatever information they might be willing to disclose > > to a random stranger. > > > > - given some unique address that is known to be associated > > with a given individual, find a different address for the > > same individual that is usable for some desired form of > > communication. > > > > The latter is probably a much more solvable problem. > > > >> The real problem of the phonebook, today, is the privacy > >> problem. An extension is needed for interactive user > >> permissions as stated by Adam Roach. > >> > >> A note about name collisions: > >> > >> Similarly to a traditional phonebook user, if you are looking > >> for a certain John Smith, hopefully you will have some > >> additional information helping filter the results. > >> > >> (in the proposed extension, the target cell phone may return > >> such information, e.g. company name, street address, etc.) > > > > I'm not likely to have my phone return that sort of information to > > unknown requestors. I don't know who would. > > > >> Note also that if anyone can send you a resolution request, that is > > >> roughly equivalent, in terms of intrusiveness, to anyone causing > your > >> phone to ring. > >> > >> > >> The proposal is rather as follows (abstract): > >> > >> You solve to a challenge ( e.g. a CAPTCHA) to obtain the target > >> phone number. > >> Then, you can make a call, send a message etc. > > > > Really! Maybe you are willing to give your information out to anyone who > > can solve a CAPTCHA, but I'm not. > > > > Note that in Adam's example you might be sending this request to dozens, > > hundreds, or more of targets that you are not interested in, and who are > > presumably not interested in you either. Then you are going to solve a > > capcha from each one enroute to finding the right one? And they are > > going to go along with this? > > > > Paul > > > >> Thanks, > >> pars > >> > >> > >> Alternatively, if you want a challenge / response on the resolution > > >> request, you can give a challenge / response on the SIP request. > >> > >> Yours, > >> Joel > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use [EMAIL PROTECTED] for questions on current sip > >> Use [EMAIL PROTECTED] for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > >
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
