[sipcore] Orie Steele's No Objection on draft-ietf-sipcore-callinfo-rcd-17: (with COMMENT)

Orie Steele via Datatracker <noreply@ietf.org> Mon, 14 April 2025 22:51 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@mail2.ietf.org
Received: from [10.244.8.129] (unknown [104.131.183.230]) by mail2.ietf.org (Postfix) with ESMTP id F3ED61BEFCDA; Mon, 14 Apr 2025 15:51:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Orie Steele via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <174467109077.1158299.333560895944334001@dt-datatracker-64c5c9b5f9-hz6qg>
Date: Mon, 14 Apr 2025 15:51:30 -0700
Message-ID-Hash: RWLWGYWJL6RKWG3HMQQCQ6CRRBYONTUQ
X-Message-ID-Hash: RWLWGYWJL6RKWG3HMQQCQ6CRRBYONTUQ
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-sipcore.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-sipcore-callinfo-rcd@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Orie Steele <orie@or13.io>
Subject: [sipcore] Orie Steele's No Objection on draft-ietf-sipcore-callinfo-rcd-17: (with COMMENT)
List-Id: SIP Core Working Group <sipcore.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/c-dk6JUOOSDpMwBingV1Smi0P5E>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Owner: <mailto:sipcore-owner@ietf.org>
List-Post: <mailto:sipcore@ietf.org>
List-Subscribe: <mailto:sipcore-join@ietf.org>
List-Unsubscribe: <mailto:sipcore-leave@ietf.org>

Orie Steele has entered the following ballot position for
draft-ietf-sipcore-callinfo-rcd-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-rcd/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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