dtcreated/ dtstamp / last-modified

Christian Mollekopf mollekopf at kolabsys.com
Wed Jun 5 11:13:46 CEST 2013


On Wednesday 05 June 2013 11.08:43 Thomas Brüderli wrote:
> Christian Mollekopf wrote:
> > On Wednesday 05 June 2013 08.45:42 you wrote:
> >> Christian Mollekopf wrote:
> >>> There are three types of relevant timestamps:
> >>> * $A: The creation date of the conceptual object
> >>> * $B: The last-modified date of the conceptual object
> >>> * $C: The timestamp of the serialization
> >>> 
> >>> Again, In terms of layers, $A and $B belong to a higher layer than $C
> >>> 
> >>> == KEP:17 ==
> >>> 
> >>> In KEP:17 I defined the last-modified [1] date to represent $B. There is
> >>> no
> >>> representation for $C in KEP:17 as it belongs to a different layer. $C
> >>> is
> >>> represented by the Date header in the MIME message [2] for Kolab
> >>> Objects.
> >>> This is not strictly correct, but was considered a good enough
> >>> approximation. After all we don't actually want the time of
> >>> serialization
> >>> we rather want to know when the file was written to storage.
> >> 
> >> Did you also consider to save the creator and last-modification user
> >> (e.g.
> >> the email address)? This might me an interesting piece of information in
> >> a
> >> groupware environment. Although I suppose that neither iCalendar nor
> >> VCard
> >> have such properties defined.
> > 
> > The only possibilty I see in iCalendar is ORGANIZER in conjunction with
> > SENT- BY:
> > 
> > "ORGANIZER;SENT-BY="mailto:sray at example.com":mailto:
> > jsmith at example.com"
> > 
> > The last-modification user is the one from SENT-BY, or the ORGANIZER if
> > SENT-BY is not available.
> > 
> > Other than that I don't think iCalendar contains a suitable property to
> > represent this. The creator wouldn't be saved in this case, but I suppose
> > the organizer plus the person who last modified the event should be
> > enough context?
> Well, that seems to be a feasible hack for iCalendar but I'm more talking
> about a general way to store creation and modification information
> (including user) to all Kolab objects. I remember a potential Kolab
> user/customer asking for such a feature.

Yes. The feature can only be implemented if we either add our own x-properties 
to the format or find suitable ones within what is specified in the rfc's.
For iCalendar it's imo either SENT-BY or an x-property as the spec doesn't 
explicitly support this. Either way, the information belongs to the xCal 
object and not the mime message.

Cheers,
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20130605/4580518b/attachment.sig>


More information about the format mailing list