Re: [Sml] My thoughts on the SML BOF

["Hernâni Marques (p≡p foundation)" <[e-mail]>]

Hello Jari

On 29.03.23 02:42, Jari Arkko wrote:

> IAB members are asked to provide feedback on BOFs, and we do this, but it should be noted that the feedback is a personal opinion, and often from a generalist perspective. In other words, here’s some feedback, hopefully it is helpful, feel free to do what you want with it, including ignoring it :-)

I think it's very useful: thanks!

> This BOF looked at structured email, which was defined as mail that is at least partially or fully handled by automation. The main question was whether various semantics annotation or definition mechanisms from the web could be applied in email. There’s already structured email for some cases, e.g., calendar invites, Majordomo subscribe emails, schema.org annotations in gmail, and so on. Adoption is limited to large providers, however, usage is unidirectional only, and there’s variation in the used vocabularies. This BOF suggests that work is required to go beyond current ”big senders -> big providers” usage.
>  
> One main question brought up in the BOF relates to how structured email annotations relate to the wish of the content providers to render their content exactly as they desire (e.g., including brand signage or opportunities to buy more).
>  
> Another question from my side relates to the scope of the BOF. Around ten different topics were listed for possible standards effort, each with fairly complex. For instance, whether there should be a way to respond with respect to the annotations. But there are issues with following HTTP links, an ability to reject, track response status, etc. If a working group is created, maybe a shorter list of actual work items is needed. There was some discussion about this at the end of the BOF, but not enough.
 >
> My conclusion is that this is work that is interesting, fits the IETF and our expertise, but more work is needed to narrow down what is actually to be done. (I’m not sold on the idea of another BOF, but rather work on a narrow charter on list. Some comments at the very end of the BOF were along these lines.)

IMHO, at least a mechanism to hide messages which are purely technical  
could easily be defined, e.g., by introducing a header like we do:

X-pEp-autoconsume: yes

(cf. the pEp slide deck p.12+13 for example wire formats we produce:  
https://datatracker.ietf.org/meeting/116/materials/slides-116-sml-sml-use-cases-for-opportunistic-email-encryption-in-pep)

This could be generalized for other applications which also produce  
purely technical messages like with a generic ".*autoconsume: yes"  
header and would not be limited to applications doing encryption.

As for our Use Case 1 with the attached pubkey (or other key material)  
perhaps a specific header inciting a special handling on the MUA side  
based on key material as defined in RFC4880 could do the trick; the  
concrete handling to be incited going into UX topics, however.

Still, I think, such work could easily be concluded. :-)

What concerns concrete formats for other structured data like flight  
data, this might be more tricky, but creating a narrow scope, concluding  
work and then defining a further scope / changing the charter / doing  
another BoF could help to get the work done, step by step.

I agree, however, we shouldn't try to do everything at once.

Greets --hernani

--  
p≡p foundation: https://pep.foundation/