I don't see any point in having a design conversation based on what might
happen to future iterations of the design.
It is of course possible, likely even that two variants of a syntax would
diverge over time. At some point there will be a decision that future
versions of the format will use only one of the syntaxes.
The happened in the XML world, at the start most specifications included
both the DTD and XML Schema definitions of the schema. Now we only use the
XML Schema version and DTDs are obsolete.
Given the way that calendar applications behave, an incompatible format
change would be no bad thing. In particular, calendar applications seem to
have no idea that there is a difference between local time and UTC or that
daylight savings rules vary with place. I don't know if there is also a
problem in the iCal format, but the applications are certainly broken.
I suspect that the problem here is the type of fourth rate 'usability'
specialists who have ruined a lot of security protocols by removing
information that the user needs from the user interface. They think that
user acceptance scores in 60 minute lab experiments are definitive. But all
that a short interaction in a lab can show you is the usability of the
application for the task you give them.
Without the ability to specify the local time when setting a recurring
appointment, a calendar application is broken. A meeting that happens at 9am
Eastern time every week is not the same as one that happens at 2pm UK time.
When I was using Outlook it would let me specify the place I was in but
didn't bother to change the time zone for me unless I did it manually and
the setting would then affect the whole machine (which of course is a
privileged operation). So when setting up a trip to the West cost for next
week, Outlook was still trying to find me meeting times in the wrong time
zone.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf