Re: [Jmap] I-D Action: draft-ietf-jmap-jscontact-04.txt

[Neil Jenkins <[e-mail]>]

I've read through this draft and I have a few comments:
 * The metadata section is missing a `created` timestamp. Also the type of this and updated should be `UTCDate`, not just String (this is more a notational comment, but I would recommend using exactly the same type system as JSCalendar).
 * The `fullName` description doesn't make it clear to me what its purpose is. Is it always the same as `name` joined together by spaces? (Presumably not, as that wouldn't be very useful.) Or is it to provide alternative versions of the name in different character sets for internationalisation? (It's a LocalizedString type so can have multiple variants, so maybe.) Or is to provide the preferred name to call someone? (Not at all what the description says, but perhaps useful.)
 * The idea of the `name` field is its an array of tagged components, so you can accurately represent names in locales where, for example, the family name comes first when written out. That's great, however I think `nickname` is not the same as one of these components and should be a separate field in JSContact; a nickname is not a subpart of a name, it's an alternate one.
 * I found the description of the `roles` property hard to understand; I don't really get it.
 * The value for `Resources` in the `emails` field should just be the email address. The spec currently says it can be this or a mailto: URI, but there's no reason to allow an alternate encoding of exactly the same data and the escaping/unescaping of characters to transform to/from a mailto URI is a pain to get right and likely to lead to incompatibilities.
 * For `phones` there's a kind of similar thing, although I do see the idea behind URIs here with `sip:` vs `tel:`. I wonder if uri should just be an optional extra property instead rather than the value being *either* a URI or the phone number.
 * The taxonomy of `type` doesn't feel quite right for phones: if I have a mobile (cell) phone number, is that "voice"? But it also accepts SMS. But type is single valued, so what type should it be?
 * I don't think the `labels` property of a Resource should be multi-valued (it should just be `label`, like it is in the `Address` data type). While there's always a tension here between allowing expressivity and keeping it easier to use, I think this veers too much into the former. It's not clear how you would be supposed to deal with multiple values; as they are just free form text, a single one should be sufficient.
 * I think the `Address` type needs thinking about more. The street/locality/region properties are not sufficient to accurately express many global addresses. An array of tagged components like in `name` is probably a better approach, allowing many more options for accurately describing the parts of the address without making it too unwieldy to use.
 * As with name, I think the purpose of `fullAddress` would need to be detailed more (if it is indeed needed at all).
 * I think the `notes` field should be single-valued rather than an array, for the same reason as with `labels`.
Cheers,
Neil.