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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
