Re: [dispatch] Updated JSContact revision 02

["Robert Stepanek" <[e-mail]>]

Hi Marten,

thanks for your feedback.

On Thu, Jun 20, 2019, at 3:54 PM, Marten Gajda wrote:
> Thanks! I have a few more comments/ideas.
> 
> * considering the new "kinds" we should also discuss the name "JSContact" again; JSCard sounds more appropriate.

I had this planned as well. The next RFC draft will use JSCard and JSCardGroup. We keep using JSContact for the overall RFC for now.

> * consider creating one section per property, this way they show up in the index and as section titles which makes it easier to parse the document (I suppose that was planned for a later stage but it would be helpful at this stage already).

Mario and I will keep the current layout for now. I say we'll revisit the document layout when the data format is more stable.

> * creating one property for each kind of date associated with a contact doesn't scale well. [...]

The next RFC draft will include an anniversaries property.

> * nickname is already a very specific type of "alias", there are other kinds of alias names like "religious name" or "stage name", hence an array of "Alias" objects (each with a type and name field) would be more appropriate.
> * during the Bedford CalConnect we discussed the option to replaces "addresses" with an array of the more generic locations taken from JSCalendar
> * not sure about the PersonalInfo object, all the other properties are pretty much "personal information" as well. In case of a machine (but also a person) you could/would probably call these "capabilities". I think this could be useful for other "kinds" of "contacts" too, like
>  * whether a "location" is accessible
>  * whether a "resource" kind like a "projector" is movable
>  * which kind of fuel a "car" resource needs
>  I think all these fall into the same category of information. Again I don't suggest to specify all these, just to make this property fit for these use cases too.

I'm not convinced of that. Our current idea is to provide specific properties for the common use cases, and add generic properties for the uncommon ones. We assume it's common to organize personal contact addressbook information. That being said, I expect the format will still change considerably, the more we learn about the expected use cases of the format.

> * it would be helpful to have a few examples (especially for non-individual kind of contacts) to see how this would look like in action.

I'm looking at this RFC mainly with the experience from our contact organizer application at FastMail. It'd be great to see how other people would like to use the non-person contact cards, or how they are doing now with VCARD!

Regards,
Robert