Session Date/Time: 20 Jul 2026 09:30
[00:00:05] Arndt Rogge: Which
[00:00:06] Alexey Melnikov: how are you meeting her?
[00:00:08] Hans-Jörg Happel: No. Friends we made.
[00:00:11] Arndt Rogge: It's today? Yep. Shit.
[00:00:15] Hans-Jörg Happel: Well, shit happens. I know. Anyway
[00:00:19] Philip: I just I saw my sweet files.
[00:00:23] Arndt Rogge: But at least I think it's today.
[00:00:26] Alexey Melnikov: Yes. I was like, I
[00:00:27] Hans-Jörg Happel: miss it. That was the thing Then
[00:00:32] Arndt Rogge: bringing a higher up here is a very good sign in. No. I just googled the
[00:00:44] Alexey Melnikov: unknown names on the
[00:00:45] Hans-Jörg Happel: at least. Cool.
[00:01:29] Arndt Rogge: Cool. Let me find should I watch the chat, or do you want?
[00:01:40] Hans-Jörg Happel: Stop talking and saying, you know, welcome to SML.
[00:01:44] Alexey Melnikov: I I think it's live.
[00:01:46] Arndt Rogge: Welcome to SML. You can stop talking now because I'm talking. I'm Arndt. This is Alexey. We have chairs and notes. We also have only one hour, so we have to be a little bit more efficient this time than usually. I trust that all of you have read Note well. The really short version is that you need to behave well. You all do behave well, I'm sure. Lexi? Treat colleagues with respect. Speak slowly, slower than I do. Use reasoned arguments and engineering judgment, and remember that we're here for the whole Internet, not for your company. The session is being recorded. One moment. And we need a oh, the session is being recorded, and you will please sign in to MeetEco or something like that on-site or off-site too. And we need a notetaker. I see Ben is hiding. Any other volunteers? Difficult. Oh, that's doing that on the phone is a problem. The people on the laptops are looking very conspicuously into the laptop.
[00:03:40] Alexey Melnikov: Right. Oh, thank
[00:03:41] Arndt Rogge: you. Lisa, you're my best friend.
[00:03:45] Hans-Jörg Happel: Let's do my session.
[00:03:50] Alexey Melnikov: Cool.
[00:03:57] Arndt Rogge: We assigned twenty minutes to the core draft, twenty more minutes to structured quoting. After that, ten minutes to trust and security considerations. Any other business? Any changes wanted? Okay. The times are slightly approximate, we simply guessed. In that case, start on the core drafts.
[00:04:39] Alexey Melnikov: You want to click or do you want me to
[00:04:45] Hans-Jörg Happel: It's here. No? Ah, much better.
[00:05:15] Alexey Melnikov: Don't know where do we Maybe you can talk. Okay. Okay. Alright.
[00:05:23] Hans-Jörg Happel: Welcome everybody to Vienna. First working group session on a Monday. Yeah. Welcome to sml as well. We will talk about the core draft. I think, yeah, the open issues in the core draft are getting less and less, and we will discuss some of them today. Next slide, please. Okay. Yeah. So just as a sentence, a core draft is a core draft for SML, and upon which other SML work builds upon or, like, the trust draft connects to. Think next slide. This is just as an informational thing. So what changed since the last version of the draft? If you look at the document, there were some refactorings in section four, which are mainly to give the text a little bit of a better structure for understanding. But there is still some issues in section four, which we will come to in the next slide. There's also some clarification in section six, which we will discuss about, and there a number of editorial changes, I think, which we won't get too deep into. Next slide, please. Alright. One thing beyond all these existing changes is so I keep rereading the draft by myself once in a while, especially when updating it. And I had the feeling now on on on the train ride here, checking it, that yeah. Reading the first one or two paragraphs, especially the introduction, there was still something missing probably for somebody not involved in that working group. So I plan to add one more sentence probably which explains a little bit what's the scope of the draft and SMS in that sense. But my question to the group is as well, please probably provide some feedback on that because it would probably be helpful if that impression, which I have, is an impression others also do have. And, yeah, we wanna produce a good document for also people that were not involved in all the discussion here. And, yeah, so the big picture, not not the details only, also understanding how things fit together, and if if the document is clear, it would be helpful. Next slide, please. Alright, so getting into section four. Section four is about structured data within email messages, so how is it positioned, and so on. I already said there is a small refactoring in terms of stuff that was mixed into a session called placement was now now placed in a section called content types. So I welcome feedback on if you read it, if that makes sense. So in my opinion, it makes it more readable and more understandable. But, yeah, I'm open to to feedback here. There's one thing, and that's probably one of the discussions we will have now here in the session, because I received some feedback about that. So there is legacy precedent for people sending structured data in email already, so you might receive structured data by some senders, and this is embedded into the HTML email part of the message. And earlier in this working group in the past, there was a discussion if we want to continue this practice within the spec, in parts because it's a little bit misusing the HTML body part and stuffing in structured data within that, or if we rather wanna recommend clean separate body parts for that. And the decision so far, I think which was mainly taken at the Vancouver meeting, was to go for the more clearer part, separating it into body parts. But now recently, there was some feedback I received from people starting to implement certain of the SML drafts that, yeah, it might at least, in some cases, be more appropriate to still use the, you know, the HTML version part. So what so far in the document is that for reading, yeah, it is it says that MUAS may consider that there is this legacy structured data, but it's not recommended for writing. And so maybe the question to the group is a little bit if this should be sustained or if we should rediscuss. So I see there is a little bit of a risk because that was a fundamental thing we discussed quite a while in the beginning of the working group, so that made me first hesitant in re raising that issue. On the other hand, now that people start implementing it and have real world experience, of course, it's also a worthwhile exercise and feedback here. So, yeah, that's a little bit of a question.
[00:10:19] Alexey Melnikov: Sorry. I put myself in the queue, so pretend I'm not a chair for this. If this is efficiently documented, so, like, if you say I may may implement legacy, as long as it's clear what you're actually asking in the sense of maybe you need to put more details. You may implement legacy processing in text HTML by reading the script tag and with corresponding JSON LD. Legacy can mean lots of different things
[00:10:58] Hans-Jörg Happel: Right.
[00:10:59] Alexey Melnikov: If you be more specific about Right.
[00:11:02] Hans-Jörg Happel: Okay.
[00:11:02] Alexey Melnikov: And if you cannot be more specific, as in there are lots of different legacy things which are incompatible, then I would rather not have the requirements because it's unimplementable then.
[00:11:14] Hans-Jörg Happel: There's there's one very specific way which is Okay. Putting it into the HTML body part script tag.
[00:11:20] Alexey Melnikov: Yeah. I think the document doesn't It might it might not say script tag. You know? Maybe it's obvious, but, you know okay.
[00:11:33] Hans-Jörg Happel: So, anyhow, the the question is a little bit so I heard from people feedbacks that this, you know, might might be something that we should discuss. So the question is now, do we do it now or do we later in Philip's draft? So I'm fine. Do it now. Yeah. So.
[00:11:52] Arndt Rogge: I'll check. Arndt, as a participant, I know this disagrees with what I've said before, but I've tried implementing this in several clients now. And in some code bases, it seems to be easier to send stuff as HTML comment, and in some, as a separate mime part. And even though I don't like it, I almost feel that allowing both makes most sense. Very sad to say that. In principle, I much prefer that we choose one thing and stick to it. Just one thing to test, just one thing to implement. However, making it easy for legacy code to add is also significance? Sorry.
[00:12:57] Alexey Melnikov: Philip?
[00:13:03] Philip: Hello? Okay. Philip. So, yeah, I think I think I I maybe was one of the voices arguing to have this have structured data in a separate MIME part. But I think, you know, since we've had more implementation and really thought about the different use cases, I think my opinion is shifting towards it really varies by the use cases, and I think specifically the difference between machine readable messages versus more, like, partial representation cases. So I think for a machine readable message, it really makes sense as a separate MIME part because you're probably not going to want to MUAs aren't gonna want to waste the bandwidth downloading unnecessary MIME parts and etcetera. But for cases where it's more of a partial representation where you're gonna need the text HTML part anyway to display along with the structured data, I think that really changes the calculus there. Those two parts are really tightly coupled semantically, you know, then then embedding the the structured data within the HTML, I think, makes more sense as well. And I think the the in my mind at least, that's a slightly different question from legacy structured data. Like, even if we decide to to move forward with having partial representation embedded in HTML, it doesn't necessarily mean we have to go with, you know, what's out there today. And, also, what's out there today is not doesn't necessarily always correspond to the partial use cases. Right? And and legacy, I think, to to Alexei's point, carries a lot of other baggage about, you know, how things are being done. So, like, whether to embed things in the HTML or not is is a small subpart that kind of overlaps with, you know, legacy use cases, but is also Mhmm. A separate enough question that I think they should be addressed separately.
[00:15:08] Hans-Jörg Happel: So a very short comment. Maybe just wait. So I would say from the emails I've seen or from the practice of what's called legacy, what is sent around right now, I would say this, by default, is partial all the time because it's just not considered in a way. Yeah, that's how I would interpret it. On the question of how to if to follow that or how do it differently within the HTML, I mean, the question is a little bit, wouldn't it even confuse people more to invent just another way. Right? Sure.
[00:15:38] Philip: Yeah. I'm I'm just saying that that's an option. I'm not suggesting that we really need to just you know, if if we're gonna explore how we want to embed it in the HTML, we don't necessarily need to constrain ourselves to how it's done today. You know, maybe that is still the best way for for practical reasons as well. Okay.
[00:15:55] Hans-Jörg Happel: Yeah. Other than that, I agree also with what you said about machine readable messages as a whole. Message is machine readable to, in that case, insist on doing it in a
[00:16:06] Neil Jenkins: body parts.
[00:16:07] Hans-Jörg Happel: Seems that makes sense. You
[00:16:15] Alexey Melnikov: couldn't add add yourself to the list?
[00:16:17] Ben Bucksch: I can't I can't because I cannot log in. Sorry.
[00:16:20] Alexey Melnikov: Okay. Alright. Go on, Ben.
[00:16:22] Ben Bucksch: This is Ben Books from Parula. So I was one of the ones who argued very strongly for partial representation to be a MIME part. However, I would make a distinction, for example, for cases like structured quotes, because that is fundamentally a different use case. I saw partial representation as something where the machine can make sense of this information completely independent from the text and the body. It makes sense standing on its own. Like, for example, I'm sending a song to you, and the song makes sense on its own without looking anyhow at the message. So I can make sense of this information on its own. This is machine readable for me. I can act on this. But it's still partial representation because there might be other information in the email that we still need to render because there might be text saying, hey, I have this cool song. Love it very much because the drums are so great, whatever. And I cannot just completely ignore that. So that's why partial presentation. The case for structured quotes is different because this information makes absolutely no sense whatsoever without the HTML. So it's inherently about the content in there, and it's just augmenting that. So I feel like this is actually a new class of things, which is neither full nor partial nor independent, but it's a new thing, a fourth thing, which is about the HTML itself or the content in the HTML. So in this particular case, I think it really belongs inside the HTML because for me it looks more like I would actually take this if we didn't have SML, I would just use micro formats and put this in HTML attributes and put the information in there. So basically what we're doing here is just a more rich form of data that we would normally put in the attributes. It's just more content, more objects, but it's still the same thing you would put in HTML attributes. And as a matter of fact, for example, Thunderbird has been doing this Netscape email since the nineties, and that we have blog code site, and it has a CID in there, in this property, which is exactly what we're putting in here now in the SML. So why would this be a different MIND part now when we've been doing this in thirty years, being doing this in an HTML property? So I feel like what we're doing is just a richer thing, and it actually belongs in an HTML property. Structurally, historically, there's historic precedence for that. We know this works because we've never had any problems with that. And this particular case is even more important because we would lose information. If we put it in a different line part and some other email client replies to it, we would lose that information.
[00:19:27] Hans-Jörg Happel: Okay. Thanks for the point. I agree with you in terms of what is the nature of the knowledge which is encoded here. It's, I think, a little bit of a philosophical, ontological question, right? Because it's about the structure of the message, But still, I think to to a certain extent, I think that's probably irrelevant from a technical perspective of implementing it. And what was not clear for me was your conclusion here in the end. I mean, I understand you say it's more appropriate for, like, structure quoted content to put it into HTML, but would you say we should really do a special case for that, or we should also allow partial representation for other things within the message within the HTML body part?
[00:20:10] Ben Bucksch: Basically, what I'm proposing is that in addition to the no representation, full representation, partial representation, have fourth class, which is information about the message content, which is augmenting the message content, where we're saying this is a case where we put it directly in the HTML. And what I would propose is to make an HTML attribute and put the LD directly in the HTML attribute that is very easy to parse. I don't have to hunt for script tags or anything. I'm parsing the email anyway, the HTML, and because I'm interpreting this information, so I have this information right here. It's from an implementation perspective much easier than having the reading HTML attribute than having to hunt it in a MIND part, and then matching IDs. And the most important reason, which really for me completely swings it from the implementation perspective, is that Apple Mail augments, makes a quote, augments the quote information. And then Outlook goes and quotes that and sends it back. And then Apple Mail goes and quotes. And the two, Outlook and Apple Mail, go between themselves. So Outlook is probably going to lose the MIME part, but is probably going to quote the HTML verbatim and is going to keep the HTML attributes. They're unlikely to strip the attributes. I can say that because we have implementation experience on that. So the HTML attribute is very likely to survive. The tag is very almost certain to not survive because I'm going to strip that. And the MIND part also is very unlikely to survive. So the HTML attribute is the only thing that's going to So
[00:21:58] Hans-Jörg Happel: I think, I mean, I have no hard opinion on that, but I think you could run the counterargument that, of course, if you scatter the structured information across the HTML part, I mean, it might even there's a higher risk of it breaks in that sense. It might be less easy to manage. But probably on on a media level, the question is, so I see there is obviously some arguments to reopen that discussion on how to put the structured data inside. I'm not sure, given the one hour time limit here, if we I mean, we could probably continue half an hour now just on that. So it's a question to chairs on
[00:22:35] Alexey Melnikov: Okay. I think we're giving you a little bit more time if you want to discuss this topic. As a high level, if I can try to summarize, there are two separate issues. One is actually feedback on Philip's draft on the quoted text that we might want to revisit how this is generated. And the other one is more philosophical discussion of whether we need the fourth class and what it means because we can still decide to change how structured quoting is done in Philip's draft without necessarily going to too much high level discussions of new class. I mean, yeah, we can do either way.
[00:23:19] Hans-Jörg Happel: The question is, should we rather take it to the list then and continue the because I don't think we have enough time now in the session, otherwise, to cover all the remaining stuff.
[00:23:31] Alexey Melnikov: Probably to the list, unless people have very quick comments now. Just come to the mic then because we want it on the records as opposed to, you know.
[00:23:48] Ben Bucksch: Just one sentence. I think this thing is going to come up in other cases too.
[00:23:52] Alexey Melnikov: Okay. Alright. I think I would like to see other cases as well and then, you know. Okay.
[00:24:03] Hans-Jörg Happel: Okay. My time is already over.
[00:24:05] Alexey Melnikov: Well, we're giving you more time, and we are sacrificing, you know.
[00:24:08] Hans-Jörg Happel: Alright.
[00:24:09] Alexey Melnikov: Okay. Let's keep you open now.
[00:24:12] Hans-Jörg Happel: Alright. In terms Sorry, yeah. So, there was one point. A very small point is currently the draft mentions as a potential different encoding of the JSON LD using COSE standards, like assigned or encrypted versions. That's also partially mentioned in the trust draft, because there is a relationship to that, so answers to do with JSON web signatures. My opinion would make sense to allow this in general. Probably the wording right now in the draft could be a little more of a both, and it should probably be aligned and reference a trust draft in that sense because this is where the trust draft and the core draft in one aspect overlap. But unless it's otherwise controversial, I would continue.
[00:25:06] Arndt Rogge: Go on.
[00:25:06] Hans-Jörg Happel: Or maybe we can later, when we come to the trust presentation, go back to that. There is one minor thing that came to my mind when rereading the draft, which is that in full representation, part of the message which can contain semantic information by the sender, is not part of body parts, it's actually the subject. So I was wondering if it's worthwhile reminding people that if they want to send a full representation message, they should avoid putting information which is not otherwise covered by the structured data in the message in the subject, because some people use subjects to actually write messages sometimes. Yeah. That's basically it.
[00:25:50] Alexey Melnikov: Sorry. Alex, again, as a participant. I feel a bit uneasy about having must not.
[00:25:57] Hans-Jörg Happel: Mhmm.
[00:25:58] Alexey Melnikov: But I think soft attack saying that is just not a good idea. Mhmm. I think subject is still useful in cases, you know, there is a human trying to, you know, look at messages even if they are automated and just trying to make sense of them. Like, it can be, I don't know, appointment sorted by time, and there is a timestamp in the in the subject. I know, you know, you should be using other things like date. But I am just trying to give an example of, you know, you don't want no subject or three dots like you use an encrypted email, you know, just be there because it's not super helpful to distinguish between the messages.
[00:26:40] Hans-Jörg Happel: Just for clarification, so your main point is you disagree a little bit with a must not, but you agree with the underlying topic. Right?
[00:26:47] Alexey Melnikov: Yeah. So I'm Yeah. Basically, encouraging saying people, like, if you can put data into the structured data Mhmm. Try not to put it into try not to have it only in the subject. Right? You know? Or something like that.
[00:27:04] Hans-Jörg Happel: I mean, just to to reassure, I mean, the idea here was really to make people aware that if they wanna design a machine readable message, they should just avoid and and or take care of what they do with the subject and not expect that the human will read it because it's a machine readable message.
[00:27:21] Alexey Melnikov: The wording you said just now is better than what's in the draft right now.
[00:27:28] Hans-Jörg Happel: No,
[00:27:29] Philip: think that.
[00:27:30] Hans-Jörg Happel: Okay, fine. Yeah, I think also it's probably controversial. Okay, next slide, please. Alright, I think that's the second thing we probably can shortly discuss, because in part, was on the list. So, this is about the relationship about an HTML body part and the structured data in a partial representation case. And the question is a little bit on, in to what sense one want to get get give hints to clients that render the HTML on how they may interrelate the structured data with HTML. So there is a property which is already in the draft since a while, which is basically the data ID, which helps you to put on an HTML element within the HTML email a link referencing concept in the structured data. For instance, you have Vienna, a picture about Vienna or something like that, and you can link it to the Vienna concept in the structured data so the client can then understand, uh-huh, okay, this is basically tying this together and can probably make a pop up or whatever kind of thing or allow contextual actions based on that. So that's the idea here. There is a separate or related property we come to on the next slide because it's a little bit more complicated, and there is a third property which in Philip his structured quoted message draft about the data source ID from which body parts it stems. I think this latest part is probably the most controversial, and we can discuss it offline and maybe come up with the proposal, but I want to go to the next slide for the presentation part. So the point here is, again, as I said, there is the HTML body, sorry for the typo, and the structured data, And there's actually two aspects that so far came up in the discussion besides the actual ID of the concept, which might be helpful for a client to understand. And one aspect is basically what is called the level of of the deepness of presentation. The idea here is basically consider, for instance, a newsletter, like the New York Times cooking newsletter. You have recipes inside that, and typically, you have a featured recipe which is totally, extensively displayed in all of its extent, and you might have other recipes which are just URLs or links. Yeah? So it might so the idea here is it might be helpful for the MUA to understand in this reference to the structured data if this is rather a brief representation of the actual data or a detailed one, because you might then choose to provide additional visualization from the structured data a complementary way, because if there's already a detailed presentation of a recipe, you don't need to show a pop up of the whole recipe. You probably just want to have a little action or something like that. That's the idea behind this aspect. Then came Arndt on the mailing list with the question of, if I understood it right, and Arndt, need to correct me. I think you phrased it, suppressing the HTML fallback, which I find a little bit confusing because fallback can be considered as a multi part alternative language as well, but I understand your idea was to allow or suggest a client to not even render a certain HTML element and instead do whatever the client thinks about rendering something by itself from structured data, which might be HTML itself, of course, but basically modifying or directly inter directly dealing with the HTML document. Did I get that right?
[00:31:09] Arndt Rogge: Quite right.
[00:31:11] Hans-Jörg Happel: Okay. And so my suggestion is, if I got that right, I thought about that, how it so it certainly relates a little bit to that previous aspect I was talking about, but I think, actually, I would argue it's orthogonal, because it's two different things. One is deepness of the presentation, and the other one is, I would coin it, allow replace, probably, or something like that. That would be my suggestion for this. But, yeah, that's open for discussion. If you're happy with it, just thumbs up, and we can go on.
[00:31:43] Arndt Rogge: Arndt as Thumbs
[00:31:44] Hans-Jörg Happel: up there, actually.
[00:31:45] Alexey Melnikov: Okay.
[00:31:48] Hans-Jörg Happel: So thumbs up there. Would just want to understand.
[00:31:50] Arndt Rogge: Right. Arndt as a as a participant, I think that data load replace solves the problems that I had with SML. It does not solve the same problem with calendar invitations, come from, Office March with a long HTML implement invitation and the same thing as an ICS thing. But that's not our problem. Alright. So fine. Hello. Replace makes
[00:32:23] Alexey Melnikov: sense. Philip.
[00:32:28] Philip: I guess when I was reading the core draft, I just kind of assumed that replacement is what you would do if, you know, an HTML part had a structured data alternative. Like, I'm curious what use cases do you imagine where you wouldn't want to allow replacement? Like, when would you have structured data that represents some part of the HTML, but you still also want to display the original HTML?
[00:32:55] Hans-Jörg Happel: So I'm probably not even the one answering that can best answer that, because I'm not necessarily a client developer. I could imagine from from theory that if if I'm a designer of an HTML newsletter, for instance, right, I might make preparations for if, If I consciously add structured data to it, for a client that is capable of it, I might even do preparations in terms of the layout or something like that, which are specifically designed for that. So I think in that case, I would say I definitely allow it, and give the client a hint, okay, this is really designed to be replaced, whereas in other cases, it's totally up to the client on how to do it. But I agree, it's probably not yet perfect here. We might come up with some examples, But I think the underlying general idea is is clear, probably, and we will come up with something. Okay. I think we are anyway already done. The next slide we can skip, because it was just an example. And then I think
[00:33:56] Alexey Melnikov: I will give you five more minutes.
[00:33:58] Hans-Jörg Happel: Oh, but I oh, Neil Jenkins is on the queue.
[00:34:02] Alexey Melnikov: If you don't use it, you know. Yeah. Are subtracting it from the trust, not from
[00:34:07] Hans-Jörg Happel: We have Neil on the queue, Isaac. I don't know. Neil?
[00:34:13] Neil Jenkins: Oh, yeah. Hey. Sorry. I just want to clarify. Is the idea here that you could tell it to replace a bit of the HTML with other HTML that the clients rendered based on the structure representation? Was that the
[00:34:29] Hans-Jörg Happel: have I Yes. I think so. Yeah. I mean, technically, it could probably also be an image or something. Right? No? Okay.
[00:34:37] Neil Jenkins: I think that's unlikely to ever happen. Like, you've got all sorts of security issues when you're trying to, like, inject stuff inside the HTML. If it was you can display this part and then the HTML part. So that's so just go back to the calendar example, which we already have. So an iCalendar part can be a multipart alternative, in which case, generally, you render it just as the whole content, and the HTML is kind of completely hidden, and that's the normal case for most, like, invitations from calendars, that kind of thing. Or it can just be an attachment that's not part of a multipart alternative. It can be multipart related, and you get that when someone's sending you, like like, an email that has real information in it that may not be in the iCalendar, they're but attaching that in case you wanna add it to your calendar as well. And that's common for bookings and things like that. But in that case, I would display, you know, the calendar information first and then the HTML, but I'm not trying to inject it inside the HTML, if that makes sense. But maybe I'm misunderstanding what you're suggesting here.
[00:35:40] Hans-Jörg Happel: I mean, maybe I misunderstood what aren't initially intended, but maybe Ben can clarify.
[00:35:46] Ben Bucksch: Ben Bux, Parula. To answer Neil's question, I think that's implementation specific. Like, the client can do whatever makes sense for the client. In some cases, I might be replacing parts of the message with my own content, but then I pay attention for the security because I have certain links that can only do certain things, and I'm I'm paying attention for that. Or I have some way to inject some secure HTML secure part into this message. There's ways to do that when I leave space and put an iframe on top of it. There's ways to do that. Or I put it on the site, or I'm not even doing this in any way. Maybe I do it natively in HFL mail. I think this is non
[00:36:29] Daniel Kahn Gillmor (DKG): It's a
[00:36:29] Hans-Jörg Happel: wrap question
[00:36:30] Arndt Rogge: of this.
[00:36:30] Neil Jenkins: The the
[00:36:30] Ben Bucksch: the mail client has a freedom to do what it wants to do, and that's, I think, the whole point here that that the mail client has the freedom to render. And and there might there might be rich things which is tightly integrated with my application or it might not. We don't know.
[00:36:47] Neil Jenkins: I think we Any comment on that would be being wary of too much flexibility tends to lead to less interoperability. Anyway, okay.
[00:36:55] Alexey Melnikov: Yeah. I think we need to take it to the mailing list. And I think maybe, sorry, last comment on this. If the client wants to force display and non display, should use existing mechanism like multipart alternative and multipart mixed. But, you know, we can also discuss the HTML injection replacement and security implications of this. I think we need to think a bit more about this.
[00:37:24] Hans-Jörg Happel: Okay. Next slide, please. Two slides further. Alright. This is, I think, the last slide, and it's also very short, so that was based on a discussion we had after the last meeting, and it's basically So there is a notion of a fully machine readable message, MRM, which is supposed to be a message flag which an incoming SMTP might apply to a message, which was determined to be fully containing machine readable information. And so far, it was distinct from the flag has structured data, which is another flag which an incoming SMTP might apply if there's any structured data inside irrespective of machine readable message. So as I said, this this was distinct so far, and that was found to be confusing because also in the MRM case, it is supposed to have structured data, so the suggestion now is to basically have subsumed like structure have structured data in both cases and only apply the MRM flag in the second case. K. So it might be a little bit sound complicated, but I think it makes it easier to understand the draft or to apply it.
[00:38:36] Philip: Philip? Philip. Yeah. I I think having these as separate flags makes sense to me, but another slightly separate question, I guess. The MRM flag so so as an IMAP flag, I guess that would not be applied that would be applied by the mail provider, right, not the sender. So so the sender has no way to kind of signal that this message is meant to be a machine readable message?
[00:39:04] Hans-Jörg Happel: I mean, there there was a discussion we had very early in the working groups that there could be a header for that. But there was some discussion about, does it make sense? Isn't that something just the receiver should decide upon? And probably not the client, but usually, there is a similar thing with test attachment, which I think is a parallel draft in Mailman right now. So this is typically decided by the incoming SMTP. So yeah.
[00:39:31] Philip: Yeah. I I think especially now with with the, like, the the header that you mentioned in the core draft for for legal reasons and stuff, the the MIME structure of a so like a full representation of part of the MIME I think it's becoming increasingly harder to determine what is a machine readable message versus not, so I think it's more valuable now for the sender to signal that in a header that, hey, even though this has a really complicated MIME structure, it's intended to to be a machine readable message, so you should, you know, just look at, you know, maybe the various two or three, you know, structured email parts and and and ignore all the other parts or something.
[00:40:11] Hans-Jörg Happel: So would you suggest that in addition to the flag or in replacement?
[00:40:18] Philip: I I think at least you would want the header. The maybe in addition. I can imagine an IMAP flag being useful as well. But a separate comment. So for the header, think it would be useful for a header to be able to represent to signal whether it's a machine readable message or not. But in addition to that, I think that may not even be enough for the MUA to make a useful decision. Because even if I know that it's a machine readable message, you know, the content carried in the machine readable representation may or may not be something I understand. Right? So, like, there's various use cases for what kinds of messages you might want to display here. And as a MUA, maybe I can only interpret, you know, certain subsets of of these machine readable messages. So I think I guess I'm saying it it would be helpful to have a header that says this is a machine readable message plus this is, you know, like a one time code or or this is a vacation notice or or something like that. And, you know, maybe within AYANA registry for various valid types. Mhmm. And so so then I know, you know, which subtype I'm expecting.
[00:41:33] Alexey Melnikov: I I think you're volunteering to at least write some text to the mailing list and propose a header.
[00:41:39] Philip: I can do that.
[00:41:41] Alexey Melnikov: Yeah. And then there might be some existing header we can plug this into. But if you send it to the mailing list, then we can respond and and figure this out. Sounds like a plan? So I think we have decided about the flags. Probably, I'm almost feeling that we're dropping MRM, but maybe not. And and then we'll have a discussion with the head of field first, and then we'll kind of wrap it up after that.
[00:42:10] Hans-Jörg Happel: Okay. Alright. That brings us DKG? Sorry?
[00:42:18] Daniel Kahn Gillmor (DKG): Hi there. Yeah. I I just wanted to ask for the flags. I think that I think the way to think about what we should do with the flags is to think what is a reasonable client gonna actually do with those flags. Like, if the client is gonna look for messages that have structured data but are not machine readable messages, not fully machine readable messages, do they have to search for you know, has this tag and doesn't have this other tag? I think I think just approaching it from the client's perspective of what they're gonna actually do with those tags is more important than do we have a do we have a clear, like, a a clear ontology for it.
[00:43:03] Hans-Jörg Happel: Should I comment now on this?
[00:43:04] Alexey Melnikov: You can comment. I can also comment.
[00:43:07] Hans-Jörg Happel: No. Two two ideas why that was put in DKG. So one thing was, if it's not an end user client, but probably something like SIF rules also processing it, so for a SIF rule processing stack, that might be an important signal. But even for end user clients, similar to the HAS attachment, it might be interesting, for instance, for a message list or something like that. You might wanna not show the fully machine readable message there for some reason or stuff like that. So these might be the use cases for it.
[00:43:39] Alexey Melnikov: Yeah. So, basically, you can use it to display and not display or what, you know, icon you display. The other thing, a lot of times, some of the flags are used as an optimization. As in, you calculate something already from the message and you mark this the flag and then you don't need to calculate it again,
[00:44:01] Hans-Jörg Happel: Hey. With Derek? Yep.
[00:44:07] Alexey Melnikov: Okay. Good.
[00:44:16] Arndt Rogge: Cool.
[00:44:18] Philip: Okay. I'm Philip. Here to talk about structured quoted content.
[00:44:27] Ben Bucksch: Next slide.
[00:44:28] Philip: So, yeah, quick summary. It's basically a way to to annotate the quoted content in replies and forwards so can do something intelligent with that.
[00:44:41] Alexey Melnikov: Next slide.
[00:44:42] Ben Bucksch: Yep.
[00:44:45] Philip: So the update since the last IETF, it's been adopted by the working group. New coauthors. Very excited for you guys to to contribute your expertise. Thank you so much. And for the draft itself, the the main changes are we had a discussion about whether we're interested in doing this for plain text as well. And it seemed like the consensus was that anyone interested in this probably is not someone who's writing a MUA that only supports plain text. So I think we can drop that and simplify this a little. One thing that was missing was being able to represent the preamble attached to the forwarding, so like the begin forwarded content that a lot of clients tend to add. And there was a lot of interest in having examples because it was kind of hard to follow without examples. So I have added a few of those. Next slide. So yeah, the forward preamble is pretty straightforward. It's just a new property that you can add to the quoted content. And, yeah, not not much more than that. Next slide. So I added three examples, which hopefully capture most of the use cases. So, like, a simple example of someone forwarding a message and then somebody else replying to that. One where there's a inline comment inserted in in a reply chain with, like, two levels of comments. And one where you're that there's some quotes that have happened before any clients that have adopted structured content structured quoting have replied. So basically, just to illustrate that, you know, any quoting done by previous clients that don't support it would just be part of the text content of the innermost quoted message. Next slide. There was also at the last session in the open questions section, I had a a thing about, like, do we need to think about attachments? And I think the answer to that is mostly no. I think it was also a little bit unclear what I was talking about. So mainly I was talking about some client support showing attachments, mostly image attachments in line, interspersed with the text. And for Apple clients at least, I'm not sure if other clients do that. It was done in a way where it was also interspersed MIME parts in a multi part related of, like, text and and image or or other attachment parts. So I think now that we've dropped the plain text support, we don't need to worry about that part. And the other way this is typically done is in the HTML with image tags that reference other MIME parts. And I think just treating that as part of the text content is fine. Although maybe the text content should be renamed. But yeah, I think there is no nothing else structurally that we really need to do for that. Next slide. So open issues, next steps. The other thing that I think would still be really interesting and useful to have is a way to reference which part of the original message was quoted. So, like, as a moo, if you have, you know, the original message from Alice and then you have Bob's reply to Alice that quotes, you know, certain portions of Alice's message. It would be nice to know which specific bits of Alice's message are also represented in Bob's message. So, you know, presentation wise, might want to do something interesting there. The other thing is the vocabulary right now. It kind of uses both schema.org and and the new vocabulary we're proposing specifically for structured email. Not sure if that's the best choice to kind of mix those in the JSON and RDF structure just in general, if anyone wants to take a look at those and make sure it all makes sense. Just in general, more eyes on it, more implementation would be much appreciated. And I think that's pretty much it for me.
[00:50:05] Arndt Rogge: We have me first. This is a document that I've I've implemented the replying part twice and rendering part once, not implemented forwarding. And in one case, it was pretty clear that replying is easier to do with a with h with the JSON LD and HTML comment. And the other, actually, easier to do with the JSON LD in a separate MIME part. Letting people decide there makes letting letting senders do whatever is easiest makes sense to me to get wide deployment. The back reference, I don't really understand how that can be, That's a question.
[00:51:06] Philip: Yeah. I think that that the the back reference bit. I think it would be useful, but I'm also struggling to figure out if there's any feasible way to do that. As as for the other one, I think, yeah, you know, we we had a discussion about that, and we should continue on the list. In general, though, I I would like this draft not to be too much of a special case, so I would like, you know, these kinds of questions to be handled in the core draft. You know, what one of the proposals, I guess, during the previous discussion was that some of the like like, we we we we have some kind of special casing in here which I think is kind of strange because then it's kind of its own thing that's not really any of the use cases mentioned in the core draft which seems a bit odd to me. I'd like, I I yeah. So I think we we should continue on the list and I would lean towards this not really being a special case. And if we need a fourth representation type in the core draft, maybe that's the way to go or yeah.
[00:52:21] Alexey Melnikov: Okay. I started implementing this and it's all very exciting. I will send you a bunch of nits. I think one thing that's small but kind of general comment is description of objects probably need a bit more explanation just or maybe put a short examples there when you describe them for which bits of information, you know, they're being used. I appreciate the irony. It will be probably plain text example of, you know, displaying what how this will appear to the user just to give people idea. The other thing is for email message, I think you're trying to list list of properties that should be available on the list. CC recipient and BCC recipient is not on the list, and then you use cc recipient in the example below. So, also, maybe try to see if you want to have a table to describe all the properties you expect to be allowed. Like and whether it's a closed list, you, you know, you these are the only ones supported because schema.org has tons of other inherited properties, which is, like, I'm not even sure what to do with them. So maybe you say, if you see any others, you ignore them, you know, or or I don't know. Anyway, kind of have a list, see if if it's complete list or not, and say what to do with other stuff if you if you observe it in JSONLG, what do do or not do with it.
[00:54:08] Philip: Yeah. Makes sense. Think yeah. The the two recipients in not mentioning the CCBCC, that was definitely an oversight. I I realized that this morning as well. But, yeah, the other comments, I will do that. Thank you.
[00:54:23] Hans-Jörg Happel: Alright. I'll share a couple. Just some very quick notes. So first, thanks for the presentation. I was I think I already wrote on the list, so I was also thinking about how would I implement that. I think, even though it's probably not the core purpose of the draft, I think in this particular case, it would help to have some suggestions on how a client would use it. Certainly, we won't want to prescribe that, but I think it might help understanding of people that try to implement it to understand actually the underlying logic. At least for me, it would be helpful. To your question about mixing stimulant org with other with custom concepts defined, that's perfectly fine. That's actually the whole idea of structured data, so I think there's no problem in that. One thing that came to my mind when rereading the draft is probably there is this structured signature thing in the defined in the core draft, so this might be something to cross reference or consider because it's also part of quoting sometimes and getting in the way of people and stuff like that.
[00:55:34] Philip: That's great. That all makes sense.
[00:55:40] Ben Bucksch: Ben Bux from Parula. I'm a co author, so I shouldn't be too cheerful, but this is fantastic. This is great. This is useful, for example, whenever you want to have a whole thread displaying at the same time, whether it's a Gmail conversation thread or if you have a chat like view like WhatsApp, you want to cut the quotes. So this is very good to know what I can cut and what I shouldn't cut because some people intersperse quotes and others just make full quotes, so it's good to know what I can cut. It's good for the attribution lines. I hate the Outlook attribution stuff. I can shorten that. This is what you intended, right? This is I like it very lot. A quick answer to this back reference. I don't think there's a reasonable way to do that because it's basically just text the semantic. You don't know. I wanted to ask a question to the ITF guys here because Thunderbird, like maybe Alexei or Arndt can help with this. Thunderbird no, actually, Netscape Mail since the nineties has been doing block quote and then attribute site equals and it has a CID in there. Site equals CID and then a message ID. And they've been doing this since the 90s and I took this over when I wrote the corresponding Thunderbird code. Like twenty five years ago I added this and then it has been super helpful because it shows the difference between a normal block code, which is sometimes intended to be an indention, and if you have block code cite, I'm sure this is a quotation. And this is kind of going halfway what you're trying to accomplish. And then many and there's been no problem with this. This has been working fine, but it's not in the HTML spec. So this is why some clients don't do it, and some people say you must remove it because it's not in the spec. In here, I think it would be very useful to add this in here, but I don't know the relation between I t f and what v g and the v w three c. How do we add this to the HTML spec, this block code side, and maybe other attributes that we need to add? Because we can't use data because data is intended not to be a spec. This is document specific, and we're going on the document specific namespace. So it has to be something else. How how does it work when we need to add an HTML to it? That's what I'm asking.
[00:58:19] Alexey Melnikov: Yeah. This is a tough one. In ideal world, we probably will ask what working group and I mean, we can still ask and see what happens. Okay.
[00:58:31] Ben Bucksch: Are they part of the IETf or are they different?
[00:58:33] Alexey Melnikov: No. They they are responsible for HTML. Right. HTML five and stuff like that. So But we just asked him honestly. Well, I think we probably should ask because then at least we can say if they reject it or don't don't do anything about it, at least we can say it. At least we tried. But, yeah, it's not the spec that IETF owns for some loose definition of owns. Right? So just doing unilateral extensions to to HTML here without talking to w three c and what working group. That's probably not great.
[00:59:20] Ben Bucksch: Yeah. So I I know HTML three dot two, and I think four was owned by IETF, but no longer I know that.
[00:59:26] Arndt Rogge: Yes.
[00:59:27] Ben Bucksch: So, okay, so there's no no official path how to do this. We just do it Yep. Understood.
[00:59:34] Neil Jenkins: Sorry. Can I can I jump in just because HTML already defines site attribute for block quote, and it's just defined as a URL that references the content? So there's no need for anything with the block working group here. You just need the URLs team.
[00:59:51] Ben Bucksch: Which which property?
[00:59:53] Neil Jenkins: The block quote already supports a site attribute in HTML, so there's no need for a new thing here. It's a URL which cites the original message that you're or the original document you're quoting. Therefore, you just need a URL scheme that would reference the previous message for this to be valid. There's no need for what working group changes.
[01:00:15] Alexey Melnikov: Well,
[01:00:19] Ben Bucksch: what I was pointing out at the blockquote site, I think, is not an official attribute yet. Has been around since thirty years, but it's not
[01:00:27] Alexey Melnikov: Okay. Let's just follow-up of of you know, after the meeting and send email to chairs, and we we, you know, add Neil and cc, and we'll just double check and make sure it's all correct. I
[01:00:47] Arndt Rogge: volunteer to provide text for this. Lisa didn't hear me.
[01:00:54] Hans-Jörg Happel: K.
[01:00:58] Alexey Melnikov: You're done?
[01:01:00] Philip: You have nobody else's comments?
[01:01:02] Alexey Melnikov: Well, we we yeah. I'm I'm gently looking at the clock. We're out of time. So we sacrificed the trust document, you know, for other good discussions we've had this time. So thank you all. If this amount of interest continues next time, I probably should ask him for more than an hour. So just to make sure that we can fit everything out. But alright. Thank you all. And different people have various actions and emails they need to send to the mailing lists, so please do that.
[01:01:38] Hans-Jörg Happel: Alexey, you could also do an interim virtual meeting if you wanted to.
[01:01:42] Alexey Melnikov: Yeah. We probably should. Yes. K. Alright. Thank you.