Subject: [Simple] Pres Data Model Open Issue #1: in-person communications

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Sep 2004 17:05:44 -0400

Currently, there is no easy way to incorporate the notion of "in person" 
or "written/postal" communications as services represented in the data 
model. The reason is that there is no URI scheme for them, and no 
attributes that can be used to define them. The issue is, what to do 
about this?

My proposal is to punt the issue in this document. State that it is 
expected that future specifications will address how to represent these.

To actually solve the problem, I think the right approach is to define a 
URN scheme along the lines of "urn:inperson" to represent an in-person 
communications scheme. For postal communications, I think you want a URN 
that includes the postal address, something like 
urn:postal:sname=Lanidex%20Plaza-snumber=600-state=NJ-city=Parsippany-zip=07054 
or something like that. Thats probably a fairly hard problem to solve, 
and I think even less important for us to tackle.

However, we can defer working on either of those in earnest for a bit, 
until our basic work is done.

Comments?

Thanks,
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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Sep 2004 20:00:54 -0400

I agree, although the two examples you give are rather different in 
their usefulness.

In practice, status information for the postal elements is not 
particularly useful as it doesn't tend to change a lot. Your postal 
availability is not exactly something subject to OPEN/CLOSED. Plus, the 
CIPID vcard element already allows to express this.

The in-person indication is definitely more useful for coordination. I'd 
argue you'd actually want a "protocol" indication, not a URN indication, 
since you've already identified the person.

As you said, this can easily be solved by a convention, maybe suitably 
defined in an April 1 RFC, along with the carrier pigeon URL.

---

From: Mike Hammer <[email-masked]>
Date: Wed, 29 Sep 2004 11:14:35 -0400

The location information is not the presentity, but an attribute of the 
in-person capability.

What about providing a postal availability to tell your friends that you 
are in town, in a hotel, in the lobby for direct communication, rather that 
have two people on opposite sides of the same lobby (perhaps obscured by a 
plant) trying to talk over cell phones?

I think the possibility of using presence to determine proximity is a 
useful indication.  So long as this can be deduced from the information 
provided in the presence document, then this issue is covered.

Mike

At 08:00 PM 9/28/2004 -0400, Henning Schulzrinne wrote:
>I agree, although the two examples you give are rather different in their 
>usefulness.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Sep 2004 11:19:40 -0400

I'm not sure I understand your comment completely, but general physical 
location for presentities, in both civic (street/city) and geospatial 
format, are available in the PIDF-LO document, recently finished. Note 
that postal addresses are often not a good approximation to physical 
location. (You probably don't want to meet at my PO box, but there are 
other cases that are less obvious.)

Mike Hammer wrote:

> are in town, in a hotel, in the lobby for direct communication, rather 
> that have two people on opposite sides of the same lobby (perhaps 
> obscured by a plant) trying to talk over cell phones?
> 
>> availability is not exactly something subject to OPEN/CLOSED. Plus, 
>> the CIPID vcard element already allows to express this.
>>
>> The in-person indication is definitely more useful for coordination. 
>> I'd argue you'd actually want a "protocol" indication, not a URN 
>> indication, since you've already identified the person.
>>
>>> Currently, there is no easy way to incorporate the notion of "in 
>>> person" or "written/postal" communications as services represented in 
>>> the data model. The reason is that there is no URI scheme for them, 
>>> and no attributes that can be used to define them. The issue is, what 
>>> to do about this?
>>> To actually solve the problem, I think the right approach is to 
>>> define a URN scheme along the lines of "urn:inperson" to represent an 
>>> in-person communications scheme. For postal communications, I think 
>>> you want a URN that includes the postal address, something like 
>>> or something like that. Thats probably a fairly hard problem to 
>>> solve, and I think even less important for us to tackle.
>>> However, we can defer working on either of those in earnest for a 
>>> bit, until our basic work is done.
>>> Comments?
>>> Thanks,
>>> Jonathan R.
>>
>>

---

From: Mike Hammer <[email-masked]>
Date: Wed, 29 Sep 2004 13:22:49 -0400

On the other hand, not all folks carry GPS devices, so the ability 
somewhere to convert a Lat/Long to a street address is useful.

But, to clarify my early point, if the person location information is 
available via presence, then the need to define an in-person communications 
means is probably moot.

Mike

At 11:19 AM 9/29/2004 -0400, Henning Schulzrinne wrote:
>>>>the data model. The reason is that there is no URI scheme for them, and 
>>>>no attributes that can be used to define them. The issue is, what to do 
>>>>about this?
>>>>To actually solve the problem, I think the right approach is to define 
>>>>a URN scheme along the lines of "urn:inperson" to represent an 
>>>>in-person communications scheme. For postal communications, I think you 
>>>>want a URN that includes the postal address, something like