Re: [Vcon] Email metadata in vCon

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 12 April 2024 16:38 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: vcon@ietfa.amsl.com
Delivered-To: vcon@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7DC14F5E2 for <vcon@ietfa.amsl.com>; Fri, 12 Apr 2024 09:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Level:
X-Spam-Status: No, score=-2.074 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsV5Z-SujDBd for <vcon@ietfa.amsl.com>; Fri, 12 Apr 2024 09:37:55 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A9C53C14F5EF for <vcon@ietf.org>; Fri, 12 Apr 2024 09:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1712939873; d=isode.com; s=june2016; i=@isode.com; bh=7YP/EKwwybGfR4T2K94TU1Pv5AgHX29f70/KIz8FW0I=; 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=iaibZWaN25gBZpOlhy8aVy1F2jy1JiLU7CMFlGJBDAUwBOn2r5H+DOM7dtkE64bc6cJGU5 Sai2wBg1Ohk/l7mPJGkGLur5g1ukvMycBBtRjUFVFwYmDn4TaJF1fL5D9q/WeLIHdAeS+W kjv4Puz302n71RhPVoDCP4CVa3hQ640=;
Received: from [192.168.1.222] ((unknown) [31.117.114.119]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <ZhljXgAKdpJm@waldorf.isode.com>; Fri, 12 Apr 2024 17:37:52 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <93b2c230-3868-45d9-a1da-31f064c593b2@isode.com>
Date: Fri, 12 Apr 2024 17:37:49 +0100
User-Agent: Mozilla Thunderbird
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Dan Petrie <dan.ietf@sipez.com>, Orie Steele <orie@transmute.industries>
Cc: vCon WG <vcon@ietf.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
References: <923730760.1991278.1711573128213.ref@mail.yahoo.com> <923730760.1991278.1711573128213@mail.yahoo.com> <CAN8C-_LqL_UWW+5NPJ0QzFzOOFtqoP61wU_HEwW9rGOWq9iefw@mail.gmail.com> <CAN8C-_JZXGZzVQVsY50qNtyQ5Te-55vSTrtj-0O0=C=0_kfaGw@mail.gmail.com> <CAN8C-_L6AXGaPx_SE_4Cjk7=i8jUzwx=NcAGTZ1VhbBeQrfufA@mail.gmail.com> <155734004.4688980.1712271916204@mail.yahoo.com>
In-Reply-To: <155734004.4688980.1712271916204@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------cdvztDp3TSNYqErIgcp3I0R6"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/vcon/XXCNnz4KTAPVlTpEGQG-EQ-xwCQ>
Subject: Re: [Vcon] Email metadata in vCon
X-BeenThere: vcon@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: container for conversation data <vcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcon>, <mailto:vcon-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vcon/>
List-Post: <mailto:vcon@ietf.org>
List-Help: <mailto:vcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcon>, <mailto:vcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2024 16:38:00 -0000

Hi all,

On 05/04/2024 00:05, Dan Petrie wrote:
> Hi Orie:
> Thank you for exploring SMPT with respect to vCon.
>
> There are two aspects of this.  Part of the goal of vCon is to 
> abstract the metadata to a common set across all communications modes 
> (SMS, email, web chat, phone, video conference).

I understand and appreciate this goal. Certainly it is Ok to extract and 
generalize participants of a conversation, including From/To/Cc/Bcc 
email recipients.

> If we just encapsulate SMTP in JSON, we have not accomplished this.  
> It's important to find the common data across the communications modes 
> and map them to an abstraction.  This allows the consumer of a vCon to 
> do things like get the data, or parties, or text to the conversation 
> and know have to know any details about the communication mode and and 
> its protocol or format specifics. What I am looking for feedback on, 
> is what of the SMTP headers, do people feel is the metadata that 
> should be abstracted in the vCon and may be common with other 
> communications modes.
>
> On the other hand we are also trying to contain or reference all of 
> these communications in their various modes and format.  We could just 
> contain the whole SMTP message if we wanted to with no loss of data.  
> I am not sure we need a loss less capture in all cases though. Perhaps 
> is is sufficient in the SMTP case, to contain the body/multipart-mime 
> and some small portion of the SMTP headers, loosing most of the 
> transport details.

I have a separate use I want to implement in JSON - an POP/IMAP/JMAP 
mailstore archive (and also import/export format). For that use what you 
currently do is not sufficient, as you need to preserve all email 
message header fields, including the ones added in transport, such as 
Received. Do you think vCon is the right base for this use case?

Best Regards,

Alexey

>
> Cheers,
> Dan
>
>
> On Thursday, April 4, 2024 at 03:05:57 PM EDT, Orie Steele 
> <orie@transmute.industries> wrote:
>
>
> Following up on this, I was reading 
> https://www.rfc-editor.org/rfc/rfc4155.txt recently.
>
> I wonder if there are JSON Email representations that vCon might more 
> directly defer to?
>
> I was hoping there might be some JSON based email representation that 
> vCon could cite or otherwise use without redefining terms.
>
> I came across:
>
> https://datatracker.ietf.org/doc/draft-ietf-sml-structured-email/
>
> I wonder if JSON-LD for vCon had been previously discussed, or had 
> there been any conversation about how vCon and SML might fit together 
> or not?
>
> OS
>
>
>
> On Wed, Mar 27, 2024 at 4:47 PM Orie Steele 
> <orie@transmute.industries> wrote:
>
>     Context for Dan and Alexey:
>
>     - https://datatracker.ietf.org/doc/charter-ietf-vcon
>     - https://datatracker.ietf.org/doc/draft-petrie-vcon
>
>     We had some hallway conversations at IETF 119, about using vCon &
>     SCITT for transparency and archival purposes.
>
>     Regards,
>
>     OS
>
>     On Wed, Mar 27, 2024 at 2:44 PM Orie Steele
>     <orie@transmute.industries> wrote:
>
>         Adding a few email experts (I am not an email expert).
>
>         These parameters look correct to me for vCon, but I am not
>         sure if there are additional email details that should be
>         considered for archival use cases.
>
>         I also wonder if there is any encryption or signing
>         information which might be retained in a useful way, such that
>         a holder of a vCon and some trust roots might confirm that
>         parts of a vCon have not been tampered with, without using the
>         custom JOSE approaches in the draft today.
>
>         I'm thinking specifically of the case where I might know that
>         a Party had a particular key at a point in time, and I might
>         be able to use that key to verify an email message that had
>         been archived in vCon.
>
>         I suppose there could also be DMARC / DKIM fields that we
>         might expect to see preserved per message.
>
>         Regards,
>
>         OS
>
>         On Wed, Mar 27, 2024 at 2:03 PM Dan Petrie
>         <dan.ietf@sipez.com> wrote:
>
>             Hi Orie:
>             You are probably swamped, catching up after IETF 119. 
>             When you have a few minutes, it would be great to have
>             your input on this.
>
>             I think that you have worked with email in a vCon more
>             than many people have so far. However, if anyone else on
>             the list has any thoughts on this, I would greatly
>             appreciate your input too.
>
>             I have done a little work putting email messages into a
>             vCon, one message per dialog. Mostly, my use was in some
>             simple unit tests and in generating examples for the I-D. 
>             The table below maps the SMTP headers that I have put into
>             a vCon.
>
>             Are there any other SMTP header fields or metadata that
>             you think should be possible to include in a vCon?
>
>             Do you agree with the mapping from SMTP to vCon parameters?
>
>             Cheers,
>             Dan
>
>             Inline image
>
>
>
>
>         -- 
>
>
>         ORIE STEELE
>         Chief Technology Officer
>         www.transmute.industries
>
>         <https://transmute.industries>
>
>
>
>     -- 
>
>
>     ORIE STEELE
>     Chief Technology Officer
>     www.transmute.industries
>
>     <https://transmute.industries>
>
>
>
> -- 
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>