4 commits - KEP-0017.txt

Christian Mollekopf mollekopf at kolabsys.com
Wed May 23 14:42:32 CEST 2012


 KEP-0017.txt |   74 ++++++++++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 56 insertions(+), 18 deletions(-)

New commits:
commit bc9d29ddaefb218f19146873f65c2c3f6d7732d9
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed May 23 14:42:02 2012 +0200

    Attendee updates (delegation, cutype)

diff --git a/KEP-0017.txt b/KEP-0017.txt
index edff195..4263f4c 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -667,7 +667,15 @@ Implements:
         "OPT-PARTICIPANT" |
         "NON-PARTICIPANT"
       } } ?,
-      element dir { element uri { [[#UID|uri-uid]] } } ?
+      element dir { element uri { [[#UID|uri-uid]] } } ?,
+      element delegated-to { element cal-address { [[Mailto URI]] } + } ?,
+      element delegated-from { element cal-address { [[Mailto URI]] } + } ?,
+      element cutype { element text {
+        "INDIVIDUAL" |
+        "GROUP" |
+        "RESOURCE" |
+        "UNKNOWN"
+      } } ?,
     }?,
     element cal-address { [[Mailto URI]] }
   }
@@ -690,13 +698,22 @@ A contact '''MAY''' be referenced using the [[#UID|uri-uid]].
 :* "REQ-PARTICIPANT": Indicates a participant whose participation is required.
 :* "OPT-PARTICIPANT": Indicates a participant whose participation is optional.
 :* "NON-PARTICIPANT": Indicates a participant who is copied for information purposes only.
+* "dir": A uri pointing to a directory entry of the attendee.
+* "delegated-to": Specifies the address of a calendar user to whom the attendee delegated participation.
+* "delegated-from": Specifies the address of a calendar user that has delegated his participation to this attendee.
+* "cutype": The type of attendee. This parameter '''SHALL''' default to "INDIVIDUAL".
+:* "INDIVIDUAL": Marks the attendee as an indiviual.
+:* "GROUP": Marks the attendee as a group of individuals. Useful to add e.g. a mailinglist as attendee.
+:* "RESOURCE": Marks the attendee as a physical resource. Used for Resource Management.
+:* "UNKNOWN": Should not be used.  Undefined semantics.
+:* "ROOM": Should not be used. Undefined semantics.
 
 Implements:
 * {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.4.1 section-3.8.4.1]
 
-{{note|cutype for resource management|By using cutype it would be possible to mark an attendee as i.e. a room or car, which would be useful in resource management.}}
 {{note|cal-address/dir|While a urn uri would also be valid in cal-address according to iCal, dir seems to be more according to the intentions of iCal, as a uri for a vcard is not strictly a "contact address"}}
 {{note|cal-address|The cal-address would allow for any uri, it was restricted to keep clients from having to handle arbitrary contact mediums.}}
+{{note|cutype|Not sure if we should have "UNKNOWN" and "ROOM" as part of the format, as they are only here for compatibility reasons.}}
 
 ===== Attachment =====
 


commit a4ecbacbad76065efeefd981d6a2247a30437689
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed May 23 14:41:12 2012 +0200

    Some more info regarding the sequence number which is required for iTip message handling.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 5c2d7ba..edff195 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -365,10 +365,11 @@ This property '''MUST''' be increased by one everytime the object is modified.
 
 The initial value of this property '''SHALL''' be zero.
 
+This property is used primarily for iTip message handling.
+
 Implements:
 * {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.7.4 section-3.8.7.4]
-
-{{note|Needs clarification: Relevance|Its set by korganizer but whats the usecase? It is used in recurrence id matching to identify the exactly same instance (I believe). The last modification date should be enought though.}}
+* {{rfc|5546}} [https://tools.ietf.org/html/rfc5546#section-2.1 section-2.1]
 
 ===== Recurrences =====
 


commit df656c5c34aca10501523ebab04967780fd7c192
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Mon May 21 18:56:17 2012 +0200

    We need both lastmodified-date and dtstamp for iTip, and on top of that used the wrong property for the last-modified date.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 6893bd6..5c2d7ba 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -114,7 +114,7 @@ Implements:
 
   value-lastmodified-date = ( [[#Date-Time]] )
 
-''The date-time timestamp when the object was last modified.''
+''The date-time timestamp when the objects content was last modified.''
 
 The date-time '''MUST''' be in UTC.
 
@@ -123,9 +123,24 @@ This property '''MUST''' be updated whenever an object is modified.
 {{note|xCard|Note that xCard uses a timestamp element instead of a date-time element for the "ref" property.}}
 
 Implements:
-* {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.7.2 section-3.8.7.2]
+* {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.7.3 section-3.8.7.3]
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.7.4 section-6.7.4]
 
+==== Timestamp ====
+
+  value-timestamp = ( [[#Date-Time]] )
+
+''The date-time timestamp when the object instance was created.''
+
+The date-time '''MUST''' be in UTC.
+
+This property '''MUST''' be updated whenever an object instance is created (e.g. by serializing an object).
+
+{{note|last-modified|This property should be updated every-time the object is written out, while the last-modified date should only be updated when the objects properties have been modified (i.e. when the user edited the object).}}
+
+Implements:
+* {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.7.2 section-3.8.7.2]
+
 ==== Product ID ====
 
   value-productid = ( [[#String]] )
@@ -802,7 +817,8 @@ Implements:
     element properties {
       element uid { [[#UID|text-uid]] },
       element created { [[#Creation date]] },
-      element dtstamp { [[#Last modification date]] },
+      element last-modified { [[#Last modification date]] } ?,
+      element dtstamp { [[#Timestamp]] },
       element sequence { [[#Sequence]] }, ?
       element class { [[#Classification]] } ?,
       element categories { [[#Categories|property-categories]] } ?,
@@ -845,7 +861,8 @@ Implements:
     element properties {
       element uid { [[#UID|text-uid]] },
       element created { [[#Creation Date]] },
-      element dtstamp { [[#Last modification date]] },
+      element last-modified { [[#Last modification date]] } ?,
+      element dtstamp { [[#Timestamp]] },
       element sequence { [[#Sequence]] }, ?
       element class { [[#Classification]] } ?,
       element categories { [[#Categories|property-categories]] } ?,
@@ -888,7 +905,8 @@ Implements:
     element properties {
       element uid { [[#UID|text-uid]] },
       element created { [[#Creation Date]] },
-      element dtstamp { [[#Last modification date]] },
+      element last-modified { [[#Last modification date]] } ?,
+      element dtstamp { [[#Timestamp]] },
       element sequence { [[#Sequence]] }, ?
       element class { [[#Classification]] } ?,
       element categories { [[#Categories]] } ?,


commit 23f034441cbebe393e88645cd39272d9486727de
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Sat Apr 28 00:07:24 2012 +0200

    A bit of cleanup.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index da38b46..6893bd6 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -167,6 +167,7 @@ Implements:
 * {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.1.3 section-3.8.1.3]
 
 {{note|Implementation note: Classification/Sensitivity|This property was renamed from Sensitivity to Classification to reuse the wording used in RFC5545}}
+{{note|xCard Kolab V2 compatibility|xCard doesn't support this notion and the property was dropped for the Contact/Distribution-List Objects}}
 
 ==== Categories ====
 
@@ -750,7 +751,8 @@ Properties:
 * "summary": The subject line of the email
 * "description": The body of the email.
 * "attendee": A receipent of the email alarm.
-* "duration/repeat":
+* "duration": Interval for additional repetitions.
+* "repeat": Number of repetitions additionally to the trigger. (0 repetitions results in 1 execution of the alarm)
 
   type-audioprop = element properties {
     element action { text { "AUDIO" } },
@@ -791,8 +793,8 @@ An alarm can trigger repeatedly by setting "duration", which '''SHALL''' indicat
 Implements:
 * {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.6.6 section-3.6.6]
 
-{{note|RFC conflict|ical says there MUST be a summary for the email alarm and xCal doesnt even allow it (also some other properties are mixed up between email and disp). An erratum has been submitted.}}
-{{note|Needs clarification: X-KDE-KCALCORE-ENABLED|what is it good for and how can we model it? X-KDE-KCALCORE-ENABLED:TRUE}}
+{{note|RFC conflict|ical says there MUST be a summary for the email alarm and xCal doesnt even allow it (also some other properties are mixed up between email and disp). An erratum has been submitted and confirmed.}}
+{{note|Unsupported KDE feature: X-KDE-KCALCORE-ENABLED|KAlarm allows to disable alarms without deleting it. This is not supported by xcal.}}
 
 ==== Todo ====
 
@@ -827,8 +829,6 @@ Implements:
     }?
   }
 
-{{note|Needs clarification: f/b|transp does not apply to todo, do we need show-time-as form the old format spec?}}
-
 ''An object representing a task/todo.''
 
 * Content-Type: application/calendar+xml
@@ -837,6 +837,8 @@ Implements:
 Implements:
 * {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.6.2 section-3.6.2]
 
+{{note|transp|transp does not apply to todo, and show-time-as from the old format spec is not supported. show-time-as is a further specification, which allows to specify how exactly one is not available (out of office, busy but in the office, meeting, ...). Something for a future version maybe.}}
+
 ==== Event ====
 
   event = element vevent {
@@ -1044,7 +1046,7 @@ Further text values '''MAY''' be appended to denote organizational units the con
 Implements:
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.4 section-6.6.4]
 
-{{note|Needs clarification: Better modeling of organizations|We could add a link to a organization vcard here. This would also allow to add a address which is associated with the organization etc. It would add complexity to the client though}}
+{{note|Note: Better modeling of organizations|We could add a link to a organization vcard here. This would also allow to add a address which is associated with the organization etc. It would add complexity to the client though}}
 
 ====== Logo ======
 
@@ -1182,7 +1184,7 @@ Types:
 Implements:
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.6 section-6.6.6]
 
-{{note|Needs clarification: manager/assistat|The two x-values should be submitted to the vCard RFC.}
+{{note|Note: manager/assistat|The two x-values should be submitted to the vCard RFC.}
 
 ===== Birthday =====
 
@@ -1310,7 +1312,7 @@ The "pref" parameter '''MAY''' be used to indicate the preferred IM address. Onl
 Implements:
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.4.3 section-6.4.3]
 
-{{note|Needs clarification|Do we need a "application type" field? That information should be part of the uri I suppose.}}
+{{note|Note: application type|They application should be chosen based on the protocol indicated by the uri.}}
 
 ===== EMail =====
 
@@ -1392,7 +1394,7 @@ Uses:
 {{note|Opaque signing|Opaque signing refers to the technique of embedding the text into the base64 encoded CMS (PKCS #7 based Cryptographic Message Syntax) object (content type: application/x-pkcs7-mime) of the signature, so it can only be read if the client supports S/MIME. Clear signing transmits the clear text and only appends the signature (content type: application/x-pkcs7-signature), which allows clients without S/MIME support to read the message.}}
 {{note|Needs clarification: Key storage|Im not sure yet how the key should be stored. Im also dont think the application/pkcs7-mime mimetype is correct for the key itself.}}
 {{note|Needs clarification: allowed|Is this correct that it is only for incoming content? (the allowed element is derived from the KAddressbook Crypto settings page)}}
-{{note|x-crypto|This property is missing in the xCard standard and should be added to it.}}
+{{note|x-crypto|This property is missing in the xCard standard and should be added to it (probably as crypto-pref).}}
 {{note|identities|Ideally crypto settings would be per identity and not per contact.}}
 
 ===== Member =====





More information about the commits mailing list