WEBVTT

00:00.000 --> 00:10.000
All right, here we go.

00:10.000 --> 00:14.280
Yeah, for those that have been here in the start, or not been here, my name is Franz

00:14.280 --> 00:15.280
York.

00:15.280 --> 00:22.760
I'm from Austria, and I will talk a little bit about mostly, but not necessarily completely

00:22.760 --> 00:27.640
a client related topic, but it is sort of crosscutting, so it's not about a very specific

00:27.640 --> 00:34.120
client, but it's about a forthcoming new standard way of improving email, which for the

00:34.120 --> 00:39.480
moment, or probably for the time being, will be called structured email, and I will walk you

00:39.480 --> 00:44.280
through a little bit about what it is about, what you can do with it, what is around in terms

00:44.280 --> 00:49.560
of bits and pieces, and especially if you are an inner client developer or an email software

00:49.560 --> 00:56.120
developer, what kind of actions you could take, or what kind of help or feedback you could

00:56.120 --> 01:06.120
give here at the current stage, I'm going to switch by the way, oh, no, sorry, okay, well,

01:06.120 --> 01:16.880
another good back, I thought it's a, I thought it's arrow keys, but it doesn't work

01:16.880 --> 01:21.720
because it arrow keys, okay, this way, okay, sorry, here we go, that's the motivation slide,

01:21.720 --> 01:27.480
so we already know, email is still a quite unique technology with very unique properties that

01:27.480 --> 01:31.880
not so many other technologies have, so if you say the web, in a way, is a building block

01:31.880 --> 01:39.440
of the current internet in terms of something where you dynamically interact or synchronously

01:39.440 --> 01:45.000
interact with websites, email, so to a certain extent, it's a most standard, asynchronous

01:45.000 --> 01:49.800
technology are currently using most of the time, and it's also very unique in terms of

01:49.880 --> 01:54.840
the addressing, we are email addresses between, as I said, in the beginning, exchanging

01:54.840 --> 01:59.720
between your private and the public space, so it's actually a very versatile technology,

01:59.720 --> 02:04.040
and most of you will know that because you use even for all sorts of things, right, so it's

02:04.040 --> 02:09.080
like a little bit Swiss army knife of IT sometimes, which is to the good and to the bad

02:09.080 --> 02:15.240
to the certain extent. However, email, since it is widespread, it's challenged all the time

02:15.320 --> 02:22.360
with new features, so we saw in Benstock already also, there is a lot of movement in terms

02:22.360 --> 02:29.000
of private chats, like in some messaging, which I think has captured a lot of use cases,

02:29.000 --> 02:34.040
which historically some people were using by email, and there's also in the copyright world,

02:34.040 --> 02:38.760
you have things like Slack and team, and all these kind of things, which again, overlapped

02:38.760 --> 02:44.600
to a certain extent with email, but still email is actually growing worldwide, so which is part

02:44.680 --> 02:49.960
of the reason you to, you know, IT grows worldwide anyway, but also, you know, when you look

02:49.960 --> 02:54.920
into your mailbox, email to nowadays is a lot of transactional, so a lot of males, which you have

02:54.920 --> 03:00.520
are basically your orders, your foster registration, your whole registration, your energy bills,

03:00.520 --> 03:06.360
these kind of things, and so there's a lot of email, which is actually generated by not pay

03:06.360 --> 03:12.840
humans, center you, but generated by systems, and you know, templates and stuff, but in a way,

03:12.840 --> 03:16.840
your email client is sort of dumb, so it cannot help you a lot with that, it can help you

03:16.840 --> 03:21.160
somehow with calendar invitations, but it cannot help you with all the other stuff, most of the time.

03:22.440 --> 03:25.480
But, you know, if you think about this email, it's a little bit like your personal API,

03:25.480 --> 03:31.000
like you receive posts in the form of days, and you know, your bills and stuff, and put it in your

03:31.000 --> 03:35.960
in your wardrobe, now it's, you find it in a folder probably, or something like that,

03:35.960 --> 03:40.840
but still it's a very manual process, so the whole motivation behind is how can this

03:40.840 --> 03:45.640
done more efficiently actionable, interoperable, and maybe even enjoyable, yeah, so it's

03:45.640 --> 03:52.920
forcing in a row, let's see how far we can get here. So what's a basic idea, so the idea is,

03:53.640 --> 03:58.040
you know, there is machine readable data on the web already for a long time, so many people

