[04:33:26] --- julian.reschke has joined [04:33:27] --- julian.reschke has left [04:33:56] --- julian.reschke has joined [05:53:45] --- kdz has joined [06:04:25] --- Chris Newman has joined [06:04:39] --- resnick has joined [06:05:07] * resnick scribing [06:05:24] Blue sheets started around [06:05:28] --- Barry Leiba has joined [06:05:40] --- cyrus has joined [06:06:30] Note well. [06:07:39] Alexey will co-scribe [06:07:48] Meeting materials are up on the web site. [06:08:03] Charter: [06:08:14] 1) rev vCard spec [06:08:39] 2) Address book protocol (small feature set, security, 3rd party access) [06:08:42] test [06:08:45] Then: [06:08:53] --- julian.reschke has left [06:08:54] 3) XML Schema [06:09:05] 4) vCard vendor extensions [06:09:29] 5) Sieve extension [06:09:36] 6) LDAP mapping. [06:09:46] --- julian.reschke has joined [06:09:55] Anyone using the audio out there? [06:09:57] --- alexey.melnikov has joined [06:10:12] I will scribe, to the best of my ability [06:10:48] I have been so far. [06:10:54] Good :-) [06:11:01] I'll stop when I have to speak. ;) [06:11:17] Mark Paterson: OMA DS and vCard. [06:12:17] Input from DS vCard workshop [06:12:39] OMA DS == SyncML [06:13:35] OMA currently specifies vCard 2.1 and 3.0 should be used. [06:13:42] But there are issues with those. [06:14:41] Too many type combinations [06:14:46] --- julian.reschke has left [06:14:54] Can't know how much info the device can take [06:15:13] can't enumerate contact methods. [06:15:14] --- julian.reschke has joined [06:15:14] --- julian.reschke has left [06:15:30] Clarify date time format [06:15:33] --- Paul Hoffman has joined [06:15:35] Clarify phone number format [06:15:36] --- julian.reschke has joined [06:15:42] Clarify address format [06:15:58] Obsolete communication format. [06:16:04] Specifics: [06:16:07] --- bernard.desruisseaux has joined [06:16:27] Type combinations are overly complex. [06:16:38] Not interoperable. [06:17:21] Devices handle these more or less well. [06:17:58] CN: Do you have the data on which form is most interoperable? [06:18:14] Mark: It's very variant. [06:18:59] CN: Losing information is one thing, but want to know which form is best to generate. [06:19:30] Mark: Should at least remove stupid combinations. [06:21:09] Hard to describe what each device will accept. [06:21:11] --- julian.reschke has left [06:22:23] --- julian.reschke has joined [06:22:25] Also can't tell what changed after you get data back. [06:23:31] CD: Devices have their own schema. You're trying to map from vCard to schema (round trip). How much of this can you say, "You *need* to support this stuff." [06:24:15] (CN == Chris Newman. CD == Cyrus Daboo) [06:24:45] Mark: [06:25:45] No support for identifying which particular item is being talked about. (cf. PID slide later in Simon/Pete's stuff) [06:26:49] More stringent date formats. [06:27:11] More stringent phone number format. [06:28:16] (Do we want e.164?) [06:28:33] KZ: Difference between "numbers" and "dialing sequences" [06:29:22] Unknown: Can't have shortened phone number w/e.164 [06:29:40] KZ: Some way to mark things as e.164 [06:29:54] SP: 2426 says e.164 [06:31:00] Pete: Agrees with Kurt about adding type information for phone numbers [06:31:35] SP: Need 2 properties. [06:32:33] Unknown: Other ways of specifying dialing strings might be needed. But still don't want re-formatting; should always keep original. [06:33:14] (Would someone who knows identify the speakers who are unknown to me.) [06:33:47] Format of postal addresses need specification. [06:34:17] Therefore use LABEL instead of ADDR. [06:34:50] --- cyrus has left [06:35:02] Pause -- We're moving next door. [06:35:25] --- kdz has left [06:35:28] Please listen on v6Ops if you need to listen to the audio. [06:35:37] --- Barry Leiba has left [06:35:56] --- Paul Hoffman has left [06:36:16] http://videolab.uoregon.edu/events/ietf/ietf716.m3u [06:36:43] --- Julian has joined [06:38:53] We're settling in to new room. [06:39:08] And apparently 802.11 roaming works. [06:39:28] --- Barry Leiba has joined [06:39:30] --- cyrus has joined [06:40:57] We're ba-aaaaaaack. [06:40:59] Back to LABEL vs. ADDR [06:42:02] SP: LABEL should be more like FN vs. N [06:42:51] --- julian.reschke has left [06:42:57] DC: We need to acknowledge that free-form fields will get used. [06:43:48] DC: Not sure that it's a solution, but we can't mandate the psychology of using it. [06:44:06] KZ: Is the spec specific to US? [06:44:07] --- Julian has left [06:44:11] --- Julian has joined [06:44:17] Mark: Not clear. [06:44:58] KZ: Have both because you can't derive fields from presentation and vice-versa. [06:45:10] DC: What are constraints on WG wrt installed base? [06:45:37] DC: If it's US based, that's stupid and needs changing, but if there's installed base, we have to deal with that. [06:45:49] KZ: We can make changes to "fix" things. [06:46:55] DC: If the spec doesn't acknowledge the shortcuts by the community, it won't reflect reality. [06:47:13] SP: ADDR is supposed to be x.500. We could do another standardized property. [06:47:25] SP: Is LABEL actually useful? [06:47:50] SP: Answer: Yes. Not clear that ADDR solves every problem. [06:48:22] KZ: How do match which LABEL goes with each ADDR? [06:48:26] KZ: It's a problem. [06:49:42] Unknown: Do we "click" on addresses? (Ans: Yes, for mapping) [06:49:54] CD: Should look at Geopriv work on this topic. [06:50:33] Mark: Next slide - Remove obsolete communication methods (mostly done in 3.0) [06:51:15] Add things that are missing. [06:52:12] What would help OMA DS? Update spec. Test suites. [06:53:02] vObject Min. Interop Profile (not a great solution) [06:53:53] AS: Is the sloppiness the *cause* of the success? (e.g., things like LABEL make it easy to implement) [06:54:46] Mark: Need tight spec if you want to do sync [06:55:04] --- kdz has joined [06:55:06] MB: So is OMA DS going to review our specs? [06:55:20] MP: Yes, I'm encouraging that. [06:56:58] Simon is presenting vCard 4.0 [06:58:42] Changes from 00 [06:58:52] Merged RFC 2425 and 2426 [06:59:23] (some generic stuff which was irrelevant was removed) [06:59:25] Integrated RFC 2739 and 4770 [07:00:08] UTF-8 is now the default charset [07:00:59] New MIME type: text/vcard [07:01:22] question: does MS Outlook interop with UTF-8? I recall it doesn't. [07:02:13] Chris: MIME has default of US-ASCII for text/* [07:02:35] Pete: we didn't want to have a charset inside the vcard itself [07:03:28] Chris: internal label that the content is UTF-8 might be helpful for backward compatibility [07:03:42] Pete: VERSION:4.0 is the new label [07:04:33] Dave Crocker: it is important to have the default and also label it. Some contries were known to change the default, but this leaked [07:04:57] Kurt: any concerns about new MIME type? [07:05:01] [07:05:04] Room voiced no concern over the change in the MIME type. [07:06:03] New properties: places of birth, death, gender, preferred language of contact, kind (org, group, individual) [07:07:19] Dave Crocker: there are other important events in human lives. Should we be more generic? [07:07:40] --- aki has joined [07:07:41] --- aki has left: Lost connection [07:07:49] Dave C: add events: name, place and time [07:08:32] Dave C: what is the difference between "org" and "group"? [07:09:54] Simon: group is a vcard that refers to other vcards [07:10:13] "org" is more like X.500 thing [07:10:29] Dave C: suggestion group->grouping [07:11:13] Dave C: agrees with defining core in the document and letting IANA do the rest [07:11:27] Chris: date of birth without the year? [07:11:43] Cyrus: "sometimes in 1600" [07:11:59] Cyrus: another example: wedding anniversary [07:12:21] (some support for dates with no year) [07:13:11] Zoltan: do we really need date of death? Will people go and update my vcard when I die :-)? [07:13:30] Barry: it is useful for historic purposes [07:13:58] Kurt: might be used for representing the person's estate. [07:14:34] Zoltan: can this be done using a reference to another vcard? [07:14:37] Barry: that too [07:15:19] Cyrus: date of death is important for some religions. But maybe this can be better dealt in calendars [07:15:32] Simon: some properties were removed: [07:16:11] charset, mailer (obsolete, due to vcarddav, etc), context (redundant with URI scheme) [07:16:34] Also removed the group construct - no evidence that it is in use [07:17:05] N property is no longer mandatory, FN is [07:17:32] Apple is using group constuct, but it shouldn't [07:17:52] IANA changes: add vendor namespaces, etc. [07:18:22] Synchronization: big issue for vCard 4.0, lots of recent discussions on the mailing list. [07:18:39] Example: per-properies IDs [07:19:17] (e.g. TEL;PID=1;555-1234) [07:19:37] Many questions: is this needed. Should this be unique? [07:19:45] Should this be extended to parameters? [07:20:14] Pete: vcard itself has UID, so we just need simple PIDs (they can be just incremented) [07:20:41] Kurt: You might need UUIDs and change sequence numbers [07:21:22] Cyrus: you need to store the highest PID somewhere, or synchronization breaks [07:22:30] Pete got it and now explains it to Mark :-) [07:23:03] Cyrus: doesn't exactly likes UUIDs, as they are big strings. But compression should help [07:23:44] Zoltan: store this information outside of vcard? [07:24:29] Dave C: vcard is a standalone object, shouldn't require any external state for synchronization [07:25:10] Dave C: what is the biggest PID size? [07:25:58] Aki: we shouldn't even try to fix this, these are just bugs in implementations [07:26:21] Aki: the only useful usecase is offline editing. Not sure it is important [07:26:37] Pete: jumping up and down: Aki and Zoltan are wrong :-) [07:27:08] Pete: there is no server. [07:27:44] Pete: changing a phone result in new number being added on another device. We need to fix this. [07:28:04] Aki: we should have masters and slaves [07:28:16] : no, we have equal peers [07:28:39] Cyrus: we want to have a proper diff format for vcards [07:29:16] This might be better: tag only properties that changed [07:29:39] Dave C: I am hearing several issues [07:30:15] 1) relationship between a vcard and an underlying service [07:30:39] 2). synchronization problem - need to be clear about scenarious [07:31:10] 3). diff format - seems to be independent from the synchronization task [07:31:35] Mark (as the chair): should this be a WG draft? [07:32:22] No objection to not having this as the WG document [07:33:15] Pete: if we can't get closure on synchronization on the mailing list, can we create a design team? [07:33:22] chairs: too early for that [07:33:44] * resnick is back to scribing [07:33:53] Cyrus: CardDAV [07:34:26] vCard extensions to WebDAV, modeled on CalDAV (RFC 4791) [07:34:31] Currently draft -04 [07:34:33] Overview [07:34:49] vCards to store address/contact on the server [07:35:04] Server may use other formats, but semantics must map to vCard. [07:35:14] "Synchronization" was discussed at the App Area Workshop held last month. The following I-D might be of interest to folks: draft-jennings-apps-sync-00 [07:35:16] http://www3.ietf.org/proceedings/08mar/slides/vcarddav-0.pdf [07:35:39] --- mrichardson has joined [07:35:57] Address Object Resource is stored in Addres Book Collection on server. [07:36:04] AOR has 1 vcard. [07:36:14] ABC is a WebDAV collection. [07:36:40] (with specific semantics) [07:37:11] All vCards must be unique (a la UID) in a collection [07:37:21] Can't cross contain collections. [07:37:55] Draft extends MKCOL to create ABC [07:39:02] I also note the (concluded) LDUP working group did a lot of work in the area of synchronization, so some of its I-Ds might be of interest (in particular the I-D on automated updated reconciliation procedures). [07:39:42] Create: Use HTTP PUT, to retrieve use GET. [07:39:52] Use ETags for changes [07:40:15] Use WebDAV pre-conditions for invalid content on PUT [07:40:28] WebDAV ACLs for sharing address books and content [07:40:49] CARDAV:addressbook-home-set property to find address books. [07:41:48] CARDDAV:principal-address property points to a vCard for the user. [07:42:41] (i.e., the "me" card) [07:42:55] Question for cyrus... [07:42:58] CARDDAV:addressbook-query REPORT for search. [07:43:06] Go ahead Bernard. [07:43:07] Would the "Me" vCard be writeable by the user? [07:43:23] or would it simply be generated by the server and read-only [07:43:46] Answer: It might be. Server dependent. [07:43:57] More to the point, implementation dependent. [07:44:02] (I'm listening to the audio) [07:44:09] Thanks! [07:44:11] ack [07:44:43] Searches can return matches, and can return some of the data. [07:45:30] Q: Is this a recursive search? [07:45:49] A: No, not currently. [07:46:05] Perhaps we could do this with groups. [07:48:29] CARDAV:addressbook-multiget REPORT [07:48:39] retrieves multiple vCards in a single request [07:49:40] (very sceptic about multiget; I think this should use multiple GETs and pipelining) [07:49:49] Pete: why just not use multiget all the time? [07:50:12] Cyrus: multiget targets the parent URI, while get the specific URI [07:50:40] Cyrus: advantages - can also get properties of the resource with multiget [07:50:49] multiget also allow partial retrieval of the body of the resource [07:51:04] Actually, you would get these with the GET response as well. [07:51:38] query would probably need a logical OR [07:52:04] We don't have partial retrieval of the body with GET [07:52:05] --- aki has joined [08:01:42] --- resnick has joined [08:02:01] Additional workNeed better sync of collection contents - e.g., draft-daboo-webdav-syncNeed better notification of changes (to avoid polling)Aki: It's not just server performance; it's also client resourcesTo DoFeedback on MKCOL needs to be addressedNeed to work on syncNeed to work on notifications (more important to CalDAV)MB: Query room - Pull in CardDAV draft? Yes: Most No: NoneWhat should be done with MKCOLCN: Discuss here, but keep WebDAV mailing list in the loop [08:02:39] CN: We can adopt MKCOL as a WG document. [08:02:44] --- Julian Reschke has joined [08:03:08] On the draft: [08:04:24] Aki: Why not new methods? [08:04:33] CD: New methods are hard. [08:04:36] --- kdz has joined [08:05:11] The main argument for not inventing new methods is that they should be of *generic* use. [08:05:36] MB: Query room - Pull in MKCOL draft? Yes: Some No: None. [08:05:42] --- kdz has left [08:05:52] CardDAV Implementation report: Simon [08:05:55] --- kdz has joined [08:06:36] Apache module in C/C++ [08:07:16] Aki: This is the issue: Not enough hooks for MKCOL. [08:07:30] SP: Must force Apache to write the resource type in the info. [08:07:52] SP: API calls for changing resources don't allow modifying resource type. So had to force this. [08:08:16] CD: But what would you have to do to do MKADDRESSBOOK. [08:08:46] CD: It was anticipated that MKCOL bodies might be used in the future. [08:09:03] AN: Most client libraries allow any method. [08:09:16] Simon: [08:09:30] WebDAV: mod_dav (only class 2) [08:09:38] ACLs: mod_dav_acl [08:09:45] Support for MKCOL added to apache [08:10:10] Client is a perl command-line client. [08:10:22] Standard WebDAV ops. [08:10:56] Edit vCards interactively, with locking, by external editor or in batch mode [08:11:35] Comprehensive reports. [08:12:08] --- mrichardson has joined [08:12:13] Feedback: [08:12:20] Client is easy. [08:12:37] Requirements make server implementation harder [08:12:59] (WebDAV class 3, WebDAV ACL, TLS) [08:13:13] 3 obsoletes 1 [08:13:24] It doesn't include class 2. [08:13:25] CD: CalDAV couldn't use class 3 (timing) [08:14:32] SP: But why not do it in class 1? Easier to implement. [08:14:52] I don't think it's easier to implement. [08:14:57] CD: Worth looking at difference between 2 and 1. Locking is a big thing. [08:15:14] JR: Let me know if you want something said aloud. [08:15:26] /msg resnick Please do so. [08:15:33] ack [08:16:00] The important thing is that level 3 is not a superset of 2, but of 1. It doesn't include locking. [08:16:03] SP to Julian: Locking is hard. [08:16:18] Level 3 does not include locking. [08:16:33] --- mrichardson has left [08:17:55] Debate to continue later. [08:18:03] Why would we require something that is obsoleted? [08:18:27] (JR, personal opinion is that SP could be convinced.) [08:18:45] SP: Don't like to have to deal with ACL and TLS. [08:18:56] --- kdz has left [08:19:07] I guess the issue is that mod_dav is not yet at level 3. Let's fix that :-) [08:19:37] CD: Most mobiles have TLS; don't know why anyone would be worried about it. It wasn't a problem for CalDAV. [08:20:06] AN: TLS is not too hard for mobile devices. [08:20:27] CD: Version of TLS is an argument. [08:21:10] CD: wrt ACL - Key use case is sharing. Need ACL. [08:22:28] --- Chris Newman has joined [08:22:49] --- Chris Newman has left [08:22:58] --- Chris Newman has joined [08:23:09] SP: But why do we need it for a public server? [08:23:23] CD: So claim you implement it and always return Forbidden. [08:24:24] MB: Want lowest bar of entry. Some of these things shouldn't be required for a "good enough" implementation. [08:24:41] SP: Should be able to do a CardDAV server in a weekend in perl. [08:24:52] CD: Don't want out of band sharing mechanism. [08:26:00] Do we need multiget? Do we therefore need multiput? [08:26:25] CD: Yeah, more and more convinced this is necessary. [08:27:09] multiget defeats caching. [08:27:13] multiple GETs don't. [08:27:39] ack [08:27:43] OK, we are done. [08:27:46] Thanks all. [08:27:58] See you in Dublin. [08:28:03] --- resnick has left [08:28:08] --- Julian Reschke has left [08:28:21] --- Chris Newman has left: Replaced by new connection [09:32:02] --- alexey.melnikov has joined [09:33:00] --- alexey.melnikov has left