[Sml] Re: Suppressing SML fallbacks
arnt@gulbrandsen.priv.no Tue, 28 April 2026 18:09 UTC
Return-Path: <arnt@gulbrandsen.priv.no>
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 D37A0E4F8601 for <sml@mail2.ietf.org>; Tue, 28 Apr 2026 11:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777399762; bh=O3G86AdEz8p0dnQV7QG7v7XJ3UtAMsm6j4TS/o65UP4=; h=From:To:Subject:Date:References; b=TkJnCRSkqxiLfpdgnd48eUbs0FOuMCfL2R3zrkdq2XhZpVeGzJBA0Vdbbi/Gw5VRi IbFA1Z5dm8WQnX/smjnUSnrhKVlPYLZJT/N5oAO9f7WlIJJCZDCLxWvnh1sqUKLazu j9YlDIEEzcmd2XebicRMyDxIwQTCL5TO32P0EOPc=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no
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 f9pVPkEKzvKv for <sml@mail2.ietf.org>; Tue, 28 Apr 2026 11:09:22 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 13E78E4F85F4 for <sml@ietf.org>; Tue, 28 Apr 2026 11:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1777399759; bh=O3G86AdEz8p0dnQV7QG7v7XJ3UtAMsm6j4TS/o65UP4=; h=From:To:Subject:Date:References:From; b=aq3e2cFtPhw0/35Y0GIgxiohgd3N8kSGq3UcjHpnxDmNygeVU/RHRmrM9hIDoMXS7 RkaPI5vTm01MrUZDxU7vudP/iZll8HYOX1ZJfl3ITFRgSMk03E+ChssqUGAdyPpMKe E507UP0yyRmangGh4yZiGrqL5DJu+7gY48oQxq/g=
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 3E60EC0050; Tue, 28 Apr 2026 19:09:17 +0100 (IST)
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1777399756-3471-3470/9/21; Tue, 28 Apr 2026 18:09:16 +0000
From: arnt@gulbrandsen.priv.no
To: sml@ietf.org, Ben Bucksch <ben.bucksch@beonex.com>
Date: Tue, 28 Apr 2026 20:09:16 +0200
Message-Id: <51SoKRXB4fsH5xlB23GyYy9B0ltqVy1mtnbcXJ8yAOk=.sha-256@antelope.email>
References: <87pl3k2l0o.fsf@libertango.gulbrandsen.priv.no> <7d018465-e97f-27f4-3be3-2404de50ef72@beonex.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="https://antelope.email"
Message-ID-Hash: CW7QR6LODV2Y46NMNFHM5JOMQAGFISNN
X-Message-ID-Hash: CW7QR6LODV2Y46NMNFHM5JOMQAGFISNN
X-MailFrom: arnt@gulbrandsen.priv.no
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: [Sml] Re: Suppressing SML fallbacks
List-Id: Structured Email <sml.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sml/oqARvbPrnHU56L9tOBs_exExMAc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sml>
List-Help: <mailto:sml-request@ietf.org?subject=help>
List-Owner: <mailto:sml-owner@ietf.org>
List-Post: <mailto:sml@ietf.org>
List-Subscribe: <mailto:sml-join@ietf.org>
List-Unsubscribe: <mailto:sml-leave@ietf.org>
Hi, Now that your say it, I remember that. Perhaps the spec should be "render either this or your json-ld thing, your choice, they're equivalent". HJ? Can you add this to the draft, unless you disagree? Arnt On 2026-04-28 Ben Bucksch <ben.bucksch@beonex.com> wrote: > Hey Arnt, SML group, > Arnt Gulbrandsen wrote on 27.4.2026, 22:41: > > SML is extremely minimal in some senses, there's no rendering > > advice or anything. When I composed some mail on Friday, I > > found that there was something I wanted: Suppose you send some > > HTML mail and you attach some SML. Fine. You may want to add a > > fallback of some sort. In actual fact I immediately … > Yes, there's definitely a need for that. > We've discussed this about a year ago, in one of the IETF > meetings. HJ suggested to mark this fallback HTML element with > an attribute that references an ID in the SML. That attribute > tells the renderer that the SML is equivalent to that HTML > element, so the renderer can do its fancy programmatic rendering > instead of the static HTML. We had this conceptually mostly > nailed down, and were fairly concrete in the solution. We > stopped just short of defining the exact HTML attribute name, > value, and how IDs look like and how exactly they are found in > the SML. > Why important: E.g. the Polls usecase that I presented at FOSDEM > 2026 <https://fosdem.org/2026/schedule/event/JQSRHP-parula/>. > You want the responses from all recipients, not only those that > happen to use Parula or HJ's version of K9Mail. So, my plan (not > implemented yet) is to include a static preview of the options, > and a link to a webpage, where the recipient can then answer the > poll. Parula (and other SML mail readers that support this > particular "meeting time poll" usecase) can render the calendar > UI inline, and merge the poll with my own calendar, which > supports me better, but non-Parula users can still respond. For > this to work, Parula needs to know at which point in the HTML > the fallback is, so that it can replace it. > Ben > -- > Beonex GmbH > Taunusstein bei Wiesbaden, Germany > CEO / Geschäftsführer: Ben Bucksch > Handelsregister: Amtsgericht Wiesbaden, HRB 30065 > -- > Sml mailing list -- sml@ietf.org > To unsubscribe send an email to sml-leave@ietf.org
- [Sml] Suppressing SML fallbacks Arnt Gulbrandsen
- [Sml] Re: Suppressing SML fallbacks Ben Bucksch
- [Sml] Re: Suppressing SML fallbacks arnt
- [Sml] Re: [EXT] Re: Suppressing SML fallbacks Happel