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

[Mario Loffredo <[e-mail]>]

Hi Russ,

sorry for the delay in replying.

Thanks a lot for your review and feedback.

Please find my comments below.

Anyway, we are publishing the new version in a few days so you will be 
able to check if all of the points have been addressed.

Best,

Mario

Il 22/03/2023 19:58, Russ Housley via Datatracker ha scritto:
> 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.

[ML] Removed the last statement because, thinking back, converters are 
unable to avoid such senario.

> Sections 2.12.2 and 2.12.10: What is an implementation to do?

[ML] Stated that they convert to an entry in the vCardProps property. 
The PID parameter converts to an entry in the vCardParams property.

As a cosequence, we changed the definition of vCardProps and vCardParams 
in section 2.16 to clarify that they are not only used to convert vCard 
extensions but any vCard property or parameter that doesn't have a 
direct match in JSContact.

> 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.

[ML] Just removed both the sentences.

> 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.

[ML] Rephrased the paragraph by defining more clearly how vCard FN is 
generated in the following cases:

- fullName exists

- fullName is missing but name exists

- both fullName and name are missing

> 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.
[ML] Removed both the sentences because the VALUE parameter is set to 
"TEXT" by default.
> 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.
[ML] Yes. SHOULD sounds better.
> 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".

[ML] No, it's a mistake. They refer to vCardProps and vCardParams 
defined in Section 2.16.  This issue has already been raised by the AD 
and we fixed it by removing "props or params" from the sentence.

To preserve the verbatim value of the ALTID
parameter, set the JSContact extension properties
defined in Section 2.16.

> Nits:
>
> It would be helpful if there is a way to come up with examples that do
> not exceed 73 characters on a line.
[ML] Fixed.
> 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".
[ML] Fixed.
> 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."
[ML] OK.
> 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/

[ML] Fixed all nits above.


Best,

Mario

> Note: I did not review Section 6.
>
>
>
-- 
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