summaryrefslogtreecommitdiff
path: root/KEP-0017.txt
diff options
context:
space:
mode:
Diffstat (limited to 'KEP-0017.txt')
-rw-r--r--KEP-0017.txt20
1 files changed, 11 insertions, 9 deletions
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 =====