03:58.040 --> 04:03.880
of you might be aware of RAF, in general, as a standard by the W3C, for knowledge representation,

04:03.880 --> 04:08.360
which is around for quite a while, and it's also used very widespread on the web by the way,

04:08.360 --> 04:12.440
so if you do a web search nowadays, and you see these rich search snippets, which tell you this

04:12.440 --> 04:17.160
pizzeria, has system this rating, and this is this phone number, it's very often actually

04:17.160 --> 04:23.000
fueled by a structured data annotated by the website hostels, owner of the website, so you have

04:23.000 --> 04:30.920
some 10 million websites, any new sites you look at, any cooking site, any music site, yeah,

04:30.920 --> 04:36.920
you look into the metadata of the site, and it would typically have so full metadata of content

04:37.720 --> 04:43.160
in the metadata of the site, which is just silently used by the search engines so far, but which

04:43.160 --> 04:48.840
could be leveraged for much more, and in ways the idea for email is sort of the same, right? So

04:48.840 --> 04:53.560
you have historically different representations for email, so email started text-based, asky-based,

04:54.520 --> 04:58.840
and there's still asky-based, to the round we have seen in the very first talk, which is great,

04:59.560 --> 05:04.600
but many email nowadays is also HTML-based, yeah, but email already was so flexible,

05:04.600 --> 05:08.920
that typically you can combine both of these things, because you have these multi-part alternative

05:09.960 --> 05:15.560
body parts, so many of the emails you receive today have this feature where you can look at

05:15.560 --> 05:20.600
them at the command line, but you can also look at them in a fully-fledged visual client,

05:20.600 --> 05:24.760
and the idea here is just to add a third part of it, part of it, which is a machine-reader part,

05:25.320 --> 05:29.960
so if you have an email client that can understand that and can act upon that kind of machine-reader

05:30.040 --> 05:35.960
but data is fine, if not, you can just use email as you used it before, so it's actually quite a

05:37.560 --> 05:43.400
quite a nice thing, which can be added into the email without disturbing the workflow of people using

05:43.400 --> 05:49.720
email to that extent, and actually a lot of people do that already, so to a certain extent,

05:49.720 --> 05:54.600
the happening, if you scan your mailbox and I'll show you a tool later where you can actually

05:54.600 --> 05:59.800
try that out if you want, you will find that for instance, many airlines already put this kind

05:59.800 --> 06:05.160
of structure data in their emails, they mainly do that because Gmail is rendering the airline

06:05.160 --> 06:09.480
case within Gmail, if you opted into that, but they will also send it out typically to your

06:09.480 --> 06:15.720
non-Gmail account, but just your typically email client will just not make use of it, yeah, and

06:17.160 --> 06:22.920
yeah, so but of course if the email client knows that it could help you much more, you know, adding

06:22.920 --> 06:27.800
this to the calendar, probably re-bubbing the flight and whatever you want to do with that kind of

06:27.800 --> 06:33.800
data, very short, maybe because some people might know, okay, making something smart or so there

06:33.800 --> 06:38.520
is a icing around, right, like everyone is talking about, just for those who get a little bit

06:38.520 --> 06:43.480
confused, how this relates to the other, right, so with AI typically you don't have necessarily

06:43.480 --> 06:47.240
structure data, but you have text-based data in the AI twice makes sense of that, that's why

06:47.320 --> 06:53.160
you try to find other cases, might be a flight from here to there, whereas the idea of structure

06:53.160 --> 06:59.400
data in that sense here comes from the source, like the sender will already, you know, provide

06:59.400 --> 07:05.960
well-defined structure data for the certain use case because typically the sender will know already,

07:05.960 --> 07:11.800
so in an idea where these two things are complementary, yeah, so obviously it's a little bit

07:11.800 --> 07:16.280
closely to have structure data for everything, so you will do it if you have the data already,

07:16.280 --> 07:21.960
anyway, so the case for AI is always like, you know, there is not yet that prescribed data,

07:21.960 --> 07:25.880
but if the sender anyway has that structure data already, it typically makes much more sense

07:26.840 --> 07:31.080
to already include it, so there is no AI that has to guess on that or something like that,

07:31.080 --> 07:36.680
but these two things are also used to work together to a certain extent in, you know,

07:36.680 --> 07:43.240
providing additional things for AI assistance and so on, so it's not a thing that is, you know,

07:43.240 --> 07:48.200
totally different, but it comes from a different direction that's said like that, yeah, so what

07:48.200 --> 07:53.080
use cases can you use is for, so our retention sets are is to standard seeing like orders,

07:53.080 --> 07:58.040
reservation, the flight reservation, the train reservation, the hotel reservation, there is also

07:58.040 --> 08:02.040
things you can do in instant messaging, right, so for instance in instant messaging we had already

08:02.120 --> 08:09.480
an example by bandwidth pulse or locations, right, if you do that right now in email it's not

08:09.480 --> 08:16.680
really possible in an interoperable way and having some some markup here which would tell the email

08:16.680 --> 08:20.840
clients this is actually a location or this is a poll, it could be very beneficial in making

08:20.840 --> 08:27.400
that interoperable, similar things with things like articles, recipes and songs, I've been told,

08:27.400 --> 08:31.320
I've been telling you that a lot of websites you already have submitted data, yeah,

08:32.280 --> 08:37.080
so if you if you for instance go on on a on your mobile on a web browser and share

08:37.080 --> 08:42.680
a Spotify or whatever song with like your WhatsApp or something like that, it will basically show

08:42.680 --> 08:48.280
up a link preview at least, yeah, so you see like the song album cover or something like that,

08:48.280 --> 08:53.080
do that to an email client and it you will just see the URL, yeah, so you have stuck to that kind of

08:53.080 --> 08:58.200
Spotify thing, we structure data since for instance on Spotify the structure data is already in the

08:58.200 --> 09:03.320
website we can even add additionally the structure data so your client doesn't just have a link

09:03.320 --> 09:07.720
or just an album cover but the client actually knows this is a song and this is the artist

09:07.720 --> 09:12.120
and could for instance is a map set to another service if you're not a Spotify subscriber or

09:12.120 --> 09:18.680
your personal np3 archive which is you know why it's your thing so that also gives you a level of

09:18.680 --> 09:24.920
you know portability and you know less beings stuck to a certain service provider here

09:25.880 --> 09:30.440
and as he is case might be something like new slators or meeting info so you're of all been receiving

09:30.440 --> 09:34.600
emails from the first them organizers like you know this is a venue here is the train station

09:34.600 --> 09:39.480
here is probably hotels or restaurants something like that and it's really always a link in the email,

09:39.480 --> 09:43.640
yeah so your email client has no clue what this is about so what about first time could you know

09:43.640 --> 09:51.480
annotates this kind of information in that newsletter which is anyway you know crafted very nicely so

09:51.480 --> 09:55.880
that would be a very helpful if you could very easily as an import that to another app or where

09:55.880 --> 10:01.320
you manage your trip with or something like that and finally there's also email specific use cases

10:01.320 --> 10:05.320
for instance like you might know what vacation notices which tell you somebody is absent for a

10:05.320 --> 10:09.400
certain point of time it's also something you need to read by yourself understand by yourself

10:10.280 --> 10:15.720
and actually there is a particular draft ITF draft for this particular use case you know

10:16.680 --> 10:20.760
leveraging structure data also in that case so your email client can basically understand

10:21.480 --> 10:25.800
that's remote persons absent and there is also you know

10:25.800 --> 10:30.280
and everything more on some more use cases there is a particular ITF draft for this interested

10:30.280 --> 10:36.520
and certainly this is also a call to the community to you know think about use cases provide feedback

10:36.520 --> 10:43.240
on what people might find useful and so on so how does it work for many implementation side

10:43.320 --> 10:48.360
because you know we have a chicken act problem here email is a very um you know

10:48.360 --> 10:53.160
widespread longstanding ecosystem with a lot of actors and it's very hard to get all of

10:53.160 --> 10:59.480
some you know on one boat to make this happen and obviously you for this to be useful you

10:59.480 --> 11:05.560
need senders to do it and clients to use it as well and the clients will say the senders should

11:05.560 --> 11:10.360
put that in first otherwise why should I care about the senders will say oh no client is supporting

11:10.360 --> 11:16.440
that for sure I do yeah so yeah that's classic you check in act problem good thing is I told you

11:16.440 --> 11:22.200
some senders already are using it through certain extended list also for senders at least for

11:22.200 --> 11:27.160
automated senders it's to a certain extent probably easy because as I say if I already

11:27.720 --> 11:33.320
build the email out of a database already maybe even using a certain system a lot of people are

11:33.320 --> 11:39.320
using it might be easy to just put in some mechanism in the template and then have a real

