►
From YouTube: IETF104-T2TRG-20190326-1610
Description
T2TRG meeting session at IETF104
2019/03/26 1610
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
B
C
B
D
D
D
D
Ok
thanks
and
thanks
to
the
agenda
for
today,
we
will
give
you
a
very
brief
intro
and
Archie
status
in
the
beginning,
and
then
we
will
give
a
report
from
some
of
the
recent
activities
in
the
whisky.
In
the
pre
work
meeting
we
had
on
Friday
and
also
from
the
hackathon.
Then
we
have
micro
coaster
joining
remotely
to
present
that
able
to
see
community
group
schema.
D
Extensions
mattias
will
give
an
update
on
the
web
of
things
group
and
then
Klaus
will
give
us
a
presentation
and-
and
we
have
assigned
time
for
discussion
on
using
kora,
to
bring
more
hyper
media
through
IOT
and
finally,
christine
I'm
just
will
be
presenting
research,
Directory
replication.
Any
questions
or
comments
on
the
agenda.
D
D
The
user:
what
are
we
doing
intently
research
group?
What
is
our
scope
and
goals?
We
are
looking
into
these
open
research
issues,
how
we
can
really
turn
IOT
that
we
are
working
on
into
reality.
We
are
focusing
here
on
things
that
there
is
opportunities
for
either
standardization.
It
way,
starting
with
the
IP
layer,
going
all
the
way
up
to
the
application
layer
and
an
API.
So.
D
D
Some
recent
activities
where
we
have
been
involved
we've
been
driving.
This
work
on
IOT
70,
hypermedia
interoperability
called
wishy,
that's
historic.
Two
years
ago
here
in
Prague
in
the
inter-regional
we
she
works
up,
and
then
we
have
had
a
lot
of
virtual
meetings
and
bunch
of
hackathons,
actually
the
fifth
hackathon
at
this
time.
D
D
Matthias
will
tell
a
bit
more
about
that,
but
there's
also
likely
good
collaboration
with
the
things
in
Archie
and
another
organizations
and
then,
of
course,
at
the
next
IETF
in
in
Montreal
we're
planning
to
have
a
yet
again
a
we
see
hackathon
on
the
weekend
before
and
there's
also
potential
to
have
a
joint
meeting
with
a
spec
work.
So
long
name
is
meeting
the
week
before
so
potentially
on
the
Friday,
we
could
have
a
face-to-face
activity
together
with
all
may
also.
D
D
The
document
state
is
state
of
the
art
challenges
for
the
IOT
Security's
currently
in
the
RFC
editor
queue,
so
that
will
be.
The
first
are
see
we'll
publish
any
day.
Now
it's
actually
on
the
top
of
the
queue.
So
we
expect
that
to
be
ready
very
soon.
We
also
have
another
research
group
document.
Restful
design
for
IOT
I
will
have
a
bit
more
details
in
the
upcoming
slides
on
that
we
have
also
bunch
of
documents
we've
been
discussing,
in
particular
on
the
Friday
meeting
that
we
could
be
taking
on
as
a
research
for
topics.
D
There
has
been
quite
a
lot
of
work
done
on
the
H
and
IO
team,
so
having
a
research
group
document
on
that
could
make
a
lot
of
sense
on
core
applications
and
with
the
whole
coral
ecosystem.
If
you
wish,
some
part
of
that
work
would
make
a
lot
of
sense
to
do
here
in
the
RT.
Some
of
that
has
to
be
done
in
the
working
group
where
it's
standardization
work,
but
then
the
more
explorative
parts,
for
example,
application
descriptions
are
very
much
related
to
this
restful
design.
D
Also,
there's
a
bunch
of
other
documents
where
you
can
have
a
look
at
the
Friday
meeting
notes
for
more
details.
One
topic
we
discussed
then
was
this
layer.
Three
considerations,
I
have
another
more
detail
slide
10
on
upcoming.
We
could
make
a
some
document
out
of
that
and
in
the
we
see
work
we
have
been
making
a
set
of
what
we
call
wishy
notes
right
now.
A
set
of
informal
wiki
pages
are
turning
some
of
those
potentially
in
the
archie
documents.
Longer-Term
the
right
way
to
go.
D
D
D
So
I
mentioned
about
some
additions
to
the
terminology.
We
are
planning
for
two
new
terms:
there,
a
transfer
protocol
and
transfer
layer,
and
actually
these
are
not
really
any
new
terms.
We've
been
using
this
in
the
co-working
research
group,
probably
up
to
a
decade
or
right
now,
as
it
turns
out,
we
never
formally
defined
what
we
mean
by
a
transfer
protocol
or
transfer
layer,
some
examples
that
we'll
be
referring
to
these
protocols.
D
D
So
we
have
not
drafted
too
early
draft
definitions.
I
would
very
much
like
your
input
and
feedback
on
these.
You
can
read
them
on
the
slides,
but
they
basically
for
transfer
protocols-
and
this
here
we're
now
discussing
in
particular
IOT
domain,
because
the
draft
is
about
restful
IOT,
but
the
transfer
the
cost
would
be
protocols
about
transport
transport,
layer
that
are
used
to
transfer
data
objects
and
provide
semantics
for
operations
on
the
data.
D
The
key
thing
is,
you
are
transferring
some
sort
of
a
top
speed
between
between
systems
and
you
provide
some
additional
semantics,
but
these
protocols
are
reusable
and
often
even
to
some
extent
replaceable.
So
it's
not
a
that
tightly
bound
part
of
a
vertical
stack,
but
actually
a
a,
maybe
even
a
distinct
layer
and
for
the
layer
part
what
we
are
being
draft,
as
the
definition
is
reusable
part
of
the
application
protocol
that
is
used
to
transfer
the
application
specific
data
items
using
a
standard
set
of
methods
that
fulfill
application,
specific
operations.
D
D
D
So,
at
least
in
the
context
where
I
have
end
up.
Quite
often
when
you
see
that
there's
some,
you
have
a
European
application
and
then
you
are
underneath
have
a
set
of
choice
for
protocols
happy
having
a
term
to
describe
what
is
that
thing
that
is
traditionally
part
of
the
application
layer
of
a
par
stack,
but
it
has
kind
of
reusable
characteristics
and
even
potential
for
replacing
protocols
across
seem
to
be
very
useful.
D
D
Then,
moving
on
in
the
indo-asia
work,
what
we
have
had
so
far
is
six
online
meetings.
Since
the
last
IETF,
we
have
been
discussing
a
set
of
topics
we
started
with
this
plot
object
model.
It's
a
new
IOT
object,
more
explorative
from
robert
from
google
we
have
been
discussing.
The
work
is
happening
in
the
schema
and
IOT
extensions.
D
We
have
had
quite
a
few
meetings
on
this
topic
of
best
practices
for
data
model
component
reusability.
It's
a
topic.
We
also
discussed
on
friday
friday
meeting,
and
I
have
more
details
coming
on
that
and
also
how,
in
general,
can
we
go
about
adding
semantics
to
existing
instances
of
data?
So
if
you
have
data
that
doesn't
have
machine,
readable
semantics
when
you're
consuming
it,
how
can
you
apply
after
the
fact,
some
different
ways
of
getting
the
semantics
in
order
to
do,
for
example,
translation
between
different
models
and
it
topic
very
much
related.
D
This
one
is
of
this
parsing
and
translating
binary
data
in
part
of
our
comment
coming
from
legacy
sources.
If
you
can
apply
semantics
to
it
becomes
much
more
simpler
to
handle
the
data
in
the
rest
of
the
pipeline
and
finally,
one
example
of
a
topic
that
was
originally
discussed
in
the
core
working
group.
But
then
we
realized
this
perhaps
more
wider
resource
aspects.
Is
this
exposing
more
structured
media
types
in
hyper
media
exchanges?
D
So
in
core
working
group?
There
is
this
draft
on
on
expressing
multiple
media
types
in
within
a
single
media
type,
and
we
were
discussing
that
in
core.
We
realized
okay.
This
actually
may
have
much
wider
implications
than
just
for
the
draft
that
was
discussed
in
the
core.
So
then
that
was
discussed
in
the
we
see
working
group
like
what
are
perhaps
wider,
longer
term
implications,
or
do
we
have
new
design
patterns
here
that
we
should
have
to
be
more
explorative
on.
D
Then
we
also
had
the
we
see
hackathon
that
was
the
weekend
before
the
IETF.
This
was
the
first
one
and
we
had
actually
12
participants
and
a
few
more
extras
occasionally
showing
up.
We
had
also
one
remote
participant,
and
in
this
we
see
hackathon,
we
had
the
roughly
on
high
level
the
same
goal
of
connecting
things
from
different
ecosystems,
and
we
are
using
hyper
media
and
shared
semantics
as
the
tools
to
achieve
that.
D
But
this
time
we
had
a
slightly
more
different
approach.
We
had
a
lot
of
work
done
around
coral,
so
some
of
the
things
that
we
did
achieve
we
have
now.
It
is
a
new
parser
for
for
text
form
of
coral.
It's
already
publishes
open
source
as
a
ruby
game.
There
is
also
now
a
basic
coral,
encoder
and
parser
and
a
serum
model
for
the
right
operating
systems,
and
you
have
links
there
on
the
slides
for
more
details.
We
work
quite
a
bit
on
coral
examples
and
use
case
is
to
get
get
more
practical
experience.
D
Unlike
how
would
these
things
look
in
practice,
and
also
we
have
been
using
quite
a
bit
the
web
of
things
that
we
develop.
Things
thing
description
format
and
they
are
related
for
much
but
slice.
Taking
a
different
annual
on
the
similar
approach.
We
were
looking
into
ways
to
be
doing
translation
between
the
two,
although
there's
a
Python
implementation
from
Christine,
a
masseuse
that
is
able
to
do
coral.
D
D
Some
of
the
things
that
we
learned
over
the
weekend,
it
seems
to
be
coral-
is
working
especially
with
using
for
resource
discovery
but
also
beyond,
and
one
experience
that
was
that
these
hackathons
are
very
useful
for
getting
the
implement
a
and
testing
guidance.
In
particular,
on
coral
distances,
we
had
people
who
were
actually
finding
coral
and
multiple
implementers
over
the
same
table
get
a
lot
of
good
feedback
on
on
the
approaches
on
both
sides,
and
also
it
seems
we
are
now
getting
better
ideas
on
how
all
this
should
be
integrated
together
to
actually
achieve
interoperability.
D
D
We
started
with
the
data
that
model
component
reusability
discussions,
for
example,
discuss
the
vocabulary,
definitions
and,
and
what
kind
of
term
mappings
we
do
need
their
terms
were
discussing
for
affordances
traits,
resources,
object,
etc.
Different
models
used
light
click
on
different
terms.
How
do
these
fit
together
and
how
can
we
use
those
to
go
actually
across
different
models?
D
Some
conclusion
was
that
we
do
need
tools
that
we
can
use
to
describe
these
data
models,
and
we'd
also
seems
to
be
need
for
language
that
is
independent
from
from
the
transport
and
this
common
metamodel
language
that
Michael
will
be
discussing
it
later
is
one
example
of
that,
and
also
there
are
a
lot
of
choices.
What
you
have
to
do
when
you
design
this
datum
was
in
particle,
how
fixed
or
dynamic
features
suited
a
the
models
have,
and
we
did
manage
to
gather
a
bit
of
guidance
and
that
may
be
getting
a
bit
more
formal.
D
D
Speaking
of
hypermedia.
Well,
one
topic
was
using
color
to
bring
more
hypermedia
to
iot.
One
observation
we
had
two
is
that
the
coral
today
comes
without
batteries.
You
need
a
bit
more
to
actually
build
your
application
on
it,
so
we
should
perhaps
start
building
some
of
those
aspects
to
make
it
more
easy
to
use
in
in
real
use
cases.
D
One
thing
was
this:
common
composable
vocabulary
in
part
well,
link
relation
types
that
that
could
be
defined
and
also
tools
are
around
coral.
One
tool,
for
example,
was
this
TD
and
in
coral
transformations
we
did
discover
that
this
whole
topic
of
authorizations
like
who
is
allowed
to
say
what
and
and
where
and
when,
when
it
comes
to
link
relations
and
how
we
can,
for
example,
use
this
in
our
days.
D
It's
very
interesting
topic
to
explore
more
and
also
coral,
complex
Cora
is
a
very
simple
format,
but,
of
course,
the
more
features
you
add,
more
complexity
out
there
and
one
interesting
design
goal
when
it
comes
to
link
format
was
that
you
cannot
have
it
only
in
ROM
and
that's
what
we
call
a
row,
mobility
and
and
how
much
of
that
can
you
have
with
coral?
In
what
kind
of
that
boundary
conditions
seems
to
be
an
interesting
area
to
explore
more.
D
One
good
observation
on
this
kind
of
models
was
that
we
really
need
to
make
this
useful
for
domain
experts
cause
oftentimes
when
these
models
would
be
described
by
a
language.
It
is
someone
who
may
not
have
years
of
IETF
or
data
model
back
from
it
actually
has
to
mine
expertise,
for
example,
in
agriculture
or
smart
metering.
So,
instead
of
showing
a
what
we
call
a
core
dump,
perhaps
something
more
human
friendly
language
is
an
important
design.
Consideration.
D
We
had
a
whole
session
on
on
security.
There
is
already
one
draft
new
traffic
on
that
enabling
network
access
for
IOT
devices
from
the
cloud
currently
an
individual
submission,
but
something
we
could
consider
as
an
Archie
document.
Also.
What
we
were
discussing
is
that
would
be
very
good
to
document
some
of
those
success
factors
and
lessons
that
we
have
learned
from
different
security
mechanisms
in
this
area.
D
For
example,
why
EAP
has
been
rather
successful
in
its
own
area
and
also
when
it
comes
to
the
security
work
outside
of
the
tilting
Archy,
but
within
ietf
like
if
we
can
come
up
with
specific
requirements,
especially
on
the
constrained
IOT,
for
example,
for
new
crypto.
That
would
be
very
huge,
very
helpful
for
the
rest
of
the
community.
D
H
and
IOT
has
been
a
very
popular
topic
in
denoting
artyom
over
over
years
already,
and
this
is
something
that
also
Co.
Energy
and
energy
are
working
on
on
various
aspects.
We've
been
looking
mostly
on
the
IOT
specifics
on
this,
but
there
seem
to
be
a
lot
of
interesting
work
to
be
done
together.
We
con
r.g
and
energy,
but
the
question
here
was
having,
at
the
thing
centric
view
to
edge
computing.
We
also
discussed
this
some
called
beyond
its
edge
and
even
abyss.
D
Computing
was
one
term
that
was
raised
during
the
session
and
also
what
kind
of
instance
is
today.
Do
we
have
of
this
internet
for
resources
and
computing
and,
for
example,
pops
up
rocker
was
raises
one
instance
of
data:
do
we
have
already
in
the
core
infrastructure
some
examples
of
storing
some
of
your
representations
in
in
the
network
and
having
network
infrastructure
helping
you?
D
There
is
a
in
video
submission
between
you,
RT
already
on
the
IOT
in
the
credit
bit
edge
computing.
We
concluded
that
that's
perhaps
a
good
way
to
continue
with
our
collaboration
and
an
extending
on
that
and
perhaps
considering
later
adopting
as
an
RT
document,
there's
also
one
spin-off
topic
from
this
whole
H
and
an
IOT
which
was
this
in
300
IOT.
So
of
course,
the
industrial
side
has
a
lot
of
commonalities
with
the
other
areas,
but
it
also
has
some
specific
requirements,
for
example
on
the
criticality
of
different
operations.
D
So
what
is
what
is
that
piece
that
is
is
different
in
industrial
area
and
how
to
explore?
That
was
one
one
thing
that
we
highlighted
and
finally
something
we
didn't
have
in
the
agenda
originally.
But
what
that
lemon
raised
up
as
an
interesting
topic
is
this
layer,
three
considerations
and
that
called
single
thing
end
to
end.
So
it
seems
that
there
are
quite
a
few
challenges
still
when
it
comes
to
routing
and
reach
ability
when
you
are
connecting
constraint.
D
Node
networks
such
as
trip
networks
with
each
other
over
over
a
LAN,
for
example,
home
network,
so
things
as
of
today,
it
says,
don't
happen
automatically,
but
you
do
need
some
infrastructure
management,
for
example,
the
home
network
control
protocol.
Also,
there
are
challenges
when
it
comes
to
discovery.
We
did
discuss
that.
We
have
quite
a
lot
of
tools
on
this
in
the
core
core
set
up,
for
example,
resource
directory.
But
then
you
also
run
into
challenges.
How
do
you
actually
find
your
resource
directory,
in
particular
in
this
kind
of
heterogeneous
environment?
D
Also
on
the
security
side
for
an
isolation
conference,
Warren
was
one
of
the
mechanisms
that
were
highlighted
could
be
helping
here.
But
overall
the
conclusion
was
a
bishop.
Someone
should
probably
implement
all
this
and
really
see
where,
where
are
the
gaps,
we
do
think
we
have
a
good
set
of
tools
available
that
do
they
actually
fit
in
practice
as
well
together,
as
we
think
probably
some
good
implementation.
Work
would
be
very
helpful
here.
D
D
B
Okay,
everyone
ready
yeah
good
yeah,
so
this
is
another
update
of
this
yeah
collaboration
with
w3c,
where
we
have
the
web
of
Things
activity.
Main
part
of
the
work
is
happening
in
the
working
group
at
the
moment.
As
a
quick
reminder,
this
is
the
big
picture,
what
we
are
working
on.
So
what
we
have
is
a
big
umbrella
document
about
the
what
architecture
and
there
we
basically
describe
blue
sheets
are
coming.
B
They
we
describe
how
the
building
blocks
that
we
are
standardizing
fit
together.
So
the
overall
idea
is
that
we
do
not
define
a
complete
vertical
solution
that
now
everyone
has
to
implement,
but
we
look
at
standards
that
complement
what
is
already
out
there
and
help
the
inter
probability
and
the
integration
of
these
individual
systems
already
out
there
and
a
key
part
of
this
is
the
so
called
thing
description.
So
it's
a
document
format
that
allows
you
to
learn
what
a
thing
provides.
So
it
has
general
metadata.
B
It
has
what
we
now
conclude
it
on
calling
affordances
to
be
aligned
with
the
hypermedia
work,
and
it
also
includes
then
the
protocol
bindings.
So
you
can
figure
out
in
a
uniform
format
what
protocol
use,
what
weeks
has
have
been
applied
to
this
protocol
and
so
on,
and
we
have
the
central
interaction
model
to
simplify,
to
connect
this
with
applications.
B
So
this
was
work
on
defining
a
common
runtime,
a
bit
sim
or
similar
to
to
the
web
browser
where
you
have
a
common
common
runtime
to
define
web
applications,
but
it's
not
transferred
to
the
IOT
where
it's
more
about
automation
has
orchestration.
That
would
run
in
the
background,
but
still
against
a
standard
API
for
communication
and
so
on,
and
the
last
document
down
here
is
the
binding
templates.
This
is
basically
a
document
that
helps
you
to
define
your
finger:
scription
x'.
B
B
And
we
are
now
close
to
completing
this
work
on
the
first
set
of
building
blocks
here.
The
picture
is
now
as
follows:
the
architecture
document
and
the
finger
scription
recommendation
tract
documents,
so
in
w3c
speak.
That
means
those
will
become
standards
and
the
scripting
API,
unfortunately,
was
downgraded
to
a
working
group
node.
That
means
all
the
work,
all
the
findings
that
we
have
are
still
covered
in
a
document.
We
will
officially
publish
this
document,
but
it's
not
normative.
B
The
reason
for
this
was
that
the
kind
of
the
interest
of
implementing
this
and
gaining
experience
hands
on
discretely
decreased.
Unfortunately,
over
time
and
in
the
end
we
had
kind
of
two
two
camps
with
different
opinions.
The
central
problem
is
here:
api's
are
difficult.
There
are
so
many
styles
out
there,
and
often
it's
even
a
fashion
how
to
do
it
so,
for
instance,
even
in
the
WC
for
the
bet
platform
itself,
the
overall
recommendations
change
over
time.
B
So
this
would
be
an
item
that
we
take
to
the
interest
group
and
then
try
to
have
more
consensus
while
gaining
more
experience
actually.
Hence
on
implementing
this
good.
Let's
have
a
look
at
timelines.
So,
overall,
the
efforts
were
now
going
on
for
almost
five
years,
so
the
first
actual
work
in
in
the
w3c
started
in
2014,
with
workshop
with
quite
some
high
interest.
B
As
you
can
see,
the
now
bar
is
pretty
close
to
the
end
of
Charter
and
yeah.
We
are
currently
in
in
the
wrapping
up
face,
so
it's
a
lot
of
work
that
we
have
to
do
at
the
moment.
Our
last
face-to-face
meeting
was
end
of
January
to
mainly
work
on
the
test
Suites,
so
something
that
you
have
to
provide
in
WC
is
a
test
report
that
shows
that
the
recommendation
is
basically
implementable
by
two
independent
implementations
and
those
yabber
correctly.
B
According
to
to
the
specification,
we
have
then
prepared
the
supporting
documents
that
are
required,
like
an
explainer
to
send
it
to
the
TAC,
the
technical
advisory
group
of
w3c,
and
we
are
currently
running
the
fight
review.
So
for
everyone
who
is
interested
and
maybe
even
adopted
this
so,
for
instance,
there
is
a
collaboration
of
ocf
with
one
m2m
and
so
on.
B
Have
a
look
at
these
to
your
eyes
and
yeah
provide
us
with
anything
that
you
might
have
had
on
the
back
burner
or
yeah
thought
yeah
you
will
come
back
to
us
now
would
be
the
time
because
we
have
to
close
this
soon,
planets
to
publish
or
transition
to
the
so-called
candidate
recommendation
on
the
9th
of
April.
So,
basically,
in
roughly
two
weeks
that
means
it's
a
free
stem
and
we
then
have
to
work
on
the
test.
B
Suite
so
basically
provide
enough
test
results
that
show
that
this
document
is
complete
and
sufficient
to
implement
correctly
and
then,
according
to
to
the
process
of
w3c,
there
will
be
another
transition
to
the
so
called
proposed
recommendation.
If
we
are
successful
by
to
show
that
everything
is
quite
right
on
the
21st
of
May,
and
this
would
be
important
a
date
for
those
people
who
have
or
work
for
companies
or
organizations
that
are
active
in
the
w3c.
B
So
what's
this
about,
we
had
the
last
workshop
about
about
five
years
ago
and
back
then
to
see
what
is
the
general
interest
of
of
doing
this
kind
of
work
in
the
w3c,
so
more
application-centric
standardization
work
on
on
the
Internet
of
Things,
and
this
workshop
we
want
to
use
to,
of
course,
disseminate
our
findings.
Basically,
what
we
have
learned
in
this
quite
diversified
group
that
we
had
in
the
w3c
and
then
also
discussed
the
way
forward,
meaning
yeah.
B
B
We
have
this
call
for
participation,
so
this
is
a
w3c
process
that
it's
open
to
/
and
free
to
participate
at
these
workshops.
However,
you
have
to
submit
this
notion
of
interest,
which
is
just
them
yeah,
an
expression
of
interest,
so
you
basically
say:
hey
I'm
interested
in
this.
Can
I
please
come
if
you
want
to
have
some
stage
time
so
participate
in
some
of
the
panel
discussions,
give
a
keynote
or
presentation
and
so
on.
Then
you
have
to
create
a
submit
one
to
five
pages
position
paper.
B
Also,
if
you
have
a
good
opinion
on
on
what
should
be
done,
then
this
position
paper
would
be
the
right
format
for
you.
The
submissions
are
handled
through
easy-chair,
so
those
from
the
academic
background
should
be
aware
of
this.
The
deadline
is,
unfortunately,
pretty
soon,
so
the
15th
of
April
I
saw
that
there
are
some
of
the
announcement
systems
still
say
it's
the
7th
of
April.
B
If
you
find
that
always
pick
the
latest
date
that
you
find
on
some
official
source
at
the
moment,
it's
the
15th
of
April
notifications
would
be
then
end
of
April
and
then
there's
another
deadline
for
the
actual
registration
to
show
up
more.
You
can
find
under
this
link
here
for
the
call
for
participation
and
that's
it.
D
F
So
the
first
one
I'm
referring
to
your
Android
document
here,
it
just
sets
up,
sets
out
the
the
structure
sort.
It
describes
some
challenges
in
upscaling.
What
are
the
requirements
and
what
are
patterns
that
can
be
used
to
have
a
resource
directory?
That
is
not
only
a
single
thing
that
everything
depends
on,
but
a
composition
of
several
devices
that
together
act
as
a
larger
one.
F
A
one
like
the
the
I'd
not
say
tribute
the
solution,
but
the
first
solution
that
comes
to
mind
is
having
a
single
application
under
a
single
authority
that
has
some
kind
of
back-end
that
more
or
less
magically
orchestrates
things
and
whenever
the
request
comes
in
all
instances
of
that
application
refer
to
the
shared
database.
But
it
turns
out
that,
due
to
the
way
that
the
resource
directory
is
is
built,
it
is
not
necessary
to
have
such
a
tight
coupling.
F
So
there
is
very
little
running
code
to
back
this,
so
for
very
few
very
small
examples.
But
the
rough
findings
of
the
document
are
that
we
can
have
resource
directories
that
are
distributed
and
tolerant
for
signals
to
fail
and
still
provide
for
lookups
still
allow
registrations
and
still
have
a
way
for
registered
devices
to
say
that
to
recognize
that
their
registration
partners
just
gun
and
they
failover
to
someone
something
different
different
yeah.
So
that
is
what
the
first
document
says
sets
out
and
yeah.
Let's
not
talk
about
something
else.
F
That
is
how
do
we
describe
with
which
device
is
another
device
talk?
So
let
me
very
briefly
sketch
out
the
scenario
where
we
are
having
a
small
device
that
talks
to
your
cell
phone
and
they
are
just
finding
each
other
in
a
local
network
and
have
an
address
to
express
that
name
that
that
relation,
whether
what
the
phone
is
looking
at,
but
as
soon
as
the
as
the
phone
leaves.
The
network,
for
example,
fails
over
to
to
sell
you
on
an
n-type
network.
That
name
won't
broke
anymore.
So,
let's
the
Louis
list.
F
What
do
we
want
of
names
so
stable
identifiers
is
something
that
it's
probably
good
because
cool
your
eyes?
Don't
change
and
the
your
eyes
are
what
we
are
using
in
web,
linking
they
should
probably
also
be
your
else
so
be
used,
be
usable
to
resolve
that
name
into
something
that
we
can
work
with,
and
they
should
be
able
to
set
us
up
for
enter
and
security.
So,
if
I
have
an
IPA,
if
I
have
an
IP
address
as
no
matter
how
stable
that
is,
that
won't
tell
me
how
I
know
how
to
trust.
F
Well,
if
you're,
probably
familiar
with
the
regular
scheme,
so
I
coop
plus
80,
is
something
that
core
is
working
on
to
have
a
single
scheme
rather
than
one
scheme
for
UTP
and
one
scheme
for
TCP,
and
then
we
need
to
have
something
that
is
certainly
a
property
of
that
device
and
the,
in
my
opinion,
best
thing
for
those
things,
especially
if
we
can't
rely
on
being
part
of
any
centralized
structure
for
a
hierarchical
structure.
For
that
matter
is
a
cryptographic
identifier
and
that
should
be
still
usable
in
for
expressing
a
particular
resource
on
that
thing.
F
F
Oh,
what
a
request
resolve
those
could
either
in
local
scenarios,
when
maybe
we
don't
even
have
an
uplink,
be
yourself
using
multicast
and
in
most
for
the
internet
case,
those
could
be
entered
into
a
distributed
hash
table
with
some
additional
ascertain
that
that
the
address
that
we
are
advertising
is
actually
an
address
that
is
backed
by
whatever
cryptographic.
Identifier
is
in
that
address.
F
Now,
of
course,
we
are
talking
about
constraint
devices
here,
so
those
will
in
all
likelihood
not
participate
in
that
THD,
but
we
can
have
helper
notes
and
those
helper
nodes
would
form
something
like
a
global
resource
directory
that
might
not
support
everything
that
resource
directory
is
set
out
to
especially
kind
of
in-depth
resource.
Lookups
will
not
work,
because
is
you
can't
just
find
everything
on
the
internet,
but
it
will
look
very
much
very
similar
therese
of
directory
and
participate
in
all
the
protocol
negotiation
steps
that
a
resource
directory
can
participate
in
as
well.
F
So
this,
of
course,
is
doesn't
kind
of
I
come
from
nothing.
So
I've
looked
at
several
other
earlier
approaches
to
the
same
to
the
same
issue
of
finding
names
for
things
that
can
be
used,
so
the
Tor
project
and
their
onion
addresses
are
certainly
a
large
influence.
I've
looked
at
various
others
as
well.
F
I
do
not
claim
to
have
read
through
all
of
that,
in
particular
the
probably
30
years
RFC's
on
hip,
but
those
are
all
things
from
which
we
could
from
which
I'd
like
to
learn
and
take
lessons,
and
much
of
that
has
already
gone
into
the
design
I'm
presenting
here
so
from
the
idea.
How
do
we
get
up
forward?
One
thing
is
this
relies
on
working
core,
so
there
are
two
to
kind
of
building
blocks
that
are
that
still
need
to
be
fleshed
out
next.
F
That,
for
me,
would
be
to
tour
us
to
write
some
to
do
some
prototyping
and
to
get
actual
running
code
and
then
to
answer
questions
of
operations
so
right
now,
I'm
having
an
opera
address
in
there
or
I.
Think
I
haven't
even
entered
something
into
an
eye
on
a
registry
yet
and
having
it
at
our
portal.
Using
it
at
our
codomain
is
definitely
a
step
up
from
that.
F
So
one
question
is
for
me
that
I
will
need
to
answer
in
the
course
of
this
is
how
will
that
work
in
particular,
but
also
something
that,
where
I
hope
to
get
feedback
from
a
research
group
is
who
else
would
participate
in
that?
So
how
could
that
be
spread
out?
Because
this
will,
if
it
is
to
succeed,
this
will
need
to
be
it's
an
effort
that
is
distributed
among
among
several
parties,
the
ghio
I'm
having
with
that
is
that
I
would
like
to
run
this
with
off-the-shelf
devices
by
2023.
F
F
What
this
can
mistakes
I
made
things
that
things
I
did
not
consider
all
the
things
that
are
that
someone
else
might
have
solved
an
interesting
question,
especially
with
respect
to
also
to
the
chairs,
and
is
that
is
this
at
all
the
right
place,
so
I'm
standing
here,
because
basically
I'm
resource
directory
or
application
moved
here
and
I
think
this
is
a
good
place,
because
this
is
definitely
something
experimental,
but
I
might
be
wrong,
but
the
most
important
purpose
of
this
presentation
is
to
to
gather
you
in
so.
Do
you
have
requirements
for
for
similar
applications?
F
G
G
We
need
that
replication
in
many
places
and
in
many
use
cases
and
I've
seen
this
being
applied
in
various
industries,
that
without
replication
we
find
extremely
weird
implementations
where
suddenly
a
resource
directory
becomes
a
co-op
server
and
then
they
put
a
client
inside
it
and
then
try
to
do
registrations
toward
a
different
resource
directory
and
so
on.
So
I
think.
That's
that's.
That's
really
good
and
I
hope
that
that
work
goes
forward
and
then
the
something
completely
different
part
that
is
interesting.
G
I
am
obviously
very
keen
on
the
protocol
negotiation,
as
well
as
the
effortless
80.
So
I'd
like
to
discuss
this
more
flying
with
you.
Unfortunately,
I
was
not
able
to
look
through
this
rough
before
today,
but
but
I.
Think
I,
like
the
ideas.
What
you
proposed,
and
especially
the
prior
art,
is
it's
it's.
It's
there
I
think
there
are
some
things
that
we
can
also
look
outside
this
prior
art,
for
example
ocf
as
a
similar
scheme
that
you
could
resolve.
So
we
could
talk
about
that
bit
later
yeah.
Thank
you.
So.
H
Eric
dawn
marks,
I
didn't
capture
in
the
case
of
the
global,
you
know,
resource
directory,
be
the
DHT
or
anything
else.
So
what
are
the
thoughts
about
sort
of
having
some
level
of
control
about
who
can
see
what
information
sure
these
are
basically
hashes,
but
still
I
might
only
want
to
expose
you
to
my
company
or
my
family
or
whatever
yeah
so.
F
There
there
are
three
answers
that
I
have
to
this.
First,
is
that
when
it
comes
to
things
that
the
device
has
about
itself,
which
usually
in
a
resource
directory
registration,
are
all
my
different
resources,
those
would
probably
be
alighted
by
most
devices,
which
is
okay
with
the
resource
directory.
Now.
The
second
is
what
do
I
know
of
this
hat?
What
can
I
know
of
this
hat
and
I've
talked
to
people
from
the
Tor
project
and
with
their
version
three
identifiers.
F
F
That
name
is
looks
like
a
tor
address,
so
that
is
60-ish
characters
of
base
32
and
coated
parts
that
are
formed
from
a
authority
component
under
well-known,
well-known
domain,
and
the
third
part
is
about
restricting
control
with
respect
to
two
organizations
now
there
first,
this
does
not
by
itself
expose
the
devices
from
the
network.
So
if
your
device
is
unreachable
from
the
outside,
unless
the
device
asks
someone
outside
to
proxy
for
it,
it
will
still
not
be
reachable.
F
H
So
I
think
convinced
me
that
the
most
you
can
do
is
sort
of
count
how
many
people
are
sitting
behind
some
set
of
it
might
be
at
this
prefix
I
can
count
them
if
I
had
access
to
the
whole
DHT
I
can
count.
This
is
a
big
organization
because
they
have
a
million
of
these
things
as
opposed
to
three.
Yes,
you
can
make
guesses
on.
F
H
D
Okay,
thank
you
Christian
and
regarding
your
question
to
the
to
the
chairs
yeah,
this
different
sounds
very
explorative
so
and
if
there
is
interest
in
the
group,
then
I
think
it's
certain
right
place
to
look
into
this
so
and
I
base
where
I
see
so
far.
Look
at
this
initial
interest
so
seems
worth
exploring
deeper.
Thank
you.
I
A
I
I
Okay,
so
if
you
saw
my
slides,
then
I
don't
mean
to
present
okay,
that's
fine,
okay,
so
I'll
just
I'll
just
start
so
yeah.
This
is
going
to
be
about
the
status
and
things
that
are
happening
around
IOT
extensions
for
schema.org.
We
used
to
call
this
IOT
schema.org,
but
we
aren't
probably
aren't
going
to
have
a
sub-domain
now,
as
you
see
from
the
presentation,
we
are
likely
to
integrate
directly
so
next
slide,
please!
I
Okay!
So
briefly,
we've
formed
a
community
group,
but
it's
still
not
active
that
the
plan
is
to
do
most
of
this
work
in
a
w3c
community
group
for
these
extensions,
but
we
haven't
actually
spun
that
up.
Yet
it's
formed
and
people
are
joined
and
more
people
can
join,
but
we're
not
really
using
it.
Yet.
The
next
step,
as
you'll
see,
is
to
engage
that
and
I
want
to
talk
about
how
we're
going
to
integrate
IOT
extensions
in
the
schema.org
and
then
a
thing
that's
recently
come
up.
I
I
But
some
simple
and
types
like
a
capability
provides
an
interaction
pattern
and
provides
output
data
and
that
can
be
used
of
course,
standalone.
Other
things
could
provide
output
data
data
item
constrains
are
already
there
in
property
value
constraints
and
we
want
to
add
some
property
types
for
features
of
interest.
So
we
can
say,
for
example,
that
this
temperature
sensor
is
measuring
the
oil
temperature
of
an
automobile
and
the
oil
is
the
feature
of
interest
and
doing
that.
Linkage
allows
the
semantics
client
to
be
able
to
understand
what
they're
doing
so.
I
The
definitions
themselves,
when
we
say
here's
the
thermostat,
here's
a
light
bulb
here's
the
capability
to
turn
something
on
and
off.
Here's
two
capability
to
set
the
level
of
something
those
might
not
be
in
the
ayats:
they
won't
be
in
the
schema.org
core
definition
model
they'll
likely
be
in
external
namespaces.
So
the
idea
is
to
just
integrate
the
the
basic
core
property
types
and
object
types,
and
then
let
the
people
who
want
to
define
things
use
their
own
namespace,
and
this
is
the
pattern
that
we're
also
seeing
in
this
one
data
model.
I
Okay,
next
slide,
please.
So
what
this
is
is
basically
just
a
description
of
what
we're
doing.
This
is
basically
the
core
model
right.
This
is
really
the
part
we
want
to
add
to
schema.org
and
the
next
slide
and,
along
with
the
extensions
for
feature
of
interest.
So
this
is
basically
basically
the
model
that
we've
been
developing
over
the
last
couple
of
years
of
collaboration
in
schema
or
in
IOT
schema
in
the
extension
group,
and
this
is
really
what
we've
come
up
with.
I
I
I
So
the
plan
is
to
basically
create
yep
github
issues
and
drive
discussion
in
our
collab
organization
and
in
the
community
group
and
at
some
point,
when
we
know
exactly
what
we
want
to
contribute,
we
will
go
and
create
issues
on
that
schema.org
and
engage
them
and
start
the
debate.
Discussion
about
you
know
how
to
add
this
stuff
to
schema.org
all
right.
I
So
now,
I
I
think
it's
a
good
time
to
go
back
and
now
that
now
that
I've
reminded
everyone
what
the
core
model
looks
like:
let's
go
back
and
look
at
one
data
model,
stuff,
okay,
so
the
proposal
is
to
basically
so
one
data
model
is
a
bunch
of
SDO,
Sandman
and
and
vendors.
So
it's
be
OCF
gsm,
a
oma
with
lightweight
m2m
and
google
and
smart
things
and
Amazon
and
Comcast,
and
basically
it's
to
create
a
high
level
semantic
model
that
does
not
require
a
particular
protocol
implementation.
So.
I
The
same
same
mission
that
we
took
on
in
this
game
about
organ
stanchions
and
what
it
turns
out
is
that
we're
probably
going
to
converge
on
the
same
patterns
and
the
alignment
is
uncanny
in
terms
of
how
how
well
it's
it's
I
guess
the
work
we've
done
is
held
up
pretty
well,
because
it
seems
like
that.
This
is
the
same.
The
same
conclusions
are
being
made
in
this
group
I'm,
currently
at
the
first
face-to-face
meeting
of
this
group
and
already
made
proposals
of
the
nature
that
are
well.
I
Basically,
it's
a
high-level
semantic
model
with
protocol
bindings,
and
it
says
that,
for
example,
you
can
you
can
turn
a
light
on
or
off
or
a
measured
temperature
or
set
a
set
point,
and
then
do
that
based
on
the
abstract
high-level
model
in
the
application,
and
then
the
system
will
be
able
to
sort
of
select
the
protocol
bindings
and
figure
out.
You
know
from
the
protocol
bindings
that
you
need
to
go
to
a
post
at
this
particular
address
and
and
what
the
format
should
be,
what
the
data
types
are
and
this
sort
of
thing.
I
So,
let's
look
at
a
couple
of
examples.
I've
got
some
of
that.
I
pulled
out
here
next
slide,
please
so
the
UML
model,
okay,
this
is
just
a
repeating
what
we
already
said:
there's
the
thing
and
it
has
capabilities
and
they
have
interaction
affordances
which
can
be
events,
action,
properties
and
then
there's
some
data
types
and
data
typing
is
for
the
range
and
the
range
units
things
like
that.
I
What's
in
a
non
net,
cetera,
okay,
next
slide,
please
so
I'm
just
gonna
blow
through
these
and
not
go
line
by
line,
but
here's
describing
a
switch
and
a
switch
level
capability,
which
is
an
on/off
and
a
dimming
capability,
and
basically
it
says
for
a
switch.
I,
have
a
value
property
and
an
on
and
off
actions
and
for
the
level
property,
I
have
a
level
property
and
a
set
level.
Action
really
simple.
I
Next
next
slide,
please
yeah!
So
then,
the
those
things
link
this
here
are
some
of
the
things
they
link
to
so
remember,
I
guess
I
explained
a
little
bit.
This
is
essentially
json-ld,
which
is
JSON
with
some
RDF
hooks
that
allow
you
to
do
namespaces
and
you
are
eyes-
and
things
like
that.
So
when
we
say
add
ID,
that
means
that
this
thing
is
meant
to
be
linkable
from
externally.
This
is
a
URI,
it's
defining
where
this
thing
is
in
the
in
the
data
space
by
URI,
so
the
switch
level
level
property.
I
That's
the
thing
that
I
can
refer
to
from
another
file
right
and
says
that
a
level
property
has
a
subclass
of
affordance
and
it
has
switch
level
data.
It
has
a
data
item
and
then
it's
saying
the
set
level
action
is
a
is
also
an
interaction
affordance,
it's
an
action
type
and
it
has
level
data
and
rate
data.
So
basically,
with
this
information
that
the
application
knows
what
you
know,
what
what
kind
of
data
items
and
are
available
and
then
next
slide,
please
and
the
data
items
themselves
are
defined
and
yet
another
place
again.
I
It's
a
smart
things,
pseudo
device
that
you
have
access
to
in
the
cloud,
but
it's
just
basically
a
you,
might
call
a
shadow
or
a
mirror
so
at
the
data
items
that
we're
using
your
value
data,
that's
the
on
off
the
level
data
which
is
a
an
integer
from
0
to
100
and
rate
data,
which
is
a
an
integer
from
0
to
65535.
So
now
that
now
the
application
knows,
you
know
what
what
it
can
do
and
those
sort
of
what
the
data
items
are
needed
in
and
it
knows
how
to
conform.
I
Those
data
items-
and
this
is
all
the
definition
that
we're
doing
at
at
this
level
the
next
level
we're
taking
these
in
these
terms
like
switch
value,
data
and
level
data
and
putting
them
to
a
protocol
binding.
So
next
next
page,
please
yeah,
so
here's
an
example
of
a
protocol
banning
this
is
a
fragment
of
a
swagger
file,
an
AS
2.0,
and
it
says
this:
this
resource
has
a
path.
I
This
is
the
path
of
the
resource
and
it
has
get
in
host
operations
and
what
we've
done
is
added
annotations
to
say
at
type,
which
means
that
the
semantics
type
sort
of
tags,
these
things.
So
what
you
know
is
that
this
URI
exposes
a
value
property
and
it's
also
where
you
go
to
do
a
non-action
and
an
off
action.
And
then,
when
you
look
at
the
the
verbs,
the
get
gap
says
this
is:
this
is
how
you
you
access
the
value
property.
I
I
The
client
already
knows
how
to
how
to
look
through
the
swagger
and
figure
out
how
to
create
a
request,
but
it
doesn't
really
know
what
they
do,
and
so
this
basically
adds
information
about
what
these
requests
do
and
how
to
do
the
different
things
next
slide.
Please
in
the
last.
The
last
thing
is,
it
says
the
data
so
on
I
want
to
send
the
value,
and
this
is
basically
in
the
in
the
swagger
part
that
says,
describes
the
values.
It
says
it's
a
boolean
which
actually
doesn't
really
match,
who
the
the
other
example.
I
I
I
What
we're
planning
on
doing
is
working
on
the
existing
ontology
until
we
get
it
ready
to
put
into
schema.org,
and
we
need
some
broad
agreement
across
a
lot
of
different
communities
on
what
these
are
yeah
and
we
need
to
figure
out
how
to
make
the
definitions,
how
to
make
the
navigation
work
on
the
definitions.
So
we
have
a
web
page.
You
can
go
to
read
them,
nextslide
yeah.
So
on
the
definitions,
we're
basically
going
to
start
creating
these
examples.
I
Now
that
we
have
a
format
and
tools
and
all
that
work,
we're
going
to
go
forward
and-
and
you
know
have
have
as
many
of
these
examples
as
we
can
and
then
in
terms
of
tools
most
of
what
we
get
requests
for
to
make
this
easy
for
developers
to
use.
So
the
same
thing
is
happening
in
one
data
model,
so
basically
we're
looking
at
a
best
practices
guideline,
and
eventually
some
tools
and
scripts
that
allow
the
developer
to
automate
a
lot
of
the
redundant
part.
So
that
means
all
right.
So
we're
looking
at.
I
Probably
adding
a
few
new
classes
like
data
typing
and
some
some
common
thing,
types
that
and
and
also
enumeration,
so
we
may
be
adding
a
little
bit
more
to
the
ontology,
but
these
are
things
that
that
general
problems
in
the
industry
that
need
to
be
solved
like
what
the
enumerations
for
the
fan
mode
of
a
thermostat
and
things
like
that.
For
example,
you
want
to
make
those
interoperable
as
well
right
next
slide,
please
so
yeah
building
the
web
interface.
I
We
probably
need
to
use
shapes
constraints
and
and
do
some
navigation,
and
then
we
need
to
figure
out.
If
you
go
to
schema.org.
How
do
you
get
over
to
this
other
namespace
and
then
agates?
These
definitions
is
that
one
entry
point
or
separate
or
whatever
we
need
to
figure
all
that
out.
I
think
that's
about
it.
That
was
probably
one
more
slide.
Yes,
yeah
future
of
interest.
So
this
is
a
thing
where
what's
happened
in
the
last
couple
of
years.
I
That's
I
think
that's
all.
Is
there
one
more
slide?
Yeah?
No,
that's
it!
Okay!
So
that's
that's
where
we
are
the
you
know.
The
big
news
is
this:
one
data
model
thing
which
really
is
is
in
its
early
stages,
but
I'd
say
that
the
outlook
is
very
good,
that
a
lot
of
these
st
o--'s
and
manufacturers
can
make
some
some
agreements
at
this
high
level.
A
I
So
I'm
I'm
in
Philadelphia
at
the
first
face-to-face
meeting
of
the
one
data
model,
I,
wouldn't
even
call
it
an
organization.
It's
a
I,
don't
even
know
I,
guess:
I
guess,
you'd
call
it
an
organization,
but
we
have
a
group
of
folks
and
we're
we're
getting
together
to
sort
of
hash
out
some
of
the
high-level
details.
I
It's
an
oxymoron.
You
know
how
we're
going
to
go
about
this
and
it
really.
It
really
started
off
as
a
fairly
low
level
thing
that
okay,
there's
a
ZigBee
model,
there's
an
ocf
model.
There's
a
lightweight
m2m
model.
How
do
we
do
we
just
pick
the
best
one?
You
know
what
do
we
do
and
through
through
the
discussions
that
led
up
to
this
we've
kind
of
come
around
to
realizing
that
we
mean
you
know
we
need
to
do
something
like
capabilities,
events,
actions
and
properties
that
everyone
now
agrees
that
we
really
want
to
decoupled.
I
I
You
know
like
this,
this
earlier
thing
that
we
earlier
slides,
we
saw
of
how
we
could
use
json-ld
with
namespaces
and
all
of
that
as
a
common
definition
format,
and
no
one
else
has
proposed
in
the
alternates,
so
it
looks
like
we
may
be
able
to
go
forward
with
a
lot
of
without
a
lot
of
arguing
about
what
the
format
should
look
like
we'll
see
anyway.
This
afternoon
is,
is
the
concluding
quarter
of
the
meeting.
We've
met
all
day
yesterday
and
we're
meeting
today
and
this
afternoon
we're
going
to
work
through
some
examples.
J
J
I
That's
really
good
question
and
I
think
what
we're
what
we're
looking
at
is.
We
probably
want
to
enable
domain
experts
to
create
these
definitions
and
not
just
pull
things
from
exist
existing
stos,
so
we
want
to
get
people
who
are
more
well
domain.
Experts,
like
the
we
mentioned
with
IIC,
for
example,
we'd
also
like
to
get
people
that
don't
have
leis
on
agreements.
I
Currently
it's
sort
of
working
Eleison
agreement
with
with
ocf
and
ZigBee,
and
all
of
that,
and
we
have
some
invited
experts,
but
we
really
want
to
bring
in
people
from
my
ETF
and
I
RTF
as
well,
and
get
more
interaction
there.
We
have
some
people
who
are
in
both
like
Ari
and
myself
and
and
and
some
others,
but
we
really
want
to
try
to
open
it
up
a
little
bit
so
I'd
say
in
those
two
areas
get
at
the
other
representation
from
other
SDOs
and
other
people
that
are
building
definitions
and.
J
I
I
A
A
I
Thanks
and
one
more
thing:
if
anyone
wants
to
participate,
we
have
a
way
of
inviting
experts.
We
have
an
invited
expert
kind
of
category
that
they
obviously
won't
be
able
to
participate
in
some
of
the
if
we
go
into
any
NDA
space.
But
why
am
I
hoping
we
never
have
to
do
that?
We
try
to
keep
it
all
open.
So
please,
let
me
know
if
you'd
like
to
participate
and
I'll
try
to
get
an
invitation
for
you.
H
A
You
know
I
think
it's
good!
Thank
you.
So
maybe
we
should
provide
a
link
to
to
that
tutorial,
which
is
recorded
on
on
youtube.
If
you
want
to
have
a
little
bit
more
detail
on
how
coral
works-
and
this
segment
here
really
is
about
looking
at
the
larger
world
of
how
you
can
build
applications
in
a
restful,
hyper
media
oriented
way
and
talk
about
the
the
place
that
coral
has
in
in
this
world.
So,
let's
hand
over
to
tell
us.
K
Thank
you,
so
happy
already
talked
a
bit
earlier
in
this
meeting
about
what
we
did
did
at
the
hackathon
and
I
have
a
few
slides
and
just
to
provide
a
bit
more
background
on
what
we
did
there
and
then
I
guess.
It
would
be
a
good
opportunity
to
take
some
time
to
for
discussion
and
next
steps
and
how
we
might
want
to
move
forward
with
this
and.
K
Slides
for
that,
before
I
come
to
to
the
hackathon
things,
I
would
to
briefly
talk
about
hyper
media
in
the
ITF
and
I
RTF
in
general.
So
this
idea
of
using
hyper
media
for
infections,
where
there's
not
a
human
in
front
of
the
screen
clicking
on
links
and
looking
at
funny
pictures
but
using
it
to
drive
the
interactions
between
machines
has
been
around
for
a
while
and
several
occasions.
K
People
have
come
up
with
some
kind
of
hyper
media
format,
usually
based
on
JSON,
that
they
propose
for
for
driving
these
machine
to
machine
injections
in
some
way
and
the
surprising
number
of
those
have
been
published
as
internet
draft.
None
of
them
of
these
often
called
hypertext
application.
Languages
have
made
it
to
a
working
group
document
status
so
far,
but
as
the
number
keeps
increasing
over
time,
it
shows
there
is
some
potential
here
and
there's
also
some
need
for
Standardization,
because
essentially
all
of
these
formats
are
almost
doing
the
same
thing,
but
slightly
different.
K
So
bit
order
is
the
hypertext
application
language.
How
more
recent
is
jason
hyper
schema,
which
has
the
interesting
approach
of
not
putting
the
hyper
media
on
the
wire,
but
instead
augmenting
existing
json
documents
with
hyper
media
controls?
That
then
tell
you
how
you
can
interact
with
the
service
based
on
this
data
and
very
recent
is
the
profile
hypertext
application
language
and
with
which
is
unrelated
to
how
and
my
proposal
is
coral
for
a
while.
K
There
has
been
this
HTTP
link
header
field,
which
also
falls
into
the
category
of
providing
machine,
readable
and
machine,
understandable,
hyperlinks
for
navigating
and
detecting
with
HTTP
based
applications
and
the
core
working
group.
We
have
the
link
format
that
is
now
showing
a
bit
of
its
age,
so
we
are
thinking
of
maybe
replacing
that
with
coral
at
some
point
and
right
now,
the
primary
use
case
for
link
format
is
this
bone
or
resource
where
you
can
ask
a
server,
Kristen
Lee?
K
K
The
primary
one
is
based
on
C
bar
and
it's
very
compact
binary
format,
it's
suitable
for
constrained
environments
and
it
that's
the
biggest
difference
to
their
other
hypermedia
formats.
I
showed
on
the
previous
slides,
because
those
are
mainly
targeted
at
the
big
web
and
not
at
constrained
environments
where
every
big
and
every
byte
counts.
K
It
turns
out
that
this
binary
format
is
so
compact
that
you
almost
only
can
look
at
it
as
a
hex
dump
or
that's
not
very
useful
for
humans.
So
there's
also
a
text-based
format
for
coral
that
we
mostly
use
for
writing
down
examples
and
then
that
code
get
compressed
into
the
binary
format
and
if
I
had
to
summarize
coral
in
in
three
sentences
and
I
would
describe
it
as
it
gives
you
a
description
of
what
is
the
resource
that
you're
currently
looking
at?
K
K
It's
currently
brewing
something
it's
making
progress
and
it
has
some
limit
self
and
how
many
orders
can
be
queued
up
and
then
there's
essentially
a
queue
of
coffee
orders
that
the
Machine
will
produce
one
after
the
other
and
embedded
in
there
is
a
form,
a
create
form
that
instructs
a
client
how
to
crank,
create
co-op
requests
for
adding
new
orders
to
the
end
of
the
queue.
And
then
there
are
some
forms
for
counseling
some
coffee
order
or
posing
and
posing
it.
K
Then
we
had
one
example
where
we
had
a
w3c
thing
description
and
I
caught
it.
Michels
light
switch
because
it's
very
similar
to
what
we
just
saw
on
Michael,
slides
with
the
IOT
scheme
or
odd
update,
and
here
it's
not
using
a
made-up
example
of
coffee
machine
vocabulary,
but
the
existing
IOT
schema
exam
vocabulary
as
much
as
as
much
as
possible,
and
this
is
a
good
example
for
showing
this.
What
is
it?
What
operations
can
it
do?
How
does
it
relate
to
other
resources?
K
K
K
Then
I've
this
slide
you're
not
supposed
to
read
this,
but
I
went
to
the
omae
slip,
so
definition
of
reusable
resources.
So
they
have
these
definitions
of
resources
that
can
be
used
inside
of
episo--
objects
and
I.
Try
to
extract
this
list
of
resources
and
I
gave
each
one
a
name
that
can
be
used
in
coral,
so
this
could
be
a
first
step
for
expressing,
if
so,
structures
using
coral.
So
you
could
ask
if
so
implementing
device
what
what
resources
do
you
have
and
it
could
answer
using
coral.
K
If
that
could,
if
coral
could
solve
some
problems
there-
and
it
would
be
very
nice
to
hear
that,
but
so
that's
somewhat
independent
of
that.
We
also
now
have
a
bunch
of
specifications,
one
for
coral
itself
and
some
details
and
a
couple
for
essentially
showcases
of
poorer,
and
these
at
least
the
coral
document
itself
is
quickly
stabilizing
and
I.
Guess
it
would
make
sense
to
now
look
for
a
home
in
some
broken
coupe
for
it,
and
the
question
is:
how
do
we
do
that.
D
So
yeah
for
the
record
get
some
thumbs
up
from
the
audience
from
Christian,
so
yeah,
maybe
for
everyone
I,
don't
my
personal
experience
was
Cora
was
like
first,
it
took
a
while
to
get
my
head
around
it,
but
then
more
and
more
I
started
to
actually
understand
it.
The
more
useful
and
cool.
Yet
she
started
to
look
like
so
I
had
a
lot
of
fun
over
the
weekend
in
the
heck
I.
D
Don't
thinking
about
how
we
could
be
using,
and
especially
adding
these
semantics
to
coral,
and
how
can
we
be
modeling
systems
in
in
a
slightly
different
way
that
we've
been
doing
so
far
using
more
hyper
media,
also
in
in
the
IOT
space?
So
I
can
highly
recommend
having
a
closer
look
at
that
and
Thursday,
because
we'll
we'll
post
a
tutorial
also
somewhere
more
easy
to
access.
D
D
D
Yeah
I,
don't
wanna,
keep
you
away
from
your
from
your
dinner
plans,
but
for
the
meeting
planning,
so
we
showed
in
the
beginning.
What's
what's
our
another
plan
for
now,
so
you
can
see
see
the
list
here.
We,
of
course
having
is
used
well
with
IDF
summary
meetings,
but
these
meetings
usually
are
not
the
one
where
we're
doing
most
of
work.
D
We
have
those
meetings
coming
and
we
all
be
posting
all
of
this
information
on
the
mailing
list
and
then
in
part,
go
to
the
last
point,
as
I
mentioned,
like
very
interested
on
on
having
a
co-located
event
with
academia
this
year
next
year,
but
in
any
way
doing
bit
more
of
that
than
what
we
have
done
before.
So,
if
you
have
ideas
on
good
venues,
good
locations,
good
good
ways
to
do
that,
and
please
talk
to
us
chairs.