martin: doc/kolab-formats/kolab2 Contacts, 1.3, 1.4 addressbook, 1.1, NONE

cvs at intevation.de cvs at intevation.de
Sun May 30 03:59:36 CEST 2004


Author: martin

Update of /kolabrepository/doc/kolab-formats/kolab2
In directory doto:/tmp/cvs-serv6150

Modified Files:
	Contacts 
Removed Files:
	addressbook 
Log Message:
Martin K.: RFC style, overview, formating and more details missing


Index: Contacts
===================================================================
RCS file: /kolabrepository/doc/kolab-formats/kolab2/Contacts,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- Contacts	30 May 2004 00:33:54 -0000	1.3
+++ Contacts	30 May 2004 01:59:33 -0000	1.4
@@ -1,47 +1,114 @@
-This is a request for comments of the kcard specification for handling
-contacts in a common format for the KDE Kolab client, the Kolab web client
-and the Toltec Kolab Connector for Outlook.
+Kolab Development                          Martin Konold
+Request for Comments                       erfrakon Partnerschaftsgesellschaft
+Category: File Formats                     martin.konold at erfrakon.de
 
-The format is basically derived from an reverse engineering effort of the
-Outlook data structures using Outlook Spy.
 
-In general we want a common format for
+                        Kolab Contacts File Format
 
-        - Calendars
-        - Todos
+Status of this Memo
+
+   This document specifies a Kolab standard for the Internet community, and
+   requests discussion and suggestions for improvements. Distribution of this
+   memo is unlimited.
+
+
+1. Abstract
+
+   When dealing with many different Kolab clients on different platforms
+   it is desirable to be able to share contacts amongst different
+   implementations. The requirement for heterogeneous Kolab client
+   platforms is typical for larger enterprises and governmental agencies and
+   a major requirement for institutions in the process of migrating
+   from proprietary to free information infrastructures.
+
+   In the past there have been multiple efforts to create interoperable contact
+   data structures for handling address data on the foundation of the vcard
+   standard as documented in the RFC 2425 and RFC 2426.
+
+   Sofar this has unfortunately been a failure even though very many
+   developers see the requirement for an interchange format. For example my
+   personal vcard capable Nokia phone, my Outlook XP installation and
+   KDE Kontact cannot fully exchange address data without information loss
+   even though all of them follow the vcard standard. Even worse not even the
+   two most popular opensourc PIM solutions Kontact and Evolution have compatible
+   vcard implementations.
+
+   The reason for the obvious problems of the vcard standard is the tremendous
+   power and flexibility of a multi-vendor standard. It allows every vendor to
+   comply rather easily with while missing the goal of lossless interoperability.
+
+
+Table of Contents
+
+        1. Abstract
+        2. Conventions used in this document
+        3. Introduction and Overview
+        4. Rules and Syntax
+        5. Formal Syntax
+        6. Differences from vcard (RFC 2425, 2426)
+        7. Acknowledgements
+        8. Authors' addresses
+        9. Security considerations
+        10. References
+        11. Full copyright statement
+
+
+2. Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+3. Introduction and Overview
+
+   This is a request for comments of the kCard specification for handling
+   contacts in a common format for the KDE Kolab client, the Kolab web client
+   and the Toltec Kolab Connector for Outlook.
+
+   In general we want a common format for
+
+        - Calendar
+        - Todo (Tasks))
         - Journal (secondary goal)
-        - Notes
-        - Contacts
+        - Note
+        - Contact
 
-It has been discussed that defining a common format for contacts are the most
-difficult part as the available standards are umbigious and the vcard
-standard does unfortunately not guarantee interoperability between different
-implementations.
+   while this RFC is limited to a common format for storing and exchanging
+   contact data future RFC will deal with the others.
 
-I therefore chose the Outlook way of handling contact data because on one hand
-it is a defacto standard, reasonable enough and on the other hand we value
-interoperability with Outlook very much while changing the way how Outlook
-handles contact data is beyond our current capabilities.
+   It has been discussed that defining a common format for contacts is the most
+   difficult part as the available standards are umbigious and the vcard
+   standard does unfortunately not guarantee interoperability between different
+   implementations.
 
