<Dong-Young> Presence+ Dong-Young_Lee

<dom> ScribeNick: Suresh

Introductions

tlr: W3C defines an API for contacts/address book

Trying to understand the format to use for the API

It currently is based on PoCo, but we are aware of IETF vCard and we have received a liaison from OMA CAB re CAB Format

Quick overview of the various efforts

IETF Intro

Marc: new version of vCard spec is vCard4.0

Out in Mar 2010

Last Call occured two months ago, recevied comments, review under progress

<simon> yo

we are pretty late in the new process for changes but their is some room

tlr: any clarifications?

OMA CAB Intro:

Cristina: OMA CAB is defining a service around address book

The relevance for this discussion is the format for contacts, we considered vcard, poco, and other fields of community interest

we would like to see this format be re-used as much as possible including W3C

W3C DAP Intro:

Richard: we are working between the device and the web, we are looking for a solution to address this

we have PoCo which looks like a superset to vCard, but we also have a new format CAB

<stpeter> could the person who is typing in the background kindly mute their audio?

stpeter why do you think vCard is a subset and not a superset?

<danbri> [poco has all the opensocial fields; these aren't in vcard]

<Cristina_OMA-CAB> CAB has considered vCard, PoCo, OpenSocial, OASIS, etc in the CAB format

Suresh: it is not fair to say PoCo is a superset of the vCard, it depends on the version of vCard, etc. to make this judgement

<danbri> (vcard might have also have some constructs not directly in poco, true)

tlr: Cristina, can you clarify from CAB and how you see convergence?

<simon> most input from Joseph Smarr was to take features *out* of vCard to make it aligned on PoCo

Cristina: we have considered all formats including vcard, and PoCo

<tlr> OASIS contacts

Marc: we have OMA come to us showing interest but no contributions later on

vCard charter only included binding to XML but did not include functioanlity from OMA

Cristina: Individual companies representation was in IETF but not from OMA

tlr: are we in a position to converge or are we so far that it is difficult?

Cristina: From OMA, it will be a major change to go back and change the format

Rich: Does this mean there are implementations, or a process issue?

<tantek> apologies for the delay

Cristina: a little bit of both i.e. implementations and process issue

<tantek> hi danbri

<tantek> what'd I miss? ;)

Jerry: There is also an industry initiative RCS which is considering to use CAB Format

<tantek> RCS (URL?), CAB Format (URL?)

<simon> e.g. genealogy stuff

Peter: In IETF, we considered social network extensions

It has not been an effort to define everything (e.g. zodiac signs) but allow extensions to support new fields

<tantek> genealogy stuff has very little to do with social network extensions - what was the justification for adding the genealogy stuff?

<tantek> (no address book I know of implements any of the genealogy stuff)

tlr: the most important part of divergence seems to be platform piece...can you elaborate on the differences

<simon> no, i mean that genealogy stuff is an example of stuff that was considered for extensions

<simon> it's not in core

<tantek> but simon, why are there DDAY BIRTH DEATH properties?

<richt> tantek, I beleive that was an off-the-wall example to state that vcarddav are not throwing the kitchen sink in to vcard v4.0.

<simon> 1. they were already in vcard 3

<simon> 2. they were widely used in implementations

tlr: can you explain structural differences vcard 3 and 4?

<tantek> DDAY BIRTH DEATH are NOT in vcard3

<tantek> what implementations?

<simon> either 1 or 2

<simon> not both

<tantek> name / give a URL to *any* address book sw

<tantek> that has DDAY BIRTH DEATH

<simon> and I don't remember, it's in the mailing list archives

<tantek> sorry, citation required

<tantek> I'm not buying it

Peter: structure and semantics is similar in vCard 3 and 4, but we have fixed some semantics in vCard 4, sync of vcard objects between multiple devices

<simon> ;)

tlr: Cristina, can you elaborate on CAB?

<tantek> "search the archives" is an insufficient answer

<simon> it's been two years!

<tantek> if the spec authors cannot provide URLs to references, how can any of the rest of us be expected to find them?

<tantek> CAB (URL?)

<simon> i'll search afterwards and send you the ref

Cristina: The structure was developed from scratch, it revolves around individual and group, however, we have provided mapping to vCard

<richt> I believe the CAB spec is public, right?

Suresh: yes, the draft is public

<tantek> Suresh - could you post a URL to said public draft?

<Cristina_OMA-CAB> the link to cab 1.0 TS including the CAB format: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-CAB/Permanent_documents/OMA-TS-CAB_XDMS-V1_0-20100831-D.zip

see sub-clause 5.2.1.1 and 5.2.1.7 (for structure and semantics)

<tantek> what's in the .zip?

<tantek> is there a direct link to some HTML?

<dom> in the zip, there are 2 Word documents

<tantek> dom, that's a joke right? you're not being serious are you?

<dom> I'm afraid I am

<tlr> indeed

<marcblanc> for completeness for all to review:

<tantek> seriously folks, if you can't post HTML of your draft/proposal, you don't deserve to contribute to WEB standards

<tantek> no sympathy

<marcblanc> vcard4: http://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardrev/

<tantek> this is no longer the 1990s

<marcblanc> vcard xml mapping: http://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/

<Cristina_OMA-CAB> the link to the mapping between CAB format and vcard 2.1 and 3.0: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-CAB/Permanent_documents/OMA-TS-CAB-V1_0-20100901-D.zip, see sect. 5.4.3

