Subject: Re: [Simple] comments on rpids-01 - <placetype>

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Jun 2003 11:32:23 -0400

Peterson, Jon wrote:

> Well, I think it's pretty unlikely that, say, geoloc will be able to be
> transformed into a <placetype> anytime soon, and even setting cell-phone
> profiles is user entry. It seems to me that these have a realistic
> dependency on user provisioning. 

In addition to the real-life BlueTooth example I gave in an earlier 
note, the transformation from geoloc into placetype isn't all that 
difficult, at least for the common cases. All I need is a trivial 
mapping that says "if geoloc is within polygon X, I'm at home; if in 
polygon Y (covering the area between 110 and 120th Street and Broadway 
and Amsterdam), I'm at my office; otherwise, default to public". This 
doesn't deal with all cases, such as visiting other places, but it will 
be correct at least 90% of the time, with no central database, new 
protocols or anything else beyond basic geoloc.

> 
> But my argument above was really that the specific use for which <placetype>
> and <privacy> were defined in the current document is irrelevant to
> automatons - basically, that if all these indicators tell you is what sorts
> of communications with the presentity might be appropriate, automatons
> aren't going to be able to help you much with that. So sure, if there were
> registered values, an automaton might understand them, but then what would
> it do, exactly? Probably just render them to you, so you can see what kind
> of communication is appropriate. Same thing it would do with a note. 

We may have somewhat different models of end system behavior. In my 
model, end systems (watchers) can also have processing logic. (In 
addition, end systems don't need to be PDAs or PCs running an IM 
application with smiley buttons.) In that model of end system 
intelligence, structured information is far more useful than random 
notes in <note>. For example, my end system logic can prioritize tuples 
that offer private communications, they can assign suitable icons that 
allow me to quickly distinguish home from office addresses or they can 
include appropriate warnings before I make a call. All of these require 
structured information.

In addition, when publishing presence information, this allows to 
construct easy rules. For example: "only publish office contacts to my 
co-workers; only publish 'home' contacts to my friends list". Again, a 
<note> isn't going to do this reliably.

> 
> If we change the motivation for these elements, we might draw a different
> conclusion, of course. I'm only speaking to the current motivation in the
> draft, not any other usage of these elements. 

I've added some additional motivational wording for <placetype> and 
<privacy>.

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