Re: [Vcon] Email metadata in vCon

[Dan Petrie <[e-mail]>]

 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).  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.
Cheers,Dan

    On Thursday, April 4, 2024 at 03:05:57 PM EDT, Orie Steele <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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






-- 




ORIE STEELE
Chief Technology Officer
www.transmute.industries






-- 




ORIE STEELE
Chief Technology Officer
www.transmute.industries






-- 




ORIE STEELE
Chief Technology Officer
www.transmute.industries