[Sml] Re: Structured quoting

[Ben Bucksch <[e-mail]>]

I concur with Arnt that this use case is one that begs to be embedded in HTML,
not as a separate MIME part. Because it's so inherently about the text itself.
It's not data represented in text, but rather data about the text.

Phillip Tao wrote on 27.4.2026, 22:58:

> I think that makes sense for partial representation. I think full and
> non-presentation should continue to use a separate MIME part.


Yes. In my mind, "partial representation" means that I send a song to someone,
and then add text to the email. The song is a data item by itself, independent
of the text. And then it becomes part of the text. But it's not the entire text
- I cannot show only the song and ignore the text. That's what "partial
representation" means for me.

Quotes are meta data about a part of the text. They are not "representing" the
text, they are text, and we're merely adding meta-data about the text. This is
most naturally in HTML.

I'd even go so far that we should express it as native HTML attributes whenever
possible, and use JSON-LD only for more complex data, but still within HTML
attributes.



> Even for partial representation, I just want to note that disallowing a
> separate MIME part would mean that it becomes explicitly incompatible with
> plain text. From the last WG session, it sounded like we're all pretty much
> fine with that? Or are there any use cases that would still make sense to have
> both partial representation and plaintext compatibility?



Plaintext people typically want "just the text, nothing else, thank you very
much". So, yes, I would explicitly not try to do metadata for quotes in
plaintext in the form of JSON-LD.

What would be helpful for plaintext is to define
a) What quote markers must look like
b) Wrapping (or not)
c) How to write the attribution line

a) and b) is already well-defined in RFC 3676. I would simply re-use that.
c) would be helpful to narrow down further.

However, I think that's better done in a different RFC. They can reference each
other. I think adoption by plaintext people would be better, if this was a
separate spec, specifically for plaintext, not inside a spec that's primarily
talking about HTML. Given the hostility towards HTML by that user/developer
group, such a spec is less likely to be even read and honored.

Ben



>  * Phillip
> 
> > On Apr 27, 2026, at 1:48 PM, Arnt Gulbrandsen [e-mail]
> > [[e-mail]] wrote:
> > 
> > Hi,
> > 
> > one of the things I've implemented now is structured quoting, which I've
> > done twice (once to generate, once to render).
> > 
> > I found both really easy, but in one case I had to make it really easy by
> > putting the JSON-LD in a HTML comment when I generated outgoing mail, and in
> > the other I had to assume that the JSON-LD is in the HTML I parse (because
> > the existing surrounding code assumed that parsing the text/html was enough
> > to generate HTML for display.)
> > 
> > Phillip's draft currently specifies that the JSON-LD goes in a separate MIME
> > part, because the main draft has a corresponding rule.
> > 
> > Based on this overwhelming number of samples (two) I suggest specifying that
> > the JSON-LD goes in the HTML, always, not optionally.
> > 
> > Arnt
> > 
> > --
> > Sml mailing list -- [e-mail] [[e-mail]]
> > To unsubscribe send an email to [e-mail] [[e-mail]]
> 
> --
> Sml mailing list -- [e-mail] [[e-mail]]
> To unsubscribe send an email to [e-mail] [[e-mail]]



--
Beonex GmbH
Taunusstein bei Wiesbaden, Germany
CEO / Geschäftsführer: Ben Bucksch
Handelsregister: Amtsgericht Wiesbaden, HRB 30065