-In addition I propose that the opensource clients (Kontact and Webclient)
-adopt this standard and code appropriate forms to handle the data. From a
-user interface point of view imho these clients can do better than Outlook
-though.
+   I therefore chose the Outlook way of handling contact data because on one hand
+   it is a defacto standard, reasonable enough and on the other hand we value
+   interoperability with Outlook very much while changing the way how Outlook
+   handles contact data is beyond our current capabilities.
 
-In addition I plan to adapt our kInetOrgPerson objectclass to become more
-compatible to the Outlook contacts.
+   In addition I propose that the opensource clients (Kontact and Webclient)
+   adopt this standard and code appropriate forms to handle the data. From a
+   user interface point of view imho these clients can do better than Outlook
+   though.
 
-This should allow to copy LDAP addressbook entries to a contacts folder which
-is then compatible to all Kolab clients. Beeing able to share contacts
-between clients is a very important feature for our users.
+   In addition I plan to adapt our kInetOrgPerson objectclass to become more
+   compatible to the kCard contacts.
 
-We use Unix linefeed convention (\n) and UTF-8 for the encoding of strings.
-Binary data if required is encoded using the vcard compatible "B" encoding.
+   This should allow to copy LDAP addressbook entries to a contacts folder which
+   is then compatible to all Kolab clients. Beeing able to share contacts
+   between clients is a very important feature for our users.
 
-In case a Kolab client does not understand a property it is mandatory to
-preserve it unchanged. Therefore Kolab clients must be able to store unknown
-properties in their local data structures. The foreign property is then restored
-when the contact is updated in the repository.
+
+4. Rules and Syntax
+
+   We use Unix linefeed convention (\n) and UTF-8 for the encoding of strings.
+   Binary data if required is encoded using the vcard compatible "B" encoding.
+
+   In case a Kolab client does not understand a property it is mandatory to
+   preserve it unchanged. Therefore Kolab clients must be able to store unknown
+   properties in their local data structures. The foreign property is then restored
+   when the contact is updated in the repository.
 
 CONTACT_FIELD (FULL_NAME, "full_name")
 CONTACT_FIELD (FAMILY_NAME, "family_name"),
@@ -141,90 +208,250 @@
 allows to stay compatible with vcard, Windows and LDAP naming schemes whenever
 reasonable.
 
-full_name displayName
-given_name givenName First Name
-middle_name initials
-family_name sn last_name
-birth_date bday
-email mail
-email_2 email2
-email_3 email3
-business_phone telephoneNumber
-business_phone_2 otherTelephone
-business_fax officeFax facsimileTelephoneNumber
-home_phone homePhone
-home_phone2_ otherHomePhone
-mobile_phone mobile Mobile
-business_fax facsimileTelephoneNumber
-other_fax otherFacsimileTelephoneNumber
-pager Pager officePager
-org company o organizationName
-org_unit department ou organizationalUnitName
-office physicalDeliveryOfficeName
-title Title
-manager Manager
-street st homePostalAddress
-state st
-zip_code postalCode
-location l
-country c co countryName
-zip postalCode
-url wwwHomePage
-note info comment
-fburl msExchFBURL labeledURI
+   TODO: Check with LDAP RFCs and other sources for more synonyms
 
-The following example of a kcard shows how we allow vcard-, Windows- and LDAP like attribute synonyms
+      full_name; displayName
+      given_name; givenName; First Name
+      middle_name; initials
+      family_name; sn; last_name
+      birth_date; bday
+      email; mail
+      email_2; email2
+      email_3; email3
+      business_phone; telephoneNumber
+      business_phone_2; otherTelephone
+      business_fax; officeFax; facsimileTelephoneNumber
+      home_phone; homePhone
+      home_phone2; otherHomePhone
+      mobile_phone; mobile; Mobile
+      business_fax; facsimileTelephoneNumber
+      other_fax; otherFacsimileTelephoneNumber
+      pager Pager; officePager
+      org company; o; organizationName
+      org_unit; department; ou; organizationalUnitName
+      office; physicalDeliveryOfficeName
+      title; Title
+      manager; Manager
+      street; st; homePostalAddress
+      state; st
+      zip_code; postalCode
+      location; l
+      country; c; co; countryName
+      zip; postalCode
+      url; wwwHomePage
+      note; info; comment
+      fburl; msExchFBURL; labeledURI
+
+The following example of a kCard shows how we allow a mixture of vcard-, Windows- and LDAP like attribute synonyms
 and how we user a vcard like syntax. The later shall help us to easily extend the definition in the future
 and also makes it easy to implement the functionality in the opensource client and LDAP repositories.
 
