Reviewer: Paul Kyzivat
Review result: Ready with Issues

I am the assigned ARTART reviewer for this Internet-Draft.

Document: draft-ietf-calext-jscontact-profiles-09
Reviewer: Paul Kyzivat
Review Date: 2025-11-24
IETF LC End Date: 22025-11-25
IESG Telechat date: ?

Summary: This draft is on the right track but has open issues, described 
in the review.

ISSUES: 3
NITS:  2

Issues:

1) ISSUE: Identification of profile use:

While this document gives a mechanism to define named profiles, it 
doesn't provide any mechanism to announce or negotiate the use of 
profiles, or to identify them in use. I suggest that the document at 
least discuss these issues, and perhaps solve some of them. E.g., define 
a mechanism for identifying the profile name and version in the body of 
a conforming json document.

2) ISSUE: Meaning of subtype

Section 3.3 (Restricted Property Type) says "...the value MUST be a type 
signature as defined in Section 1.3.2 of [RFC9553] and it MUST be a 
subtype of the original type signature...".

It isn't evident to me that the notion of "subtype" is well defined in 
this context. Please precisely define what you mean.

3) ISSUE: Insufficient IANA instructions

Section 5 (IANA Considerations) instructs IANA to create a new 
"JSContact Profile" registry. However, it fails to specify a 
registration policy. It should specify one of those defined in RFC 8126.

This section then describes two templates:
- JSContact Profile Registry Template
- JSContact Profile Property Template

In some documents, templates are inputs to IANA of data to be installed 
into tables maintained by IANA within the registry. In other cases, 
templates describe data to be included in a document that is referenced 
by an IANA registry.

It appears that this document intends that IANA store all the data. But 
it isn't at all clear what structures it intends IANA to set up to hold 
this data. The best information the document gives is the example 
profile in section 4. It appears the intent is that each entry in the 
JSContact Profile Registry should contain a subordinate set of JSContact 
Profile Property items. But examples aren't normative. A more detailed 
specification for IANA is needed. I recommend that the authors, wg, or 
area director request an early-review by IANA to work this out.

4) NIT: long lines

IdNits reports 26 instances of lines too long, with the longest being 20 
characters in excess of 72. These all occur with Table 1. I defer to the 
editors from the RFC Production Center on how best to resolve this. You 
can probably defer dealing with this to AUTH48.

5) NIT: non-ascii characters

IdNits reports two instances of lines with non-ascii characters in the 
document. They are in the card object example in section 4. I think this 
is an appropriate use and the warning can be ignored.