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

James M. Polk wrote:
> At 11:00 AM 3/20/2003 -0500, Henning Schulzrinne 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.
>>
>>
>> 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?

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
jdrosen <at> dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com