Subject: [dispatch] Updated JSContact revision 02

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 20 Jun 2019 13:32:55 +0200

I have just submitted revision draft-stepanek-jscontact-02 of the JSContact RFC draft: https://tools.ietf.org/html/draft-stepanek-jscontact-02

I'm happy to say that Mario Loffredo and me are now co-authors of this draft! Mario provided lots of input since the initial draft, and the current revision is largely shaped by his insights. Thanks, Mario!

We are still looking for a workgroup to adopt this draft. If you know any which might be interested, please let us know.

Revision 02 address the feedback received on this list and personal emails:

- fullName is an array of FullName objects
- structuredName wraps the individual name fields
- jobTitle and role are multi-valued
- Address objects have new properties postOfficeBox and extension
- prodId property stores the VCARD PRODID identifier
- added the updated UTC-timestamp property
- added new kinds: device and application (RFC 6473, RFC 6869)
- added categories property
- allow RFC3339 timestamps in birthday
- added deathDate, birthPlace and deathPlace properties (RFC 6474)
- renamed ContactInformation object to ContactMethod
- added personalInfo property and PersonalInfo object (RFC 6715)
- rephrased uid property definition

As always, we are looking forward to your feedback.

Regards,
Robert

---

From: Marten Gajda <[email-masked]>
Date: Thu, 20 Jun 2019 15:53:18 +0200

Thanks! I have a few more comments/ideas.

* considering the new "kinds" we should also discuss the name
"JSContact" again; JSCard sounds more appropriate.

* 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).

* 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

* creating one property for each kind of date associated with a contact
doesn't scale well. We already have three different date properties
(birthday, deathdate, anniversary), there are others which may be worth
taking note of, depending on the "kind" of contact:
  * some individuals celebrate two birthdays, like the Queen of England
(see https://www.royal.uk/queens-birthday)
  * some religions have special personal events like "confirmation", etc.
  * devices may have a "next/last maintenance date"
  * locations may have a "construction date"
 I don't want to suggest to specify them all, just wanted to justify the
need for such a structured date type.

* deathPlace and birthPlace should become location types instead of
dedicated properties

* 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.

* 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.

That's all for now.

Cheers,

Marten

Am 20.06.19 um 13:32 schrieb Robert Stepanek:
> I have just submitted revision draft-stepanek-jscontact-02 of the
> JSContact RFC draft:
> https://tools.ietf.org/html/draft-stepanek-jscontact-02
>
> I'm happy to say that Mario Loffredo and me are now co-authors of this
> draft! Mario provided lots of input since the initial draft, and the
> current revision is largely shaped by his insights. Thanks, Mario!
>
> We are still looking for a workgroup to adopt this draft. If you know
> any which might be interested, please let us know.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: "Robert Stepanek" <[email-masked]>
Date: Sat, 29 Jun 2019 17:23:46 +0200

Hi Marten,

thanks for your feedback.

On Thu, Jun 20, 2019, at 3:54 PM, Marten Gajda wrote:
> * 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
>  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