dtcreated/ dtstamp / last-modified

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Wed Jun 12 14:10:11 CEST 2013


On 2013-06-05 11:13, Christian Mollekopf wrote:
> 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.
> 

x-* options are out - they are a form of compromise we should not be 
willing to make.

What about the From: and Date: headers in the RFC822 mail message?

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08




More information about the format mailing list