Subject: [dispatch] JSCalendar: Updated to draft version 01

From: "Robert Stepanek" <[email-masked]>
Date: Fri, 07 Jun 2019 12:06:57 +0100

Hi all,

I've submitted draft version 01 of draft-stepanek-jscontact:
https://tools.ietf.org/html/draft-stepanek-jscontact

This version is includes some, but not yet all of the feedback of individual
reviewers as well as the CalConnect XLV meeting this week.

Changes:
- Added a new property for full names.
- Changed the single-string name component fields to arrays.
- Added a kind property, similar to VCARD KIND.
- Added a ISO-3166-1 country code property to Address.
- Added a full address property to Address.
- Added preferredContactMethod property.
- Added geo URI and time zone properties to Address.
- Added a role property.

There following feedback needs further consideration and I'm happy about
any input:

Names:
- Learn more about the findings of ISO/TC 37/SC4 on naming schemes, and
 probably reuse it for JSContact.
- Current vendors such as Google and Apple already make use of
 X-PHONETIC-{FIRST,LAST}-NAME properties for phonetic names.
 It's similar to https://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-03

Contact:
- Support more than one company, and consider renaming it to affiliations or
 organizations.
- Allow for a similar property such as SORT-AS in VCARD4.
- Add categories and keywords properties, similar to JSCalendar.
- Allow for hierarchies? (group includes group? contact includes contact?)

ContactInformation:
- Add a unique id to each ContactInformation, so that sync conflicts can be
 better resolved. (might want to change the contact information lists to
 JMAP-style maps, where the id is the map key).

ContactGroup:
- List contact objects in a group, rather than their uids. If only uid is of
 interest, the embedded contact could just define that property.
- Allow to override properties for a contact within a group. E.g. a contact
 might override its "role" for a group that defines a project. Could use
 JSCalendar PatchObject in a property called contactOverrides.

Address:
- consider renaming it to Location
- Learn more about ISO19160-6 for international address
 profiles.

Other:
- Localization most probably will be only required for names and address.
- Rename either the RFC or the Contact object to JSCard for disambiguation?

Cheers,
Robert

---

From: Marten Gajda <[email-masked]>
Date: Tue, 18 Jun 2019 00:24:59 +0200

Hi Robert,

here are a few more ideas for consideration:

* instead of making name components top level elements introduce an
object called "structuredName" { firstName, lastName, middleName,
prefix, suffix ...}.

* ContactInformation -> use URIs instead of plain strings? e.g. vCard 4
prefers "tel:" URIs. Not sure if that's a good idea though. They are
machine readable, but not necessarily user friendly.

* Add additional kind "Resource" (i.e. projector, car …). Few years
back, we had a TC Resource, not sure whether the results have been
published somewhere though

* Support other kinds of events (i.e. see
https://tools.ietf.org/html/rfc6474, also specifies additional location
types: place of birth, place of death)

* Relationships (manager of, spouse of, etc), ideally linked via UID, I
guess

Cheers,

Marten