-Example:
-Content-Type: text/directory; profile="kcard"; charset=iso-8859-15
-Content-ID: <id3 at erfrakon.com>
-Content-Transfer-Encoding: Quoted-Printable
+   Example:
 
-begin:kcard
-source:ldap://cn=Martin%20Konold,cn=erfrakon,cn=de
-displayName:Martin (K) onold
-givenName: Martin
-sn: Konold
-bday;value=date:1967-10-13
-o:erfrakon
-title:Diplom Physiker
-note:Founding member
-email;entryid:Qs23445csasadd12312321das
-email;address:martin.konold at erfrakon.de
-email;dn:Martin Konold (erfrakon)
-email2:martin at konold.de
-business_phone:+49 711 674009-63
-business_phone_2:+49 711 674009-65
-other_fax:+49 711 674009-59
-home_phone:+49 7071 940353
-business_address;po_box:123456
-business_address;street:Nobelstrasse 15
-business_address;city:Stuttgart
-business_address;zip:70569
-business_address;country;Germany
-key;type=X509;encoding=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ
- AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI
- ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD
- ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc
- 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW
- 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF
- hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG
- SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc
- oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E
- IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9
- w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M
- SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V
- UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
-end:kcard
+      Content-Type: text/directory; profile="kCard"; charset=iso-8859-15
+      Content-ID: <id3 at erfrakon.com>
+      Content-Transfer-Encoding: Quoted-Printable
 
-In this example the properties source and key are unknown to most clients
-and have to be preserved(ignored) whenever possible.
+      begin:kCard
+      source:ldap://cn=Martin%20Konold,cn=erfrakon,cn=de
+      displayName:Martin (K) onold
+      givenName: Martin
+      sn: Konold
+      bday;value=date:1967-10-13
+      o:erfrakon
+      title:Diplom Physiker
+      note:Founding member
+      email;entryid:Qs23445csasadd12312321das
+      email;address:martin.konold at erfrakon.de
+      email;dn:Martin Konold (erfrakon)
+      email2:martin at konold.de
+      business_phone:+49 711 674009-63
+      business_phone_2:+49 711 674009-65
+      other_fax:+49 711 674009-59
+      home_phone:+49 7071 940353
+      business_address;po_box:123456
+      business_address;street:Nobelstrasse 15
+      business_address;city:Stuttgart
+      business_address;zip:70569
+      business_address;country;Germany
+      key;type=X509;encoding=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ
+       AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI
+       ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD
+       ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc
+       1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW
+       9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF
+       hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG
+       SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc
+       oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E
+       IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9
+       w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M
+       SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V
+       UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
+      end:kCard
 
-The property email has in total four lines representing the structure of a
-kcard email address. The following email2 property shows the simple
-default behaviour in the absense of detailed specifications.
+   In this example the properties source and key are unknown to most clients
+   and have to be preserved(ignored) whenever possible.
 
