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

[Mario Loffredo <[e-mail]>]

Hi Daniel and Robert,

Il 09/01/2023 18:09, Robert Stepanek ha scritto:
> Hi Daniel,
>
> Mario needs more time to check for any IPR disclosures with his 
> organization.
Confirm that no IPR constraint exist from my side.
>
> 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.

Confirm this too.


Best,

Mario

>
> 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
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo