Subject: [Simple] Address and person URIs

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Jul 2004 14:48:18 -0400

In idle curiosity, I looked around a bit to see if others had thought 
about URIs representing postal and in-person resources. (2396bis 
explicitly mentions persons as resources.) One such discussion ist at

http://www.mail-archive.com/[email-masked]/msg00673.html

While we obviously don't need or want to design such a thing now, having 
some estimation as to its practicality might guide us as to whether 
relying on some future definition is prudent. After all, we wouldn't 
want to have a spec that says "We need a perpetuum mobile here; the 
details are for future study.".

The basic problem with a "human" URI is that there does not appear to be 
a unique, universally accepted identifier for humans except one that 
each human picks randomly from a very large space. References to the 
'mark of the beast' are left to other discussion venues. (Even then, I 
suspect that lots of Chinese will randomly pick human:888888 
[http://www.travelchinaguide.com/intro/social_customs/lucky_number.htm])

For human-to-human communication, it is also more often than not 
unnecessary to know which precise DNA instantiation will be meeting me. 
Indeed, for privacy reasons, such unique identification is undesirable. 
Thus, unique identifiers are the wrong model for identifying 
human-to-human interaction. While, therefore, a human is a resource, an 
identifier is unnecessary and undesirable, making a URI scheme dubious 
at best.

The problems with a "postal" URI are less severe, but the discussions 
surrounding the civic address format in the geopriv working group have 
shown that this is far from trivial. With the CIPID vcard element, it 
also seems unclear as to why this would be helpful in practice.

Henning

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jul 2004 09:39:31 -0400

inline.

> details are for future study.".

The actual proposal at http://infomesh.net/2001/03/address/ seems 
reasonable to me. It looks old though, and I suspect went nowhere. I 
think it would actually be a lot of work to do this properly, given 
issues of variations in addressing structure and hierarchy, 
internationalization issues, equality, etc.

> [http://www.travelchinaguide.com/intro/social_customs/lucky_number.htm])

I don't think we want to label a human, per se. What we really want for 
person to person communications is a place - i.e., "room 527".

> identifier is unnecessary and undesirable, making a URI scheme dubious 

Actually I suspect that, if you think of it in terms of "go here to talk 
to me", then the same postal URI structure would probably work, but just 
a different scheme.

> also seems unclear as to why this would be helpful in practice.

Well, another solution is to somehow define a URI scheme that just 
contains a reference to such a vcard.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jul 2004 15:55:29 -0400

Jonathan Rosenberg wrote:
>> The basic problem with a "human" URI is that there does not appear to 
>> be a unique, universally accepted identifier for humans except one 
>> that each human picks randomly from a very large space. References to 
>> the 'mark of the beast' are left to other discussion venues. (Even 
>> then, I suspect that lots of Chinese will randomly pick human:888888 

Well, a place isn't always sufficient. We see this all the time in the 
movies: "Meet me in the bar of tha Acme Hotel at 7pm on April 1, 2005. 
I'll have a red carnation in my lapel."

So we don't need a *globally* unique person identifier. We need a person 
identifier that is locally unique in the context of the time and 
location of the intended meeting. And the time is important too.

The time we can deal with. With regular status it is NOW. We can use 
timed-status to cover some other time.

I don't think location has to be part of the Contact, as long as it is 
provided as part of the (timed-)status along with the contact.

Coming up with URIs for identifying people locally within a particular 
time-space region sounds like future research. Sounds like some sort of 
arbitary predicate would do the trick.

>> unnecessary to know which precise DNA instantiation will be meeting 
>> me. Indeed, for privacy reasons, such unique identification is 
>> undesirable. Thus, unique identifiers are the wrong model for 
>> identifying human-to-human interaction. While, therefore, a human is a 
>> resource, an identifier is unnecessary and undesirable, making a URI 
>> scheme dubious at best.
> 
> 

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Jul 2004 17:44:56 -0400

>> I don't think we want to label a human, per se. What we really want 
>> for person to person communications is a place - i.e., "room 527".
> 
> 

I suspect that one of the desirable properties would be that the person 
doesn't change identifiers just because they changed location. If you 
don't do that, it will get very confusing - is this URI the same person 
at a different location or a completely different person? (Imagine a 
friend finder service that works in physical space.)

There is also the issue that you now have two ways to represent 
"location of a presentity", as a URI or as PIDF-LO, with contact 
information also available as a vCard.

> arbitary predicate would do the trick.

Do you want to define people by a game of twenty questions?

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jul 2004 19:42:08 -0400

Henning Schulzrinne wrote:
>> So we don't need a *globally* unique person identifier. We need a 
>> person identifier that is locally unique in the context of the time 
>> and location of the intended meeting. And the time is important too.
>>
>> time-space region sounds like future research. Sounds like some sort 
>> of arbitary predicate would do the trick.
> 

Well, it would be easier if everyone just agreed to have a barcode 
branded on their forehead and an RFID chip embedded in them, each 
containing their UN assigned global person UUID.

But I sense a lot of people don't want to be so easily or irrevokably 
identifiable. So weak forms of identification may be all that is 
generally acceptable. (Hence "I'll have a red carnation in my lapel" 
rather than "The SSN on my forehead will be 123-56-7890.")

Unfortunately, this doesn't lend itself well to URIs or URNs, because 
the information isn't Unique.

I think we continue to punt this one for now.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Jul 2004 20:02:01 -0400

> the information isn't Unique.

That would argue for my half-in-jest algorithm: a user-chosen random 
identifier with a one-to-many mapping from DNA instantiation to 
identifier. If you want to change personas or want multiple 
personalities, just pick another number.

persona:1234567

will do.

Indeed, RFC 3043 describes something similar, except that it is 
server-assigned.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jul 2004 23:20:14 -0400

I'm fine to punt, but I think this is a case where the perfect is a 
serious enemy of the good.

I think that a service URI of the form:

uri:inperson

is sufficient, without any additional per-user data. We can leave it to 
the human to figure out how to resolve the URI. Indeed, the presentity 
placetype (home, work, etc.) would probably suffice, since  a watcher 
can ususally infer how to find them within that place. We just need a 
way to say, "come talk to me". Does that cover EVERY case? No way. Does 
it cover many of the important ones? Yes.

-Jonathan R.

Paul Kyzivat wrote:

>>> Well, a place isn't always sufficient. We see this all the time in 
>>> the movies: "Meet me in the bar of tha Acme Hotel at 7pm on April 1, 
>>> 2005. I'll have a red carnation in my lapel."
>>
>>
>> I suspect that one of the desirable properties would be that the 
>> person doesn't change identifiers just because they changed location. 
>> If you don't do that, it will get very confusing - is this URI the 
>> same person at a different location or a completely different person? 
>> (Imagine a friend finder service that works in physical space.)
>>
>>> I don't think location has to be part of the Contact, as long as it 
>>> is provided as part of the (timed-)status along with the contact.
>>>
>>> Coming up with URIs for identifying people locally within a 
>>> particular time-space region sounds like future research. Sounds like 
>>> some sort of arbitary predicate would do the trick.
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Jul 2004 14:20:12 -0400

> it cover many of the important ones? Yes.

I am fine with that, although it may be difficult to register such a uri 
scheme.

	Paul

>>>> particular time-space region sounds like future research. Sounds 
>>>> like some sort of arbitary predicate would do the trick.
>>>
>>>
>>>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Jul 2004 11:58:44 -0700

At 2:20 PM -0400 7/21/04, Paul Kyzivat wrote:
>>is sufficient, without any additional per-user data. We can leave 
>>it to the human to figure out how to resolve the URI. Indeed, the 
>>presentity placetype (home, work, etc.) would probably suffice, 
>>since  a watcher can ususally infer how to find them within that 
>>place. We just need a way to say, "come talk to me". Does that 
>>cover EVERY case? No way. Does it cover many of the important ones? 
>>Yes.
>
>I am fine with that, although it may be difficult to register such a 
>uri scheme.
>
>	Paul

I would certainly suggest running it by the uri mailing list as soon
as you can.  But a worked description of the scheme might be
needed before you do that, as a bare proposal of "what about an
inperson scheme?" seems likely to attract ideas far different from those
the working group has in mind.
				regards,
					Ted Hardie

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 21 Jul 2004 15:11:09 -0400

> I am fine with that, although it may be difficult to register such a uri 

In a different context (emergency services and tel URIs), I've thought 
about a 'service' URI which indicates a generic content-oriented 
communication service. This addresses the current deficiency of the tel 
URI (really, URN) that can't express services nicely.

There may be a connnection there, i.e.,

urn:service:inperson

might do the trick.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jul 2004 13:58:37 -0400

inline.

> There may be a connnection there, i.e.,

To be clear, is your intent here that urn:service would be defined as 
allowing registered values through an IANA registry or something? i.e., 
if I come up with a new service, foo, I could register it and thus 
urn:service:foo would be defined?

I'm not sure how one would properly define the scope of "service" in 
such a context...

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Jul 2004 14:58:10 -0400

Yes.

> I'm not sure how one would properly define the scope of "service" in 

Depends on what you mean by "scope". If you mean "what does the foo 
service really mean, i.e., what do I get", I'd punt: the registrant 
defines the meaning of the service.

I had one simple model in mind: Define by resolution. Each service is 
associated with a DNS resolving hierarchy, e.g.,

urn:service:sos.arpa

is the service defined by the DNS resolution mechanism sos.arpa. The 
assumption is that any proxy that resolves this domain has to know what 
request information is necessary to do the resolution, e.g., by location 
or other request property.

This doesn't necessarily fit the 'real human being' one all that well, 
but some other services, including

urn:service:pizzahut
urn:service:directory-service

work reasonably well, as long as each service can agree on a resolution 
mechanism. This is somewhat akin to an IP-level anycast service: "I want 
any suitable instance of this service and you figure out what that might 
be".

This is obviously very rough thinking at this stage. As has been pointed 
out in private email, it is not clear that the URN definition matches 
this particularly well. However, one could argue that something like an 
ISBN URN has somewhat similar properties, albeit with a much more 
precise contract as to what one might get back.

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jul 2004 13:44:47 -0400

inline.

> defines the meaning of the service.

No. What I meant was, what are the set of things for which it would be 
valid for me to register wtihin this namespace. For example, is this OK:

urn:service:dog-washing-service

Or how about this:

urn:service:soap-binding:method-name

"service" is sufficiently broad that there is almost nothing that ISNT a 
service by someones definition...

> or other request property.

Not sure I follow here.

I was hoping to avoid anything that actually requires resolution in the 
dns. I think this increases complexity well beyond what we need for the 
problem at hand.

> any suitable instance of this service and you figure out what that might 

Well, I just think that this is a problem for someone else to solve...

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Jul 2004 13:30:00 -0400

Maybe the right model is to use a scheme, as in

inperson:

Schemes can define any means of communication. Indeed, URIs like mailto: 
(or im:) don't directly define protocols, but rather modes of 
communication. We already have common, albeit non-standard, URIs such as

about:

without any further elements. One could generalize this to

inperson:some-identifier

where the identifier is only locally defined (e.g., it's just the 
presentity URI in our case), with no global semantics.