IETF Logo Mail Archive

Re: [Last-Call] [art] Artart last call review of draft-ietf-jmap-contacts-06

Carsten Bormann <cabo@tzi.org> Mon, 08 April 2024 04:41 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941B1C14F5EA; Sun, 7 Apr 2024 21:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uHPLin_GRp9; Sun, 7 Apr 2024 21:41:08 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58567C14F684; Sun, 7 Apr 2024 21:41:03 -0700 (PDT)
Received: from smtpclient.apple (p5089a101.dip0.t-ipconnect.de [80.137.161.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4VCby33XHszDCbG; Mon, 8 Apr 2024 06:40:59 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <58438804-1a10-4a86-8f87-d449c0db542a@betaapp.fastmail.com>
Date: Mon, 08 Apr 2024 06:40:48 +0200
Cc: John C Klensin <john-ietf@jck.com>, Peter Saint-Andre <stpeter@stpeter.im>, "art@ietf.org" <art@ietf.org>, draft-ietf-jmap-contacts.all@ietf.org, IETF JMAP Mailing List <jmap@ietf.org>, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <407F5BC2-BEFE-4F6B-872D-FB31934740A3@tzi.org>
References: <171112316193.8644.5801107423421446407@ietfa.amsl.com> <1C02FE5D-624B-4BBE-A7F3-91EDF54CDE4F@tzi.org> <b5fac088-9eb3-4ede-a266-f943aeaab076@stpeter.im> <4E9A8148-9EFE-4448-B94E-96FBDB6A2B9A@tzi.org> <06c317c8-8d14-4d78-a4c9-9c44cfc3ec31@stpeter.im> <03ef2b74-19d2-43c1-9c5b-b0aa315c8738@dogfoodapp.fastmail.com> <5c10be7c-8913-46f5-a0bd-e28102624d88@stpeter.im> <C42C278BC5CB8F3EE2920E99@PSB> <521b092a-6490-4fe2-9126-961335a1892b@stpeter.im> <94FE04C6853F55BF4B1C1FFB@PSB> <58438804-1a10-4a86-8f87-d449c0db542a@betaapp.fastmail.com>
To: Bron Gondwana <brong=40fastmailteam.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/oTJ_iCn1gkguEBERcMArbhouRXk>
Subject: Re: [Last-Call] [art] Artart last call review of draft-ietf-jmap-contacts-06
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2024 04:41:12 -0000

On 8. Apr 2024, at 06:06, Bron Gondwana <brong=40fastmailteam.com@dmarc.ietf.org> wrote:
> 
> I suggest saying something like this in the security considerations:
> 
> […] SHOULD […]

The security considerations section is not the place to make normative statements about the protocol.
What *is* the security consideration that would lead to such a set of statement?

(I also think that this would be a rather heavy late change of the protocol.
Has the "Freeform Class as defined in PRECIS” been examined to actually be useful for this application?
[Quick, does it say all the right things about bidirectional strings for contact information?]
Why is the server only to be restricted about setting “names" while the client is restricted about displaying any strings?)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email