KEP2: Modification of datetime type, introduction of 'tz' sub-tag (wiki revision 10645 of 2010-11-19)
Hendrik Helwich
h.helwich at tarent.de
Thu Dec 9 11:08:52 CET 2010
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
> [...]
More information about the format
mailing list