[art] Artart last call review of draft-ietf-calext-vcard-jscontact-extensions-06

Carsten Bormann via Datatracker <noreply@ietf.org> Mon, 01 May 2023 11:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7F5C151B25; Mon, 1 May 2023 04:07:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carsten Bormann via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: calsify@ietf.org, draft-ietf-calext-vcard-jscontact-extensions.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168293926122.50065.3380749283361629478@ietfa.amsl.com>
Reply-To: Carsten Bormann <cabo@tzi.org>
Date: Mon, 01 May 2023 04:07:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/pVbwFDdbII2fWt7ZhHEjXjjh9L8>
Subject: [art] Artart last call review of draft-ietf-calext-vcard-jscontact-extensions-06
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 May 2023 11:07:41 -0000

Reviewer: Carsten Bormann
Review result: Ready with Issues

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