Thank you to Christian Huitema for his secdir reviews.

I appreciated the well written descriptions and explanations in this draft. 

One small comment, and possibly just a misunderstanding on my part.

Section 13, para 2, first sentence:  This phrase seems odd 'is intended primarily for providing verified information at the termination of a call,' not at the start of a call? but as a call is terminated?  But maybe I'm missing something?

Thanks so much for putting this draft together. I found it really well written, even as someone more of a generalist without a deep SIP background, I was able to follow along and get a good understanding of the technology you're describing. Nice work.

Hi Chris, 

I went through the full changes [1] vs -16 and overall I like how we ended.

Thank you for the discussion and for resolving most of my points [2].

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-sipcore-callinfo-rcd-16&url2=draft-ietf-sipcore-callinfo-rcd-18&difftype=--html 

[2] https://mailarchive.ietf.org/arch/msg/sipcore/osM_W7yyzca6tbnk_EMLh0UrD3g/

# Orie Steele, ART AD, comments for draft-ietf-sipcore-callinfo-rcd-17 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sipcore-callinfo-rcd-17.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thanks to Scott Hollenbeck for the ARTART review.

### Verified True without Integrity

```
607	      Call-Info: <https://example.com/photos/q-256x256.png>;purpose=
608	       icon;verified="true";integrity="sha256-RojgWwU6xUtI4q82+kHPyHm
609	       1JKbm7+663bMvzymhkl4"
610	      Call-Info: <data:>;purpose=jcard;call-reason="Rendezvous for
611	       Little Nellie";verified="true"
612	      Call-Info: <data:>;purpose=jcard;verified="true"
```

In the example above, verified true does not mean that sha256 of resolved bytes of https://example.com/photos/q-256x256.png is "RojgWwU6xUtI4q82+kHPyHm..."... Right?

Consider if this deserves any special consideration.

You might also consider a direct reference to https://www.w3.org/TR/SRI/ instead of through https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-rcd-26#section-4

Any MTI hash functions? SRI requires SHA-256, SHA-384 and SHA-512.

Is there a case where you have `<cid:12155551000@example.com>;purpose=jcard;verified="true"integrity="sha256-R..."` and the integrity field is for the cid?

### MUST be avoided?

```
326	   The fields like "fn", "photo", or "logo" if used with the use of
327	   "icon" calling name in From or P-Asserted-ID header field or purpose
328	   token, as described in the previous section, MUST either match or be
329	   avoided to allow the called party to clearly determine the intended
330	   calling name or icon.
```

I think you mean MUST match if present, but this could be clearer.

### Base Encoding for Data URIs?

```
307	   of UTF-8 [RFC8259].  This MAY be carried directly in the Call-Info
308	   header field URI using the "data" URI scheme.  A jCard also MAY be
```

Consider clarifying if base encoding is allowed.
I would assume that it should not be used given the media type is application/json.

Thank you to Roni Even for the GENART review.

Thanks for the work done in this document and for addressing all the DISCUSS/COMMENT points.
(see https://mailarchive.ietf.org/arch/msg/iesg/6lvXa0dhiFltmtcNEplNK-f8nJ8/ )