On Mon, Mar 15, 2010 at 7:12 PM, Peter Saint-Andre <[email protected]> wrote: > On 3/12/10 1:35 PM, Laurent Eschenauer wrote: >> Hi all, >> >> As discussed previously, I've started looking at a potential vcard4 >> extension. Here are some initial thoughts. I'm sure that I missed a >> lot of things, having just looked at these specs for the first time. >> Feel free to add/comment. Once we had some more discussions, I'm happy >> to summarize the feedback and have a go at a first draft. >> >> Cheers, >> >> -Laurent >> >> 1. the introduction of extensibility is a good thing, it will enable >> clients, servers and applications to innovate in the profile space, >> adding new fields to support new kind of use cases (e.g. social >> networking related fields, private enterprise fields, etc.). We should >> aim at supporting it is as much as possible. > > Agreed. > >> 2. vCard-4 introduces the notion of 'merge' and PID to uniquely >> identify a property in the vcard. > > I think those notions might have been defined before, but now they are > specified more completely. > > The merge stuff scares me. :) > >> Supporting this would enable a >> client to add or modify a field without having to resubmit the whole >> profile. I therefore suggest to move away from the 'simple' >> iq-get/iq-set pattern of vcard-temp and have something like >> <query/><publish/><merge/>. >> http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-09#section-7 > > Possibly. This is something we need to discuss, because it adds much > more complexity. > >> 3. the server can't simply store the vCard as a text blob, it will >> have to be aware of the content, be able to merge two vcards, retrieve >> a property and update it, etc... In addition, I suggest the server >> also do validation and enforce some rules with respect to extensions >> (you don't want to see the profile creep to insane size because a >> client keeps on adding extensions). > > More complexity. :( > >> 4. because of extension, profile sizes can become much larger anyway. >> Allowing the query to be selective will help (e.g. a client may just >> be interested in the name of the user). > > Probably. > >> 5. the JABBERID of vCard-temp is not required anymore, can be replaced by >> IMPP. >> http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-09#section-6.4.3 > > Yes. > >> 6. I did not find replacement for the DESC property. A lot of other >> "social properties" are also missing of vcard (see portable contacts >> for ideas; DESC is equivalent of NOTE in PoCo). It may be worthwile to >> suggest properties name and namespace in the spec to avoid >> fragmentation. I don't know if there is a repository of 'vcard >> extensions' somewhere. We could start. > > There are already discussions about this on the IETF list. > >> 7. Should we bring vcard based avatars (XEP-0153) in this or leave it >> in vcard-temp for now ? > > Or move to XEP-0084? > > Good questions. I'm not sure yet. > >> 8. I personally don't want to show all fields to all users and would >> like to be able to specify rules on a per field basis. E.g. birthday >> only visible to people on my roster with subscription both, phone >> number only visible to people tagged 'Friend' in my roster, etc... >> We'll eventually propose to add our acl extension to this. > > And yet more complexity. :( > > PEP gives us a relatively simple approach to that kind of behavior. > >> 9. vcard and PEP ? I can imagine some use cases where you want to be >> notified of changes in someone profile. I wonder if there is any >> reasons to try to link this to a PEP node. I don't say this should be >> part of the spec, but the use case is worth keeping in mind. > > Agreed. > > Peter >
I am not quite sure if vCard is a good format in the first place, what about moving forward to things like the OpenSocial format for specifying profiles ? Cheers, Ali
