Skip to main content

Last Call Review of draft-ietf-calext-vcard-jscontact-extensions-06

Request Review of draft-ietf-calext-vcard-jscontact-extensions
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-04-07
Requested 2023-03-17
Authors Robert Stepanek , Mario Loffredo
I-D last updated 2023-05-01
Completed reviews Artart Last Call review of -06 by Carsten Bormann (diff)
Assignment Reviewer Carsten Bormann
State Completed
Review review-ietf-calext-vcard-jscontact-extensions-06-artart-lc-bormann-2023-05-01
Posted at
Reviewed revision 06 (document currently at 10)
Result Ready w/issues
Completed 2023-05-01
## intro:

This spec backports certain features from jscontact to the legacy
vcard format.

I am not a vcard expert.
I didn't read this document for correctness or completeness with
respect to the jscontact functionality not yet in RFC6350.
(I also found it hard to use RFC6350 in this review, which (besides
numerous verified and held errata) has 9 unprocessed errata reports

## major:

Are you sure
should be informative references?
Are the definitions in draft-ietf-calext-vcard-jscontact-extensions
really meant to be self-contained?
E.g., I'm not sure I understand GRAMMATICAL-GENDER without first
having read those other drafts (actually, I'm not sure I understand it
*with* having read those).

Section 3.5:
I do not understand the syntax of ranks-param, which requires exactly
five instances of ranks-component to be present.  This is not
supported by the examples.
Have the examples been checked against the ABNF?

## minor:

Section 2.4:
The language tag property is called "LOCALE".
The latter term usually implies characteristics beyond those of a language tag.

Section 3.6 uses "the same type" and then "the same name" a few times.
Is name and type the same concept here?  Still, wouldn't it help to
use the same referent to that concept throughout?

## idnits:

  ** The abstract seems to contain references ([RFC6350]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

(See Section 4.3 of RFC 7322.)

## nits:

Section 1: s/loosing/losing/
Section 2.6: s/equal is they match/equal if they match