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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Oct 2004 00:49:49 -0400

Henning Schulzrinne wrote:

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

I don't see why my postal information isn't subject to open or closed, 
like anything else. Admittedly it won't change often. HOwever, if I go 
on vacation for two weeks, might I not want to change it to closed? This 
is the example Mike gave. I don't see how email or SMS or MMS, or any 
form of store and forward messaging, would be different than postal in 
this regard. I do think we have agreed that sms, mms and email are 
useful services to list in the presence docuemnt.

I agree that the cipid vcard can be used to convey my postal address. 
Perhaps then the postal "url" is nothing more than the reference to this 
vcard, perhaps in the same presence document even. However, that doesnt 
mean that postal is not a communications service as defined in the model.

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

OK, so you are saying its a url, and not a URN. I can buy that...

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

Well, except that I dont think its a joke at all.

I think it would be quite valuable to have this capability in PIDF. Its 
a real, valid, and absolutely useful form of a communications service to 
list in a presence document.

-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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Oct 2004 00:54:34 -0400

inline.

Mike Hammer wrote:

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

I strongly disagree.

In-person communications is a service as defined in our model. It has 
all of the properties of a service. Its a modality. It has 
characteristics (audio and video content, low latency), and most 
importantly, it has status (I'm available for folks to come to my office 
now). Indeed, this status is different from person status. For example, 
I as a person (using the term person as defined in the model) can be "on 
the phone", but my availability for in-person communications might still 
be open if I'm willing to answer a knock at the door while on the phone.

It also makes sense to me to be able to prioritize in-person 
communications over other services, like telephony or IM. Indeed, I 
might prioritize them differently for different watchers.

None of this would be conveyable in the model if in-person is not 
identified as a service; person doesn't convey availability for 
communcations, priority, or other characteristics.

Thanks,
Jonathan R.

---

From: Mike Hammer <[email-masked]>
Date: Fri, 01 Oct 2004 10:15:25 -0400

Hmmm...

I was never against the inclusion of the in-person service, just thought 
that once in visual contact that body language would take over.  But, I can 
see that it could save a trip down the hall if one knows someone is in, but 
not willing to have interruptions, or where that might otherwise be ambiguous.

I'm also picturing the teenager with the status set to: "talk to the hand". :)

It might also help disambiguate the case where several devices report 
wildly different locations, but you really want to know where the person 
is, mod privacy controls.

Mike

At 12:54 AM 10/1/2004 -0400, Jonathan Rosenberg wrote:
>In-person communications is a service as defined in our model. It has all 
>of the properties of a service. Its a modality. It has characteristics 
>(audio and video content, low latency), and most importantly, it has 
>status (I'm available for folks to come to my office now). Indeed, this 
>status is different from person status. For example, I as a person (using 
>the term person as defined in the model) can be "on the phone", but my 
>availability for in-person communications might still be open if I'm 
>willing to answer a knock at the door while on the phone.
>
>communications over other services, like telephony or IM. Indeed, I might 
>prioritize them differently for different watchers.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Oct 2004 11:56:08 -0400

> mean that postal is not a communications service as defined in the model.

But given its description by a vCard, it probably doesn't need a service 
URI. The problem is similar for other "generic" means of communications. 
Imagine some future SOAP-based service. It will have HTTP as a URI, 
which will not tell you much.

> Well, except that I dont think its a joke at all.

My concern is not that we don't need it, but that the reaction from 
others, outside the SIMPLE/IM community, will be less accommodating. 
Maybe I'm being too pessimistic.

> list in a presence document.

Having a service modality identifier (postal, personal, electronic) 
might be easier. Postal and personal would not need URLs.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Oct 2004 22:02:28 -0400

Mike Hammer wrote:

> that once in visual contact that body language would take over.  But, I 
> can see that it could save a trip down the hall if one knows someone is 
> in, but not willing to have interruptions, or where that might otherwise 
> be ambiguous.
> 

Right, exactly. Perhaps we should even add "talk to the hand" as a 
status element in rpid ;)

> is, mod privacy controls.

Well, that we can already do. This problem exactly is the kind of thing 
that has motivated the separation of the three components of the data 
model - person, service, and device, each of which can have its onw 
attributes. Device location and person location are not the same thing.

But the idea with in-person as a *service* is not just a vehicle for 
carrying the location of the person, its for indicating status and 
characteristics of that service.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Oct 2004 22:06:17 -0400

inline.

Henning Schulzrinne wrote:

>> on vacation for two weeks, might I not want to change it to closed? 
>> This is the example Mike gave. I don't see how email or SMS or MMS, or 
>> any form of store and forward messaging, would be different than 
>> postal in this regard. I do think we have agreed that sms, mms and 
>> email are useful services to list in the presence docuemnt.
>>
>> Perhaps then the postal "url" is nothing more than the reference to 
>> this vcard, perhaps in the same presence document even. However, that 
>> doesnt mean that postal is not a communications service as defined in 
>> the model.
> 
> 

