[Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND
recurrence rules where value type is DATE
dave at cridland.net
Sat Sep 30 01:14:48 PDT 2006
On Fri Sep 29 23:12:10 2006, Sam Roberts wrote:
> Are you sure you want to tell people that they MUST accept as valid
> files that were generated in violation of a MUST? Seems odd to me
> to be
> in the business of telling people what to do with invalid data, its
> hard enough to specify what to do with valid data.
Just to pick up on this, the constructions of "MUST NOT generate x,
but MUST ignore x", or "MUST NOT generate x, but SHOULD accept x",
are quite common practise. It's a codification of when to apply
Postel's Principle - "Be conservative in what you sent, but be
liberal in what you accept".
It's all the more useful when a specification is being revised, and
we know there's bad data (or clients, or servers) in actual
deployment. Another particularly useful time is when it concerns an
invalid combination of two somewhat distinct elements. In this case,
at least the latter applies, and possibly the former.
Let's pretend you have a CUA written which has the feature of copying
a recurrence rule from one event to a new one, so for complex rules,
the user can just say "Like this one", instead of re-entering a
possibly complex rule. This text (or your replacement) gives your CUA
a clear mandate to drop BYHOUR, BYMINUTE, and BYSECOND from the
recurrence rule you're copying if it's a DATE value for DTSTART.
(As for which text, as someone merely tracking this WG, I understood
what the text meant, and took "such constructs" to mean "BYHOUR,
BYMINUTE, or BYSECOND". I don't think that "OR" should be
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Ietf-calsify