## 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
outstanding.)

## major:

Are you sure
           [I-D.ietf-calext-jscontact]
           [I-D.ietf-calext-jscontact-vcard]
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