11:39.400 --> 11:46.840
part impact on on the data involved also senders especially put especially a professional

11:46.840 --> 11:51.960
senders I interested in that in a sense because if it would enable user better user experience

11:51.960 --> 11:57.720
on the receiving side um they are interested of course in you know providing this kind of

11:57.720 --> 12:01.880
add-on work because it would help serviceability in the inbox it's a similar mechanism somehow

12:01.880 --> 12:06.200
here for the web yeah so people started annotating that on websites because basically they had

12:06.200 --> 12:13.800
a benefit in Google search or in other search engines um there's another way also of course

12:13.800 --> 12:18.200
that would be useful if you could buy yourself if you could if you would draft an email if you

12:18.200 --> 12:22.920
could send certain structured emails I mean nobody would necessarily require you to write like

12:23.720 --> 12:29.160
RTF in the email explicitly but you could think about you know when you share a link for

12:29.160 --> 12:33.800
instance it could try to pull the structure data out somewhere and there could also be 10

12:33.800 --> 12:37.880
plates for something like a poll or something like that yeah so there might even be support

12:37.880 --> 12:43.480
uh in email clients for this kind of use case on the receiver side um you might think about

12:43.480 --> 12:48.680
adding this on the MTA level like if the mail comes in you order process it already uh and write

12:48.680 --> 12:53.960
it somewhere to restore or to some system this could at least something not 100% in focus but

12:53.960 --> 13:01.000
that could obviously be done um currently for for uh implementations it's more on the user agent

13:01.080 --> 13:05.880
levels from the email client level where it's directly visible to the user but these two things

13:05.880 --> 13:11.880
could easily um work together of course and maybe just to explain a little bit it's it's actually

13:11.880 --> 13:16.520
very similar so this is just the screenshot of a meeting invite many people of you know so there

13:16.520 --> 13:22.120
is RFCs for this particular use case and it's basically working very similar like so also in

13:22.120 --> 13:27.080
calendar invite sometimes you have servers acting about that already sometimes you do it in a client

13:27.160 --> 13:33.240
so you have a very same situation of how to deal with this kind of data um and also what's

13:33.240 --> 13:38.280
interesting is you have a typical way of presenting that kind of information adjacent to the actual

13:38.280 --> 13:43.000
mail or even fully replacing the email yeah so this is a user experience which is very similar

13:43.640 --> 13:49.720
of which people are used already for invitations or these calendar invitations and many tools

13:49.720 --> 13:54.040
do it in a similar fashion I would say yeah so this is sort of a little bit of an inspiration

13:54.760 --> 13:58.920
um so in a way you can think about all this structured email is a sort of a generalization of

13:58.920 --> 14:04.520
that yeah so um you have this thing happening for calendars but you probably wouldn't write like

14:04.520 --> 14:10.520
500 more RFCs for very specific topics but the idea is to have a more um general framework here

14:11.400 --> 14:17.000
um so how does it work generally so um this is now the use case on the client side so we you

14:17.000 --> 14:22.200
really have something like parula or son of a bird or something like that um so the first question is

14:22.200 --> 14:28.280
when should you analyze the email in that case yeah so um um obviously when the mail is incoming

14:28.280 --> 14:32.520
to the user that is not on the client side typically because the client would need to be active so

14:32.520 --> 14:38.040
that would be the NGA case which we don't look at right now here but one thing could be once the

14:38.040 --> 14:42.040
email client is running you look in the background and new mail is coming in you process it and you

14:42.040 --> 14:47.400
look is a structure data inside which you might want to act on you know the other option is to

14:47.400 --> 14:52.040
use or explicitly open the email and you look then into what is in that kind of email yeah

14:53.880 --> 15:00.760
in terms of extraction I told you already some airlines um doing it for instance in emails

15:01.480 --> 15:06.520
embedding this structure data they do it a little bit in and let's say not so clean way so it's

15:06.520 --> 15:12.920
basically put in the text HTML part of the message and actually not many of the windows really like it

15:12.920 --> 15:18.600
because it's a little bit uh yeah I would not say they dirty approach and so on so the idea with

15:18.600 --> 15:24.760
in the um ITF or the probably consensus that will be is every reach is to really do it as a separate

15:24.760 --> 15:32.520
a multi-part alternative type um so somehow maybe at least for some time when this is rolled out

15:32.520 --> 15:37.800
you might have situations that both of these things are around um but you would have a library

