Reviewer: Russ Housley Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-calext-jscontact-vcard-06 Reviewer: Russ Housley Review Date: 2023-03-22 IETF LC End Date: 2023-04-07 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: Section 2.3.10: I do not understand what an implementation is intended to do with a MAY followed by a SHOULD: ... In this case, implementations MAY choose to add the localized vCard properties only to the localizations object. Implementations SHOULD avoid this scenario as much as possible. Sections 2.12.2 and 2.12.10: What is an implementation to do? Sections 2.26.1 and 2.16.2: I do not understand what an implementation is intended to do with a MAY followed by a MUST: ... It MAY contain vCard IANA-registered properties which also got converted to an IANA-registered property in the same JSContact object. In case of conflict, the values of the JSContact property MUST be used. Section 3.1: I do not understand what an implementation is intended to do with a MAY followed by a MUST: ... If the fullName is not set but the name property is, then implementations MAY derive the value of the FN property from it. In this case, they MUST set the DERIVED parameter on the FN property. Otherwise, they MUST set the FN property with an empty value. Section 3.2.1: I do not understand what an implementation is intended to do with a MAY followed by a MUST: ... The VALUE parameter MAY be set once, in which case its value MUST be URI. Minor Concerns: Section 2.2.2 says: "vCard properties or parameters having such values MAY convert as defined in Section 2.16." I expected SHOULD here. If MAY is correct, then this section needs explain how interoperability is achieved. Section 2.2.3 says: "To preserve the verbatim value of the ALTID parameter, set the JSContact extension properties props or params defined in Section 2.16." I cannot understand this sentence. I think this is talking about "extended properties and parameters". Nits: It would be helpful if there is a way to come up with examples that do not exceed 73 characters on a line. Section 2 says: "Its follows the same structure as the vCard v4 RFC document [RFC6350]." I suggest dropping "RFC document". Likewise, in the following sentence, I suggest dropping "RFC". Section 2.1.1 says: "Consequently, a vCard without UID property MAY not convert to one exact instance of a JSContact card." This use of MAY seems out of place. I suggest: "Consequently, a vCard without UID property could result in one or more instance of a JSContact card." Section 2.3.10: s/property.Figure 4 /property. Figure 4 / Section 2.3.15: s/vCard property converts to./vCard property converts./ Section 2.10.4: s/OrgUnit object/OrgUnit object./ Section 2.12.4: s/(Figure 33)/(Figure 33)./ Section 2.16: s/unknown Section/unknown; see Section/ Section 3.1: s/section Section 3.2/Section 3.2/ Note: I did not review Section 6. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
