Re: [Jmap] Erik Kline's No Objection on draft-ietf-jmap-smime-09: (with COMMENT)

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 18 October 2021 14:21 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC93A148B; Mon, 18 Oct 2021 07:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKieuMPIqHAK; Mon, 18 Oct 2021 07:21:00 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A257E3A1441; Mon, 18 Oct 2021 07:21:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634566859; d=isode.com; s=june2016; i=@isode.com; bh=Uf2zFCCLr+5fA9KpkBaphP+AMcFEgS5dw8+nxsQcd2k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Osmjvvv5ZcdOrldHL8VGsOAxZt1c02DUG1af6Gvq7vuCm/heE2VGy9KLdZ07TP5xqsYT3A ZGVCrvUNfKwDxsDJAN+vWQQUt1UWzzEfS0VTu5kXg4fk5jT7wHvgeyEMIFS5F48qfU8VmH EM8FrDL8BfcainaIq/bMAW3kv4DcSX0=;
Received: from [192.168.1.222] (host5-81-100-13.range5-81.btcentralplus.com [5.81.100.13]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <YW2CygBdg2oC@statler.isode.com>; Mon, 18 Oct 2021 15:20:58 +0100
To: Erik Kline <ek.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com
References: <163453890907.1076.7397961358484844853@ietfa.amsl.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <9fd6316b-add5-0100-f975-2f0af605d20c@isode.com>
Date: Mon, 18 Oct 2021 15:20:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
In-Reply-To: <163453890907.1076.7397961358484844853@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/KgV2whmcrl7HwNmr6V6Nc4T7Yy4>
Subject: Re: [Jmap] Erik Kline's No Objection on draft-ietf-jmap-smime-09: (with COMMENT)
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Oct 2021 14:21:15 -0000

Hi Erik,

Thank you for your comments.

On 18/10/2021 07:35, Erik Kline via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Just some random questions that came to mind...
>
> [S4.2, question]
>
> * Is there any benefit to/reason to consider some boolean like
>    "hasVerifiedAtDeliverySmime"?
Yes, it might be useful to know whether a message (or a group of 
messages) was valid (S/MIME signed/verified) at delivery time.
> [S5, question]
>
> * In section 4.1, the values of smimeStatus are defined as
>
>     ... Possible string values of the property are
>     listed below.  Servers MAY return other values not defined below, as
>     defined in extensions to this document.
>
>    If the intention is that documents that update this document are the
>    the way to create new possible values, should this imply the establishment
>    of a registry of these values?
>
>    But perhaps this level of process is not desired.

I suppose the document can create a registry. But I can only think of a 
couple of additions that can be added when S/MIME encryption is also 
used. I would probably leave this to a future document.

Best Regards,

Alexey