15:37.800 --> 15:42.680
probably looking for all of that um the interesting thing is you could also do some kind of bootstraping

15:42.760 --> 15:48.360
beyond that yeah so even if you think about uh having not directly at the F in the email and

15:48.360 --> 15:54.840
there is already a lot of emails um that have some other structure data um like okay ICS files

15:54.840 --> 15:59.480
if they are not a meeting invite to the user just to play an attachment I mean some clients might

15:59.480 --> 16:05.160
render them um you have this pick-up past tickets that Apple for instance sends around for events

16:05.720 --> 16:11.880
many of you might know um also there is some approaches or e-in voices as a very recent

16:11.960 --> 16:16.920
thing is a u especially um and there is also things around like you can even extract from

16:16.920 --> 16:21.560
textual emails certain stuff so the k etinary project which was presenting here at first and

16:21.560 --> 16:27.640
last year in the track um they have basically some regular expressions um where they do support certain

16:27.640 --> 16:33.960
airlines you know extracting the flight data even if the airlines do not yet include the structure data

16:33.960 --> 16:40.360
just based on um on the textual content that of course not a very nice and sustainable thing

16:40.360 --> 16:45.720
but it's probably a bootstraping approach to help the things get running right so then how does

16:45.720 --> 16:49.720
the interaction work yeah so once you did all the parsing and everything what can you actually do

16:49.720 --> 16:55.880
is it yeah and um so one idea is um to do it a little bit like also you do it is the instant

16:55.880 --> 17:00.520
messengers or select also also like you have sort of a cut-based rendering where you do some

17:00.520 --> 17:07.480
have some human readable information of what's a structure data is about so this is something

17:07.480 --> 17:12.520
you could do quite for a lot of data without being too specific because it's probably like an

17:12.520 --> 17:19.000
image and the title and then we come to the actions um but for some sort of use cases you might

17:19.000 --> 17:23.320
also have very specific templates like for a poll such a card would not be sufficient but you

17:23.320 --> 17:28.920
would need a more specific you know rendering of a poll with options and submissions things

17:30.680 --> 17:35.480
another thing you could probably do is that some simple forms yeah where you could probably

17:35.480 --> 17:41.480
enter some information think about your electricity provider asking you for the you know look

17:41.480 --> 17:47.000
up so electricity meter in your backyard typically you go to a portal a little bit just to

17:47.000 --> 17:51.320
enter just a very single number so that could be theoretically something you could also do

17:52.440 --> 17:59.000
with that kind of approach and yeah the engine is of course actions yeah because rendering is nice

17:59.000 --> 18:03.320
but you want to do something with it yeah but the good thing is once you know which kind of structure

18:03.400 --> 18:09.800
data that is like for instance here we know it's a location yeah we can for instance trigger our

18:09.800 --> 18:16.440
launches in our open street map or whatever kind of thing we want to have we might even decide

18:16.440 --> 18:22.920
some email client might even want to decide to render that in a map yeah so because the location is

18:22.920 --> 18:28.280
known think about my case before we are first them since you're list of restaurant recommendations

18:28.280 --> 18:33.400
or something like that you know the email client is covering that might offer you to render that

18:33.800 --> 18:39.160
within the email client somehow in a view on a nice map or something like that yeah so

18:40.040 --> 18:44.440
this is what I call you like platform dependence or there might be also add ons in your email

18:44.440 --> 18:49.400
clients that act on certain kind of sea structure data it's obviously not that's the email client itself

18:49.400 --> 18:55.880
will be doing most of that but yeah you could have a cookbook app for instance where you have

18:55.880 --> 19:00.760
recipes in right and the recipe you get sent in by email might be directly wired into that

19:01.960 --> 19:06.760
the second category of actions might be structured data responses where you say you directly send

19:06.760 --> 19:13.080
a structured data back to the to the ones that was sending to you good example might be the answer

19:13.080 --> 19:18.440
to the poll for instance yeah where you just choose this and or something like you could sing about

19:19.400 --> 19:27.000
a vacation request yeah I wonder if vacation leave next week for two days yes or no

19:28.040 --> 19:35.960
and that's could also be done by that yeah very shortly security and trust it's probably

19:35.960 --> 19:40.280
something maybe also for the discussion if somebody's interested this is also an ongoing discussion

19:40.280 --> 19:47.960
on you know should one require S-mine signing or PGP signing for this kind of content to avoid abuse

