(IETF 126)
1 hour
Chairs: Arnt Gulbrandsen and Alexey Melnikov
Note-takers: Lisa Dusseault & Daniel Kahn Gillmor
https://datatracker.ietf.org/meeting/126/materials/slides-126-sml-structured-email-core-draft-02
Fewer and fewer open issues
Question of whether MUAs MAY consider legacy structured data -- is this
OK by group?
Alexey: maybe be more specific about what 'legacy' means otherwise it's
pretty unimplementable. But happy with having some text that encourages
not using Subject for stuff not also included in the structured data
itself.
Hans-Jörg has in mind one specific legacy way of putting information in
the mail
Arnt says he has changed his mind after trying to implement: for legacy
clients, it can be easier to add in multiple different ways.
Phillip Tao: for MRM ("Machine Readable Representation"), separate MIME
part makes sense. For partial representation, if the parts are tightly
coupled, embedding in the HTML makes more sense. But this is distinct
from the question of legacy -- we can embed it in the HTML without doing
so exactly as we have done it in the past. If it's machine readable, it
should be in a separate MIME part.
H-J: legacy (what is sent around right now) is by definition always
partial. But maybe we don't want a third way to do it. All of the SML is
machine readable, what matters more is the distinction between whether
it's partial or full machine readable representation.
Ben Bucksh: I argued strongly for partial representation to be a MIME
part. But this doesn't make sense for things like structured quoted
text. The distinction is whether the material in question is
interpretable without the context of the broader message (e.g. an
attached song might be fine without the context) Netscape mail has been
using <blockquote cite=$CID> since the 1990s, it doesn't make sense to
break that out into a separate MIME part or a different design in the
text/html. For material that requires the context of the HTML, I propose
"use an HTML attribute" in ways that make sense, for simplicity.
Consider how Outlook strips most MIME parts, and how <script> tags are
often stripped, but inline quoting annotations a la Netscape survive
Outlook replies.
H-J: Consider also how scattering the structured data throughout the
HTML, that might also have trouble surviving.
Alexey: taking both these issues to the list unless there are final
statements from people.
Ben: I think this will come up in other cases too.
H-J: There's issues in the draft about signing with JOSE, it does make
sense to include this - we should align with and reference a trust
draft. Reminding people that if they have information that is not going
into the structured data to put into the Subject, because users want
Subject to actually be the subject...
Alexey: I disagree a little bit with saying you "MUST NOT put in the
subject", but generally agree with guidance. "MUST NOT" is too strong.
Give guidance about why not to use Subject this way.
H-J: We should guide implementations that want to do messages that are
primarily machine-readable, to still consider the human user and their
use of Subject.
[see slides for explanation of display hints]
H-J: Arnt on the mailing list asked about suppressing the HTML fallback.
Your idea was to suggest a client not even render an HTML element? (yes)
So my suggestion is to use 'data-allow-replace' for this.
Phillip: i'd assumed that you'd always do replacement. Why wouldn't i do
a replacment?
H-J: maybe you want to prepare something, but not immediately render it?
Sometimes it's up to the client what to do, but sometimes the sender has
an intention.
Neil Jenkins: there are security issues if you're replacing HTML
piecemeal. multipart/alternative are generally safer.
Ben: those risks and how they're handled differently for different MUAs.
Neil: there's a risk of too much flexibility leading to bad
interoperability.
Alexey: we need to take this to the list and think more about this.
[next topic]
H-J: Propose to refactor meaning of $hasStructuredData with $MRM
Phillip: It's getting harder to figure out what's machine-readable, so I
can see a flag indicating to pay attention to, among all these MIME
parts, the machine-readable part. But this might not be enough for the
MUA to make a decision. The content carried in the machine-readable
representation, I may or may not understand. It would be helpful to have
a header field to state that it's a machine readable message and perhaps
which type (e.g. "one time code")
Alexey: I think you're volunteering to write some text and send to
mailing list.
DKG: The way to think about what we should do with the flags is to think
about what a reasonable client will do with those flags. Will the client
look at messages that have structured data but are not only
machine-readable, what will they do with those flags? Do we have a clear
ontology for the flags?
H-J: Partly it's there also for SIEVE rules, it could be an important
signal. For a message list, you might not want to show the
machine-readable portion [when browsing archives].
Alexey: Flags are typically used for display (or non display) of
messages, as well as an optimization that a certain property of the
message doesn't need to be recalculated. For example, $hasAttachment can
be set on an S/MIME encrypted message that has an encrypted attachment.
When this flag is not set, MUA needs to decrypt and calculate it every
time.
https://datatracker.ietf.org/meeting/126/materials/slides-126-sml-structured-quoted-content-01
draft-ietf-sml-structured-quoted-content-00 replaces individual draft
Arnt: i've implemented it multiple times. replying is easier to do with
JSON-LD in the HTML with some implementations, separate MIME part is
easier in others. Can we just let implementers choose their preferred
way?
Alexey: i started implementation, i'm excited and i will send a list of
nits. Very quickly: ccRecipient and bccRecipient not listed in the list
of allowed propertied for EmailMessage object. Also, please list all
allowed attributes of EmailMessage object and make a statement in the
document about what MUAs should do if they see an attribute in JSON-LD
that is not listed as allowed. (For example, such attributes are to be
ignored, or cause an error, etc.)
H-J: [some reference to a question that also went on the mailing list
and whether it would help to explain that in the draft]
Ben: This is really useful for rendering attributions and quoted text.
Netscape Mail has been doing <blockquote cite="$cid">for ages. Can we
add this to the HTML spec, or do we need to work with the WHATWG or
something?
Alexey: in an ideal world, we'd ask WHATWG. We can do that and see what
happens. IETF doesn't own the HTML spec, so unilaterally extending it
without coordination isn't great.
Neil: HTML already defines an element for blockquote with the 'cite'
attribute, so there's no need to go to WHATWG to standardize anything,
you just need to define a URL to go in the 'cite' attribute.
Ben: But this is NOT a standard part of HTML I believe.
Neil: https://html.spec.whatwg.org/#attr-blockquote-cite
Somebody volunteered to write something up for list...
out of time bye everybody