Re: [calsify] Working Group Last call for jscontact drafts

[Daniel Migault <[e-mail]>]

Hi Robert,

Thanks for the responses. I will move the docs forwards and also send it
for review to the IANA. Please see inline some comments.

Yours,

Daniel

On Tue, Jan 10, 2023 at 5:02 AM Robert Stepanek <[e-mail]>
wrote:

> Hi Daniel,
>
> thanks again for the document review. Please see my replies below.
>
> On Wed, Jan 4, 2023, at 11:46 PM, Daniel Migault wrote:
>
> 1.  Introduction
>
>    This document defines a data model for contact card data normally
>    used in address book or directory applications and services.  It aims
>    to be an alternative to the vCard data format [RFC6350] and to
>    provide a JSON-based standard representation of contact card data.
>
> <mglt>
> Maybe I am not enough familiar with the terminology, but I am expecting
> from thes eline the vCard format to be expressed in JSON which is already
> done by jCard.
> I believe that JSCard i sprimarily a new (or updated) data model used by
> vCard and the fact it is expressed as JSON seems sort of secondary.
> If I am correct, I am wondering what indicates JSCard is not simply a
> translation to JSON.
> </mglt>
>
>
> Thanks, I simply removed the "provide a JSON-based standard representation
> of contact card data" part.
>
>
>    The key design considerations for this data model are as follows:
>
>    *  Most of the initial set of attributes should be taken from the
>       vCard data format [RFC6350] and extensions ([RFC6473], [RFC6474],
>       [RFC6715], [RFC6869], [RFC8605]).  The specification should add
>       new attributes or value types, or not support existing ones, where
>       appropriate.  Conversion between the data formats need not fully
>       preserve semantic meaning.
>
> <mglt>
> I found the formulation a bit strange, especially the sentence:
> """
>  The specification should add
>       new attributes or value types, or not support existing ones, where
>       appropriate.
> """
> I am just checking I understand it correctly.
>  "not supporting ones" confused me and raised my attention as it could
> sound - at least to me - as SHOULD NOT support existing ones, which I do
> not think was the purpose. I think the specification should take most of
> the existing attributes. Since this is "most" it means some attributes have
> been left over and these are not supported. I do think this is implicit. In
> addition the spec adds new attributes.
> Am I correct ?
>
> I let you decide whether the text can be clearer or not.
> </mglt>
> [...]
>
>
> I now made more clear that JSContact may choose to not define equivalent
> properties for vCard attributes, if the vCard ones are considered to be
> obsolete or otherwise inappropriate.
>
>
>
> 1.3.  Type Signatures
> ...
>    *  A[] - An array of values of type A.
>
> <mglt>
> Maybe we should have a JSON array to remain coherent with the other
> definition.
> </mglt>
>    *  A|B - The value is either of type A or of type B.
>
>
> Done
>
> 1.5.3.  The pref property
>
>    Type: UnsignedInt
>
>    This property allows to define a preference order for contact
>    information.  For example, a card holder may have two email addresses
>    and prefer to be contacted with one of them.
> ...
>
> <mglt>
> It seems to be more a ranking than a preference no ? I understand the
> higher the preference is the least it is preferred. If that is correct, I
> am wondering if that is common practice or if we think that could be more
> coherent.
> </mglt>
>
>
> We chose "pref" as this matches the name of the equivalent "PREF" property
> in vCard.
>
>
>
> 2.2.2.  name
> [...]
>
> <mglt>
> If I get it right the names components are ordered as the "one entering
> them" wishes them to be printed. This order may vary, so rank can clarifies
> this.
>
> sortAs indicates how to handle these names components for sorting.
> However, I suspect that sorting may also depend on the culture and for
> example a list of participants in country A or country B will be sorted
> differently.
> I am wondering if that is correct or if I am missing something.
>
> </mglt>
>
>
> Correct, rank is more culture-specific and tells how same-typed name
> components rank within a name. sortAs defines how to sort by name component
> among multiple addressbook entries. As it is likely that an addressbook
> contains entries from multiple cultures, the sortAs property defines a
> generic sort. If an application wants to support multiple sorts depending
> on the culture of the viewer, they need to derive that by themselves.
>
>
>
> 2.3.3.  phones
> [...]
> <mglt>
> I understand "voice" is "phone" i.e a non mobile phone;-)
> </mglt>
>
>
> We chose to use the exact same enumeration values like vCard. They more
> describe the features of a phone, e.g. any smartphone would contain the
> features "voice", "text", "cell", "video". Admittedly, I don't think most
> will bother to set all these features for a personal or business contacts,
> but the option is here. Maybe "cell" is a misnomer in the current time and
> "mobile" would be more appropriate?
>
> That was more a comment. The current designation seems a bit outdated.
However, people are used to handling and displaying them with vCard, so
it's probably better to keep them as it is.  I suspect that having
appropriated term is likely to cause UI bugs.

>
> 2.6.2.  directories
> [...]
>       ...
>        "directories": {
>          ...
>           "dir1": {
>             "@type": "DirectoryResource",
>             "type": "entry",
>             "uri": "http://directory.example.com/address
> books/jdoe/Jean%20Dupont.vcf"
>           },
>          "dir2": {
>            "@type": "DirectoryResource",
>            "type": "directory",
>            "uri":
> "ldap://ldap.tech.example/o=Example%20Tech,ou=Engineering",
>            "pref": 1
>          },
>       ...
>       },
>       ...
>
> <mglt>
> There is a space in address book. I am wondering if that is not a nit.
> </mglt>
>
>
> Thanks, I fixed that when I fixed the long-line errors that idnits found.
>
>
> 4.2.6.  Initial Contents for the "JSContact Properties" Registry
>
>    The following table lists the initial common usage entries of the
>    "JSContact Properties" registry.  The Since Version for all
>    properties is 1.0.  The Until Version for all properties is not set.
>    All RFC section references are for this document.  The change
>    controller for all these properties is IETF.
>
> <mglt>
> The table is a bit too large.
> </mglt>
>
>
> Do you want us to split the table? I might come up with a way to do that,
> but any split would be kind of arbitrary.
>
> I thought that removing the white spaces could do the job maybe, but
otherwise let's see what the IANA or RFC Editor or other people think about
how it should be done.

> Regards,
> Robert
>


-- 
Daniel Migault
Ericsson