[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.
- [sipcore] Orie Steele's No Objection on draft-iet… Orie Steele via Datatracker
- [sipcore] Re: Orie Steele's No Objection on draft… Chris Wendt