-The business_address is an example for a complete record.
+   The property email has in total four lines representing the structure of a
+   kCard email address. The following email2 property shows the simple
+   default behaviour in the absense of detailed specifications.
+
+   The business_address is an example for a complete record.
+
+   The key property is meant for an X.503v3 client certificate encoded
+   with the vcard compatible b-encoding.
+
+
+5. Formal Syntax
+
+
+6. Differences from vcard (RFC 2425, 2426)
+
+
+7. Acknowledgements
+
+   Many ideas and concepts got shamelessly lifted from looking at different
+   applications (KOrganizer, Evolution and others) and from the vcard
+   specification.
+
+   Too many valuable comments contributed by Joon Radleys from South Africa.
+   He was especially helpful for insisting on me to acknowledge the problem
+   with the existing vcard specification.
+
+8. Authors' addresses
+
+   Martin Konold
+   erfrakon Partnerschaftsgesellschaft
+   Nobelstrasse 15
+   70569 Stuttgart
+   Germany
+
+   Phone: +49.711.674009.63
+   EMail: martin.konold at erfrakon.de
+
+
+9. Security considerations
+
+   kCards can carry cryptographic keys or certificates, as shown in the example
+   in section 4.
+
+   kCards may carry private, confidential or public data. There is no
+   enforcement for such a classification withing this data format.
+   Access control and transport security has to be implemented using other
+   techniques like S/MIME and IMAP ACLs
+
+   The kCard objects have no inherent authentication or privacy, but can
+   easily be carried by any security mechanism that transfers MIME
+   objects with authentication or privacy.
+
+   The information in a kCard may become out of date.
+
+
+10. References
+
+   [ISO 8601]    ISO 8601:1988 - Data elements and interchange formats -
+                 Information interchange - Representation of dates and
+                 times - The International Organization for
+                 Standardization, June, 1988.
+
+   [ISO 8601 TC] ISO 8601, Technical Corrigendum 1 - Data elements and
+                 interchange formats - Information interchange -
+                 Representation of dates and times - The International
+                 Organization for Standardization, May, 1991.
+
+   [ISO 9070]    ISO 9070, Information Processing - SGML support
+                 facilities - Registration Procedures for Public Text
+                 Owner Identifiers, April, 1991.
+
+   [CCITT E.163] Recommendation E.163 - Numbering Plan for The
+                 International Telephone Service, CCITT Blue Book,
+                 Fascicle II.2, pp.  128-134, November, 1988.
+
+   [CCITT X.121] Recommendation X.121 - International Numbering Plan for
+                 Public Data Networks, CCITT Blue Book, Fascicle VIII.3,
+                 pp. 317-332, November, 1988.
+
+   [CCITT X.520] Recommendation X.520 - The Directory - Selected
+                 Attribute Types, November 1988.
+
+   [CCITT X.521] Recommendation X.521 - The Directory - Selected Object
+                 Classes, November 1988.
+
+   [MIME-DIR]    Howes, T., Smith, M., and F. Dawson, "A MIME Content-
+                 Type for Directory Information", RFC 2425, September
+                 1998.
+
+   [RFC 1738]    Berners-Lee, T., Masinter, L., and M. McCahill,
+                 "Uniform Resource Locators (URL)", RFC 1738, December
+                 1994.
+
+   [RFC 1766]    Alvestrand, H., "Tags for the Identification of
+                 Languages", RFC 1766, March 1995.
+
+   [RFC 1872]    Levinson, E., "The MIME Multipart/Related Content-
+                 type", RFC 1872, December 1995.
+
+   [RFC 2045]    Freed, N., and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) - Part One: Format of Internet
+                 Message Bodies", RFC 2045, November 1996.
+
+   [RFC 2046]    Freed, N., and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) - Part Two: Media Types", RFC
+                 2046, November 1996.
 
+   [RFC 2047]    Moore, K., "Multipurpose Internet Mail Extensions
+                 (MIME) - Part Three: Message Header Extensions for
+                 Non-ASCII Text", RFC 2047, November 1996.
+
+   [RFC 2048]    Freed, N., Klensin, J., and J. Postel, "Multipurpose
+                 Internet Mail Extensions (MIME) - Part Four:
+                 Registration Procedures", RFC 2048, January 1997.
+
+   [RFC 2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2234]    Crocker, D., and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 2234, November 1997.
+
+   [RFC 2425]    Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type
+                 for Directory Information", RFC 2425, September 1998.
+
+   [RFC 2426]    Dawson, F., and T. Howes, "vCard MIME Directory Profile",
+                 RFC 2425, September 1998.
+
+   [UNICODE]     "The Unicode Standard - Version 2.0", The Unicode
+                 Consortium, July 1996.
+
+   [VCARD]       Internet Mail Consortium, "vCard - The Electronic
+                 Business Card Version 2.1",
+                 http://www.imc.org/pdi/vcard-21.txt, September 18,
+                 1996.
+
+
+11. Full copyright statement
+
+   Copyright (C) Martin Konold, erfrakon (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the author or other
+   Internet organizations, except as needed for the purpose of
+   developing kolab standards in which case the procedures for
+   copyrights defined by the kolab community process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by author or erfrakon or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
\ No newline at end of file

--- addressbook DELETED ---





More information about the commits mailing list