On 3/18/10 4:54 AM, Laurent Eschenauer wrote: > Thanks Peter for the feedback on vcard4. Comments below. > > We'll start implementing and experimenting with these concepts on our > side, so if anyone else has feedback, I would be happy to hear now. If > things work well, I'll draft the XEP reflecting the way we do things > and we can iterate on the document if you guys want to move forward on > this.
We definitely want to move forward on this. >>> 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. :) > > We can call it "update" instead of "merge" if you prefer :-) I > personally think that merging can be hell when we talk about merging > complete address books (multiple vcards). But in this case, it is in > fact a simple update of well identified fields. I need to look at the merge logic again. Perhaps it's not as scary as I remember. >>> 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. > > Supporting extension will inevitably add complexity. The question is > where: client or server side ? I would favor a richer server API and a > larger server responsibility in guaranteeing validity of the profile. That is the original Jabber tradition, yes. >>> 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. :( > > See previous point. > >>> 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. > > Another argument in favor of selective query is bandwidth/processing > constraints in mobile use cases. Most of the time, our client fetches > someone profile just to get the avatar, the description and maybe an > email. If the profile gets bigger because of extensions, this will be > even more important. True. >>> 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. >> > Hmm. I would love to hear more on how you see this being done with > PEP. I will post this question (and a reflection on the micronlog pep > xep) in another thread. > >>> 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. Yes, more discussion is needed... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
