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

From: [email-masked]
Date: Fri, 8 Jun 2001 10:49:42 -0400

First off, an appology for my brief disappearance.  Real Work (TM) and 
Bronchitis conspired to keep me offline for a week and a half and Im just 
now getting dug out of the backlog...

[email-masked] wrote on 05/14/2001 11:50:59 AM:
> That is, in fact, the problem: how do you build a user interface
> that expresses the full power? It can be done, I suppose, but
> it's going to be *massively* complex, very hard for users to
> learn.

Lets not muddy the water w/different issues.  How you design a UI for this 
is separate from the eventual on the wire encoding of the settings.  If 
your concerns are really UI centric, start a new thread (that would be OOS 
for this WG anyway)...

>                                                     From that
> viewpoint, it's not a particularly complex grammar; but, from the
> viewpoint of a user who has to be able to take a recurrence rule,
> hold in their head, and maybe edit it, it's *far* too
> complicated. 

Again, this is a UI issue and not an issue w/the grammar. 

>                              To repeat the example I posted in my
> draft-stracke-calsch-rrule-subset-00.txt (unsubmitted, but posted
> to the WG:
> <http://www.imc.org/ietf-calendar/mail-archive/msg06770.html>),
> iCalendar lets you specify an event which:
> 
>    * occurs every 79 seconds,
>    * also occurs at 3:15:25 PM on the 12th, 37th, and 159th days
>      of the year,
>    * but does not occur unless it's 13 or 23 seconds after the
>      minute,
>    * and does not occur on the second Tuesday of the month.
> 
> This is absurd--and yet, any compliant implementation has to be
> able to accept it, expand it (not too hard), show it to the user
> (difficult), and let the user edit it (well-nigh impossible).

If you do not like the fact that we did not put TONS of restrictions on 
the recurrence grammar, you should have said something sooner (ie: when we 
were going thru Last Call originally).  We (the WG at large) had tons of 
chances then to say "Hmmm, ya know that I can make this event repeat every 
79 seconds?  Why would I want to?  Isn't that overkill" but there was not 
a peep like that. 

If you are now trying to make up for that, great.  However keep in mind 
that the grammar was (and still is) intended to be useful not only for 
what C&S applications/cases we can envision now (or then) but also be 
robust enough to be reused w/o change (or much change) in any future 
"calendar or scheduling like" application.  The fact that iptel is reusing 
it is partly an endorsement of that design philosphy. 

All of your cited examples (except maybe the last one) may seem outlandish 
from the POV of a C&S app developer now but I strongly believe that if it 
is possible for someone to _want_ to be able to represent something that 
matches one of the above patterns that we should be able to represent it; 
IRREGARDLESS of the recipients ability to neatly present it in the UI/GUI. 

The last example in 2445 explains how to 'decode' a complex rule into a 
textual representation (ala Outlook 98 and laters ability to do so in 
their UI) so its not necessarily "bad" that your UI cannot graphically 
represent the grammar as buttons/sliders/widgets.  Why not just 'textify' 
it and tell them "Hey, this event repeats at 3:15:25 PM on the 12th, 37th, 
and 159th days of the year" (or express the dates if you want, etc). 
Afterall, which is easier for a real human to understand: text like "This 
entry starts at 9:00AM Today and repeats every 79 seconds until January 1, 
2002" or a GUI w/lots of buttons/pulldowns/sliders/etc??  (I assume the 
CUA can create a textual representation that is somewhat coherent and have 
ignored some issues like language conversions, etc just to make this a 
simple point.)

Argh, I digressed into a UI vs use argument again.  Sorry but I plead the 
effect of antibiotics and caffine...

> (In fact, I've since realized I could've come up with something
> even more complex, since RRULE and EXRULE can each appear
> multiple times in a VEVENT.)

Heck, add enough "simple" RRULE/EXRULEs and anything can become overly 
complex.  Is that a 'fault' in the grammar or in the user/usage?

> In fact, my objections are based largely on the prediction that
> no two implementations will implement the same subset of RECUR.
> To quote my draft again:
> 
>      In order to make the user interface comprehensible,
>      each CUA will probably expose only a subset of the
>      available recurrence features to the user.  The risk,
>      then, is that different CUAs will expose different
>      subsets, and will not be properly tested for iCalendar
>      objects which stray outside those subsets.  Even if
>      they expand those iCalendar objects correctly, they may
>      not display the full recurrence rule correctly, since
>      that would require complicating the UI.  If that
>      happens, the user will wind up seeing that the
>      recurrence rule for their repeating event says it
>      occurs every Monday, but the calendar does not show the
>      event on every Monday; there are gaps.  Confusing the
>      users like this effectively means that there will not
>      be interoperability: even if the underlying iCalendar
>      implementations understand each other, the users don't.

Ok, this all still reads like a "I cant build something to represent it 
all in a GUI so I dont like it" kind of text.  See my comment above about 
Outlook and textifying the rules for human representation.

