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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