5.4.3 for mapping to vCard

<tantek> correct - not on phone

<tantek> call day/time turned out to be very bad for me, Chris Messina (also traveling), and Joseph Smarr

<tantek> tlr what's the "PoCo question" ?

tlr: action item to set up a mailing list between the groups

<tantek> tlr - will yet another mailing list that everyone has to follow actually solve the problems?

tlr: action point: Cristina to circulate the final draft of OMA CAB specs

from W3C perspective we will continue discussions to see how we can resolve this issue

<tantek> Suresh, tlr - I request circulating a URL to HTML on the public web of the draft of the OMA CAB specs

<tantek> something that can be indexed/searched by web search engines

has anyone done vCard XML and CAB specs?

<simon> is that what you mean? vcard xml mapping: http://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/

Cristina: not sure if everyone has looked at the liaison from OMA to W3C

we have two options: 1) W3C adopt CAB, 2) provide API to support only the common fileds across different fields

Cristina: 2) maybe more appropriate

<wonsuk> Wonsuk: +1 for 2)

Richard: dependency on external formats can be a problem

Bryan: all specs are open in OMA

<tantek> Bryan please provide URLs to the licenses which you mean by "open" in this context by OMA

<tantek> e.g., Creative Commons, OWFa, etc.

<tantek> CC0 preferably IMHO

+q

Cristina: the situation is still the same with vCard in terms of maturity

<simon> we're talking about vcard 4 here. vcard has been around for a long time

<Cristina> for vcard 3.0 and 2.1 we provide a mapping in cab

richard: extension mechanisms in vcard is good

<tantek> richard, why? please cite URLs to use cases.

Suresh: CAB is in XML and will let you add extensions

cyrus: vCard 4 allows you to provide extensions

<simon> that was cyrus

<marcblanc> extensions that can be registered in a managed IANA registry, available publicly, with pointers to specs.

<tantek> re: XML and extensions - in practice on the web, XML extensions have nearly universally been a failure

<tantek> e.g. death of XHTML2 etc.

<richt> tantek, my point explained on the call (but not minuted) was that vCard 3.0 was published a loong time ago. Then an industry organically co-ordinated to create impp extension at a later date (all in IETF)

<tantek> ah, centralized extensions - ok - that makes more sense - thanks richt

<richt> ...so extensions could allow industries to align organically or within specific industries (e.g. browser makers). That the hypothesis of my argument.

Suresh: our position is that the second option is the most practical way forward

It is a short term solution and in long term we should aim for convergence

tlr: the questions is whether we can provide API extensions and whether CAB and vCard extensions are useful from DAP perspective

<tlr> say "q+" on IRC

Cristina: there are efforts to offere mapping between multiple formats, so it is only matter of putting the formats together and taking the common denominator

<tantek> is there a wiki for vcarddav work?

<tantek> or OMA work?

<marcblanc> http://trac.tools.ietf.org/wg/vcarddav/trac/wiki

<marcblanc> (not used currently by the wg)

Suresh: what do IETF folks think about the short term solution i.e. use the common fields in the DAP API

<marcblanc> generic place for IETF wg with issue tracker, etc...

<marcblanc> http://tools.ietf.org/wg/vcarddav/

<tantek> have to run

<tantek> thanks for the URLs marcblanc

<tantek> will be back on #contacts in about 30min

<tantek> in case anyone wants to continue chatting

<tantek> thanks everyone!

<Cristina> no wiki for OMA

Next Steps

<danbri> (public minutes is good / essential)

tlr: will post the minutes and action items from the meeting

marc: from IETF, we will post these minutes and discuss within IETF the next steps

tlr: will send the conclusion, thank you all for the call

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Last/Last Call/
Succeeded: s/xxx:/stpeter/
Succeeded: s/Mike/Marc/
Succeeded: s/rhi/right?/
Succeeded: s/xxx:/cyrus:/
Succeeded: s/de/what do/
Found ScribeNick: Suresh
Inferring Scribes: Suresh
Default Present: +1.418.656.aaaa, Thomas, MarcBlanchet, SimonPerrault, stpeter, DongYoungLee, +1.425.391.aabb, bryan_sullivan, Dan?(ATT), +44.208.783.aacc, +1.760.705.aadd, +44.759.510.aaee, alexey, richt, +1.361.889.aaff, Cristina_OMA, Suresh, +1.412.420.aagg, CyrusDaboo, dom, +1.217.337.aahh, PeteResnick, danbri, wonsuk, nwidell
Present: +1.418.656.aaaa Thomas MarcBlanchet SimonPerrault stpeter DongYoungLee +1.425.391.aabb bryan_sullivan Dan?(ATT) +44.208.783.aacc +1.760.705.aadd +44.759.510.aaee alexey richt +1.361.889.aaff Cristina_OMA Suresh +1.412.420.aagg CyrusDaboo dom +1.217.337.aahh PeteResnick danbri wonsuk nwidell Dong-Young_Lee Suresh_Chitturi Dominique_Hazael-Massieux Wonsuk_Lee
Agenda: http://lists.w3.org/Archives/Member/member-device-apis/2010Sep/0003.html
Got date from IRC log name: 03 Sep 2010
Guessing minutes URL: http://www.w3.org/2010/09/03-contacts-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.