Evert Pot | 17 Apr 02:33 2014

WebDAV Collection Sharing

Hi All,

At CalConnect, we are looking to standardize a way for users to share
Address Book and Calendar collections with each other.

As of right now, there's a specification to enable this for Calendars,
written by Cyrus Daboo. This is currently already implemented by a wide
range of both clients and servers.

The specification consists of two parts, and can be found here:

http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-sharing.txt
http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-notifications.txt

On a very high level, this specification operates as follows:

* A user (owner of a calendar) invites a number of people, by email
  address using a POST method on a calendar collection.
* The invitee receives a notification-resource in a notification-
  collection with the invite inforomation.
* The invitee can then choose to accept or reject the invitation with
  a second POST request.
* The owner of the calendar receive a reply in his/her notification
  collection.
* If the invitee accepted in the invite, the calendar now also appears
  in the invitees calendar home.

This all works pretty well. Recently we've started talking about
implementing something similar for CardDAV, allowing users to also share
Address Books.
(Continue reading)

Gesh hseG | 29 Jan 01:18 2014

Confusion regarding the correct use of FN, N and NICKNAME in RFC6350 with regards to nicknames and honorifics

Hello.
The correct usage of FN/N/NICKNAME in the following scenario is unclear to me:
Suppose I have an acquaintance who is either more or less close to me than the average acquaintance,
thus leading to my referring to them using a nickname or honorific, respectively.
Then it appears that in a vCard referring to them, I should specify their full name in FN,
their name broken down into components in N, and the name by which I refer to them in NICKNAME.
In addition, assuming I wish for this person to be sorted by the referring name, I should set the SORT-AS
parameter of N to the value of NICKNAME.
Thus:
FN:Mr. John Joe Doe\, MSc
N;SORT-AS="Dad":Doe;John;Joe;Mr.;MSc
NICKNAME:Dad

FN:Lady Jane Dale
N;SORT-AS="Lady Dale":Dale;Jane;;Lady;
NICKNAME:Lady Dale

FN:Jeff Lebowski
N;SORT-AS="The Dude":Lebowski;Jeff;;;
NICKNAME:The Dude

However, this reading means the property names do not reflect their use (FN, N, and NICKNAME should
instead be called Full Name, Name Components, Common Name, respectively), and causes the duplication
of data (the value of SORT-AS and NICKNAME is duplicated).
In addition, it is unclear what name should be used by an application to refer to a person.

As far as I can tell, preferably, one would use FN to signify the regionally-correct concatenation of the components
of N. Both of these would refer to the full legal name of the person in question. Any personal appellations that one
has for the person in question would be given by NICKNAME. These appellations would be used by applications
to label and sort the person.
Of course, he application may permit the usage of FN, Last Name, First Name or First Name, Last Name as
the appellation by which a person is labeled and sorted. However, the default behavior would be to use NICKNAME.

This has the benefit of allowing people to supply vCards which would then need to be only minimally modified
by their acquaintances - just enough to have the vCard use the name those acquaintances use to label those people,.
Thus, John Joe Doe from the example above would give the same vCard, who would then insert a line causing him
to be referred to as "Boss", "Dad", "Kid", etc.

In brief, assuming I refer to a person by a name that is not their full name, how do I
A) correctly note this in their vCard,
B) write a standards-conforming program that displays and sorts the person the same way I refer to them?

Thank you in advance,
Gesh
_______________________________________________
VCARDDAV mailing list
VCARDDAV <at> ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav
Erwin Rehme | 7 Jan 23:22 2014
Picon

Question about SOURCE property in RFC 6350

In RFC 6350 is says:

6.1.3. SOURCE

Purpose: To identify the source of directory information contained in the content type. Value type: uri Cardinality: * Special notes: The SOURCE property is used to provide the means by which applications knowledgable in the given directory service protocol can obtain additional or more up-to-date information from the directory service. It contains a URI as defined in [RFC3986] and/or other information referencing the vCard to which the information pertains. When directory information is available from more than one source, the sending entity can pick what it considers to be the best source, or multiple SOURCE properties can be included. Does the "and/or other information..." statement mean that the value is can be "free form" text and not just a uri?

-- Erwin Rehme
_______________________________________________
VCARDDAV mailing list
VCARDDAV <at> ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav
RFC Errata System | 23 Dec 16:33 2013

[Errata Verified] RFC6350 (3845)

The following errata report has been verified for RFC6350,
"vCard Format Specification". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3845

--------------------------------------
Status: Verified
Type: Technical

Reported by: David Riggle <riggle <at> mac.com>
Date Reported: 2013-12-20
Verified by: Barry Leiba (IESG)

Section: 6.2.4

Original Text
-------------
       PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv

Corrected Text
--------------
       PHOTO:data:image/jpeg;base64\,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv

Notes
-----
Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH
character. The PHOTO property value in the example contains a comma. Therefore it must be escaped with a
backslash. Note that there are several other uses of the "data:" URI scheme in the document that also need
to be corrected.

Alternatively, a different format for base64 encoded data could be used in vCard 4.0. The ENCODING=b
format used in vCard 3.0 wasn't so bad.

----- Verifier notes -----
This represents a difference from earlier versions of vCard, and the ABNF does not support escaping for
URIs.  This errata report is correct and verified, but a full correction to the issue will have to wait for a
document update.

--------------------------------------
RFC6350 (draft-ietf-vcarddav-vcardrev-22)
--------------------------------------
Title               : vCard Format Specification
Publication Date    : August 2011
Author(s)           : S. Perreault
Category            : PROPOSED STANDARD
Source              : vCard and CardDAV
Area                : Applications
Stream              : IETF
Verifying Party     : IESG
RFC Errata System | 23 Dec 16:30 2013

[Errata Verified] RFC6350 (3846)

The following errata report has been verified for RFC6350,
"vCard Format Specification". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3846

--------------------------------------
Status: Verified
Type: Technical

Reported by: David Riggle <riggle <at> mac.com>
Date Reported: 2013-12-20
Verified by: Barry Leiba (IESG)

Section: 6.5.2

Original Text
-------------
           GEO:geo:37.386013,-122.082932

Corrected Text
--------------
           GEO:geo:37.386013\,-122.082932

Notes
-----
Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH
character. The GEO property value in the example contains a comma. Therefore it must be escaped with a backslash.

--------------------------------------
RFC6350 (draft-ietf-vcarddav-vcardrev-22)
--------------------------------------
Title               : vCard Format Specification
Publication Date    : August 2011
Author(s)           : S. Perreault
Category            : PROPOSED STANDARD
Source              : vCard and CardDAV
Area                : Applications
Stream              : IETF
Verifying Party     : IESG
RFC Errata System | 20 Dec 20:09 2013

[Technical Errata Reported] RFC6350 (3846)

The following errata report has been submitted for RFC6350,
"vCard Format Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3846

--------------------------------------
Type: Technical
Reported by: David Riggle <riggle <at> mac.com>

Section: 6.5.2

Original Text
-------------
           GEO:geo:37.386013,-122.082932

Corrected Text
--------------
           GEO:geo:37.386013\,-122.082932

Notes
-----
Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH
character. The GEO property value in the example contains a comma. Therefore it must be escaped with a backslash.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6350 (draft-ietf-vcarddav-vcardrev-22)
--------------------------------------
Title               : vCard Format Specification
Publication Date    : August 2011
Author(s)           : S. Perreault
Category            : PROPOSED STANDARD
Source              : vCard and CardDAV
Area                : Applications
Stream              : IETF
Verifying Party     : IESG
RFC Errata System | 20 Dec 20:07 2013

[Technical Errata Reported] RFC6350 (3845)

The following errata report has been submitted for RFC6350,
"vCard Format Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3845

--------------------------------------
Type: Technical
Reported by: David Riggle <riggle <at> mac.com>

Section: 6.2.4

Original Text
-------------
       PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv

Corrected Text
--------------
       PHOTO:data:image/jpeg;base64\,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv

Notes
-----
Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH
character. The PHOTO property value in the example contains a comma. Therefore it must be escaped with a
backslash. Note that there are several other uses of the "data:" URI scheme in the document that also need
to be corrected.

Alternatively, a different format for base64 encoded data could be used in vCard 4.0. The ENCODING=b
format used in vCard 3.0 wasn't so bad.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6350 (draft-ietf-vcarddav-vcardrev-22)
--------------------------------------
Title               : vCard Format Specification
Publication Date    : August 2011
Author(s)           : S. Perreault
Category            : PROPOSED STANDARD
Source              : vCard and CardDAV
Area                : Applications
Stream              : IETF
Verifying Party     : IESG
RFC Errata System | 10 Oct 14:31 2013

[Editorial Errata Reported] RFC6350 (3748)

The following errata report has been submitted for RFC6350,
"vCard Format Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3748

--------------------------------------
Type: Editorial
Reported by: Philipp Kewisch <mozilla <at> kewis.ch>

Section: 10.3.3

Original Text
-------------
The following table has been used to initialize the parameters registry.

Corrected Text
--------------
The following table has been used to initialize the data types registry.

Notes
-----
This is a copy/paste failure from the previous section.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6350 (draft-ietf-vcarddav-vcardrev-22)
--------------------------------------
Title               : vCard Format Specification
Publication Date    : August 2011
Author(s)           : S. Perreault
Category            : PROPOSED STANDARD
Source              : vCard and CardDAV
Area                : Applications
Stream              : IETF
Verifying Party     : IESG
Renato Iannella | 26 Sep 14:57 2013
Picon

vCard Ontology WD Updated

The W3C vCard Ontology working draft [1] has been updated and announced [2].

This updated version addresses all the feedback from the first release [3] including offline discussions with some of the people who gave initial comments and feedback.

In addition we have simplified the use of Classes and updated the n-ary model to support vCard's property parameters so that OWL-DL can be supported. The ontology now also is backward compatible with the previous ontology (with deprecated terms) and has been posted here [4].

We welcome all feedback and comments.

Thanks

Cheers...
Renato Iannella
Semantic Identity
http://semanticidentity.com
Mobile: +61 4 1313 2206

[1] http://www.w3.org/TR/2013/WD-vcard-rdf-20130924/
_______________________________________________
VCARDDAV mailing list
VCARDDAV <at> ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav
Teiichiro Fukuda | 25 Sep 06:34 2013

Review of draft-fukuda-vcarddav-phonetic-transcription-02.txt

Hi,
Feedback of everybody was reflected and the draft was updated.
I ask the opinion of a lot in this draft.

http://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-02

Thanks,

Teiichiro Fukuda
DataPacRat | 20 Sep 16:59 2013
Picon

Going from I-D to RFC?

There are at least a couple of drafts for extending the vCard format - my signed vCard set, the phonetic name one, and likely a few more. Once a given draft has been hammered out into a reasonably acceptable form... what should the submitter(s) do next, to try an maximize the odds of a reasonably speedy adoption as an RFC?



--
Thank you for your time,
--
DataPacRat

_______________________________________________
VCARDDAV mailing list
VCARDDAV <at> ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav

Gmane