Before you shoot me (I agree that this is orthogonal to SIP),
thanks all for your previous input, I'm here showing you the
results of your input; the new IP pairing problem statement,
thanks.
pars
IP host pairing problem statement
Today, cell phone numbers are not published in a phonebook for avoiding
telemarketers, prank callers, Spam and SPIT (SPam over Internet
Telephony). Users today exchange their phone numbers upon user contact,
often through oral communication.
In IP telephony, users will need a user friendly "pairing" protocol
that identifies the two phones and let them exchange their SIP URIs and
Mobile IPv6 home addresses, and possibly other information. The phones
will establish an IPsec security association upon this first contact.
IPsec will be required not only for protecting their SIP URIs from
eavesdroppers, but also for protecting data.
"IP host pairing" is defined as a pairing protocol that can operate
over IP; upon user contact and also over the Internet i.e. long distances.
It will address three problems of pairing:
1. Pairing when there is user contact: In this case, users can exchange
their names or pseudonyms helping identify the hosts to each other the
first time they meet.
2. Re-pairing, or updating pairing state through the Internet: The users
may change their SIP URIs and/or Mobile IPv6 home addresses or other
information. The users will need to update these informations without
waiting until their next meeting. Or, they may need additional
information which was not previously exchanged when there was user
contact.
3. Pairing without user contact (where possible): Users may know each
other but user contact may not be possible. Or, two previously paired
hosts may lose pairing state. Users cannot probably wait until their
next meeting to recover from loss of state.
Engineering problems:
- Identifying the two hosts to each other in (1) and (3).
- Preventing unauthorized and annoying pairing attempts from unknown
users.
- The design of the pairing protocol used to exchange and update
the SIP URIs, home addresses and possibly other information.
https://www1.ietf.org/mailman/listinfo/humanresolvers
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.)
>
> 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