19:48.520 --> 19:52.680
here so there is an active draft as well and some discussion on the idea of mailing list for those

19:52.680 --> 20:00.920
people interested in that facet that's a little bit summarizing you know the current flow of how

20:00.920 --> 20:08.440
things work or get changed through certain extent a very short note only an interesting question

20:08.440 --> 20:12.680
is also like you have the message store where the actual messages are but what do you do with

20:12.680 --> 20:17.560
this structured data yeah that might not just be a one time thing you might want to have

20:17.560 --> 20:23.640
somehow within your email client or your desktop some possibility to store certain snippets yeah

20:23.640 --> 20:29.000
to store restaurant recommendations or something like that for which the message store probably

20:29.000 --> 20:34.280
is not the right way to do but this is more like a implementation decision or feel see also

20:34.280 --> 20:38.680
of clients but at a certain point that might also get interesting to maybe make more into

20:38.680 --> 20:44.120
operable between different clients but this is maybe more of a future thing here so in terms of

20:44.120 --> 20:50.680
implementations very shortly so came mail the supports is kind of approach at least to certain extent

20:50.680 --> 20:55.720
since the while already again there was a talk last year here at host them you have some support

20:55.720 --> 21:03.080
in next lot mail the very recently launched an outlook at an actually sorry for that but it was

21:04.040 --> 21:07.960
obviously also a community you want to write in the boat here it's actually specific to

21:07.960 --> 21:13.320
electronic invoices by now but underneath it's enabled or the whole mechanism is already like

21:13.320 --> 21:19.320
built for all of this structured email as well so this will be enabled in a second step here we have

21:19.320 --> 21:24.280
a prototype for K9 mail I actually wanted to have said ready for host them but we will probably

21:24.280 --> 21:32.680
have it in the next weeks published so you can try that out and we have also support for

21:32.680 --> 21:37.400
sort of a number of redmailers so we have a run queue project even on GitHub it's not the most

21:37.400 --> 21:43.880
recent conversion yet so we will also have an update on that one but some people might be also interested

21:43.880 --> 21:48.760
in having a look at that and this for instance is how it looks like if I sent you a restaurant

21:50.440 --> 21:55.240
in the K9 implementation so you see you can directly call the restaurant or have an

21:55.240 --> 22:01.400
navigation to the restaurant here there is some libraries you can use so that was one goes that we

22:01.400 --> 22:07.480
can provide a client developers with libraries for all that extraction and also for the rendering

22:07.480 --> 22:13.160
so in order to share information here so everybody has doesn't have to reinvent the wheel

22:14.920 --> 22:19.960
and I told you there is already also some additional testing code so if you want to scan your email

22:19.960 --> 22:24.440
account to know which kind of structured data by the way do I have already in my emails historically

22:25.320 --> 22:30.760
there is this little project on GitHub where you can do that there is also another project where you

22:30.760 --> 22:37.160
see some examples of structured email if you want to might want to play around with that and

22:37.160 --> 22:41.720
yeah for the top project you can also send structured email to somebody or to yourself in case

22:44.040 --> 22:49.080
you want to play around with that actually due to the fact that the ITF standardization is still

22:49.080 --> 22:54.840
ongoing so probably I don't know if I'm somewhere here to the end of the years I might be in

22:54.840 --> 23:00.520
RFC ready for for some last call probably there is different options now still how to

23:00.520 --> 23:07.160
include it in the email but still on the reading side you can do a lot of that and yeah that concludes

23:07.160 --> 23:13.400
the talk here so hopefully structured email will be a way to make make email better and make

23:13.400 --> 23:19.240
email more modern and allow for interesting new use cases for those that want to have that in

23:19.240 --> 23:25.240
their clients it's incremental which is nice so that's really also a very nice feature of email

23:26.200 --> 23:30.760
one aspect that might also be interesting here is accessibility so for people that have maybe

23:30.760 --> 23:35.080
difficulties in reading or something like that structured data might also be interesting to give

23:35.080 --> 23:41.480
them alternative ways of accessing the content here is a link to the ITF work so join ITF

23:41.480 --> 23:46.360
mailing list it's free if you're interested in that join the discussion there is an interim call in

23:47.320 --> 23:51.960
two weeks I think and that's all thank you very much looking forward to your question

23:57.320 --> 23:59.320
all right let's see

23:59.640 --> 24:07.480
yeah all right thank you

