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.)
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.
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