> It is not enough to be able to say "implementations A and B use
> BYSETPOS, and implementations C and D use UNTIL, so they both can
> stay in".  For iCalendar to advance to Draft Standard, there must
> be two implementations which implement the *entire* RECUR
> grammar.  In my opinion, "implement" in this case must cover the
> user interface, not just the backend.  (Patrik, am I right on
> this procedural point? I'm relying in part on your ruling that 1
> day == 24 hours would confuse the users.)

Sorry but I cant buy the tidbit about covering the UI as part of the 
implementation.  iCalendar is an on the wire format, NOT a GUI spec.  We 
are not in the business of specing UIs here, just standards so that 
different implementations can interoperate.

Patrick: We could use some AD feedback on this point about "in or out". 
Pardon me if it was already given, I have a big backlog of postings to 
read thru and Im taking them linearly.

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

---

From: "Shannon J. Clark" <[email-masked]>
Date: Fri, 8 Jun 2001 11:47:24 -0500

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.

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

Some standards are designed for highly technical users (think language
specifications, SQL standards etc) - in these cases complex grammars and a
low level usage may make sense and be a solution to how to handle areas of
high complexity. 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.

So - while I understand that we are not fundamentally in the business of
designing user interfaces, I think that a blanket statement "that is it
Off-Topic for the working group" is not true. A wire/data standard that
defeats itself when User Interfaces are attempted to be built will not be a
successful standard.

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 - if the rules cannot be entered INTO an
object - they will not be in objects to be read back. The intent of the
RRULES is to allow for highly flexible ways of encapsulating multiple
occurrences over time of something - to provide for flexibility many ways of
defining WHEN each occurrence should occur are built into the standard. Most
of the complexity comes from COMBINING these systems together - each
approach by itself is self-contained and generally reasonable - it is when
the pieces of each approach are combined that we get hard to represent or
define rules.

Furthermore - we have to strike a balance between imposing "reality" into
how the rules function - and allowing for flexibility. This leads to
questions involving hours of the year that exist in some timezones - but not
in others (for Daylight Savings changes) - which leads to the
counterintuitive situation of rules that in the present standard may have
undefined results depending on where and how timezones are applied to a
given object.

    (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?

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

Should the standard address this issue? Or similar ones like events set for
Feb 29 of a non-leap year? Is the correct behavior to IGNORE that occurrence
(which is NOT the intuitive behavior from an end-user's perspective - to
understand this, think of the BIRTHDAY set for FEB 29 - it shouldn't NOT
happen 3 out of 4 years... rather it should do something - but that
something is NOT standardized.)

Shannon
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
  Sent: Friday, June 08, 2001 9:50 AM
  To: John Stracke
  Cc: [email-masked]; [email-masked]; [email-masked]
  Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution

  Lets not muddy the water w/different issues.  How you design a UI for this
is separate from the eventual on the wire encoding of the settings.  If your
concerns are really UI centric, start a new thread (that would be OOS for
this WG anyway)...

79 seconds?  Why would I want to?  Isn't that overkill" but there was not a
peep like that.

  If you are now trying to make up for that, great.  However keep in mind
that the grammar was (and still is) intended to be useful not only for what
C&S applications/cases we can envision now (or then) but also be robust
enough to be reused w/o change (or much change) in any future "calendar or
scheduling like" application.  The fact that iptel is reusing it is partly
an endorsement of that design philosphy.

  All of your cited examples (except maybe the last one) may seem outlandish
from the POV of a C&S app developer now but I strongly believe that if it is
possible for someone to _want_ to be able to represent something that
matches one of the above patterns that we should be able to represent it;
IRREGARDLESS of the recipients ability to neatly present it in the UI/GUI.

  The last example in 2445 explains how to 'decode' a complex rule into a
textual representation (ala Outlook 98 and laters ability to do so in their
UI) so its not necessarily "bad" that your UI cannot graphically represent
the grammar as buttons/sliders/widgets.  Why not just 'textify' it and tell
them "Hey, this event repeats at 3:15:25 PM on the 12th, 37th, and 159th
days of the year" (or express the dates if you want, etc).  Afterall, which
is easier for a real human to understand: text like "This entry starts at
9:00AM Today and repeats every 79 seconds until January 1, 2002" or a GUI
w/lots of buttons/pulldowns/sliders/etc??  (I assume the CUA can create a
textual representation that is somewhat coherent and have ignored some
issues like language conversions, etc just to make this a simple point.)

  Sorry but I cant buy the tidbit about covering the UI as part of the
implementation.  iCalendar is an on the wire format, NOT a GUI spec.  We are
not in the business of specing UIs here, just standards so that different
implementations can interoperate.

  Patrick: We could use some AD feedback on this point about "in or out".
Pardon me if it was already given, I have a big backlog of postings to read
thru and Im taking them linearly.

  Bruce