[VCARDDAV] IETF 81 minutes

[Simon Perreault <[e-mail]>]

All,

These are the draft minutes of the meeting. Let me know if there's any
adjustment to be made.

Simon

> 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.

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca