8 commits - KEP-0017.txt
Christian Mollekopf
mollekopf at kolabsys.com
Mon Mar 19 18:22:54 CET 2012
KEP-0017.txt | 213 +++++++++++++++++++++++++++++------------------------------
1 file changed, 106 insertions(+), 107 deletions(-)
New commits:
commit 91918dd4e47d883ec0af9aec8f5120f5fe9b37a6
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date: Sat Mar 17 15:27:47 2012 +0100
Use the dir parameter instead of allowing urn's for cal-address.
diff --git a/KEP-0017.txt b/KEP-0017.txt
index 1b64a62..da38b46 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -600,14 +600,16 @@ Implements:
property-organizer = element organizer {
element parameters {
- element cn { element text { [[#String]] } } ?
+ element cn { element text { [[#String]] } } ?,
+ element dir { element uri { [[#UID|uri-uid]] } } ?
} ?,
- element cal-address { [[#Contact URI]] }
+ element cal-address { [[#Mailto URI]] }
}
''The organizer of the incidence.''
-The cal-address '''MUST''' be a valid [[#Contact URI]].
+The cal-address '''MUST''' be a valid [[#Mailto URI]].
+A contact '''MAY''' be referenced using the [[#UID|uri-uid]].
* The cn parameter '''SHALL''' represent the display name of the organizer.
@@ -647,14 +649,16 @@ Implements:
"REQ-PARTICIPANT" |
"OPT-PARTICIPANT" |
"NON-PARTICIPANT"
- } } ?
+ } } ?,
+ element dir { element uri { [[#UID|uri-uid]] } } ?
}?,
- element cal-address { [[#Contact URI]] }
+ element cal-address { [[Mailto URI]] }
}
''An attendee of an event.''
-The cal-address '''MUST''' be a valid [[#Contact URI]].
+The cal-address '''MUST''' be a valid [[Mailto URI]].
+A contact '''MAY''' be referenced using the [[#UID|uri-uid]].
* "cn": The display name of the contact.
* "rsvp": Used by the [[#Organizer]] to request a participation status reply from an attendee of a group-scheduled event or to-do. This parameter '''SHALL''' default to "FALSE" if not specified.
@@ -673,8 +677,9 @@ The cal-address '''MUST''' be a valid [[#Contact URI]].
Implements:
* {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.4.1 section-3.8.4.1]
-{{note|Needs clarification: LDAP|There would be an additonal dir parameter for an ldap uri available. useful?}}
-{{note|Needs clarification: cutype|For "resource" role? i.e. a meeting room. Currently this is not possible and it was in the old format specification. But I don't know if this is used anywhere.}}
+{{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.}}
===== Attachment =====
@@ -731,7 +736,7 @@ If a date-time value is used it '''MUST''' be in UTC.
element action { text { "EMAIL" } },
element summary { [[#Summary]] },
element description { [[#Description]] },
- element attendee { element cal-address { [[#Contact URI]] } } +,
+ element attendee { element cal-address { [[#Mailto URI]] } } +,
property-trigger,
(
element duration { [[#Duration]] },
commit e85b43d971d0cf35d776a79ba65cacf6caec1fee
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date: Fri Mar 16 23:21:51 2012 +0100
Mailto is an uri not an url.
diff --git a/KEP-0017.txt b/KEP-0017.txt
index 7c92d9a..1b64a62 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1694,9 +1694,9 @@ The uri scheme '''MUST''' be according to {{rfc|2397}}<ref name="rfc2397">{{rfc|
UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
<... remainder of base64-encoded data ...>
-==== Mailto URL ====
+==== Mailto URI ====
-A mailto url '''MUST''' conform to {{rfc|6068}}<ref name="rfc6068">{{rfc|6068}} The 'mailto' URI Scheme</ref>.
+A Mailto URI '''MUST''' conform to {{rfc|6068}}<ref name="rfc6068">{{rfc|6068}} The 'mailto' URI Scheme</ref>.
The name of the contact '''MAY''' be embedded in the email address as specified in {{rfc|822}}<ref name="rfc822">{{rfc|822}} Standard for ARPA Internet Text Messages</ref> [https://tools.ietf.org/html/rfc822#section-6.1 section-6.1].
This technique '''SHALL''' only be used if no other means to indicate the name are available.
@@ -1712,8 +1712,8 @@ Example:
''Any URI which is somehow relevant to identify/contact a Contact.''
-Clients SHALL either use a [[#UID|uri-uid]] to reference a Contact object or a [[#Mailto URL]] to specify a single email address.
-Clients MUST be able to deal with both [[#UID|uri-uid]] and [[#Mailto URL]].
+Clients SHALL either use a [[#UID|uri-uid]] to reference a Contact object or a [[#Mailto URI]] to specify a single email address.
+Clients MUST be able to deal with both [[#UID|uri-uid]] and [[#Mailto URI]].
==== Geo URI ====
commit 95c19a5db9c1b9dc0de7307074046705fed6e089
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date: Fri Mar 16 23:16:27 2012 +0100
Remove Keys from x-crypto and use key-property instead.
diff --git a/KEP-0017.txt b/KEP-0017.txt
index d805dac..7c92d9a 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1338,16 +1338,23 @@ The global position '''SHOULD''' be interpreted as a location which is related t
Implements:
* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.5.2 section-6.5.2]
-===== Crypto =====
+===== Cryptographic Key =====
+
+ property-key = element key {
+ element uri { [[#URI inline encoding]] }
+ }
+
+''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".
+
+Implements:
+* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.8.1 section-6.8.1]
+
+===== Cryptographic Preferences =====
property-crypto = element x-crypto {
element allowed { element text { "PGP/INLINE" | "PGP/MIME" | "S/MIME" | "S/MIMEOpaque" }* },
- element pgpkey {
- element uri { [[#URI inline encoding]] }
- } ?,
- element smimekey {
- element uri { [[#URI inline encoding]] }
- } ?,
element signpref { element text { "Never" | "Always" | "IfPossible" | "Ask" } } ?,
element encryptpref { element text { "Never" | "Always" | "IfPossible" | "Ask" } } ?
}
@@ -1359,8 +1366,6 @@ Implements:
:* "PGP/MIME": Allows PGP/MIME for encrypted and signed content.
:* "S/MIME": Allows clear signed messages using S/MIME.
:* "S/MIMEOpaque": Allows opaque signed messages using S/MIME.
-* "pgpkey": Specifies a public key or authentication certificate associated with the contact. This key ''MAY'' be used to encrypt or sign using OpenPGP. The embedded key '''MUST''' have the type "application/pgp-keys".
-* "smimekey": Specifies a public key or authentication certificate associated with the contact. This key ''MAY'' be used to encrypt or sign using S/MIME. The embedded key '''MUST''' have the type "application/pkcs7-mime".
* "signpref": This preference '''SHOULD''' be considered when sending content to the contact. If not specified this preference '''SHALL''' default to "Ask"
:* "Never": Never sign something before sending.
:* "Always": Alway sign, abort if signing is not possible.
@@ -1433,7 +1438,8 @@ Implements:
element impp { [[#IM Address]] } *,
element email { [[#EMail]] } *,
element geo { [[#Global Positioning]] } *,
- element x-crypto { [[#Crypto]] } ?,
+ element key { [[#Cryptographic Key]] } *,
+ element x-crypto { [[#Cryptographic Preferences]] } ?,
element x-custom { [[#Kolab Custom Property]] } *
}
commit a95d85958dad9b12212b7aba8c339326898192cf
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date: Fri Mar 16 23:02:37 2012 +0100
Removed x-office and replaced by adr.
diff --git a/KEP-0017.txt b/KEP-0017.txt
index c03a60f..d805dac 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1074,16 +1074,6 @@ Implements:
{{note|Possible error in vCard RFC|The reference in the vCard RFC to CCITT.X520.1988:Business Category is likely wrong and should be CCITT.X520.1988:Title. This would align with the example in the vCard RFC and is how we're using it.}}
-====== Office ======
-
- property-assistant = element x-office {
- element text { [[#String]] }
- }
-
-''Additional information related to the office, such as it's location.''
-
-{{note|Implementation note|This property is somewhat redunant to Address but KAddressbook provides it.}}
-
===== URL =====
property-url = element url {
@@ -1123,7 +1113,7 @@ Implements:
element country { [[#String]] }
}
-''An address of the contact.''
+''An address of the contact or organization.''
Address components:
* "pobox": The post office box. This component '''SHOULD NOT''' be used as recommended by {{rfc|6350}}[https://tools.ietf.org/html/rfc6350#section-6.3.1 section-6.3.1].
@@ -1144,6 +1134,8 @@ The "pref" parameter '''MAY''' be used to indicate the preferred address. Only o
The "label" parameter '''MAY''' be used to set a label for the address which client implementations '''SHOULD''' present to the user as primary means for identification of the address.
+If used within an [[#Affiliation]] this property '''SHALL''' be used for any related address, such as an office of the organization. The "label" parameter '''MAY''' be used to store a freeform version of such a location description (i.e. office).
+
Implements:
* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.3.1 section-6.3.1]
@@ -1426,7 +1418,7 @@ Implements:
element logo { [[#Logo]] } ?,
element role { [[#Role]] } *,
element related { [[#Related]] } *,
- element x-office { [[#Office]] } *
+ element adr { [[#Address]] } *
} *,
element url { [[#URL]] } *,
element adr { [[#Address]] } *,
commit 7624a2e90fbe128a75923bbc29513cd5bc475e8b
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date: Fri Mar 16 20:18:49 2012 +0100
Got rid of x-manager and x-assistant by using the related property.
This is now possible because we use an affiliation group.
diff --git a/KEP-0017.txt b/KEP-0017.txt
index ac7a56c..c03a60f 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1074,26 +1074,6 @@ Implements:
{{note|Possible error in vCard RFC|The reference in the vCard RFC to CCITT.X520.1988:Business Category is likely wrong and should be CCITT.X520.1988:Title. This would align with the example in the vCard RFC and is how we're using it.}}
-====== Manager ======
-
- property-manager = element x-manager {
- element text { [[#String]] }
- }
-
-''Specifies a manager of the contact within the organization.''
-
-{{note|Needs clarification: related|could be expressed using a related property}}
-
-====== Assistant ======
-
- property-assistant = element x-assistant {
- element text { [[#String]] }
- }
-
-''Specifies a manager of the contact within the organization.''
-
-{{note|Needs clarification: related|could be expressed using a related property}}
-
====== Office ======
property-assistant = element x-office {
@@ -1184,7 +1164,7 @@ Implements:
element parameters {
element type {
element text {
- "spouse" | "child"
+ "spouse" | "child" | "x-manager" | "x-assistant"
} +
}?
}?,
@@ -1197,13 +1177,15 @@ Clients SHALL use a [[#UID|uri-uid]] to reference a Contact object when using th
Clients MUST be able to deal with [[#UID|uri-uid]].
Types:
-* "spouse": Specifies that the related contact is the spouse of this contact.
-* "child": Specifies that the related contact is the child of this contact.
+* "spouse": Specifies that the related contact is the spouse of this contact. This value '''SHOULD''' only occur within the toplevel related property.
+* "child": Specifies that the related contact is the child of this contact. This value '''SHOULD''' only occur within the toplevel related property.
+* "x-manager": Specifies a manager of the contact within the organization. This value '''SHOULD''' only occur within related properties within an [[#Affiliation]].
+* "x-assistant": Specifies an assistant of the contact within the organization. This value '''SHOULD''' only occur within related properties within an [[#Affiliation]].
Implements:
* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.6 section-6.6.6]
-{{note|Needs clarification: manager/assistat|extend for manager and assistant (in which case this should be added to the affiliation group as well? This would obsolete the x-manager x-assistant properties}}
+{{note|Needs clarification: manager/assistat|The two x-values should be submitted to the vCard RFC.}
===== Birthday =====
@@ -1443,8 +1425,7 @@ Implements:
element org { [[#Organization]] },
element logo { [[#Logo]] } ?,
element role { [[#Role]] } *,
- element x-manager { [[#Manager]] } *,
- element x-assistant { [[#Assistant]] } *,
+ element related { [[#Related]] } *,
element x-office { [[#Office]] } *
} *,
element url { [[#URL]] } *,
commit edc418bf2bffc8595fbd1ed8bbb7e6b5e8f424b3
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date: Fri Mar 16 20:08:01 2012 +0100
Fix Affiliation/Role/Title
diff --git a/KEP-0017.txt b/KEP-0017.txt
index a6d2aff..ac7a56c 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -991,13 +991,32 @@ Implements:
{{note|Needs clarification: Type| do we need to indicate the type where this points?}}
{{note|Needs clarification: cardinality| do we need multiple fb urls?}}
+===== Title =====
+
+ property-title = element title {
+ element text { [[#String]] }
+ }
+
+''Specifies a position or profession of the contact.''
+
+In contrast to [[#Role]], this property denotes a general profession/occupation of the contact, and is not bound to a specifc organization.
+
+Examples:
+ * "Computer Scientist"
+
+Implements:
+* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.1 section-6.6.1]
+
+{{note|Possible error in vCard RFC|The reference in the vCard RFC to CCITT.X520.1988:Title is likely wrong and should be CCITT.X520.1988:Business Category. This would align with the example in the vCard RFC and is how we're using it.}}
+
===== Affiliation =====
Affiliation specific elements are grouped by a "group" element.
The "group" element is the xCard equivalent to the "group construct" as specified in {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-3.3 section-3.3] and is specified in {{rfc|6351}} [http://tools.ietf.org/html/rfc6351#section-5 section-5].
+A contact '''MAY''' be associated with multiple organizations by using multiple affiliation groups.
+
{{note|Implementation note|This corresponds to kaddressbooks business tab}}
-{{note|Needs clarification: name element|maybe the name element should be used for identification of the affiliation instead (not sure if this is actually necessary). If all implementations just support multiple generic affiliations its not needed, but if i.e. one supports multiple affiliations and kontact only supports a business affiliation kontact could identify the business affiliation based on the name (although thats likely to break when used this way)}}
====== Organization ======
@@ -1007,8 +1026,6 @@ The "group" element is the xCard equivalent to the "group construct" as specifie
''A organization associated with the contact''
-A contact '''MAY''' be associated with multiple organizations by using multiple org properties.
-
A single "org" property '''MUST''' be used for only one organization.
Organizations are of no specific type.
@@ -1038,28 +1055,25 @@ Implements:
{{note|Implementation note: Roundcube|roundcube does not support this property, but only the photo}}
{{note|Purpose|The purpose of this property was changed so the logo is now associated with the affiliated organization and not the "object the vCard presents" as the RFC puts it, which is how it is also used in Kontact}}
-====== Title ======
-
- property-title = element title {
- element text { [[#String]] }
- }
-
-''Specifies a position or job of the contact within the organization.''
-
-Implements:
-* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.1 section-6.6.1]
-
====== Role ======
property-role = element role {
element text { [[#String]] }
}
-''Specifies a role of the contact within the organization.''
+''Specifies a role/function of the contact within the organization.''
+
+In contrast to [[#Title]], this property denotes a specific role/function within an organization, and not a generic profession/occupation.
+
+Examples:
+ * "Systems Architect"
+ * "Manager,Distributed Applications"
Implements:
* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.2 section-6.6.2]
+{{note|Possible error in vCard RFC|The reference in the vCard RFC to CCITT.X520.1988:Business Category is likely wrong and should be CCITT.X520.1988:Title. This would align with the example in the vCard RFC and is how we're using it.}}
+
====== Manager ======
property-manager = element x-manager {
@@ -1423,11 +1437,11 @@ Implements:
element n { [[#Name Components]] } ?,
element note { [[#Note]] } ?,
element fburl { [[#Freebusy URL]] } ?,
+ element title { [[#Title]] } *,
element group {
attribute name { [[#Affiliation|"Affiliation"]] },
element org { [[#Organization]] },
element logo { [[#Logo]] } ?,
- element title { [[#Title]] } *,
element role { [[#Role]] } *,
element x-manager { [[#Manager]] } *,
element x-assistant { [[#Assistant]] } *,
@@ -1722,7 +1736,6 @@ Example:
Clients SHALL either use a [[#UID|uri-uid]] to reference a Contact object or a [[#Mailto URL]] to specify a single email address.
Clients MUST be able to deal with both [[#UID|uri-uid]] and [[#Mailto URL]].
-
==== Geo URI ====
A geographic location identifier '''MUST''' conform to {{rfc|5870}}<ref name="rfc5870">{{rfc|5870}} A Uniform Resource Identifier for Geographic Locations ('geo' URI)</ref>.
commit ea57645977cc3dddf048381db2a7da46b8546e32
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date: Fri Mar 16 19:23:24 2012 +0100
Specify notes better.
diff --git a/KEP-0017.txt b/KEP-0017.txt
index 1319466..a6d2aff 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -1490,14 +1490,14 @@ The vcard:kind element '''MUST''' have the value "group".
note = element note {
attribute version { [[#Kolab XML Version]] },
element uid { [[#UID|value-uid]] },
- element prodid { [[#Product ID]] },
- element creation-date { [[#Creation date]] },
- element last-modification-date { [[#Last modification date]] },
- element categories { [[#Categories]] } *,
- element classification { [[#Classification]] } ?,
+ 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 classification { [[#Classification|value-classification]] } ?,
element attachment { [[#Attachment]] } *,
- element summary { [[#Summary]] } ?,
- element description { [[#Description] } ?,
+ element summary { [[#String]] } ?,
+ element description { [[#String]] } ?,
element color { [[#Note Color]] } ?,
element x-custom { [[#Kolab Custom Property]]} *
}
commit 70af06a04c8ab2f712739c4a99ad698645030f96
Author: Christian Mollekopf <mollekopf at kolabsys.com>
Date: Fri Mar 16 17:21:55 2012 +0100
Removed x-uid uses, some notes for x-properties. Allow the use of either urn or mailto.
diff --git a/KEP-0017.txt b/KEP-0017.txt
index cb4ac52..1319466 100644
--- a/KEP-0017.txt
+++ b/KEP-0017.txt
@@ -602,12 +602,12 @@ Implements:
element parameters {
element cn { element text { [[#String]] } } ?
} ?,
- element cal-address { [[#Mailto URL]] }
+ element cal-address { [[#Contact URI]] }
}
''The organizer of the incidence.''
-The cal-address '''MUST''' be a [[#Mailto URL]] email address.
+The cal-address '''MUST''' be a valid [[#Contact URI]].
* The cn parameter '''SHALL''' represent the display name of the organizer.
@@ -617,9 +617,6 @@ Implements:
===== Contact =====
property-contact = element contact {
- element parameters {
- element x-uid { [[#UID|text-uid]] } ?
- } ?,
element text { [[#String]] }
}
@@ -627,13 +624,10 @@ Implements:
The text property '''SHOULD''' contain the name of the contact.
-* "x-uid": This parameter '''MAY''' be used to refer to the [[#Contact]] object of the contact. This parameter '''MUST''' contain the [[#UID]] of a [[#Contact]] if specified.
-
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).}}
-{{note|Needs clarification: x-uid|not sure if the x-uid is valid, see attendee. Specifying the uid separately helps clients to display something if they are not able to lookup the other contact.}}
===== Attendee =====
@@ -653,15 +647,14 @@ Implements:
"REQ-PARTICIPANT" |
"OPT-PARTICIPANT" |
"NON-PARTICIPANT"
- } } ?,
- element x-uid { [[#UID|text-uid]]] } ?
+ } } ?
}?,
- element cal-address { [[#Mailto URL]] }
+ element cal-address { [[#Contact URI]] }
}
''An attendee of an event.''
-The cal-address '''MUST''' be a [[#Mailto URL]] email address.
+The cal-address '''MUST''' be a valid [[#Contact URI]].
* "cn": The display name of the contact.
* "rsvp": Used by the [[#Organizer]] to request a participation status reply from an attendee of a group-scheduled event or to-do. This parameter '''SHALL''' default to "FALSE" if not specified.
@@ -676,12 +669,10 @@ The cal-address '''MUST''' be a [[#Mailto URL]] email address.
:* "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.
-* "x-uid": This propery may '''MAY''' be used to refer to the [[#Contact]] object of the attendee. The x-uid '''MUST''' contain the globally unique [[#UID]] of a [[#Contact]] if specified, internally used UID's '''MUST NOT''' be used.
Implements:
* {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.4.1 section-3.8.4.1]
-{{note|Needs clarification: x-uid param| instead of cal-address as uid? This is what kontact does with X-UID=30f35c1792c219de35c07d91456f1208 used in kontact. x-uid might not work this way because kontact uses the internal uid in this field.}}
{{note|Needs clarification: LDAP|There would be an additonal dir parameter for an ldap uri available. useful?}}
{{note|Needs clarification: cutype|For "resource" role? i.e. a meeting room. Currently this is not possible and it was in the old format specification. But I don't know if this is used anywhere.}}
@@ -711,6 +702,7 @@ Implements:
* {{rfc|5545}} [https://tools.ietf.org/html/rfc5545#section-3.8.1.1 section-3.8.1.1]
{{note|Attachments in separate Mimeparts|Attachments '''SHOULD''' be attached using a seperate Mime-Part. If this technique is used the Attachment '''MUST''' be referenced using the Content-Id(cid:) of the Mimepart in the uri element.}}
+{{note|x-label|This property should be replaced with something standard compliant or added to the official standard.}}
==== Alarm ====
@@ -739,7 +731,7 @@ If a date-time value is used it '''MUST''' be in UTC.
element action { text { "EMAIL" } },
element summary { [[#Summary]] },
element description { [[#Description]] },
- element attendee { element cal-address { [[#Mailto URL]] } } +,
+ element attendee { element cal-address { [[#Contact URI]] } } +,
property-trigger,
(
element duration { [[#Duration]] },
@@ -1116,6 +1108,7 @@ Implements:
* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.7.8 section-6.7.8]
{{note|RFC conflict|RFC 6351 permits only home, work types although RFC 6350 permits own x-values. An erratum has been submitted and confirmed.}}
+{{note|x-blog|This property should be replaced with something standard compliant or added to the official standard.}}
===== Address =====
@@ -1181,11 +1174,14 @@ Implements:
} +
}?
}?,
- ( element uri { [[#URI|xsd:anyURI]] } | element text { [[#String]] } )
+ ( element uri { [[#UID|uri-uid]] } | element text { [[#String]] } )
}
''Specifies a relation of the contact to another contact.''
+Clients SHALL use a [[#UID|uri-uid]] to reference a Contact object when using the uri element.
+Clients MUST be able to deal with [[#UID|uri-uid]].
+
Types:
* "spouse": Specifies that the related contact is the spouse of this contact.
* "child": Specifies that the related contact is the child of this contact.
@@ -1193,7 +1189,6 @@ Types:
Implements:
* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.6 section-6.6.6]
-{{note|Needs clarification: uri|maybe we should us x-uid instead of uri as well which can be specified additionally to the text. This way clients which dont support getting the name from a nother object can still display the name.}}
{{note|Needs clarification: manager/assistat|extend for manager and assistant (in which case this should be added to the affiliation group as well? This would obsolete the x-manager x-assistant properties}}
===== Birthday =====
@@ -1399,30 +1394,18 @@ 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|identities|Ideally crypto settings would be per identity and not per contact.}}
===== Member =====
property-member = element member {
- element parameters { element x-uid { [[#UID|uri-uid]] } ? } ?,
- element uri { [[#Mailto URL]] }
+ element uri { [[#Contact URI]] }
}
''A member of the distribution list.''
-A member '''MUST''' contain a [[#Mailto URL]].
-
-The name of the member '''MAY''' be embedded in the email address as specified in {{rfc|822}}<ref name="rfc822">{{rfc|822}} Standard for ARPA Internet Text Messages</ref> [https://tools.ietf.org/html/rfc822#section-6.1 section-6.1].
-In case the name is included, URL-reserved characters '''MUST''' be encoded.
-
-Example:
-
- mailto:John%20Doe%3cjdoe at example.com%3e
-
- <member>
- <uri>"mailto:John%20Doe%3cjdoe at example.com%3e"</uri>
- </member>
-
-* "x-uid": This parameter '''MAY''' be used to refer to the [[#Contact]] object of the member. This parameter '''MUST''' contain the [[#UID]] of a [[#Contact]] if specified. In case this parameter is used, the mailto: email address remains authorative for distribution-list usage. Clients '''MUST NOT''' use an email address from a referenced contact directly in this case.
+A member '''MUST''' contain a valid [[#Contact URI]].
Implements:
* {{rfc|6350}} [https://tools.ietf.org/html/rfc6350#section-6.6.5 section-6.6.5]
@@ -1479,6 +1462,7 @@ Implements:
{{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 ====
@@ -1721,6 +1705,24 @@ The uri scheme '''MUST''' be according to {{rfc|2397}}<ref name="rfc2397">{{rfc|
A mailto url '''MUST''' conform to {{rfc|6068}}<ref name="rfc6068">{{rfc|6068}} The 'mailto' URI Scheme</ref>.
+The name of the contact '''MAY''' be embedded in the email address as specified in {{rfc|822}}<ref name="rfc822">{{rfc|822}} Standard for ARPA Internet Text Messages</ref> [https://tools.ietf.org/html/rfc822#section-6.1 section-6.1].
+This technique '''SHALL''' only be used if no other means to indicate the name are available.
+In case the name is included, URL-reserved characters '''MUST''' be encoded.
+
+Example:
+
+ mailto:John%20Doe%3cjdoe at example.com%3e
+
+== Contact URI ==
+
+ value-uri = xsd:AnyURI
+
+''Any URI which is somehow relevant to identify/contact a Contact.''
+
+Clients SHALL either use a [[#UID|uri-uid]] to reference a Contact object or a [[#Mailto URL]] to specify a single email address.
+Clients MUST be able to deal with both [[#UID|uri-uid]] and [[#Mailto URL]].
+
+
==== Geo URI ====
A geographic location identifier '''MUST''' conform to {{rfc|5870}}<ref name="rfc5870">{{rfc|5870}} A Uniform Resource Identifier for Geographic Locations ('geo' URI)</ref>.
More information about the commits
mailing list