Return-Path: X-Original-To: sml@mail2.ietf.org Delivered-To: sml@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 46F4A135C1F89 for ; Fri, 4 Sep 2026 14:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1788556313; bh=JdKwK99R2V65Pz299W1ol5vy4WOcW9bBAR6bm/8Tw/c=; h=From:To:Subject:Date:References:In-Reply-To; b=XCZ34rytuwuCit2NjY26P/y2tfalx+JEzmLEWI3r0gw98ukA2b9S3X4aLm3QAvwJ2 gLHxsRwbjJVC2C2jv90joiKr7otvs+YBPhGPSiLmpXvTBShuwP+bIAOuHzMFePFgAC ks2wNKV5bvuI9EUrwaf3ikgDq3X7OHljZfg9O/Hc= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 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, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMI-XP7LCsSO for ; Fri, 4 Sep 2026 14:11:52 -0700 (PDT) Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazolkn19012076.outbound.protection.outlook.com [52.103.11.76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8DAA7135C1F7E for ; Fri, 4 Sep 2026 14:11:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QgxM7aRymGkJJbjCniBtp3NmaCJTQcqteTDtbFv6aVVegFh8nkgqG5sihd2ovQNFCRraLWT8dQI0DQ8tWrCFrZQiR3NrlJegq4XLM7K9qZijd7Pe+AnLh8CDgTZoAN7q/9hrU9O87JFfZMe341AE8z9jusOz9S3Qr99GiPIuD0zmrWA0X1nxnSYQ5ZSJ+EhezuaxjNERubww7F8wAzMzErG/cSAVebVKPlhcQbZDXv0KgvJhQ9T0aq9AtlcFRoL2aM/a7jb/V10V2kbh4+l36ztds6HNMlE4GSXcCDBakYzWxdfodhOD2xqP5JSQEUnJn7/j9rcNrwkvQw9moquELg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FGOnZoIL6UB7/OiUzzcxsHP7MKuvQV+mk3edayoBTUk=; b=O8MhtmyXitVW7vwC0+aauRRLy8/Xxo8mO3NsyRbJOoKPamozZD9tTHrTP/zN3W6YPvzeqqkPfsG8rUdA3PxdRjiQIYQtuRRKPp2c6zrkQrqOWdpbmN3TGlsWirXvXCGSEhv3deAzQXUREvBfeHT0fkJjqB3tSNHh57awxr1TXX94lQnmTuG9JSD8MHQ8H6/Qlbqo+QQhCjpfpfPk5skZy84/EMJPeU/xgY5NvyQOAHAuJgGJdraDchkLjJRkAoIlX2CKBVupDGyU8Z+CE1ZiQ15JiNnK/br1ylSiQXXX2Bqoun8Tm3lHt8uCFQAlOfdXteEQXoPOCIJo5As5FxmfAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FGOnZoIL6UB7/OiUzzcxsHP7MKuvQV+mk3edayoBTUk=; b=qmraiRAZZo9XmeVMWstrlVqBlCMXMmfaPItoi7KCXr6PCdh59GCnhffQvs0QXFkJUuBDGevT8g04TqxYil9FlycUjKeoeUK4owcmHyZ2Oor/0T6KpfUGqQ1QSfWJ88mnfzC+GbHkq3MfE3yPTOZhL67L/+TsTK2HaJEX+Bl9FP/jUOlqh0ifFpbo5S8+QyKjqdzlPaA3QYxHVGHVlGP63WeoU3hTphigK0ZaU5b4RXbbkC9/P2ddS4AtCPJCEJYYS3pHgq/PhxsRzzBl1pHVOzdea9+ZVvYNKj3AM2aQ3BnaygEtqW/ygNJq3xumyq2S/2AcmeXGyE/h6Re2yYP3nA== Received: from CY8PR20MB5403.namprd20.prod.outlook.com (2603:10b6:930:5d::15) by LVXPR20MB994793.namprd20.prod.outlook.com (2603:10b6:408:399::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 21:11:45 +0000 Received: from CY8PR20MB5403.namprd20.prod.outlook.com ([fe80::1be0:cd74:983d:a091]) by CY8PR20MB5403.namprd20.prod.outlook.com ([fe80::1be0:cd74:983d:a091%4]) with mapi id 15.21.0360.008; Fri, 4 Sep 2026 21:11:45 +0000 From: Adam Sobieski To: Phillip Tao , "sml@ietf.org" Thread-Topic: [Sml] Proposal: define a new Structured-Email header field Thread-Index: AQHdPJCicvQ7ldFDv0SggtZBS+fT6ba+14JL Date: Fri, 4 Sep 2026 21:11:45 +0000 Message-ID: References: <7CAB2414-6D44-4987-839B-87AA5EEA8CF4@apple.com> In-Reply-To: <7CAB2414-6D44-4987-839B-87AA5EEA8CF4@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CY8PR20MB5403:EE_|LVXPR20MB994793:EE_ x-ms-office365-filtering-correlation-id: 57eba49c-2a04-4431-9eb9-08df0ac9204a x-microsoft-antispam: BCL:0;ARA:14566002|8062599012|8060799015|19110799012|37011999003|15080799012|15030799006|31061999003|51005399006|24021099003|25010399006|9400799043|1602099012|40105399003|10035399007|2607281247196008|440099028|102099032|4302099013|3412199025; x-microsoft-antispam-message-info: =?iso-8859-1?Q?C9ciB58rOZPgFQ5AwiQdVAGbto2hhfHK9FS4LkIKeaqFW9ZB8EF/AlaHTT?= =?iso-8859-1?Q?veBT/fC1kjSB2aUDarW91bE2giVXwNT3WB7hnL24h7vMS2U5d5rVYYlSFD?= =?iso-8859-1?Q?XnnCJBF+7Y3hLeKPUiZYIdRgWqZF/a4dZiAFOrVq/eF3ll3OxUeWIGJtB7?= =?iso-8859-1?Q?yglq2ET3gkOWDsNJuf+IFuxhsmH5B6WlEoImzEjqoIurK7EGbD4qHzhFii?= =?iso-8859-1?Q?fzkChZq/DNaBPO3eFY1ZakVjDLaB7jkQb1AAFv0cVYBvzNgP1EByxUM9Au?= =?iso-8859-1?Q?Le314tVMNuGqLaAOE8Vo2Uf4UctPy9sscEN6zrOuQ3XU75/rm5exLOMjIh?= =?iso-8859-1?Q?yUi3EtYeZ3kgZcmO+O0VNPtq0Vw1fd/yWfznE9jjKKKjZrOr6vVEWRfzxA?= =?iso-8859-1?Q?YDwdDLqCchSvfx6/K33mAJOq6UsJBVBUxj6iXzb99OBZCPG4pHdXd3gCB+?= =?iso-8859-1?Q?oM58+1MlA2DN5Qlb9yhqcfGH4PuDL8cMcnq6IDZrg9C/HylRzd2q9pGLRw?= =?iso-8859-1?Q?OZ1XiPBOqpoWs0gXCXNrNJaIjPv4lldJizrcsZgop+Vfjsg4Rqg6zfMkR2?= =?iso-8859-1?Q?bAo4/93Rey+K4oDCJsCMU6xra+ZL0B8D6Vu6Ndy3+jBH+fK40e+spxxvxx?= =?iso-8859-1?Q?VqUeJFfeQgBRhcIry6vuRdFm315MzGsCsmhfsMGNUV6s1vKEXiUBwAyDWO?= =?iso-8859-1?Q?ht2XlwEp+vO01qEeh91DIBJogoV0LcZ+g6+xZyAnisgDTet/V42y7rahME?= =?iso-8859-1?Q?aiBTR1lOz1l7SrFa/neqxvkCFRiYN/69iWplyRpX/tKMxhHjyoD3bs7VvH?= =?iso-8859-1?Q?klfyQOMumnoCpMSnXsrcM60eoWVqWAo5O/bdorDvtdq5BmIwn3qUeTIOhM?= =?iso-8859-1?Q?sLXXZ+cHSW08kHTV9zv+7/pvYyxfj7Ty5VEsAA0unuRVueCJF8x6V3jTQk?= =?iso-8859-1?Q?1e3FiL78Z4gur5lqn2vdy5RYC5w87sDJS+9tANHp1JnZqk4D+5hWCK+WmN?= =?iso-8859-1?Q?znlGEx2PlP/JqdWhq5lKUtW9oq1UGWnbq5/Nou9B9YImURLJNFB19YGTmD?= =?iso-8859-1?Q?iDra0oTQcruCaVXYQJsKrGjUMI5NYWSyliANxfGKJNQV?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Tdgf0tyL1y7LifQgvGeMv2UWScG08gXv3spbQ6ezSdFjUGrZdXv6M97sdR?= =?iso-8859-1?Q?UMgfXRIvYbDu/94sT3mcr/YvTDMjnn0j/aVDhPcbfbjYPZSVzEpKvdhvow?= =?iso-8859-1?Q?b0vEA8aWuZ0gjsYtjMalK+VZbtsuNT/MT6LmE2r8BOBqXnr2cSRwwRWvFZ?= =?iso-8859-1?Q?raqU6bPJSLmnb+Wp6XsI6asvo54mzif10h4rPElqT/y9hbevzArU0VjgnY?= =?iso-8859-1?Q?E2yGH5sf1q++T3quKUqcs8i4bysYZ5N3kBrsQidD1nVlAV4iIyUcveBomA?= =?iso-8859-1?Q?WS3v6EN66Cq4W4EvSInhP7mwdlFofgognY0hvJixhCeDc3cZ0Lw2cjsNCJ?= =?iso-8859-1?Q?Z7AvNdcnwuGAPM5CnwGy1YR9iidBcXNyIrI6bPGXx5XMQ+8T6ghodq1PNR?= =?iso-8859-1?Q?4jWo+ryboUFkTRcUEzhroejaSAmUy0HCSQMDeVonq+GpLc6cmBiNBXDTOt?= =?iso-8859-1?Q?By6FMfvA7hRIrZVnIr8+ozOH8fRdSk8sLEjT4ld8AG/3scv2Uv2fpbFvbv?= =?iso-8859-1?Q?O6ildfJg1U79s2ZWmeih5uUoDrfDNgZUpqs3XfRzfQjIvw1+kMc7qCthjI?= =?iso-8859-1?Q?L5Uqi4x6lNDpsRO708sNvZRvoapKfBrl7JN3ADgN7zeio4zlMhSu956Daf?= =?iso-8859-1?Q?JYOv9IYRiyzChcbYdMfo5RmagYCQScAfL0j5u1pqI5CPIsj034rkVATCy6?= =?iso-8859-1?Q?PHC0LNZaMsoD/pNCwPuxNRXMekBH21H0f0KKQJ2bikpO6vQp9ZaJU7jwxE?= =?iso-8859-1?Q?ssouloZ3N8RLGOPLgtzVlnRygTF73abRPyL2yOHQGVkzwoe0ZrRzr3cBpY?= =?iso-8859-1?Q?eYPKiNq15F/7IBPsYr+k5VQFj9gwRSpEi9eVYc9QN7JTNgC6+CQE1Y9R9B?= =?iso-8859-1?Q?P1YdmkUOgMnaXXynfPlwNDKypUZ2C4uvClMKHF6ADJRA6327Fi39ZXJgPo?= =?iso-8859-1?Q?GksBanA0sKsWTfDOw9hz+y5MzfBseM4AP8g0uBcFS13e6COm7tSjal1uLF?= =?iso-8859-1?Q?zk2zpPbGFbnQYe3MQpsXV1biZ/7+J5jsek459BLYG76ZNNVaLzY11auQ1Q?= =?iso-8859-1?Q?RjqMnXqkq6o75/PyrqLG6nQ8i+9B2f65qnvfbSde1JHTb9c8gqBtHrusMA?= =?iso-8859-1?Q?GVIeLMktk7nFGSNUF0Piedb/VW8IKIOnoCXU4GQxLMXL3vo8VVAe7PiM6u?= =?iso-8859-1?Q?R+agjzRSn/Lp8X9z74RrYxfLboiS/499eFAkQ7NzX5ML5k5bart83uWq5U?= =?iso-8859-1?Q?nhHIlJGqci/9S0hFawMsGYk5h6CiMk7PfZeXhVxfZopR6z/ZWz7qH/z0Bx?= =?iso-8859-1?Q?yBQRIZUFifw3PqaMWMV5M026TunnQE8AKNV9rjx6F+21FT/2ZnESWixqUI?= =?iso-8859-1?Q?dC9ob+lal4CMRW821MXYgcAgtLyOLtsOpCjXQMbNSBYNr3o7KEVbKoWLNr?= =?iso-8859-1?Q?WpnqyEd4+lJWwtkG?= Content-Type: multipart/alternative; boundary="_000_CY8PR20MB540303A99C1AA557951EB3F2C5B52CY8PR20MB5403namp_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-9412-4-msonline-outlook-6d936.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY8PR20MB5403.namprd20.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 57eba49c-2a04-4431-9eb9-08df0ac9204a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2026 21:11:45.5745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LVXPR20MB994793 Message-ID-Hash: 2Y4Y57BYZ4LUKYZQZJ6HXAJCDCJIBCQX X-Message-ID-Hash: 2Y4Y57BYZ4LUKYZQZJ6HXAJCDCJIBCQX X-MailFrom: adamsobieski@hotmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BSml=5D_Re=3A_Proposal=3A_define_a_new_Structured-Email_header_f?= =?utf-8?q?ield?= List-Id: Structured Email Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_CY8PR20MB540303A99C1AA557951EB3F2C5B52CY8PR20MB5403namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phillip Tao, All, Hello. Drawing inspiration from JSON-LD technologies, for discussion purpos= es, I would like to share an alternative approach involving two new header = fields: 1. Content-Context 2. Content-Relation A "Content-Context" header, when present, would refer via URL to data with = which to validate and interpret a structured message and its parts. A Conte= nt-Context header would refer to data indicating those message parts which = were to be optional, those which were to be required, and, perhaps, those M= IME types that each part could be, e.g., "application/ld+json". Using MIME = parameters, i.e., the "profile" parameter, one could describe, in greater d= etail, those data expected within messages' JSON-LD parts. "Content-Relation" header fields would be of use for messages' parts to ind= icate their relationships to their containing whole messages. Using this he= ader field, messages' parts would signal which role or roles that they fill= ed in their messages' structures. These header fields would, as envisioned,= be for succinct text-string values which, resembling JSON-LD, would be int= erpretable into fuller IRIs using those data available at URLs indicated in= the Content-Context header field. In examples at: https://github.com/AdamSobieski/Web/discussions/5 , structu= red MIME-based messages are shown with structured messages' parts having ro= les: "metadata", "content", and "supplemental". In theory, as the JSON-LD format also allows providing "@context" data inli= ne, instead of having to use a HTTPS URL in the Content-Context header fiel= d to refer to (cacheable) external resources, one could use RFC 2392, the "= cid:" URL scheme, for messages to refer to contained parts, by id, which pr= ovide such data inline, inside of the messages themselves. Thank you. Best regards, Adam Sobieski ________________________________ From: Phillip Tao Sent: Friday, September 4, 2026 1:12 PM To: sml@ietf.org Subject: [Sml] Proposal: define a new Structured-Email header field Hi all, I would like to propose that a new header field be defined in the core draf= t. The reason is that MUAs may want to be able to make choices about how an= d when to download a given message, based on the presence of structured dat= a inside the message. Proposed format: Structured-Email: representation=3Dmachine-readable; content=3Dvacation= -notice; The body of the header would be a tag-value list as defined by DKIM, with t= wo tags: representation and content. The "representation" tag can have four values: "machine-readable", "full", = "partial", or "non". These map to the types of representation defined in the core doc. In my rea= ding of the core draft, machine-readable messages are strictly a subset of = "full representation", while non-machine-readable messages may be any of th= e three representation types. Therefore, I've chosen to collapse "machine-r= eadable" into one of the four representation types here, rather than expres= s that as a separate tag. Note that "non" specifies the "non-representation= " case, not the absence of structured data. The "content" tag would be a comma-separated list of values identifying the= type of structured content in the message. A new IANA registry would be cr= eated to register these types. I would propose that the header with at least a representation tag be requi= red, while the content tag would be optional. FAQ Q: Why do we need this in addition to the message flags defined in section = 6 of the core draft? A: Two main reasons: 1. The IMAP flags rely on mailbox provider implementation. For a MUA de= signed to interoperate with a variety of MBPs, a reliable signal is needed = for whether a message has structured content or not. Because the sender is = the one attaching the structured data, they're the natural party to also at= tach metadata about the presence of the structured data. 2. The currently defined flags do not convey the type of structured dat= a carried in the message. This is important because the MUA may not underst= and all possible structured data that can be in an email message, and may o= nly care about certain types. Even among the types that it does care about,= the representation type and content type may inform when and how it wants = to download the message. For example, for a machine-readable one-time-code, a MUA might want to = download it immediately, even when it would otherwise hold off on downloadi= ng message bodies due to power or network usage concerns. It may also just = download the structured data part and not any other MIME part. For a messag= e with a boarding pass or ticket, it may want to download just that part fo= r now, and download the rest of the body parts according to its normal body= download scheduling. Q: Should this replace the message flags defined in section 6? A: I lean toward yes, but I can also see some potential use cases for the m= essage flags (like, maybe being better supported for IMAP SEARCH)? Q: Why does this need to be a header? Can the same information not be deriv= ed from the BODYSTRUCTURE? A: Currently, structured data is defined as being carried exclusively in ap= plication/ld+json or application/jose parts. However, the presence of MIME = parts of those types alone are not sufficient to determine that they are ac= tually structured data, as opposed to some an attachment which happens to u= se the same format. An alternative could be to define a new attribute on th= e Content-Type or Content-Disposition. More importantly, however, there has been discussion of allowing some c= ases of structured data being allowed to be carried in the text/html part. = In that case, it is impossible to tell a message with structured data apart= from any other HTML message. Q: Why do we need a new IANA registry? A: The current IANA registry defined by the core draft is for vocabularies.= This new registry would be for content types. Some content types may share= vocabularies. One content type may also use multiple vocabularies. Many co= ntent types may not need any vocabulary defined in the IANA registry, and m= ay simply use schema.org. The broader question of why the content-type is needed at all is addres= sed in question 1. Open to any feedback, questions, or comments. - Phillip --_000_CY8PR20MB540303A99C1AA557951EB3F2C5B52CY8PR20MB5403namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Phillip Tao,
All,

Hello. Drawing inspiration from JSON-LD technologies, for discussion purpos= es, I would like to share an alternative approach involving two new header = fields:

1. Content-Context
2. Content-Relation

A "Content-Context" header, when present, would refer via URL to = data with which to validate and interpret a structured message and its part= s. A Content-Context header would refer to data indicating those message pa= rts which were to be optional, those which were to be required, and, perhaps, those MIME types that each part could b= e, e.g., "application/ld+json". Using MIME parameters, i.e., the = "profile" parameter, one could describe, in greater detail, those= data expected within messages' JSON-LD parts.

"Content-Relation" header fields would be of use for messages' pa= rts to indicate their relationships to their containing whole messages. Usi= ng this header field, messages' parts would signal which role or roles that= they filled in their messages' structures. These header fields would, as envisioned, be for succinct text-string valu= es which, resembling JSON-LD, would be interpretable into fuller IRIs using= those data available at URLs indicated in the Content-Context header field= .

In examples at: https://github.com/AdamSobieski/Web/discussions/5 , structured MIM= E-based messages are shown with structured messages' parts having roles: &q= uot;metadata", "content", and "supplemental".

In theory, as the JSON-LD format also allows providing "@context"= data inline, instead of having to use a HTTPS URL in the Content-Context h= eader field to refer to (cacheable) external resources, one could use RFC 2= 392, the "cid:" URL scheme, for messages to refer to contained parts, by id, which provide such data inline, inside of= the messages themselves.

Thank you.


Best regards,
Adam Sobieski


From: Phillip Tao <ptao=3D40apple.com@dmarc.ietf.org>
Sent: Friday, September 4, 2026 1:12 PM
To: sml@ietf.org <sml@ietf.org>
Subject: [Sml] Proposal: define a new Structured-Email header field =

Hi all,

I would like to propose that a new header field be defined in the core= draft. The reason is that MUAs may want to be able to make choices about h= ow and when to download a given message, based on the presence of structure= d data inside the message.

Proposed format:

    Structured-Email: represen= tation=3Dmachine-readable; content=3Dvacation-notice;

The body of the header would be a tag-value list as defined by DKIM, w= ith two tags: representation and content.

The "representation" tag can have four values: "machine= -readable", "full", "partial", or "non".=

These map to the types of representation defined in the core doc. In m= y reading of the core draft, machine-readable messages are strictly a subse= t of "full representation", while non-machine-readable messages m= ay be any of the three representation types. Therefore, I've chosen to collapse "machine-readable" into one o= f the four representation types here, rather than express that as a separat= e tag. Note that "non" specifies the "non-representation&quo= t; case, not the absence of structured data.

The "content" tag would be a comma-separated list of values = identifying the type of structured content in the message. A new IANA regis= try would be created to register these types.

I would propose that the header with at least a representation tag be = required, while the content tag would be optional.

FAQ

Q: Why do we need this in addition to the message flags defined= in section 6 of the core draft?
A: Two main reasons:
    1. The IMAP flags rely on mailbox provider implementatio= n. For a MUA designed to interoperate with a variety of MBPs, a reliable si= gnal is needed for whether a message has structured content or not. Because= the sender is the one attaching the structured data, they're the natural party to also attach metadata about the presence= of the structured data.
    2. The currently defined flags do not convey the type=  of structured data carried in the message. This is important beca= use the MUA may not understand all possible structured data that can be in = an email message, and may only care about certain types. Even among the types that it does care about, the representation ty= pe and content type may inform when and how it wants to download the messag= e.
    For example, for a machine-readable one-time-code, a MUA= might want to download it immediately, even when it would otherwise hold o= ff on downloading message bodies due to power or network usage concerns. It= may also just download the structured data part and not any other MIME part. For a message with a boarding pass or ti= cket, it may want to download just that part for now, and download the rest= of the body parts according to its normal body download scheduling.

Q: Should this replace the message flags defined in section 6?<= /div>
A: I lean toward yes, but I can also see some potential us= e cases for the message flags (like, maybe being better supported for IMAP = SEARCH)?

Q: Why does this need to be a header? Can the same information = not be derived from the BODYSTRUCTURE?
A: Currently, structured data is defined as being carried = exclusively in application/ld+json or application/jose parts. However, the = presence of MIME parts of those types alone are not sufficient to determine= that they are actually structured data, as opposed to some an attachment which happens to use the same format. An = alternative could be to define a new attribute on the Content-Type or Conte= nt-Disposition.
    More importantly, however, there has been discussion of = allowing some cases of structured data being allowed to be carried in the t= ext/html part. In that case, it is impossible to tell a message with struct= ured data apart from any other HTML message.

Q: Why do we need a new IANA registry?
A: The current IANA registry defined by the core draft is = for vocabularies. This new registry would be for content types. Some content types may share vocabularies. One conten= t type may also use multiple vocabularies. Many content types may not need = any vocabulary defined in the IANA registry, and may simply use schema.org.
    The broader question of why the content-type is needed a= t all is addressed in question 1.

Open to any feedback, questions, or comments.

- Phillip







--_000_CY8PR20MB540303A99C1AA557951EB3F2C5B52CY8PR20MB5403namp_--