Subject: Comments on draft-morris-geopriv-core-01

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Mar 2003 16:58:27 -0500

In IPTEL, we have defined a "policy language", CPL, that might serve as 
a good model for some of the constraints, in particular combinations of 
time (including time ranges), persons and actions.

In particular, defining repeating time intervals sounds easy, but is 
rather tricky. (IPTEL and calsch spent extremely long time on getting 
this close to right - a student in my group, Jonathan Lennox, showed 
that the rules in the original calsch specification were buggy and, in 
addition, could have effectively unbounded complexity).

We are currently working on an extension for handling subscriptions and 
notifications. It appears that this might well be applicable to express 
some of the more complicated policy constraints, such as notification, 
geographic constraints, time constraints, logging and combinations of these.

As a side note, I believe that 'logging' should be a valid element, so 
that I can find out who asked for my location.

I have to admit that "Element K" (express permission) worries me, as I 
have a hard time picturing a generic mechanism. In the presence case, 
this is easy - SUBSCRIBE usually requires an explicit permission. 
Outside that context, this seems to span an almost infinite variety of 
mechanisms, including issues such as what counts as permission. Does 
'clicking' on a button count? How much information needs to be 
presented? Etc.

The work on notification filtering that Jon, I think, mentioned, is 
orthogonal to that - it addresses limitations chosen by the watcher (to 
use SIMPLE/CPIM terminology).

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Mar 2003 01:12:35 -0600

>that I can find out who asked for my location.

This is one of John Morris's requirements that I agree with (not that I 
don't agree with most of his others) - so I believe as well this 
NOTIFY-type message should be defined by Geopriv

>Henning

cheers,
James

            *************************************
        "The road to destruction is well traveled and crowded,
if you choose to get on that road, destruction will hit you head on"

---

From: John Morris <[email-masked]>
Date: Thu, 20 Mar 2003 00:19:22 -0800

At 04:58 PM 3/19/03 -0500, Henning Schulzrinne wrote:
>In IPTEL, we have defined a "policy language", CPL, that might serve as a 
>good model for some of the constraints, in particular combinations of time 
>(including time ranges), persons and actions.
>
>rather tricky. (IPTEL and calsch spent extremely long time on getting this 
>close to right - a student in my group, Jonathan Lennox, showed that the 
>rules in the original calsch specification were buggy and, in addition, 
>could have effectively unbounded complexity).

I can imagine that it is complex.  One possible approach to consider -- if 
it would significantly reduce the complexity (something I do not know) -- 
would be to define a simpler subset of time window capability for possible 
inclusion in a Location Object, with the directive that if one needs a 
fully robust expression of time windows then one must use an external set 
of privacy rules.

Stated more generally, if we can accomplish a subset of element x within 
the LO, and thereby address a high percentage of the likely desire for 
element x, then that should be good enough for the location object 
itself.  I would prefer to have a subset of an element if a fully robust 
implementation of an element proves to be too complex for the LO.

>have a hard time picturing a generic mechanism. In the presence case, this 
>is easy - SUBSCRIBE usually requires an explicit permission. Outside that 
>context, this seems to span an almost infinite variety of mechanisms, 
>including issues such as what counts as permission. Does 'clicking' on a 
>button count? How much information needs to be presented? Etc.

I have to defer to you, Jorge, and the rest of the list on whether your 
concerns are surmountable.        I believe that Jorge initially suggested 
this element, and so he should weigh in on this point.  (I believe, 
however, that he may well be starting his trip back to Germany before he 
gets a chance to respond....)

>use SIMPLE/CPIM terminology).

Henning, fyi, I've thought further about concerns you have raised about the 
difficulty of the identification element, and I'll try to frame the issue 
and possible narrowing back to the list shortly.

John

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Mar 2003 11:00:22 -0500

> I can imagine that it is complex.  One possible approach to consider -- 
> if it would significantly reduce the complexity (something I do not 
> know) -- would be to define a simpler subset of time window capability 
> for possible inclusion in a Location Object, with the directive that if 
> one needs a fully robust expression of time windows then one must use an 
> external set of privacy rules.

Unfortunately, I think that many of the rules we'd like to express are 
the difficult ones. Take a rule that applies "during business hours" (to 
take an example from one of the drafts). This could simply mean "M-F 
9-5", but what about exceptions such as holidays, vacations, etc? If you 
have to update the rules during each vacation and holiday, you might as 
well just have daily rules.

We should probably distinguish as to what's in the LO from the location 
generator and what's in the LO from the location server. I think that 
the first interface could simply have "invoke my rule 42", and then the 
rulemaker translates this into "rule 42 = weekday; today is a weekday, 
thus create LO with delivery limit until 5 pm today". There is then no 
need to include the detailed information in the LO handed to the 
Location Recipient.

We have this notion in RPIDS (a presence format), in the form of the 
'class' identifier.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Mar 2003 19:04:40 -0600

At 11:00 AM 3/20/2003 -0500, Henning Schulzrinne wrote:
>>if it would significantly reduce the complexity (something I do not know) 
>>-- would be to define a simpler subset of time window capability for 
>>possible inclusion in a Location Object, with the directive that if one 
>>needs a fully robust expression of time windows then one must use an 
>Unfortunately, I think that many of the rules we'd like to express are the 
>difficult ones. Take a rule that applies "during business hours" (to take 
>an example from one of the drafts). This could simply mean "M-F 9-5", but 
>what about exceptions such as holidays, vacations, etc? If you have to 
>update the rules during each vacation and holiday, you might as well just 
>have daily rules.

Couldn't this be accomplished by tying your rules into your 
calender/scheduler program?

cheers,
James

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Mar 2003 23:03:42 -0500

James M. Polk wrote:
>>> I can imagine that it is complex.  One possible approach to consider 
>>> -- if it would significantly reduce the complexity (something I do 
>>> not know) -- would be to define a simpler subset of time window 
>>> capability for possible inclusion in a Location Object, with the 
>>> directive that if one needs a fully robust expression of time windows 
>>> then one must use an external set of privacy rules.
>>
>>
>> the difficult ones. Take a rule that applies "during business hours" 
>> (to take an example from one of the drafts). This could simply mean 
>> "M-F 9-5", but what about exceptions such as holidays, vacations, etc? 
>> If you have to update the rules during each vacation and holiday, you 
>> might as well just have daily rules.
> 
> 

Yes, exactly. And the scheduler program uses ical, which is the object 
that will get spit out by the program. If this object is not compatible 
with geopriv (meaning that there is loss of information because the 
geopriv object cannot convey the same calendaring information as your 
scheduler program), you get incompatibility and unpredictable behavior.

We went through this for a whole year in iptel. The lesson is - if you 
want calendaring information to be exported from your scheduling program 
into another protocol, that other protocol has to support the full 
calsch (rfc2445) semantics (syntax is not important).

-Jonathan R.

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