Subject: RE: RECUR Subset and IPTel's CPL: Need Resolution

From: [email-masked]
Date: Mon, 11 Jun 2001 12:18:44 -0400

[email-masked] wrote on 06/08/2001 12:47:24 PM:
> While there is a difference between writing a User Interface 
> standard and writing a data/wire standard the two ARE connected 
> whether we like it or not.

Sure, they are connected in that the UI needs to represent in some fashion 
the content recieved over the wire.  However just because we do not have a 
UI yet that can handle the full extensibility of the format is no reason 
to say "Lets cut this back now".  As we progress in our ability to devise 
better UIs we would then have to readd it all back in and go thru this 
process again.  Since we have already provided a means for a UI to convey 
back "Hey, I cannot grok this complex (or long or ...) recurrence rule so 
I will not accept it" I do not think that a UI argument justifys cutting 
stuff out that we will probably add back in at some point.

Had that argument used for, say, web searching or other kinds of data 
models/formats then fuzzy logic searches or matches would not be doable 
now.  Nor would natural language processing (aka "Knowledge Management" to 
some folks).  These new technlogies greatly extend the very simple "Enter 
search text" input boxes that can only do literal search matching.

Who is to say that someone does not write a tool that takes in literal 
text like "Every four years, the first Tuesday after a Monday in November, 
forever" and geneates the proper RRULE as an output??  Given the text at 
the end of 4.3.10 (top of p. 45) that it should not be nuclear science to 
at least 'textify' the incoming RRULE (assuming it was not malformed and 
adheres to the currently accepted recurrence rule updates/restrictions) so 
I do not buy that it cannot be done at all. 

> Look at it this way - if the standard is NOT representable in a 
> manner that allows for interoperability the standard is dead on arrival. 

The UI abilities will eventually catch up.  So should we hamstring the 
standard now to make the UI coders life simpler now or should we leave it 
as robust as it is now and let them catch up (and then add back in all 
that we took out)??  Id hope that the former case is not the concensus...

If our only problems in the standard are that the UI cannot easily 
represent something that no existing UI will generate yet then I dont 
think this is really a problem.  Sure, if someone wanted to hand craft a 
nasty RRULE they could but is that a viable justification?  I dont believe 
it is.  That would fall under the 99/1 rule at best I think.

>                                           However, Calendaring and 
> Scheduling is an area intended for WIDE usage by users of all sorts 
> (including non-human "users" like CPL) - this means that we very 
> much have to consider whether or not our standard will serve as a 
> foundation for tools that can be developed for wide usage - if it 
> cannot be, or if doing so requires making compromises that lead to 
> interoperability issues - such as not fully supporting "required" 
> sections of the standards or more subtly supporting them in ways 
> that lead to varying behavior from the perspective of the end user -
> such as displaying or interpreting Reoccurrence rules in a different
> manner - we are unlikely to had widespread and useful adoption of 
> iCalendar and related standards.

Sounds like you are expecting lots of cross over between different kinds 
of C&S systems and non-C&S systems that both utilize our recurrence 
model/grammar.  I suspect that its more likely that they will not intermix 
and have problems.  If any implementor of the grammar also implements a 
mechanism for dealing with rejection or negotiation (ie: Like we did with 
REQUEST-STATUS and CPL did with reply codes) then these problems you fear 
so much should be manageable.

This also smells like the "smallest common footprint" argument that was 
going around for a while a long time ago.  Some folks claimed that the 
full set of features in iCalendar (besides the recurrence model) were too 
big for small footprint devices like Palms or Cell Phones and that stuff 
needed to be cut.  If that were the case then it would not be possible to 
make an "Enterprise scalable" iCalendar based system since it would only 
have a tiny set of features that could fit into a small device.  The 
feature set would be too minimal to make it unpalatable to the user base 
that would expect LOTS of features on their desktop calendar system.

> Successful standards have managed to accommodate a wide range of 
> user interfaces by in general avoiding areas that highly complex to 
> represent - I think that as they are currently defined, even with 
> the proposed changes in the latest Draft of a new version of the 
> iCalendar standard - the Reoccurrence Rules section IS still very 
> complex - with good reason perhaps - but well worth time and 
> attention and thought about how to represent to END USERS the rules 

Feel free to start some UI discussion if you like.  However I think we all 
agree that C&S is definitely a VERY complex beast to do well in either a 
standards or a proprietary way.  As such I think that we (the WG) need to 
roll up our collective sleeves, make sure we all understand the issues and 
then work together to come up with viable solutions that can be 
implemented going forward.

> - if the rules cannot be entered INTO an object - they will not be 
> in objects to be read back. 

Im not sure if you are saying that becuase a UI cannot now represent the 
very very complex (and still rarer) kinds of examples that have been 
tossed around of late that they cannot be put into the iCalendar object 
that is sent out or something else.  As you noted before and I have 
suggested above, the ability to generate a very complex recurrence rule is 
orthogonal to being able to render one that is received.  Since a UI may 
not be able to render a rule (even a moderatly simple one) that it does 
not generate is not a good justification for some arguments.  (After all 
Outlook uses RRULEs with BYSETPOS in them but they choke on RDATEs, a much 
much simpler construct to deal with than a grammar!!)

>     (What I mean by this is the following - generally from a USER's 
> perspective the USER lives in a given timezone - thus the USER's 
> calendar should be represented in that timezone. If a given event is
> sent out to a group of users, if the event is set for 2:30AM every 
> Day (to use easy RRULES) and is set for a timezone with Daylight 
> Savings rules - there will one day a year when the event encounters 
> an issue - it is set for a time that does not "happen" - how is the 
> system supposed to deal with this?

I think you've been drinking w/Damon a bit... ;^)

What I would posit is that just because officially my clock is supposed to 
automagically shift forward/backward at a predetermined date/time for my 
time zone; this does not actually mean that all of them really do.  (Who 
here does not have to manually readjust your VCR, DVD, Alarm Clock, 
Wristwatch, or even computer clock in some cases??)  As such, it is 
somewhat logical for a CUA to consider the entry as 'missed' or 'past' 
when the clocks magically move forward.  For the back case, I would not 
suggest that they 'reoccur' unless you have the funky case of a multiple 
repeating alarm w/a sub-shift repeat interval in which case Im open to 
suggestions.

Sure the TZ shift 'hits' need to be dealt with in a reasonable manner but 
as I noted before this shift occurs at a rather unusual time for most 
business to be transacting and it these shifts happen in less than .55% of 
the the possible days in the year.  The boundary cases should be addressed 
but I would not fixate on it given its relative occurance (Typically on a 
weekend, very early in the AM even).  I think we have some bigger and more 
important stuff to resolve (like recurrence rule handling, TZ naming, 
etc).

> Further, take the following example - remove the TIMEZONE from the 
> event in question - that is place it into the LOCAL time of the user
> - now the "event" will have highly varying behavior as users around 
> the globe go through daylight savings changes on different days (and
> some do not).

Just dont forget that if a CU is mobile then you will have to 'readjust' 
yet again and that may mean reshifting an entry yet again so you would 
probably want to know the original TZ and its rules since that can be 
simpler when rerolling sets than shifting back to UTC and then to another 
local TZ.  But Ill leave it as an exercise to the UI coders... ;^o

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...