[Sml] IETF 116 follow up / Draft charter

Hans-Joerg Happel <happel@audriga.com> Tue, 16 May 2023 18:04 UTC

Return-Path: <happel@audriga.com>
X-Original-To: sml@ietfa.amsl.com
Delivered-To: sml@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7B300C169530 for <sml@ietfa.amsl.com>; Tue, 16 May 2023 11:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jJ8c0gZBuvVb for <sml@ietfa.amsl.com>; Tue, 16 May 2023 11:04:19 -0700 (PDT)
Received: from mail.audriga.com (mail.audriga.com []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3EBC16952C for <sml@ietf.org>; Tue, 16 May 2023 11:04:17 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by mail.audriga.com (Postfix) with ESMTP id A2CA9A1E2 for <sml@ietf.org>; Tue, 16 May 2023 20:04:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mail.audriga.com
Received: from mail.audriga.com ([]) by localhost (mail.audriga.com []) (amavisd-new, port 10024) with ESMTP id yUyWmU3tBiqF for <sml@ietf.org>; Tue, 16 May 2023 20:04:14 +0200 (CEST)
Received: from [] (ip-109-090-161-242.um36.pools.vodafone-ip.de []) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 57972A0C4 for <sml@ietf.org>; Tue, 16 May 2023 20:04:14 +0200 (CEST)
Message-ID: <d12e4fa7-2cf2-9d87-3dac-f7592d743ce0@audriga.com>
Date: Tue, 16 May 2023 20:04:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: sml@ietf.org
From: Hans-Joerg Happel <happel@audriga.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sml/_uWIum9SwACTGRdwUCss0dRfBSI>
Subject: [Sml] IETF 116 follow up / Draft charter
X-BeenThere: sml@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Structured Email <sml.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sml>, <mailto:sml-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sml/>
List-Post: <mailto:sml@ietf.org>
List-Help: <mailto:sml-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sml>, <mailto:sml-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 May 2023 18:04:20 -0000

Hi all,

for those of you not aware, the materials (minutes/chat/video) from the 
Structured Email BoF at IETF 116 are available online at 

One outcome was to narrow done the list of issues discussed in the 
second part of the BoF and come up with a charter draft for further 

Points mentioned in the draft are supposed to capture basic building 
blocks, while points that address more specific and advanced topics (in 
particular dealing with multiple MUAs, message updates, message 
responses to structured email, hiding attachments meant for automation 
and data extraction) have been excluded and could still be addressed 
once initial work has been done.

Please find the draft below. Comments are welcome!


## Draft charter

A large number of emails today is sent by computer programs. Those 
messages often have a transactional nature, such as notifications, 
confirmations, or receipts. Based on templates, their content typically 
has a certain structure, even if written in natural language.

Solutions like the Sieve filtering language [RFC5228] help users to 
leverage such patterns in email structure to process emails more 
efficiently. More recently, approaches to annotate text-based 
information on the Web with a machine-readable variant [Schema.org] have 
been applied in the email domain [Email markup]. While some major 
vendors support this approach, adoption is still rather low and vendor 
implementations differ in various aspects.

The Structured Email (SML) working group will provide specifications for 
annotating text-based email content with a machine-readable version. It 
will initially focus on specifying:

* The overall approach of using RDF/Schema.org in email messages to 
annotate email content, as it is used by vendors in current practice
* How machine-readable content relates to the text-based version of content
* Which RDF encoding to use in which part of email messages
* The usage and sharing of RDF vocabulary for actual annotation
* Extensions that enable client-side tools to efficiently determine if 
machine-readable annotations are present
* Security and trust recommendations to prevent abuse of structured email

These specifications are supposed to build upon the Internet Message 
Format [RFC5322] and related documents. Structured email needs to ensure 
downwards-compatibility with legacy email clients in the sense of 
allowing users to consume email content, even if a machine-readable 
variant exists in parallel.

The following points are out of scope for the working group:

* Modeling RDF vocabulary for particular use cases or domains. 
Exceptions might only be made for vocabulary directly related to the 
email domain itself. If required, such work should be carried out in 
cooperation with appropriate bodies such as the Schema.org W3C Community 

* The working group will not prescribe how structured email is processed 
in emails clients, with the exception of security recommendations as 
mentioned before. Specifications such as adding support for structured 
email to the Sieve language could however be addressed by a 
rechartering, once initial work has been finished.

The working group aims to coordinate efforts with at least these related 
groups as required:
* The IETF EXTRA and JMAP WGs, which deal with most of the IETF's email 
* The Schema.org W3C Community Group
* The M3AAWG Dynamic Email Security SIG

* (to be added in later stage of process)