Session Date/Time: 17 Mar 2026 06:00
Alexey Melnikov: Hello. Good afternoon. This is SML. So, yes, to answer Hans-Jörg's question in the Jabber, we're just starting. We're just being slightly disorganized as usual. I'm Alexey and Arnt, my co-chair is here. Arnt. Okay. Did you say you wanted slides? No, I didn't. Well, it's fine if you do it. I wanted someone to do it. Chair slides first. No, hold on. We have an off-by-one error. Okay. You go ahead.
Arnt Gulbrandsen: This is the Note Well slide. You will all kindly have read it already. However, you are expected to behave in a professional manner, extend respect and courtesy to their colleagues, blah, blah, blah. If you are aware of a contribution, make sure to disclose that or blah. For advice, please talk to the working group chairs sitting right here or the area director sitting right there. Treat colleagues with respect, speak slowly, limit use of slang, dispute ideas using reasoned argument, use best engineering judgment, find the best solution for the whole internet, and contribute to the ongoing work of the group and the IETF. This session is being recorded. We have links to Meetecho. Please do join the onsite tool if you're here so that we have a record. We will make notes if you look at it and see anything missing, just add it.
Our agenda today is severely reduced due to recent illness. I see Hans-Jörg is back on his feet now or else joining from bed. Either way, progress. The major or the item is a new document that we may want to adopt from Phillip about quoted content—machine-readable quoting in email basically. Any other business at the end. We are not doing trust this time. That's the only document that has been updated since the last meeting and the only thing I did was resolve questions that were decided at the last meeting. No one has commented so I assume that everyone is just happy. Any agenda bashing or people want—well, we will have time at the end if people want to bring other things. But if people have no objections, Phillip.
Phillip Hallam-Baker: Okay. So, one second. One second. Here it is. Okay. Let's try this. Yep. Okay. Hello. Okay. About that. Actually, maybe a little bit higher. You want the clicker yourself? Oh, yeah. That sounds good. Hi. So, yes, I'm Phillip. I'm here to talk about the structured quoted content. So, this was a discussion following Dublin, I believe. I sent out a message to the mailing list. There was some interest in that. So, I wrote a draft for it.
So, what is this all about? So, as we all know, quoted content is very common in email messages, replies and forwards and so on. It's already kind of loosely structured by convention that's built up over time. You know, typically you start with an attribution line—who said what on what day—and then the actual body of the quote is, you know, has a right-angle bracket for plain text or blockquote for HTML. Not always, but commonly. So, this structure, you know, is intrinsically tied to the presentation. So, what? So, what is the problem here? So, because the structuring is tied to the presentation, that means it's really controlled by the sender. So, the sender makes decisions like how to format the quoted text, how to localize the attribution line or the quoted headers. In the attribution line, you know, usually they'll format the name and/or addresses, and that may not match what you see in the client because email clients may pull names out of, you know, the contacts app or something from the device.
It's also a problem for inline replies. For long threads with a lot of inline comments, especially things that are kind of deeply nested, it's easy to lose track of who's—who said what, what's actually being replied to. And it's expensive and error-prone for mail clients to try to determine these quoted sections, which they may want to do to collapse them for presentation or to remove them before other processing that they may want to do.
So, a couple examples of some of the problems. On the left, we can can see that there's a conversation between three people, one of whom is using Outlook with the client set to Chinese, one of whom is using Gmail set to Spanish, and the person actually receiving this message is an English speaker. So, they're going to have, you know, some trouble making sense of what these headers—what these header fields are. Outlook also does a really interesting quoting style where this looks like it's all just one flat message, but it's actually two layers. In the middle screenshot, you can kind of see some of the problems with inline replies. So, at the top it says Leonard Gordon wrote whatever, but the thing actually being replied to is somebody else in light blue, and we can't really tell who that is. Later on, the later sections don't have any kind of attribution, so you're totally lost. And this only has two quote levels, but I'm sure you guys have received emails where like the quote lines take up like half the horizontal real estate and you just have like a thin strip of text on the on the right. Those are some real-life examples from I think the DMARC rechartering discussion, where again, in isolation, it's hard to tell who said what unless you scroll up and expand stuff.
So, yeah, how can we solve this with structured email? So, structured quoted content would always be a partial representation. And the objects that we would use are an email message, which kind of represents the message itself, the quoted content, which is the the section of text that's that that is the quote, quoted header block, which can have quoted headers, a quote attribution, which is kind of an alternative to the quoted header block, and text content. And could also have a preamble or attachment content. That's not in the draft right now, but they both should be probably. So, the preamble would be something like for forwarded messages you often have a line that's like "Begin forwarded content" or something like that.
So, this is kind of hard to understand this structure, so this hopefully will clarify things a little bit. So, you can see in this example message that we saw earlier, this is kind of how it would be laid out. So, there's one big quoted content block here, and that one has a quote attribution at the top for the "Abigail Rogers escribió" that line. And then a text content for what Abigail actually wrote, and then a quoted content where Abigail is quoting another message from James. So, in the second quoted content, instead of an attribution line, that has a quoted header block with a bunch of quoted headers and its own text content. And so, each of these quoted content also has an email message. The email message is not actually referenced from anything in the HTML, it's just in the JSON-LD, and it has some metadata about the message, which is useful in various cases.
So, a receiving client can take this structure and rewrite the HTML into something that's more consistent with how quoted content is typically presented on that in that client or on that device. So, this is an example from iOS, the mail.app quoting style. But you can imagine Gmail, Fastmail, Outlook may all want to present it in their own way to be consistent for their own users.
So, another example that we saw earlier with a lot of inline reply blocks. You can see the top one has a quote attribution, but the the next two don't. But because each of those still reference the email message, the receiving client could, you know, use that to write a little attribution line of its own or something if it wants to. And, you know, you can imagine various things it can do to transform this in a more readable way.
So, yeah, the draft, I think there are still a lot of open questions, there are sections to be fleshed out. Some of the big ones are how to do this for plain text, or if it even needs to be done for plain text. I think the point has been made that email clients that might be interested in adopting this are have probably no overlap with clients that only want to display plain text. So, maybe it's not necessary. I think even if we do want to, it may be more of a question for the base document for how partial representation should work with plain text in general. So, maybe not something to be addressed specifically with this document.
And the next point is maybe a back reference to the original message. So, right now this is a structure for for the message that contains the quote. But for each of the quoted blocks it would kind of be nice to be able to point back to the exact section of the message being quoted. I think that would allow a lot of more interesting UI that could be done with that. It's kind of tough, though, because when you're generating a reply, you obviously can't, you know, modify the original message that's already been sent. So, I don't have any great ideas about how that would work, if anyone does I'd be happy to hear about it.
And another question is, right now the JSON-LD is a separate MIME part, and perhaps it should be embedded in the HTML. I think again, this is probably something we would want to tackle with the base document rather than being specified as as part of this specifically. And finally, attachments, I think that's probably pretty straightforward. It's just an oversight that it wasn't in the draft.
Alexey Melnikov: Can you explain the last point? What do you mean by what do you need to do about attachments?
Phillip Hallam-Baker: Oh, attachments is just in the draft right now that there's no representation for an attachment in a quoted message. It's just text content or another quoted content block.
Alexey Melnikov: Okay, so possible answer might be we don't bother, there is nothing to do, as in we don't mention attachments or do you want to list names for attachments and what they are all about.
Phillip Hallam-Baker: Possibly or or or it should be just another object type. Yeah. Just something that should be addressed one way or the other.
So, yeah, I think those were all the slides. I think this is a good demonstrative use case for structured email. It kind of exercises a lot of the base document for, you know, partial representation. I think we've had some good side discussions about the yeah some some issues with the base document that came out of this. So, so yeah, I guess I think the chairs you both have looked at it. Do you think it's about ready for adoption or any next steps you would suggest? Alexey. Okay.
Alexey Melnikov: Okay, let's Hans-Jörg will talk first and then I'll I'll add myself then.
Hans-Jörg Happel: So, can you hear me? Hello?
Alexey Melnikov: Yeah.
Hans-Jörg Happel: Okay, so hello to Shenzhen. Um yeah, first of all, thank you Phillip. That's really great work. I really also think that could be a super useful thing and is also a good application case for SML here.
So, two things from your final slides so where I'm not fully clear what it's meant. So, maybe you can explain a little bit on the back referencing again. I didn't really get what it's about. And for the attachment, I was also not fully understanding if you were keen on inline attachments which have a representation already in the HTML or if it was about something else here.
Phillip Hallam-Baker: Yeah, so the back reference first. So, the back reference would be like this chunk of quote is a quote of this chunk of content from this message. So, you know, that allows the client to be able to, you know, not render that part of the original message or inline the reply into the display of the other message or, you know, do whatever interesting stuff it wants to do. For the attachments, yeah, I think I need to do more thinking about it. It's just it came up as I was writing these slides because I realized there's text content but not attachments that are addressed as part of this. So, I think I think probably I need to do more thinking about exactly what I want to do, what issues if any there are with attachments. Yeah.
Hans-Jörg Happel: All right. So, if if it's okay to comment shortly. Um so for the back reference, yes okay I understand so it's about making it more explicit because right now it's more or less the thing you are quoting, there is the assumption it is what you quote but you would enable something where people could really identify this is actually the quoted part. Okay, I got that one. Um so for the attachments, what I was what was coming to my mind immediately was somehow the point that, you know, sometimes there is a MUA which tells people "Hey you forgot to include the attachment" or something, or the other way around, or if you think about that, sometimes people explicitly mention the attachment like "There is this PDF attached" or something like that. Um or, you know, so that might be maybe something where it might be helpful to have a direct relationship in some cases. So, you can have something like a hovering or something like that. And that again brings us to some of the things in the core draft as well. So, I think one thing that is a little bit related to this here is this thing I added I think last time in the core draft about the structured email signature. Um because in a way the email signature is also something you already have in the HTML part most of the time and something that is also, you know, messing up quoting. Um so it might make sense. The way we put it into the core draft so far was a little bit initial because it was mainly for legal reasons for cases in which people need to make sure that there is a machine-readable version of the legal responsible person. But I see there might be some other use case here as well for a MUA that does the structure quoting thing. So, it's probably worth mentioning worth thinking about that as well. And the third thing which again is a little bit related to both attachments and this one is what this mentions feature—I'm not sure if that is a feature also in Apple Mail, I know it I think from Outlook where you have this @mentions of certain people somehow. Um so that I'm also need to make up my mind if it's if it's helpful or I mean right now I think the only convention is as soon as there is an HREF link with an @ symbol referencing somehow an email address or a person name from the recipients that that you are referring to that person. Um but I'm not sure if that is if that could benefit also from, you know, some structured data within the annotations. Thanks.
Phillip Hallam-Baker: Yeah, that's all really interesting. So, I guess I understand your question about attachments better. I think I was thinking more about inline attachments, but I think what you brought up about referencing attachments in the text also makes sense. Yeah, some of the other things you brought up, I definitely see how they're very similar to structured quoted content, but they're also slightly different. I'm not sure if they would be better in the core draft or if we can incorporate those and this together into some draft. Yeah, something to think about.
Arnt Gulbrandsen: Arnt as participant. I also don't really understand the attachments issue. It seems to me that if a mail composer replies and quotes then any attachments from the original message that are included necessarily will have a CID colon link. I can't imagine a reply function that includes attachments automatically without having reason to include a CID link. So what is the attachment issue?
Phillip Hallam-Baker: Yeah, I think the attachment issue is that I need to do more homework on how attachments are being included in forwarded and replied messages and if whether or not there is any issue or whether yeah they're always CID links that would already be covered by the text content. So perhaps nothing, I mean perhaps, you know, what Hans-Jörg was talking about earlier, which is a little bit different than what I was thinking but yeah just more thinking that I should do here.
Alexey Melnikov: Yeah, can I insert myself back quickly. I think some clients insert names of attachments like so you can see that there was this like PDF with this name. Again, not making judgment whether it's a good idea or not, but it's kind of an existing feature. So, yeah, maybe think about what what we want for this and then we'll figure it out.
Speaker 4: Hey Phillip, I had a question about your open question with plain text. Um if if it's a question mark, aren't you back to having the composer dictate to the client, to the recipient, of what they can see and what they can't see, and would you see this if you did have plain text, would this be an alternate, some sort of MIME alternate? Um or maybe I misunderstood what you're meaning by plain text.
Phillip Hallam-Baker: Yeah, so for a plain text message, you know, many clients are already massaging that into HTML for display, right? So so from the display perspective there's really no it's kind of an implementation detail that's hidden from the user whether the the message was transmitted in plain text or HTML, right? So ideally even if the message was transmitted in only plain text, it would be nice if it could benefit from this as well. So instead of seeing just plain text right-angle brackets, you know, we could still upgrade that to to, you know, the same consistent style.
Speaker 4: I was I was meaning from the other direction. So you have something that's coming out structured but you still want readers that understand plain text to be able to to render that.
Phillip Hallam-Baker: Yeah, yeah I think I guess that's not explicitly stated here but one of the goals would be anything that you send out received by a client that doesn't understand structured email should still be presented, you know, how it is today. So yeah.
Speaker 4: Got it. Okay, thank you.
Alexey Melnikov: Um on two other points of the discussion. So there is this question of the separate JSON-LD part or the embedded in HTML, and I think we had some offline discussion already about that because it touches also the point of, you know, how will legacy clients render the JSON-LD which they don't understand here. So yeah, my point somehow is of course that ideally that would be something we deal with in the core draft anyway, and and we should probably be consistent with the core draft here and not do something again different. I don't think that probably might make too much sense and it might also make clients, you know, take precautions in order to deal with those unknown body parts. Which again is something maybe for the group I proposed earlier, I think other people like Michael at a former meeting, Michael Richardson, were also thinking about that it might be worthwhile to have a totally separate draft which also is a non-SML draft probably but a mail-main draft rather about having a marker or a header of a body part saying that this is a body part that MUAs might probably hide. So yeah, that as a comment to this part. And then I have an additional question somehow and the question, Phillip, would be a little bit in terms of how would this evolve in the wild. So assuming that not every client would support this immediately, is the most benefit you would expect here for let's say an let's say Apple Mail would implement that. Would you say this is mainly use for let's say an Apple Mail only environment where is in a thread there is only Apple Mail users discussing, or would there be also a benefit let's say even for Apple Mail if there is just in the thread one person or one client not obeying to this, would would there already be something the Apple Mail client at the end for the final reader would make improvements out of it? That was not fully clear for me you know where the sweet spots are here in the evolvement of this.
Phillip Hallam-Baker: Yeah, I think it's a question of backwards compatibility or or adoption. It's kind of addressed in the the draft but maybe not written as clearly as it could be and probably could use some examples. But I think in general you can assume that the clients so in a mixed in in in a message with many layers of quoting it's kind of contiguous from the most from the topmost level of quoting backwards for which clients could support it, right? So like basically if if there's some conversation happening between, you know, Gmail and Outlook and they both have not adopted it and then one Apple user then forwards it to another Apple user, then the the most the topmost level of quoting would be from from Apple User 1 to Apple User 2. So that layer of quoting can still benefit from, you know, localization and whatever, and then just the quoted Gmail and Outlook content that Apple User 1 sent to Apple User 2 would still just be rendered, you know, how it is. So they wouldn't benefit. But as, you know, more more clients adopt, you know, this kind of contiguous chain will stretch back further in time and you get more and more layers that that start to benefit, if that makes sense.
Arnt Gulbrandsen: Hans-Jörg, note that this is actually invisible. Generating it causes no rendering harm.
Alexey Melnikov: Well, I will just clarify this. We would we need to design it so it's invisible right, you know. The idea is yeah, it just becomes invisible for clients that don't recognize it. Yeah. It's like optional attributes and in various places etc. etc. etc.
Phillip Hallam-Baker: Which I believe is kind of the goal of structured email in general, not not specific to this draft, right?
Alexey Melnikov: Right. Yes. I don't think we have lots of participants, so I kind of would like to have some indication maybe in the room and in the remote room who thinks that we should work on this. Can I have some show of hands? Okay, so we have—how how do I count you guys from Apple? Okay. Okay, right. Shall let's do show of hands. I'll just list so 1, 2, 3, 4, 5. Okay. 6. Yeah, so I suppose not bad. Hans-Jörg plus one. Okay. Obviously we need to bring this to the mailing list and have official discussion. People should also hopefully read the notes and view the recording. Um can I suggest, I think one thing that was would be very helpful, maybe you post one revision and add some examples. Yeah, I think that's a good idea. An example of I mean seeing an example of messages is helpful, but maybe have an example of JSON-LD even if it's not ideal how it will represent like one level of reply or two levels of reply. Yeah. And then I think after you do this, we can start adoption call, I would think. Yeah. Great. Okay, so my co-chair agrees with that, so let's do that. Thank you very much, that was great. Um any other topics? Hans-Jörg, do you want to talk about anything? You don't have to, you don't want to. Okay, he said nope. Okay, fair enough. See you then. Yeah, thank you for coming and see you next time and I'm chairs are hoping that we'll be more organized and we'll do a bit more progress till next time but that means you, Hans-Jörg. Okay, thank you all. We're done. Eventually you're using a different tool. How did you get to the different tool? It's a it's a a video link from the meeting page, if you go to Datatracker. Okay. Video link, Jabber, video stream. Video stream, yes. Video stream means full Meetecho. Full full Meetecho? Full Meetecho is this one. Is there another one? It's the same, so I copy Datatracker slides presentation. Oh, so you get in from the chair. Okay. Yeah. No, so just on Datatracker, you go up to meeting page, yeah, and and there is video stream link on the top right. Video stream. Video stream. Oh, there it is. Video stream. Video stream. That's for the recording. Video stream for the people. Ah, this is the what I'm—okay, so I thought it's the I saw on Jabber it's something. No, the Jabber is linked directly in here as well. Oh, oh, yeah. Okay. Because Hans-Jörg mentioned that he cannot unmute. He's probably in the Jabber only tool. Ah, because Hans-Jörg. Jabber. He's here now. He just posted. I see. Hans-Jörg is here. Okay, no, because he—okay. No, okay, he's in. He's in the Jabber Jabber Jabber. He's here. I'm just looking at the wrong tool here. No, no. Oh, wait. He's in—so he is listed in the participants, but he has no mic. No microphone, yeah. Okay. No microphone. He only had Jabber. Okay, okay, okay, yeah. Okay, so he was in. Yeah. Because I think in the other tool you can. No, so this is the mobile client version. This is the light light Meetecho. Yeah. Yeah, okay. The light one doesn't have it. Okay, okay. Good to know. Okay. No, I just wanted to tell him so he can go back for next time. If he clicks on the video stream button on Datatracker, then he gets this full client version. Perfect. Thank you for telling me. Okay. So, I need to get home and. Yeah. See you then. Bye. Goodbye.