Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc.

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Mar 2005 01:24:04 -0500

Henning Schulzrinne wrote:
> Paul Kyzivat wrote:
> 
>>
> 
>> Yes, I think that something of that sort may be needed, or at least 
>> desirable. (glob style anyway.)
> 
> 
> So far, prefix (for user names) and postfix (for hosts) seems to be 
> working for the examples (which is also similar to the SQL "LIKE %" 
> facility).

sip:*@*.columbia.edu ???

>> Something else that hasn't been touched upon is watchers whose 
>> identity is a tel uri. I think we have to expect that there will be 
>> such. Its ugly, but I think there will be need for special matching on 
>> various parts of these.
> 
> 
> I don't see tel:12*15*7
> 
> as all that useful.

agree that there is little utility in *full* generality. But I can see 
tel:+1978936*, tel:+1900*, or tel:*;phone-context=*.cisco.com. (And tel 
wildcard matching needs to know to ignore visual separators even when 
wildcarding - but maybe this is obvious.)

>> Yes, these are significant issues. Are you going to keep two different 
>> sets of business cards and make a decision about which one to give to 
>> someone? (The plain white ones, and the "platinum" ones.)
> 
> 
> I suspect this is more useful for the address you put on your web page 
> ("is my shop open?") vs. your business card.

Thing is, the phone number may be gotten any number of ways - even via 
"callerid" from a missed call. There is interest in using presence as an 
enabler for callbacks, when that is all you have.

>> I haven't got a particular mechanism in mind. But I agree there is 
>> some similarity between saying "I calling but I just want your 
>> voicemail server", and saying "I want whatever presence I can get 
>> without going into pending and requesting approval".
> 
> I wonder if the caller preferences mechanism couldn't be extended to 
> handle this type of mechanism pretty easily.

Well, the callerpref mechanism is structured for allowing the caller to 
select among alternative contacts in the translation of the R-URI. This 
doesn't fit well into that paradigm. So it is a least a non-trivial 
extension.

	Paul

>> The point was that phone numbers are somewhat scarce. You probably 
>> often won't be willing to have one for your buddies and another for 
>> everybody else. And then there will just be one on your business card.
> 
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Mar 2005 02:16:48 -0500

inline.

Henning Schulzrinne wrote:

>> People can be very resourceful. It won't take long for somebody to 
>> begin to discern the pattern of addresses you use. (e.g. 
>> [email-masked])
>>
>> I think there will continue to be a demand for flexible techniques to 
>> denote specific classes of addresses based on patterns in the address.
> 
> 
> Agreed, but we need to find a reasonable cut-off point of complexity and 
> predictability. You seem to be arguing for supporting general regular 
> expressions or at least "glob" style expressions, which is beyond what 
> we're currently describing, for either black or whitelists.

Yes, and beyond the existing deployed systems I'm aware of. Please, 
folks, this draft has been delayed for eons now, partly due to scope 
creep. Lets keep glob matching out.

>> I agree it is a problem that we haven't dealt with. But I am not sure 
>> that two distinct presentity names is the right solution. Then I need 
>> to manange two names, and ensure that the right name gets in the hands 
>> of each person.
> 
> 
> Unlike with unlisted phone numbers, getting the wrong one to a 
> subscriber isn't as bad since the name doesn't convey authorization. I 
> do agree that this name mapping is sub-optimal since it makes it fairly 
> obvious that you're handing out different rights and makes it really 
> difficult to change rights (upgrade or downgrade) without handing out a 
> new name.
> 
> You'd almost want some kind of caller preferences where the SUBSCRIBEr 
> can say "I'd like to ask for confirmation" or "I'm not willing to 
> authenticate so just give me what you are going to give to random 
> strangers" or "I want the maximum possible information and am willing to 
> jump through a ChoicePoint verification and lie detector test if I have 
> to". (Might be easier to just pick up a suitable identity from your 
> friendly identity retailer courtesy of that same company, but we'll 
> leave that aside.)

Egads - please can we also keep this out of scope?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2005 09:21:38 -0500

I don't think we need to boil the ocean today, as long as we make 
provision for extending the pattern matching later.

	Paul

Jonathan Rosenberg wrote:
>> Agreed, but we need to find a reasonable cut-off point of complexity 
>> and predictability. You seem to be arguing for supporting general 
>> regular expressions or at least "glob" style expressions, which is 
>> beyond what we're currently describing, for either black or whitelists.
> 
> 
>>> to manange two names, and ensure that the right name gets in the 
>>> hands of each person.
>>
>>
>>
>> do agree that this name mapping is sub-optimal since it makes it 
>> fairly obvious that you're handing out different rights and makes it 
>> really difficult to change rights (upgrade or downgrade) without 
>> handing out a new name.
>>
>> strangers" or "I want the maximum possible information and am willing 
>> to jump through a ChoicePoint verification and lie detector test if I 
>> have to". (Might be easier to just pick up a suitable identity from 
>> your friendly identity retailer courtesy of that same company, but 
>> we'll leave that aside.)
> 
>