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

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

> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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