11 commits - KEP-0017.txt

Christian Mollekopf mollekopf at kolabsys.com
Wed Oct 24 17:45:03 CEST 2012


 KEP-0017.txt |  114 +++++++++++++++++++++++------------------------------------
 1 file changed, 45 insertions(+), 69 deletions(-)

New commits:
commit efc190a32ad3e7d0016e00e8d2d8aecc3d75d7e0
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed Oct 24 17:41:57 2012 +0200

    Hierachical categories are deprecated.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 1b77cc0..7ff4720 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -171,32 +171,21 @@ Implements:
 
   value-category = ( [[#String]] )
   
-  category-hierarchy = value-category("\"value-category)*
-  
   property-categories = (
-    element text { category-hierarchy } +
+    element text { value-category } +
   )
 
 ''A simple text tag used to categorize the object.''
 
-Category tags are mostly used to group objects into categories.
-
-The tags '''MAY''' use a hierarchy by prepending parent tags using '\' (Backslash: U+005C) as delimiter.
-
-A value-category '''MUST NOT''' contain a '\' (Backslash: U+005C).
-
-Defining a single category-hierarchy '''SHALL''' be sufficient to define all categories which are part of the hierarchy, but the object "MUST" only get the whole category-hierarchy as category and not each indvidual value-category.
-
-A category '''SHALL''' be identifieable by string comparison. The whole category-hierarchy '''MUST''' be compared.
+Categories are plaintext tags which are used group objects into categories.
 
-{{note|Example|"parent\child" would indicate a parent-child relationship between "parent" and "child". This defines the categories "parent" and "parent\child". Note that the "child" category of "parent2\child" is not the same as "parent\child". Note also that unless "parent" is also explicitly added to the categories list the object has only the "parent\child" category and not the "parent" category.}}
+Categories '''SHALL''' be used as plaintext tags only and '''SHOULD NOT''' have any encoded structure.
 
 Implements:
 * {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.1.2 section-3.8.1.2]
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.7.1 section-6.7.1]
 
-{{note|Implementation note: Structured Tags|In the future the might be a need for structured tags consiting of type, identifier, display name (and possibly a hierarchical relation). This is however not currently used (except for nepomuk) and was therefore not implemented. For the current needs this would have been a overengineering solution. Structured tags can be introduced at a later stage without rendering this property useless.}}
-{{note|Implementation note: Hierarchy|The hierarchy is not build using xml element nesting (such as in the category configuration) for compatibility with the used RFCs.}}
+{{note|Hierarchical Categories|See [[#Hierarchical Categories]] for a specification of the deprecated hierarchical categories as used by Kontact}} 
 
 === xCal based objects ===
 
@@ -1486,7 +1475,7 @@ The vcard:kind element '''MUST''' have the value "group".
     element prodid { [[#Product ID|value-productid]] },
     element creation-date { [[#Creation date|value-creation-date]] },
     element last-modification-date { [[#Last modification date|value-lastmodified-date]] },
-    element categories { [[#Categories|category-hierarchy]] } *,
+    element categories { [[#Categories|value-category]] } *,
     element classification { [[#Classification|value-classification]] } ?,
     element attachment { [[#Attachment]] } *,
     element summary { [[#String]] } ?,
@@ -1928,6 +1917,33 @@ The said workaround is to make all types of the unordered list an extension of a
 
 To fix this shortcoming of the used RFC's the order is required in the Kolab XML Format.
 
+=== Hierarchical Categories ===
+
+This part describes hierarchical categories as they're traditionally used by Kontact.
+Hierachical categories are still being used until more powerful concepts such as [http://wiki.kolab.org/PIM-Item_Relations PIM-Item Relations] are in place.
+
+  value-category = ( [[#String]] )
+  
+  category-hierarchy = value-category("\"value-category)*
+  
+  property-categories = (
+    element text { category-hierarchy } +
+  )
+
+''Hierachical categories used for backwards compatibility''
+
+The tags '''MAY''' use a hierarchy by prepending parent tags using '\' (Backslash: U+005C) as delimiter.
+
+A value-category '''MUST NOT''' contain a '\' (Backslash: U+005C).
+
+Defining a single category-hierarchy '''SHALL''' be sufficient to define all categories which are part of the hierarchy, but the object "MUST" only get the whole category-hierarchy as category and not each indvidual value-category.
+
+A category '''SHALL''' be identifieable by string comparison. The whole category-hierarchy '''MUST''' be compared.
+
+{{note|Example|"parent\child" would indicate a parent-child relationship between "parent" and "child". This defines the categories "parent" and "parent\child". Note that the "child" category of "parent2\child" is not the same as "parent\child". Note also that unless "parent" is also explicitly added to the categories list the object has only the "parent\child" category and not the "parent" category.}}
+{{note|Implementation note: Hierarchy|The hierarchy is not build using xml element nesting (such as in the category configuration) for compatibility with the used RFCs.}}
+{{note|PIM-Item Relations|Hierachical categories are to be replaced with something like PIM-Item Relations. The hierarchical categories here are only a temporary solution for backwards compatiblity.}}
+
 == References ==
 
 {{Reflist}}


commit 52015a3dd38aff803611949a5ad568c4331ea334
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed Oct 24 16:46:47 2012 +0200

    The probably wrong application/pkcs7-mime mimetype still needs clarification.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 502761a..1b77cc0 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1347,11 +1347,13 @@ Implements:
 
 ''Specifies a public key or authentication certificate associated with the contact. ''
 
-This key ''MAY'' be used to encrypt or sign using OpenPGP or S/MIME. The embedded key '''MUST''' have the type "application/pgp-keys" or "application/pkcs7-mime".
+This key ''MAY'' be used to encrypt or sign using OpenPGP or S/MIME. The embedded key '''SHALL''' have the type "application/pgp-keys" or "application/pkcs7-mime".
 
 Implements:
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.8.1 section-6.8.1]
 
+{{note|Needs clarification: Key storage|I'm not sure yet how the key should be stored. I also dont think the application/pkcs7-mime mimetype is correct for the key itself.}}
+
 ===== Cryptographic Preferences =====
 
   property-crypto = element x-crypto {


commit a28d7ce5f80ee1df54cc2ed191c11be7bd19b579
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed Oct 24 15:31:23 2012 +0200

    Fixed the description and spec of the x-crypto "allowed" property.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 0a15ad1..502761a 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1355,14 +1355,14 @@ Implements:
 ===== Cryptographic Preferences =====
 
   property-crypto = element x-crypto {
-    element allowed { element text { "PGP/INLINE" | "PGP/MIME" | "S/MIME" | "S/MIMEOpaque" }* },
+    element allowed { element text { "PGP/INLINE" | "PGP/MIME" | "S/MIME" | "S/MIMEOpaque" }* } ?,
     element signpref { element text { "Never" | "Always" | "IfPossible" | "Ask" } } ?,
     element encryptpref {  element text { "Never" | "Always" | "IfPossible" | "Ask" } } ?
   }
 
 ''Specifies crypto related settings.''
 
-* "allowed": Specifies the allowed encryption/signing protocols for incoming content:
+* "allowed": Specifies the allowed encryption/signing protocols for sending mail to the contact. This setting '''SHOULD''' override the default settings of the mail composer. If none of the allowed protocols is available the signing/encrypting '''SHOULD''' fail. If not specified all protocols are allowed.
 :* "PGP/INLINE": Allows inline-PGP for encrypted and signed content.
 :* "PGP/MIME": Allows PGP/MIME for encrypted and signed content.
 :* "S/MIME": Allows clear signed messages using S/MIME.
@@ -1386,8 +1386,6 @@ Uses:
 * {{rfc|5751}}<ref name=rfc5751>{{rfc|5751}} Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification</ref> [https://tools.ietf.org/html/rfc5751]
 
 {{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 (probably as crypto-pref).}}
 {{note|identities|Ideally crypto settings would be per identity and not per contact.}}
 


commit 06ae0c14b0cc7a38a92ffdcb09b3f2ea5f3d5f51
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed Oct 24 14:19:14 2012 +0200

    We don't need the type and the cardinality can be changed when we actually need it.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 73841e6..0a15ad1 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -989,8 +989,8 @@ Implements:
 Implements:
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.9.1 section-6.9.1]
 
-{{note|Needs clarification: Type| do we need to indicate the type where this points?}}
-{{note|Needs clarification: cardinality| do we need multiple fb urls?}}
+{{note|Cardinality|We might want to allow multiple fb urls in the future, as
+it would make sense to check in multiple places for available fb information.}}
 
 ===== Title =====
 


commit cfdb75e17523d79a527543530553d39d497f4e4a
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed Oct 24 14:15:03 2012 +0200

    We don't need attachments for contacts.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index eb55dac..73841e6 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1455,7 +1455,6 @@ Implements:
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350]
 
 {{note|Obsoletion of KEP 13|This obsoletes draft [[KEP:13]]<ref name="kep13">[[KEP:13]] Update contact object (Draft)</ref> as this update will fully replace everything that KEP would have addressed.}}
-{{note|Needs clarification: Attachment| Do we need an attachment property? There is none in the RFC and RC and KAddressbook dont use attachments for contacts}}
 {{note|Identities| Contacts currently lack the notion of different identities of the same person, respectively don't support a Person/Identities modeling.}}
 
 ==== Distribution List ====


commit 3441e8ee2fbb61a6ed1469d760c64f1fd2c06cd0
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed Oct 24 14:11:34 2012 +0200

    Removed the note color, as it is nowhere used and also not properly implemented.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 4335cfa..eb55dac 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1492,7 +1492,6 @@ The vcard:kind element '''MUST''' have the value "group".
     element attachment { [[#Attachment]] } *,
     element summary { [[#String]] } ?,
     element description { [[#String]] } ?,
-    element color { [[#Note Color]] } ?,
     element x-custom { [[#Kolab Custom Property]]} *
   }
 
@@ -1501,24 +1500,10 @@ The vcard:kind element '''MUST''' have the value "group".
 * Content-Type: application/vnd.kolab+xml
 * X-Kolab-Type: application/x-vnd.kolab.note
 
-{{note|Needs clarfication: colors|do we need the color property? }}
 {{note|structure: attachment|Points to an xCal property? Maybe move the attachment to the generic section.}}
 
 ==== Properties ====
 
-===== Note Color =====
-
-  property-color = element color {
-      attribute type { "foreground" | "background" },
-      [[#Color]]
-  }
-
-''Specifies color properties of the note.''
-
-The following color types are defined:
-* "foreground": Foreground color of the note (Text color).
-* "background": Background color of the note.
-
 === Configuration ===
 
   configuration = element configuration {


commit b6b2ca937839ec705313903b9adc9aeab21bed72
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Wed Oct 24 13:47:55 2012 +0200

    Removed the contact property as it is nowhere used and not implemented.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 06becaa..4335cfa 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -612,21 +612,6 @@ A contact '''MAY''' be referenced using the [[#UID|uri-uid]].
 Implements:
 * {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.4.3 section-3.8.4.3]
 
-===== Contact =====
-
-  property-contact = element contact {
-    element text { [[#String]] }
-  }
-
-''A contact related to the incidence.''
-
-The text property '''SHOULD''' contain the name of the contact.
-
-Implements:
-* {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.4.2 section-3.8.4.2]
-
-{{note|Needs clarification: Useless?|not sure if we need this property (dont know where it is used).}}
-
 ===== Attendee =====
 
   property-attendee = element attendee {
@@ -908,15 +893,12 @@ Implements:
       element summary { [[#Summary]] } ?,
       element description { [[#Description]] } ?,
       element status { [[#Status]] } ?,
-      element contact { [[#Contact]] } *,
       element attendee { [[#Attendee]] } *,
       element attach { [[#Attachment]] } *,
       element x-custom { [[#Kolab Custom Property]] } *
     }
   }
 
-{{note|Needs clarification: Contact|Looks like a nice to have, but who really uses it? not kontact.}}
-
 An object representing an journal entry. Journal entries '''SHALL''', as opposed to notes, be related to a calendar date.
 
 * Content-Type: application/calendar+xml


commit 1f2119b6d110ec5034654009e0c7b8fce9ee6a54
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Tue Oct 23 12:28:00 2012 +0200

    Added ROOM cutype.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index fcfa9c1..06becaa 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -653,7 +653,8 @@ Implements:
         "INDIVIDUAL" |
         "GROUP" |
         "RESOURCE" |
-        "UNKNOWN"
+        "UNKNOWN" |
+        "ROOM"
       } } ?,
     }?,
     element cal-address { [[Mailto URI]] }
@@ -692,7 +693,7 @@ Implements:
 
 {{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.}}
+{{note|cutype|"UNKNOWN" and "ROOM" were added for RFC compatibility reasons.}}
 
 ===== Attachment =====
 


commit 8ccc667cbd4d6e64355203554f4ad344ec718b08
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Tue Oct 23 12:27:20 2012 +0200

    It would be, but since we don't allow duration in there it also doesn't really matter.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 3cb4886..fcfa9c1 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -448,8 +448,6 @@ While {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.5.2 section-
 Implements:
 * {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.5.2 section-3.8.5.2]
 
-{{note|Needs clarification: Period| Is the period type used to alter the duration of a single recurrence? }}
-
 ====== Exception date ======
 
   property-exdate = element exdate {


commit b6ebfbc3a8123727d94a12a62287d666fb6b0f0e
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Tue Oct 23 12:26:30 2012 +0200

    Minor cleanup.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index fdbe18f..3cb4886 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -46,8 +46,6 @@ The order of the elements is '''REQUIRED''' unless otherwise specified using the
 
 The 'X-Kolab-Type' field which is defined for every Kolab XML Object '''SHALL''' be used as {{rfc|2822}} <ref name="rfc2822">{{rfc|2822|title=Internet Message Format}}</ref> message header of the encapsulating email object.
 
-{{note|Needs Clarification: IMAP Folder|Do we need to specify in which folder the individual objects may be stored? I consider this out of the scope of this KEP.}}
-
 == Kolab XML Objects ==
 
 A Kolab XML Object is a container for the various data types the Kolab Groupware Suite stores.
@@ -538,8 +536,6 @@ A client implementation '''SHOULD''' give the user the possibilty to sort object
 
 A client implementation '''MAY''' use only a subset of priorities but it '''MUST''' understand all priority values. If a client implementation uses a range with a lower granularity it '''SHOULD''' preserve the original value if it is not modified. It '''SHOULD''' also define a mapping which preserves the meaning of the value.
 
-{{note|structure|This should probably go to a more generic part}}
-
 {{note|Example|If only 0(high), 5(normal), and 9(low) would be used the client implementation should define a mapping such as 0-2 => high, 3-6 => normal, 7-9 => low. A mapping of 0 => high, 1 => normal, 2-9 => low would not preserve the meaning because 1 is considered a "high" priority.}}
 
 Implements:
@@ -811,7 +807,6 @@ 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 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 ====
@@ -1202,7 +1197,7 @@ Types:
 Implements:
 * {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.6 section-6.6.6]
 
-{{note|Note: 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 =====
 


commit efc68b54eae6a0be2173d3f318695ec412165ec3
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date:   Thu Jun 28 15:08:12 2012 +0200

    Fixed content types.

diff --git a/KEP-0017.txt b/KEP-0017.txt
index 966e4aa..fdbe18f 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1522,7 +1522,7 @@ The vcard:kind element '''MUST''' have the value "group".
 
 ''A generic note, not necessarily associated with a specific date.''
 
-* Content-Type: application/x-vnd.kolab.*
+* Content-Type: application/vnd.kolab+xml
 * X-Kolab-Type: application/x-vnd.kolab.note
 
 {{note|Needs clarfication: colors|do we need the color property? }}
@@ -1557,7 +1557,7 @@ The following color types are defined:
 
 ''A Kolab configuration object.''
 
-* Content-Type: application/x-vnd.kolab.configuration
+* Content-Type: application/vnd.kolab+xml
 * X-Kolab-Type: application/x-vnd.kolab.configuration.TYPE
 
 The TYPE of the X-Kolab-Type '''MUST''' correspond to the "type" element.





More information about the commits mailing list