IETF 81, Québec VCARDDAV 2011-07-26 17:10-18:10 draft-cauchie-vcarddav-oma-cab-extensions Barry Leiba - Goal is to take the things in OMA that don't already exist in vCard and to create properties for them. - Agreed to take the very OMA-specific stuff out of the document. - Need to explain better the difference with base vCard properties in some cases. - Will eventually have a permanent URL to the OMA spec. - Enough guidance to make a new revision. - Propose adoption as working group item. Alexey Melnikov: Don't forget to take into account Chris Newman's review. Berry: We will. Barry: There is also some duplication between this and the next document. We'll sort this out. draft-george-vcarddav-vcard-extension Barry Leiba - This one is less straightforward. Needs effort. - Based on the FOAF project. - Needs more input, needs to be fleshed out. Needs collaborators. Alexey Melnikov: There is overlap between this and the previous one. Can be just get one? Barry: It's a bad idea to put all in a single document. But we need to eliminate duplication. Alexey: What's the IANA procedure for properties? Barry: There's a template. A new spec can update the registry for the other property. Alexey: There is an expert review. Cyrus Daboo: We want people to post this to the mailing list to get reviews. Simon Perreault: There is no designated expert. Barry: There is none yet. Alexey: IANA will ask for one to be designated when it needs one. Barry: I think it would be good for the WG to adopt this. But we need energy to put into this draft. Cyrus: Social networking properties are important. People are doing this with X- properties in vCard 3. Peter Saint-Andre: We can't do all properties in this working group. Barry: We can start with this and then people can make extension drafts or revisions. We can put some text saying that this is a first pass. draft-li-vcarddav-vcard-id-property-extensions Barry Leiba - Had good reviews, everybody is happy with it. - This one and Peter's draft are the test cases for the IANA registration process. draft-daboo-vcard-service-type Cyrus Daboo - A way of tagging properties with a service provider identifier such as Facebook, Twitter, etc. - Can be rolled into draft-george-vcarddav-vcard-extension. Happy to see Barry take over that behaviour. draft-cal-resource-schema Cyrus Daboo - Defines a schema for scheduling stuff (rooms, resources, ...). - LDAP properties and attributes. - Needs vCard reviews, LDAP reviews, as well as calendaring reviews. Spans many different areas. - Had an LDAP review from Chris Newman. - LDAP mapping is already on the charter. This draft does that for the items it defines. - There are more problems from LDAP to vCard than the other way. Joe Hildebrandt: It's useful to have LDAP to vCard mapping. The other way is less useful because it assumes you're able to write to the LDAP server. Alexey: There is no better place than this WG for this work. draft-saintandre-vcarddav-thing Peter Saint-Andre - No longer about things, this is now about "application". - In pretty good shape, pretty much done. Cyrus Daboo: The cal resource schema uses a kind that does not map to application. Do we need to define a new kind? Peter: What is a calendar resource? Something about which there is a schedule? Cyrus: Something that can be scheduled that is not a person, a group, or a room. There are four CU types in iCalendar: individual, group, location, and resource. We would like to map those to vCard. Peter: Scheduling is something that you do with something. I would prefer to look at it from a taxonomy perspective rather than just "something I can schedule". Joe Hildebrandt: Make sure "other" is in the registry, go on with our lives. Barry: Making a "schedule" KIND is reasonable. Peter: Can one vCard have multiple kinds? I wouldn't want a vCard with kind "room" and kind "schedule". Barry: There can be more than one kind for a single vCard. Cyrus: I'll take that back to the CalConnect folks. Peter: I looked at the LDAP spec and X.200. "device" is a piece of hardware. I would be fine with defining that if it is useful. Cyrus: Is "application" a kind of "device"? Peter: No. Cyrus: Will you add "device" to your draft? Peter: No I won't. We should have one little one for each. Barry: This could go in the LDAP document. Cyrus: Yes we could do that. Charter discussion Simon Perreault: We have 2 drafts ready and 4 needing work. Barry: Ready meaning ready to pass to the IESG, but the WG still needs to adopt them so that when they go to the IESG they are WG drafts rather than AD-sponsored. We're talking about 6 drafts to adopt. Simon: draft-daboo-vcard-service-type would be dropped. Simon: Who would be interested on working on social networking stuff? (draft-cauchie- and draft-george-) (a couple hands) Simon: Who will be implementing it? (two hands) Joe Hildebrandt: Depends on whether it gets mapped into LDAP. LDAP is becoming more and more important to us. We may need to define new LDAP schemas to capture this stuff. Cyrus: I'm surprised that you think social networking will be part of a corporate LDAP directory. I don't see that. Joe: This is not from a corporate deployment model. This is for another thing that we have not announced yet. Cyrus: So do we want to write the LDAP schema for that? Peter: Change the name from VCARDDAV to VCARDDAP. Simon: How about LDAP and scheduling? How many people would be willing to work on that? (a couple hands) Simon: Implementing? (two hands) Simon: How many people feel like they know LDAP well enough to have an expert advice on these drafts? (one hand) Peter: Joe's raising his hand because he is a proxy to people who know LDAP. Peter: We do have an LDAP directorate. Whenever I poke them, nothing comes back. Alexey: I know four people in the directorate. I don't know how much time they spend in the IETF. Peter: Is there LDAP energy elsewhere? Simon: If we were to be stuck with a dead technology and we wanted to import it into vCard, would we need experts to help us? Barry: LDAP has enough depth that having people who understand LDAP is enough. But we can scare up a person or two to help us. Alexey: At least half of my co-workers are working on LDAP schema. Simon: Any other question I should be asking? Joe: Would we need to recharter significantly? Does this require extraordinary measures or is this within the process of recharter? Peter: We finished a lot of the stuff in the old charter. There is still the LDAP item. The charter doesn't need updating. It's good to reach out to LDAP folks to at least review our work. Alexey: How many reviews do you want? Peter: I would like more than one interoperable implementation of the review process. Two would be much better than one. Cyrus: I'd like to see actual LDAP implementors. Simon: Do authors have all the guidance they need to make new revisions? (yes) Barry: What does the new charter look like? Do we also include future extensions? How long do you as chair see this WG continue? Simon: As shortly as possible. We don't need a WG for new extensions. We have a mailing list and an expert review. So only these 6. No need to leave it open. Peter: We've gotten interest in these 6 documents. Others might come along but we don't need to keep the WG around to do that. Simon: This cycle has been helpful. You guys have received a lot of feedback from this WG and you're going to get WG document status. If during the next cycle there is a bunch of new documents that come along, we'll do the same thing. Barry: Who is responsible for the new charter? Simon: I guess I am.