Am 07.06.19 um 13:06 schrieb Robert Stepanek:
>   It's similar to
> https://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-03
>
> Contact:
>   better resolved.. (might want to change the contact information lists to
> _______________________________________________
> 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: Tue, 18 Jun 2019 16:09:29 +0200

Hi Marten,

thanks for your input.

> * instead of making name components top level elements introduce an object called "structuredName" { firstName, lastName, middleName, prefix, suffix ...}. 

 The reason I kept it top-level is because I deemed names as "too important" for a nested property, and N properties can occur at most once in VCARD4 (RFC6474). But checking VCARD3 (RFC 2426), I see no restriction on cardinality. Any insight if N is safe to assume to occur only once? An array of StructuredName that consists of string array properties would seem to be unnecessarily complex for the majority of uses. What would you gain in your use cases from a StructuredName type?

Mario Loffredo also pointed out to me that FN can occur more than once in VCARD, so fullName might also need to become an array.

> * ContactInformation -> use URIs instead of plain strings? e.g. vCard 4 prefers "tel:" URIs. Not sure if that's a good idea though. They are machine readable, but not necessarily user friendly.

I'd rather keep plain strings, and restrict them to URIs for certain ContactInformation "type" and "label" combinations.

> * Add additional kind "Resource" (i.e. projector, car …). Few years back, we had a TC Resource, not sure whether the results have been published somewhere though

Mario also pointed me to the "application" and "device" kinds (RFC 6473, RFC 6869).

> * Support other kinds of events (i.e. see https://tools.ietf.org/html/rfc6474, also specifies additional location types: place of birth, place of death)

There's also death date for it. Which brings up another topic: VCARD BDAY and DEATHDAY allow all of the following values:

 BDAY:19960415
 BDAY:--0415
 BDAY;19531015T231000Z
 BDAY;VALUE=text:circa 1800

in JSCalendar we require them to be formatted as "YYYY-MM-DD" where any part may be 0s for unknowns. We could at least allow "YYYY-MM-DD" and "YYYY-MM-DDTHH:MM:SSZ" where any date part can be 0 for unknowns, and the time part omitted, if unknown.

> * Relationships (manager of, spouse of, etc), ideally linked via UID, I guess

Yes, we could use a structured similar to the JSCalendar "relatedTo" property (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-14#section-4.1.3)

Cheers,
Robert

---

From: Marten Gajda <[email-masked]>
Date: Wed, 19 Jun 2019 00:04:24 +0200

Am 18.06.19 um 16:09 schrieb Robert Stepanek:
> What would you gain in your use cases from a StructuredName type?
Mostly a cleaner data model.
>
> Mario Loffredo also pointed out to me that FN can occur more than once
> in VCARD, so fullName might also need to become an array.

I've never seen a vCard with more than one N or FN property. Since a
single FN is the normal case we could use a plain string for the name
and put only the additional names into an array:

{
    "name": "default formatted name goes here",
    "additionalNames": ["other formatted names", "go into this array"],
    …
}

or maybe join this with the nickname fields and give the names a label

{
    "name": "default formatted name goes here",
    "aliases": {
        "formatted": "other formatted name",
        "nickname": "nick"
    },
    …
}

Just thinking out loud here

>
>> * ContactInformation -> use URIs instead of plain strings? e.g. vCard
>> 4 prefers "tel:" URIs. Not sure if that's a good idea though. They
>> are machine readable, but not necessarily user friendly.
>>
>
> I'd rather keep plain strings, and restrict them to URIs for certain
> ContactInformation "type" and "label" combinations.

how about supporting both?

{
    "name": "John Doe",
    "phones": [{
        "type": "home",
        "value": "+1234567890",
        "href": "tel:+1-234-567-890"
    }]
}

A client which doesn't support both is supposed to remove the other one
when it updates either.

Cheers,

Marten

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 19 Jun 2019 10:02:19 +0200

Hi Marten,

Il 19/06/2019 00:04, Marten Gajda ha scritto:
>> Mario Loffredo also pointed out to me that FN can occur more than 
>> once in VCARD, so fullName might also need to become an array.
>
This case is not unusual in the context of both Domain Name Registries 
and Regional Internet Registries. The contact information about name and 
address can be either structured or unstructured and can be provided in 
multilingual form.

In jCard, it is possible to do that. In my opinion, jscontact should do 
likewise.

Cheers,

mario

>>> * ContactInformation -> use URIs instead of plain strings? e.g. 
>>> vCard 4 prefers "tel:" URIs. Not sure if that's a good idea though. 
>>> They are machine readable, but not necessarily user friendly.
>>>
>>
> A client which doesn't support both is supposed to remove the other 
> one when it updates either.
>
> Cheers,
>
> Marten
>
> email:[email-masked]

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Jun 2019 13:20:02 -0500

If anyone else is confused by the subject header (as I was), the topic is “JSContact”, not “JSCalendar”.

Thanks!

Ben.

> On Jun 7, 2019, at 6:06 AM, Robert Stepanek <[email-masked]> wrote:
> 
> Hi all,
> 
> https://tools.ietf.org/html/draft-stepanek-jscontact <https://tools.ietf.org/html/draft-stepanek-jscontact>
> 
>   It's similar to https://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-03 <https://tools.ietf.org/html/draft-fukuda-vcarddav-phonetic-transcription-03>
> 
> Contact:

---

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 20 Jun 2019 12:09:19 +0200

> If anyone else is confused by the subject header (as I was), the topic is “JSContact”, not “JSCalendar”.

That's on me, sorry. I meant "JSContact".