KEP2: Modification of datetime type, introduction of 'tz' sub-tag (wiki revision 10645 of 2010-11-19)

[Hendrik Helwich]

Hi Georg,

Am Dienstag, 7. Dezember 2010 18:44:34 schrieb Georg C. F. Greve:
> [...]
> But I have to say that I am a bit puzzled. Which part of
>
>   "For object types [...], clients *MUST* use the Zulu notation for
> datetime fields, so YYYY-MM DDTHH:MM:SSZ with 'T' and 'Z' as the literal
> characters. "
>
> do you see allowing all the various expressions RFC3339 allows?

well, it is in those parts of your revised KEP2 (Rev. 10707, 2010-12-06), 
you omitted here: the two bullet points preceding the third bullet point 
you quoted above (e.g. "All clients MUST parse datetime fields according to 
RFC:3339[3].") and the omission in "[...]" above (in the third bullet 
point).
In the version of your KEP2 you referred to in the subject line (wiki 
revision 10645 of 2010-11-19) simply stated "All datetime storage 
fields '''MUST''' be stored in the format described by [[RFC:3339]]"!
Actually, I believe that we all should work with clean arguments here, not 
ones based on partial omissions of own statements and 
specification-drafts.  You also changed your KEP2 throughout this E-Mail 
thread, and started quoting from the changed parts in your KEP2 
immediately, but the subject-line still referred to the then outdated, 
older version.

So, if you really do not intend "allowing all the various expressions 
RFC3339 allows", please simply rephrase the aforementioned third bullet 
point in your KEP2 to:
  "For all object types, clients *MUST* use the Zulu notation for datetime 
fields, so YYYY-MM DDTHH:MM:SSZ with 'T' and 'Z' as the literal 
characters." 
(Which is very, very close to be identical to your quoted version above!)
I first considered suggesting "For all object types, which contain a 
datetime-field, ...", but that seems to be superfluous as all object types 
contain a datetime-field e.g. for the last-modification-time of the 
object.  Furthermore you already listed all object types, so the 
list can and should be replaced by "all".
Can you please provide some background, why you introduced the lengthy 
list "'note', 'contact', 'distribution-list', 'journal', 'event' and 'task' 
objects" multiple times in your recent version of KEP2, instead of simply 
referring to "all object types", as before?

In my understanding the second bullet ("As a general rule, clients SHOULD 
always use the simplest possible expression for datetime fields.") is just 
a far weaker form of the third bullet in either form, your version (KEP2, 
Rev. 10707) or my simplified suggestion above.  Its weak, unspecific 
wording leaves some aspects undefined:
1. Is the Zulu-format meant with "the simplest possible expression for 
datetime fields"?  Please be specific.
2. "As a general rule, ..." but no exceptions defined: please name possible 
exceptions to this or omit the in my opinion misleading "As a general rule".
3. In "clients SHOULD always use", the "SHOULD always" is equivalent to 
a "MUST", if the "always" is really supposed to be always true: please 
use "MUST" and hence drop the "always".
Anyway, if there is no other mandatory statement/content than what is 
expressed in bullet #3, I suggest omitting bullet #2. 

Finally I do not understand, why the first bullet now states "All clients 
MUST parse datetime fields according to RFC3339", as there is absolutely no 
need to make this an requirement due to the fact that all datetime fields 
are written in Zulu-format according to the second and third bullet (as of 
KEP2 rev. 10707, 2010-12-06) discussed above.
I would fully understand and support writing "Clients MAY parse datetime 
fields according to RFC3339" and putting that point further down in the 
bullet list, but the normative "MUST" still leads to:
1. All FLOSS Kolab-clients have to adapt their code, except for one.
2. "Allowing all the various expressions RFC3339 allows"!
So please change the "MUST" in the first bullet point to a "MAY".

> This is about parsing only, with an eye on two factors:
>
> As Jeroen correctly pointed out, clients already must be able to parse
> this, as it is part of the email standard, which encapsulates the Kolab
> objects, not to mention that a full Kolab client is also a MUA.

Even though repeated multiple times on this list, this is *not* correct: 
1. Kolab-clients do *not* have to be able "to parse this" (all RFC3339 
format variances), as RFC3339 is *not* "part of the email standard" (at 
least not the relevant MIME-standard RFC5322 or its predecessors RFC2822 
and RFC822).  
Please explain what you specifically intended to address with this 
statement.
2. Even though a larger variance than strict Zulu-format in e-mail headers 
is allowed for timestamps, ...
2a. ... this does not mean that those datetime conversion routines inside an 
e-mail parsing library are externally accessible (usually they are not)
2b. ... in my opinion a format specification must never mandate a specific 
architectural, implementation or programming style.

> So this is about using one routine for parsing, instead of multiple
> routines, reducing the possibility of bugs and unforeseen issues in the
> maintenance of the code, which follows the principle you so wisely quoted:
>
>  "Perfection is achieved, not when there is nothing more to add,
>   but when there is nothing left to take away."
>     -- Antoine de Saint-Exupery
>
> So let's leave away that additional parser.

You are trying to mandate a specific architectural and implementation style 
for Kolab-clients here!  Please leave that up to each Kolab-client 
implementer and what is available/possible in the specific programming 
environment.
Furthermore, there often is no "additional parser" to leave away (for 
numerous reasons, as pointed out above), and then you instead mandate 
exactly the opposite: "You have to use an additional RFC3339 parser."!
Additionally the underlying technical assumption that this would be possible 
in general is simply untrue, as pointed out above: an e-mail parser does 
not have to be able to parse RFC3339, and does not have to export its 
datetime parsing capabilities at all.

Best regards,

Hendrik

> [...]