24:15.000 --> 24:25.400
sorry yes I know okay okay so sorry it was a little bit hard to hear so the question is there

24:25.960 --> 24:33.160
project it's a Google project basically so you can only use it in Gmail there is actually

24:33.160 --> 24:37.960
yes mostly I mean there's Yandex I think or something you're who theoretically but I didn't get it

24:37.960 --> 24:45.080
to work actually but that's another story there's also actual messages for Microsoft which is very similar

24:45.080 --> 24:51.160
to the amp same just for reference and Gmail actually does pose Gmail support some structure data

24:51.160 --> 24:57.240
and also in a unidirectional way so you cannot send it you can just receive restaurants and

24:57.240 --> 25:03.320
flights sorry parcels flights and reservations you need to sign up for that so it's not really open

25:03.320 --> 25:09.720
and decentralized and it is ant in parallel so how does it differ yeah so the structured email part

25:09.720 --> 25:14.840
of email is really Gmail can understand this is a restaurant yeah and this is a flight but with

25:14.840 --> 25:21.080
amp it's basically an HTML email to zero yeah so you can do a form an email where you can send

25:21.080 --> 25:27.880
me data but there is no idea of what is this from about or what is inside here yeah which is which

25:27.880 --> 25:33.640
is probably also the case yeah so in that sense even in Gmail they coexist yeah so it's two different

25:33.640 --> 25:38.840
things there might be the question so for something like suppose or the location sharing if you

25:38.840 --> 25:43.560
want to do live location sharing you might borrow the feature of updating information in an email

25:43.560 --> 25:48.200
or parts of the structure data at least also for the structured email approach yeah so there might

25:48.200 --> 25:53.640
be a little bit of a synergy which again as you say is something one should do very carefully but

25:53.640 --> 26:02.200
this is the current state of affairs here yeah does it happy thank you for the questions I see

26:02.200 --> 26:10.200
I just scanning the rooms suddenly so I have to start okay one of the biggest problem I have

26:10.760 --> 26:21.800
the agreement but on the demo about how to type the data exactly yeah you mentioned it quite

26:23.080 --> 26:29.080
yeah can you it above it yes so you're absolutely leaning the point so I think the main thing here

26:29.080 --> 26:33.640
will also be about you know how to most clients would agree on certain schema for certain use cases

26:34.840 --> 26:40.040
I think one there is multiple answers to that but keeping it short I think one is there is already

26:40.520 --> 26:46.200
vocabulary around in RDF like for this search engine kind of annotations thing on the web

26:46.200 --> 26:51.240
a schema org I think has some 900 classes already for certain things so this is already quite

26:51.240 --> 26:56.280
widespread use it's not very top quality I mean we can never long this pattern on that but this is

26:56.280 --> 27:01.400
at least something you can leverage um second thing is there will be certain things probably even

27:01.400 --> 27:05.800
standardized on the ITF level like vacation notice where it makes sense where it's a very super

27:05.800 --> 27:12.520
clients specific and then there might be something like community work so at least this is one of the

27:12.520 --> 27:17.960
things not yet 100% clearly figured out but the ideas probably to have some community working on

27:17.960 --> 27:24.600
that and sharing some kind of templates and use cases make sense and you have to think about

27:24.600 --> 27:30.120
typically attachments you see to email yes so in a way this is related to that so not email

27:30.120 --> 27:34.760
clients also don't agree on which kind of attachments you can add it's basically the operating

27:34.840 --> 27:39.960
systems or add-ins to the email clients which say okay I can read a PDF and you could think about that

27:39.960 --> 27:46.280
in a similar way yeah like you could have as a way of having add-ins registering for certain

27:46.280 --> 27:52.280
structure data and in that sense you might not strictly need that kind of consensus between all

27:52.280 --> 27:56.520
the email clients it would just that in order to understand a certain one you would need to

27:57.560 --> 28:03.240
have a suitable item here but maybe you can continue this question often I've one more question probably

28:03.240 --> 28:15.080
and then we unfortunately already over thing yeah this is a good question so I would

28:15.080 --> 28:20.680
think so that for instance like people like Gmail also do the expected I know from some ISPs

28:20.680 --> 28:25.240
that already also do analysis and say basically have a combined approach of using structured data

28:25.240 --> 28:31.000
and expected data and putting that into a model so in that sense yes but I'm not aware of a

28:31.000 --> 28:38.840
pure client already so that's what made it up thank you very much again