Ballot for draft-ietf-calext-jscontact
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Thanks for addressing DISCUSS and comments. I've updated my ballot to Yes.
Thank you to Derek Atkins for the SECDIR review. Thank your for addressing my DISCUSS and COMMENT feedback.
I support Paul's, Roman's, and Eric's DISCUSS positions, and I like Roman's suggestion. In Section 1.6.2, you have "implementors SHOULD take in mind..." I'm not sure we can apply our normative guidance to humans. Maybe reword this so you're addressing the software's requirements rather than people? It strikes me that Section 1.7.2 could just say this document specifies version 1.0, and future versions will be specified in their own RFCs. The MUST here seems unnecessary to me, and having this document's version down in Section 2.1.2 seems to bury the lede a little. Throughout Section 2, you indicate things as "optional" or "mandatory". Why not "OPTIONAL" or "REQUIRED", since you're already invoking BCP 14? I have a similar concern in this document as I expressed in the other CALEXT documents on the telechat this week: Many of the SHOULDs are not well explained as to why they're only SHOULD. You might want to either back them up ("SHOULD, because ...") or provide some guidance about why one might legitimately do something different from what it says ("SHOULD, unless ..."). If you can't do either, maybe they ought to be MUSTs or MAYs. Wide open SHOULDs are sometimes a little too ambiguous.
Thanks for the specification. I have No objection from a transport protocol point of view, however, I am actually missing motivations and benefits of this format over other formats like -vCard, in this document. Is that any comparative analysis of these different formats?
Thank you for addressing my DISCUSS and COMMENT points in https://mailarchive.ietf.org/arch/msg/calsify/Y2Evi7HdbiTkj-nW1gkO2z2c2eM/ Regards -éric
# GEN AD review of draft-ietf-calext-jscontact-09 CC @larseggert Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/H0SgvuhO0xzUM5Y6uwC861Mo_XA). ## Comments ### Section 1.7.2, paragraph 0 ``` 1.7.2. Version Updates ``` Agree with Roman's DISCUSS on this bit and the overall IANA considerations. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### URLs These URLs in the document did not return content: * https://rdap.pubtest.nic.it/ ### Grammar/style #### Section 1.2, paragraph 1 ``` A JSON object where the keys are all of type A, and the values are all of ty ^^^^^^^^^^^ ``` Consider using "all type" or "all of the type". #### Section 1.2, paragraph 1 ``` all of type A, and the values are all of type B. * A[] - A JSON array of valu ^^^^^^^^^^^ ``` Consider using "all type" or "all of the type". #### Section 1.5.5, paragraph 2 ``` e: String This property allows to associate contact data with user-defined l ^^^^^^^^^^^^ ``` Did you mean "associating"? Or maybe you should add a pronoun? In active voice, "allow" + "to" takes an object, usually a pronoun. #### Section 1.6, paragraph 1 ``` UnsignedInt This property allows to define a preference order for contact in ^^^^^^^^^ ``` Did you mean "defining"? Or maybe you should add a pronoun? In active voice, "allow" + "to" takes an object, usually a pronoun. #### Section 1.6.1, paragraph 4 ``` is property defines the JSContact type of a JSContact object. It allows imple ^^^^^^^^^ ``` If "type" is a classification term, "a" is not necessary. Use "type of". (The phrases "kind of" and "sort of" are informal if they mean "to some extent".). #### Section 1.7.1, paragraph 1 ``` ween three kinds of properties with regards to validation: IANA-registered pr ^^^^^^^^^^^^^^^ ``` Use "in regard to", "with regard to", or more simply "regarding". #### Section 1.7.1, paragraph 1 ``` A JSContact object is invalid if any its properties are invalid. If a JSCon ^^^^^^^ ``` A determiner cannot be combined with a possessive pronoun. Did you mean simply "any" or "its"? #### Section 1.7.2, paragraph 4 ``` dix B.1 of [RFC5234]). Notable exceptions of this rule are metadata properti ^^^^^^^^^^^^^ ``` Did you mean "exceptions to"? #### Section 1.8.2, paragraph 2 ``` 35]. The prefix ietf.org and its sub-domain names are reserved for IETF speci ^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 1.9.1, paragraph 2 ``` y new standard values once a vendor-specific turns out to be useful also for ^^^^^^^^^^^^^^^^^^^^^^^ ``` The plural noun "turns" cannot be used with the article "a". Did you mean "a vendor-specific turn" or "vendor-specific turns"? #### Section 2.2.2, paragraph 9 ``` pe: Id[NickName] (optional). The nick names of the entity represented by this ^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 2.2.2, paragraph 10 ``` * name: String (mandatory). The nick name. * contexts: String[Boolean] (opti ^^^^^^^^^ ``` This word is normally spelled as one. #### Section 2.2.2, paragraph 10 ``` The contexts in which to use this nick name. Also see Section 1.6.1. * pref ^^^^^^^^^ ``` This word is normally spelled as one. #### Section 2.2.2, paragraph 10 ``` optional). The preference of this nick name in relation to other nick names. ^^^^^^^^^ ``` This word is normally spelled as one. #### Section 2.2.2, paragraph 10 ``` is nick name in relation to other nick names. Also see Section 1.6.3. "nickN ^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 2.2.3, paragraph 2 ``` grammatical gender does not allow to infer the gender identities or assigned ^^^^^^^^ ``` Did you mean "inferring"? Or maybe you should add a pronoun? In active voice, "allow" + "to" takes an object, usually a pronoun. #### Section 2.2.4, paragraph 5 ``` presented by this Card. A Title has object the following properties: * @type: ^^^^^^ ``` Use the past participle here. #### Section 2.2.4, paragraph 9 ``` * organization: Id (optional). The id of the organization in which this titl ^^ ``` This abbreviation for "identification" is spelled all-uppercase. #### Section 2.2.5, paragraph 11 ``` e name including capitalization. Typically the service name is the one which ^^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Typically". #### Section 2.2.5, paragraph 12 ``` ders of that service use on their web sites, in their apps or other publishin ^^^^^^^^^ ``` Nowadays, it's more common to write this as one word. #### Section 2.3.4, paragraph 3 ``` dress] (optional). A map of address ids to Address objects, containing physi ^^^ ``` This abbreviation for "identification" is spelled all-uppercase. #### Section 2.3.4, paragraph 7 ``` ional). The city, town, village, post town, or other locality within which t ^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 2.5.1, paragraph 12 ``` n 1.9.1): * contact The resource is an URI by which the entity represented b ^^ ``` Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". #### Section 2.5.1, paragraph 32 ``` e to the Card that includes the localizations property. A patch MUST NOT tar ^^^^^^^^^^^^^ ``` An apostrophe may be missing. #### Section 4.5.2, paragraph 5 ``` s Contact information is very privacy sensitive. It can reveal the identity, ^^^^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Hi, Thanks for this document. Given time constraints this week. Sorry, but due to holiday & PTO, I've only been any to review this as a fairly cursory level. At a high level, the biggest question that I have is why an implementor would choose to use this instead of using one of the established and presumably widely deployed encodings of the vCard format? As such, I think that this document may benefit from a slightly longer introduction/explanation/justification as to why an implementor may choose to use this over a vCard format (i.e., what problem is being solved), and possibly an appendix (or separate document) highlighting the main differences between this format and the vCard (or jCard) formats. Perhaps this is what the introduction text is intended to already cover, but if so, that didn't come across clearly. One minor nit, in section 1.7, where it discusses versioning, it may be helpful to specify that if a new major version is published then the minor version is also reset back to 0. Regards, Rob