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

[Robert Stepanek <[e-mail]>]

Hi Daniel,

Mario needs more time to check for any IPR disclosures with his organization.

I would like to be part of Expert Review for future updates and registry entries. I expect Mario wants, too, but I'll wait for him to confirm in this email thread by himself.

Meanwhile, I have started working on the document to fix the ABNF and idnits errors. Also thanks for your review feedback, I'll take that into account, too! I will need some more time until I submit a new document version.

Thanks,
Robert

On Wed, Jan 4, 2023, at 11:46 PM, Daniel Migault wrote:
> Hi, 
> 
> Thanks Robert and Joris for the feed back. I apologise for the late response. 
> As far as I can tell I do not have Mario's IPR disclosure - which i need to complete the shepherd write up and move the document forward. 
> https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact/shepherdwriteup/
> 
> I am also wondering if anyone would be volunteering to become the IANA Expert Review for the created registries. If so please let me know.
>  
> Please find some comments below regarding the document. 
> 
> To pass the ABNF tool [1], I had to update the ABNF script with missing terms, reorder the sequence and replace the %23 by %x23 as the 'x' was missing. The resulting script is as follows. I do not know if that is necessary to include everything, so I let you include what you believe is necessary.
> 
> ;see RFC3629 section 4
> UTF8-tail   = %x80-BF
> UTF8-2      = %xC2-DF UTF8-tail
> UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
>               %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
> UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
>               %xF4 %x80-8F 2( UTF8-tail )
>   ; see RFC5234 appendix B.1
> NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4  
> SP             =  %x20
> HTAB           =  %x09
>   ; horizontal tab 
> WSP            =  SP / HTAB
>   ; white space
> ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
> DIGIT          =  %x30-39
>   ; 0-9
>   
> 
> v-name = 1*(WSP / "!" / %x23-7e / NON-ASCII)
>      ; any characters except CTLs and DQUOTE, also see RFC 6350 Section 3.3
>      ; use of "/" (%x2f) and "~" (%x7e) is discouraged
> alnum-int = ALPHA / DIGIT / NON-ASCII
>      ; see RFC 6350 Section 3.3
> v-label = alnum-int / alnum-int *(alnum-int / "-") alnum-int
> 
> v-prefix = v-label *("." v-label)
> v-extension = v-prefix ":" v-name
> 
> The id nit tools [2] finds  one forbidden language 'MUST not' in this paragraph:
>      
>      Until Version:  This defines the JSContact version after which this
>      property got obsoleted and MUST NOT be used in later versions. The Until
>      Version value either MUST not be set, or be one of the allowed values of
>      the @version property in the JSContact Enum Value registry (see Table 6).
> 
> 
> Here are some additional random comments:
> 
> 
> [1] https://author-tools.ietf.org/abnf
> [2] https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-06.txt
> 
> 
> 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>
> 
>    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>
> [...]
> 
> 
> 1.3.  Type Signatures
> 
>    Type signatures are given for all JSON values in this document.  The
>    following conventions are used:
> 
>    *  * - The type is undefined (the value could be any type, although
>       permitted values may be constrained by the context of this value).
> 
>    *  String - The JSON string type.
> 
>    *  Number - The JSON number type.
> 
>    *  Boolean - The JSON boolean type.
> 
>    *  A[B] - A JSON object where the keys are all of type A, and the
>       values are all of type B.
> 
>    *  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.
> 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.
> 
>    Its value MUST be in the range 1 and 100.  Lower values correspond to
>    a higher level of preference, with 1 being most preferred.  If no
>    preference is set, then the contact information MUST be interpreted
>    as being least preferred.
> 
>    Note that the preference only is defined in relation to contact
>    information of the same type.  For example, the preference orders
>    within emails and phone numbers are independent of each other.
> 
> 
> 
> <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>
> 
> 
> 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>
> 
> 
> 2.3.3.  phones
> [...]
> <mglt>
> I understand "voice" is "phone" i.e a non mobile phone;-)
> </mglt>
> 
> 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>
>              
> 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>
> 
> 
> On Wed, Dec 28, 2022 at 12:35 PM Robert Stepanek <[e-mail]> wrote:
>> __
>> Hi Daniel,
>> 
>> To the best of my knowledge there are no IPR disclosures to be filed.
>> 
>> Thanks,
>> Robert
>> 
>> On Wed, Dec 21, 2022, at 6:25 PM, Daniel Migault wrote:
>>> Hi, 
>>> 
>>> Thanks Roberts, I actually forgot the item that made me write the previous email. Please state if you are aware of any IPR, and if so please feel an IPR disclosure. 
>>> 
>>> Yours, 
>>> Daniel
>>> 
>>> 12. Have reasonable efforts been made to remind all authors of the intellectual
>>>     property rights (IPR) disclosure obligations described in [BCP 79][7]? To
>>>     the best of your knowledge, have all required disclosures been filed? If
>>>     not, explain why. If yes, summarize any relevant discussion, including links
>>>     to publicly-available messages when applicable.
>>> 
>>> 
>>> 
>>> On Wed, Dec 21, 2022 at 11:44 AM Robert Stepanek <rsto=[e-mail]> wrote:
>>>> __
>>>> Hi Daniel,
>>>> 
>>>> On Wed, Dec 21, 2022, at 3:17 AM, Daniel Migault wrote:
>>>>> 4. For protocol documents, are there existing implementations of the contents of
>>>>>    the document? Have a significant number of potential implementers indicated
>>>>>    plans to implement? Are any existing implementations reported somewhere,
>>>>>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>>>>>    (where)?
>>>> 
>>>> While drafting the spec, I built an experimental implementation. We definitely will implement JSContact at Fastmail.
>>>> 
>>>>> 13. Has each author, editor, and contributor shown their willingness to be
>>>>>     listed as such? If the total number of authors and editors on the front page
>>>>>     is greater than five, please provide a justification.
>>>> 
>>>> Yes.
>>>> 
>>>> Thanks,
>>>> Robert
>>>> 
>>>>> 
>>>>> Yours, 
>>>>> Daniel
>>>>> 
>>>>> On Thu, Dec 8, 2022 at 11:46 AM Robert Stepanek <rsto=[e-mail]> wrote:
>>>>>> __
>>>>>> On Thu, Dec 8, 2022, at 4:41 PM, Robert Stepanek wrote:
>>>>>>>>  * Section 2.2.4: Referring to my mail from 18th October, it is still not possible to model a contact with a department only. The Organization object cannot be created without a name. I still suggest making the name property optional (even though it can be an empty string. Maybe that would be the recommended route here?).
>>>>>>> I haven't had time to check with Mario, but I agree that we should make name optional. We'll need to sort out in the vCard conversion RFC how to deal with that, but setting an empty string on FN might work.
>>>>>> 
>>>>>> Sorry, I misread your proposal. Yes, we do want to allow name in Organization to not be set. In fact, we already had updated the draft to state "at least one of `name` and `units` *MUST* be set" , but the definition of the "name" property was still "mandatory" instead of "optional". I will update the doc.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> calsify mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/calsify
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Daniel Migault
>>>>> Ericsson
>>>>> _______________________________________________
>>>>> calsify mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/calsify
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> calsify mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/calsify
>>> 
>>> 
>>> -- 
>>> Daniel Migault
>>> Ericsson
>> 
> 
> 
> -- 
> Daniel Migault
> Ericsson