To be clear here, if we agree that in-person is a service, then 
according to the data model it shows up as a <tuple> in the presence 
document. <tuple> includes a <contact> element which contains a URI. Our 
preferred vehicle for indicating what the service is, is with the URI 
scheme. Thus, the conundrum.

In cases where the URI is not sufficient (SIP, for example, or HTTP for 
something soap-ish), then you need characteristic information to tell 
you what the service is.

> Maybe I'm being too pessimistic.

Well, there is a real problem here, so I think one might need to explain 
the motivation first...

> 
>>
>> I think it would be quite valuable to have this capability in PIDF. 
>> Its a real, valid, and absolutely useful form of a communications 
>> service to list in a presence document.
> 
> 

So you are proposing something like <postal/> as a presence attribute 
that would simply say to use a postal address? I don't think that fits 
as well really, since the presence attributes in the service are meant 
to characterize the service, not to declare it.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 03 Oct 2004 11:37:49 +0200

> something soap-ish), then you need characteristic information to tell 

One solution is having no URI and a (mandatory) service characteristic. 
Here, class of service = (electronic, postal/courier, inperson). A URI 
implies 'electronic' service. We can then later add other service types, 
such as "remote-acoustic" (bush drums) or "visual" (smoke signals, 
semaphores, etc.). I very much doubt we'd want to define URIs for all of 
these...

We agreed that just having "no URI = in-person" is bad, but it seems 
inappropriate to define a pseudo-URL scheme that doesn't really 
correspond closely with other URL schemes and contains no real 
information. With the service label, there is no ambiguity and old PIDF 
interpreters won't get confused.

> to characterize the service, not to declare it.

Not quite:

<service-class>postal</service-class>

This is just another characteristic of the service, along with all the 
other prescaps and similar characterizations that we already have.

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Oct 2004 03:36:25 -0400

inline.

Henning Schulzrinne wrote:

>> document. <tuple> includes a <contact> element which contains a URI. 
>> Our preferred vehicle for indicating what the service is, is with the 
>> URI scheme. Thus, the conundrum.
>>
>> In cases where the URI is not sufficient (SIP, for example, or HTTP 
>> for something soap-ish), then you need characteristic information to 
>> tell you what the service is.
> 
> 

Hmm, so I think what you are saying is something like this - the contact 
URI is absent for services that are not "electronic" in nature and not 
well represented by a URI. For those, and *only those*, services, we can 
define a <service-type> element that enumerates non-electronic forms of 
communications.

> other prescaps and similar characterizations that we already have.

I might add that, instead of just a string, the value of <service-class> 
could be more structured, and include information on invoking the 
non-electronic service. In the case of postal, it could contain the 
reference to the vcard, or the address itself inline:

<service-class>
   <postal>
     <street-number>600</street-number>
     <street-name>Lanidex Plaza</street-name>
     <city>Parsippany</city>
     <state>NJ</state>
     <zip>07054</zip>
   </postal>
</service-class>

I could live with that.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Oct 2004 04:31:28 -0400

> define a <service-type> element that enumerates non-electronic forms of 

Almost. For regularity, the rules would be:

- if there is a contact URL, the allowable service class is 'electronic'
- if there is a URL but no service-type, service-type 'electronic' is 
implied
- if there is no URL, a service-type element MUST be specified for a 
conformant document

>     <street-name>Lanidex Plaza</street-name>

Defining the postal details may well be non-trivial, unless one simply 
copies some XML-based version of vCard. Thus, expediency suggests 
referencing the vCard. In practice, the address is pretty constant in 
time, so a reference seems more efficient as well.

This sounds like an RPID addition?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Oct 2004 11:19:21 -0400

Henning Schulzrinne wrote:

>> Hmm, so I think what you are saying is something like this - the 
>> contact URI is absent for services that are not "electronic" in nature 
>> and not well represented by a URI. For those, and *only those*, 
>> services, we can define a <service-type> element that enumerates 
>> non-electronic forms of communications.
> 
> 

I think that this is effectively the same thing.

> 
> 
>> I might add that, instead of just a string, the value of 
>> <service-class> could be more structured, and include information on 
>> invoking the non-electronic service. In the case of postal, it could 
>> contain the reference to the vcard, or the address itself inline:
>>
>> <service-class>
>>   <postal>

Yes and no.

The data model would need to be updated to make it clear what the URI 
means when present, and what it means when its not - look for data in 
other places to identify the service.

RPID should probably define an abstract service-type (we need a 
different name, though, to make it clear that this is NOT a way to 
represent that this service is PTT or videophone).

Details for in-person and postal could then go anywhere. I would prefer 
not to increase the scope of the things in rpid; postal is something 
new, and probably belongs in a separate draft. in-person is debatable 
since we've sort of had it and sort of not.... I could go either way.

Other opinions?

-Jonathan R.