Re: [Gen-art] Genart last call review of draft-ietf-calext-jscontact-vcard-06

[Lars Eggert <[e-mail]>]

Russ, thank you for your review. I entered a No Objection ballot.

Lars

> On 22. Mar 2023, at 20:59, Russ Housley via Datatracker <[e-mail]> wrote:
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call