►
From YouTube: T2TRG Interim Meeting, 2020-06-08
Description
T2TRG Interim Meeting, 2020-06-08
A
A
Here
we
are
focusing
the
long
term
research
issues
of
the
internet,
so
we
are
not
doing
standards
development,
although
we
do
have
post
collaboration
with
IETF,
where
there
is
a
lot
of
standards,
development
happening
and
we
do
publish
occasional
information
on
experimental
documents.
But
the
key
goal
is
those
exploration.
A
A
A
A
We
cooperate
in
note-taking,
so
we
feel
free
to
chime
in
the
notes.
I
will
be
taking
some
notes
there,
but
anyone
is
feel
free
to
add
whatever
has
been
missed,
but
they
were
planning
to
experiment
with
slightly
different
notes
than
usual,
not
doing
full
transcribed,
but
rather
put
the
key
key
discussing
items
and
a
timestamp
on
the
notes.
So
then
we
can
refer
to
the
recording
for
more
detailed
aspects
whenever
needed.
So
you
will
be
seeing
some
timestamps
on
that
referred
to.
When
was
that
discussion
started.
A
A
So
we
are
a
resource
group
and
for
the
key
issue
were
focusing
on,
is
turning
the
real
IOT
into
reality,
quite
a
bit
focused
on
the
constraint
nodes
and
how
they
can
talk
among
themselves
with
the
wider
Internet,
but
in
particle.
We
are
focusing
here
on
aspects
that
have
standardization
opportunities
at
the
IDF
site,
so
starting
at
the
IPR
updation
layer,
working
up
all
the
way
up
to
its
obligations,
management,
api's
and,
of
course
not
including
not
forgetting
security
and
the
RT.
A
We
do
a
lot
of
collaboration
with
the
IDF
groups,
for
example,
core
and
an
Arabic
are
two
crews.
We
have
a
close
collaboration
with
so
there's
a
lot
of
intentional
overlap
in
the
work
and
often
often
times
document
starting
from
one
group
and
moving
to
others
and
documents
being
built
and
drafted
together.
A
Also
in
the
energy
we
have
this
activity
called
wishing,
and
this
is
a
slight
accident.
We
showed
in
a
previous
joint
meeting
with
Teresa
type
of
things
where
we
have
lot
of
overlapping
of
interest,
in
particular
in
this
meeting
on
the
modeling
of
data
interactions
for
IOT
and
also
respect
hypermedia
for
IOT.
But
there's
a
set
of
other
topics,
also
what
we
have
in
the
vc
activity.
So
if
you
are
interested
in
working
together
on
those
topics,
we
welcome
you
to
join
our
wishing
meetings.
A
A
few
words
about
our
history
with
the
drusy
w3c
web
of
things.
So
one
of
the
goals
of
thinking
Archie
is
this
facilitation
of
coordination
and
collaboration
between
the
IETF
active
groups
and
other
IT
related
organizations.
So
we
have
been
closely
in
collaboration
with
w3c.
Well,
things
are
pretty
much
from
the
beginning
of
both
of
the
groups,
so
we
have
have
stood
up
face
to
face
and
online
meetings.
We
are
doing
technology,
development
and
exploration
together.
We
are
building
tools
together,
having
common,
hackathons,
etc.
A
C
C
C
So
yeah,
so
the
one
of
things
is
a
working
group
and
an
interest
group.
If
in
WEC,
the
interest
group
is
an
exploratory
group
and
the
working
group
actually
developed
standards,
they
were
both
recently
reach,
our
turd
and
actually
the
interest
groups.
We
charted
in
November
and
the
working
group
was
just
reach
our
turd
actually
in
April
we
actually
started
the
process
much
earlier,
but
because
of
various
delays
we
had
to
delay
it.
C
However,
we're
both
not
reach
our
turd
for
near
two
years
and
there's
a
number
of
new
work
items
on
the
table
for
the
second
round.
Now,
the
previous
round,
we
just
finished,
we
did
publish
two's
to
do
with
recommendations,
but
I
will
summarize
briefly
in
a
minute
but
I
and
then
also
talk
to
the
new
work
items
and
what
we're
now
working
on
now.
The
general
goal
is
to
adapt
web
technologies
to
IOT,
but
that
covers
a
lot
of
territory.
C
One
of
the
key
strategies
here
is
a
descriptive
approach
where
we
describe
how
systems
work,
so
the
adaptation
layer
can
use
the
description
rather
than
using
a
prescriptive
approach
where
we
try
to
tell
people
how
to
do
things.
We
recognize
already
a
lot
of
things
out
there
there's
a
lot
of
brownfield
devices,
there's
a
lot
of
competing
ecosystems,
and
so,
rather
than
you
know,
playing
the
game
and
trying
to
get
everyone
to
switch
over
to
our
system
in
a
prescriptive
approach.
C
C
Architecture
basically
describes
the
high-level
constraints,
the
use
cases
actually
which
Michael
legaly
will
be
talking
about
our
recent
work
on
for
the
next
round
and
also
an
abstraction.
So
we
have
an
abstraction
if
the
application
layer
that
is
basically,
you
know,
describes
the
affordances
that
a
device
can
do
without,
and
then
we
also
have
a
protocol
binding,
which
describes
basically
how
to
map
the
high-level
abstraction
down
to
you
know
the
actual
protocol
layer,
but
the
idea
of
is
that
the
mapping
the
protocol
layer
is
done
automatically
by
the
system
and
the
user.
C
The
application
writer
needs
to
worry
about
the
high
level
abstraction.
Now.
The
thing
description
is
a
json-ld
one
point
file
that
embodies
the
description
of
a
given
device
or
thing,
and
this
is
just
a
short
little
brief
snippet,
to
show
you
the
general
idea.
So
there
is
because
it's
adjacent
LD
file,
there's
a
context
file
that
defines
basically
links
for
all
the
terms,
so
we
can
use
RDF
as
information
models.
However,
we've
avoided
a
dependency
on
our
D
app,
so
you
can
also
treat
the
things.
C
C
The
connection,
however,
with
RDF
is
that
semantic
tagging
annotation
can
be
added
to
thing
descriptions,
and
this
is
where
we
believe
is
a
connection
between
activities
like
the
one
data
model,
but
in
that
you
basically
have
properties,
events
and
actions
as
being
the
main
affordances.
Somehow
that
got
lost
here,
but
and
then
for
each
or
property
of
an
action
you
can
have
data
models
for
the
interactions
and
data
malls
are
done
with
basically
a
JSON
schema,
stylist
impacts,
but
which
also
applies
well
there
play
tables
besides
JSON.
C
This
is
our
overview
diagram
for
our
use
cases,
and
so
thin
scriptures
can
apply
it
to
a
lot
of
from
use
cases.
They
can
obviously
apply
to,
like
you
know,
looking
at
existing
devices
in
a
local
network.
They
could
also
apply
to
things
like
proxies.
Where
you
need
to.
You
know,
bring
data
into
the
cloud.
C
Let's
say
it
can
also
apply
to
things
like
digital
twins
and
the
cloud
that
or
databases
in
the
collab
and
you
ingest
data
from
a
device
and
also
gateways
and
synchronization,
so
you
might
have
to
hold
data
for
offline
devices
and
create
like
a
shadow
of
them.
So
we
are
now
in
the
midst
and
Michael.
Legaly
will
speak
to
this,
of
reviewing
our
use
cases
and
our
requirements
and
doing
a
lot
more
work
to
dig
in
to
detailed
use
cases
and
extracting
requirements.
But
I
will
let
Michael
talk
to
that.
C
Just
to
mention
that
the
applicability
of
a
thing
description
is
actually
quite
broad,
and
this
is
kind
of
good
news,
bad
news.
So
we
are
trying
to
narrow
down
precise
use
cases,
so
we
can
get
our
requirements
nail
down
a
good
example
requirements.
We
need
to
look
at
our
security.
What
exact
security
schemes
and
protocols
do
we
have
to
support
what
exact,
actually
communication
protocols?
Can
you
have
to
support
and
so
forth?
C
Another
thing
that
the
web
of
things
enables
is
orchestration.
We
currently
have
two
systems
that
have
been
built
that
are
available
to
do
orchestration.
Others
are,
of
course
possible,
but
there
is
a
scripting
API
document.
That's
been
written
and
has
been
specified.
It
is
currently
an
informative
document
and
there's
implementation
of
it
called
node
wot,
which
is
on
on
thing
web,
and
this
is
a
Linux
Foundation
project.
I
believe
you
know
Eclipse,
and
so
you
can
get
an
implementation
of
this.
C
It
runs
inside
nodejs,
it's
actually
a
typescript
implementations
also
strongly
typed,
and-
and
this
follows
the
specification
that
is
being
written
as
an
informative
document.
There's
also
visual
language
support.
So
there's
a
system
called
no
gen
that
can
take
a
thing
description
and
generate
nodes
in
node
read,
so
you
can
drag
and
drop
to
talk
to
devices
described,
I,
think
descriptions
and
the
basic
benefit
here
is
again.
C
Right,
okay,
so
let
me
talk
about
the
new
work
items,
so
at
a
very
high
level
you
can
see
was
a
bunch
of
different
things,
we're
doing
now,
some
of
these
most
of
those
in
the
first
column,
or
really
just
maintenance
operations.
So
things
we
have
to
just
fix,
and
so
a
good
example
of
this
would
be.
You
know,
default
for
observe
you
know
right
now.
We
have
you
know
some
protocols
have
an
observe
interaction,
but
it's
not
clear
on
save
example:
HTTP.
C
What
look
the
default
is
username
because
there's
six
different
ways
to
do
it
or
not
that
many,
but
so
so
just
make
it
easier
to
write
a
TV.
We
ought
to
define
some
defaults
for
some
of
these.
That's
a
simple
example.
Another
thing
that
be
useful
is
we
have
links,
but
we
don't
have
defined
relational
types
for
various
applications.
For
example,
I
might
want
to
link
Trinity
D
and
a
template
that
TD,
so
template
applies
to
a
class
of
devices.
C
A
TV
applies
to
a
particular
device,
an
instance
so
be
nice
to
have
a
standardized
relational
type
for
that
to
connect
a
TV
to
its
ta
template.
That's
just
one
example:
there's
lots
of
different
relationships.
You
might
have
to
find
between
things
these
RNA
already
I
na
type
lots
of
linked
relations,
so
the
issue
here
is
just:
can
we
can
we
pick
particular
relational
type
and
and
give
it
a
precise
definition
in
our
in
our
use
case
in
the
middle
column
is
more
complicated
things
we
to
do,
and
so
one
of
these
is
profiles.
C
So
one
of
the
problems
with
a
descriptive
mechanism
is
it
can
it's
open-ended,
so
it
can
conceptually
describe
all
kinds
of
new
things
that
mean
will
exist
when
the
spec
is
defined.
So
that's
great.
The
problem
is
when
implementer
comes
along
and
meets
implement.
Something
may
know
that
it
works
out
of
the
box.
They
want
to
know
they
don't
have
a
finite
set
of
things
the
implement,
so
we
need
to
state.
C
You
know
what
are
the
finite
set
of
things
that
an
implementation
has
to
support
in
order
to
get
out
of
the
box
interpreting
and
so
the
approach
taking
here.
It's
look
at
profiles.
This
is
still
ongoing.
Work
we're
still
discussing
precisely
what
needs
to
be
in
a
profile
so
there's
also.
Besides,
like
you
know,
protocols
that
are
supported
or
not
are
schemes,
security
schemes
or
support,
or
not
it's
also
things
like
how
should
we
have
limits
on
string
lengths
or
you
know,
finite
devices
and
so
forth?
C
This
also
relates
actually
to
a
topic
we'll
talk
about
later
on
for
discovery.
If
TVs
are
unbounded
in
length,
it
makes
protocol
discovery
tricky
and
then
I
mentioned
templates
already.
This
concept
needs
to
be
refined,
it
turns
out
there's
multiple
use
cases
for
templates
and
we
have
to
figure
out
what
the
requirements
are
and
make
sure
that
the
template
satisfy
me,
for
example,
should
security
schemes
being
a
template,
should
there
be
a
URI
template
for
forums
etc?
C
We
talked
about
discovery
today,
which
is
basically
how
do
you
get
a
thing
description,
other
topics
which
will
only
get
into
identifiers
we're
actually
looking
at
decentralized
identifiers
as
one
option
here,
but
there's
also
the
issue
of
things
like
rotating
identifiers.
What,
if
I,
have
a
thing
in
a
directory
and
the
identify
changes
they
want
to
rotate
it,
how
do
I
notify
people
etc.
C
So,
here
these
schemes,
we
we
talk
about
OAuth,
lately
and
other
possible
schemes,
and
we
need
to
figure
out
what
schemes
we
need.
What
these
cases
are,
and,
yes,
and
also
I
guess-
has
been
a
lot
of
work
lately
on
MPT
under
protocol
vocabulary
and,
generally
speaking,
new
protocols
are
being
considered.
C
C
A
Control
so
since
we
are
not
a
massive
group
whenever,
if
there's
a
natural
pause
to
ask,
questions
go
ahead
and
chime
in,
if
there's
more
discussion
ongoing,
you
can
always
put
a
Q
plus
into
that
chat
of
the
WebEx
and
then
we'll
be
picking
up
people
from
there.
But
both
options
are
available
for
you
to
own
questions
and
comments.
Thanks.
D
C
D
C
Exit
here,
people
should
also
check
their
on
this
list.
The
attendees
so
make
sure
you
got
me
captured
me.
They
can
take
a
moment
to
review
that
some
of
the
people
logged
in
didn't
use
the
real
name
in
the
WebEx.
So
it's
hard
for
us
to
know
what
to
put
here.
I
think
that
was
Ken's
been
captured.
Biscuit.
E
E
E
Michael
already
introduced
the
topic
when
he
gave
the
entire
overview
about
what
of
things
work.
Items
in
this
photo
period
and
I
have
a
little
bit
more
details
on
that
one
and
the
editor
co-editor
of
the
architecture,
taskforce,
I'm,
driving
the
work
there,
and
we
have
quite
a
lot
of
things
on
our
plate.
Just
increase
mine,
I.
E
E
In
terms
of
use
cases,
we
do
have
20
new
use
cases
in
the
pipeline
and
more
are
to
come.
So,
while
we're
speaking,
people
are
creating
with
requests
and
contributing
with
use
case
descriptions,
we
do
have
a
template
which
is
simple
and
straightforward.
It
basically
asks
for
most
motivation.
It
asks
for
what
stakeholders
are
involved
in
the
use
case.
What
kind
of
typical
flows
are
there
potential
variations
and
already
to
assess
the
potential
gaps
and
things
that
need
to
happen
to
the
thing
specifications?
E
Ultimately,
architectural
description,
security,
protocol
funding
and
others,
and
we
have
active
contributions
and
I
believe
this
list
is
outdated.
We
have
additional
contribute
less
specifically
to
have
a
FRA
offer
and
a
couple
of
others.
So
if
you're,
not
in
the
listing
on
this
call
apologies,
this
slide
is
a
little
bit
older
in
terms
of
target
domains.
E
Having
gateways
being
able
to
transfer
I
mean
the
same
abstract
level
in
terms
of
thing.
Description
in
terms
of
I
would
call
it
device
model
across
different
protocols.
But
then
we
have
a
couple
of
accessibility
use
cases
that
were
contributed
and
included
from
an
MRI
group.
We
have
automotive
use
cases.
This
is
just
an
exemplary
one.
It's
not
a
configuration
management,
we're
not
trying
to
be
exhaustive.
E
Here
we
are
trying
to
find
one
key
good
use
case
for
a
category
and
for
a
domain
and
if
there
are
many
variations
or
other
additional
ones,
we're
trying
to
get
these
in
the
key
requirements.
For
these
specific
cases,
then,
for
anything
in
smart
grid.
We
have
a
use
case
for
integration
of
generational
storage,
grid
management
and
consumption
of
energy
transportation.
E
F
E
I'd
like
that,
then
we
have
Freetail
where
we
interconnect
and
integrate
multiple
devices
into
common
retailer,
workflows,
audio
video
and,
let's
use
case,
contributed
by
broadcaster
to
synchronize
home
devices
with
TV
program,
content,
agriculture,
smart
agriculture,
greenhouse
horticulture,
to
create
an
optimal
environment
for
growing
plants
by
combining
sensors
and
gateways
and
measuring
all
kind
of
environment
data,
including
temperature
and
climate
to
optimize,
the
plant
growing
environment,
smart
city,
to
manage
mobile
devices
and
sensors
in
a
smart
city,
health
monitoring
for
a
public
health
and
private
health
specifically
well,
it
gained
three
stand
attention
to
two
coronavirus
manufacturing
to
monitor
production
lines
and
plants
and
predict
and
prevent
fault
conditions
by
having
world
metrics
and
sensor
data
and
being
able
to
find
deviations
of
expected,
behavior
quite
early
anomalies
from
multimodal
system
integration.
E
That's
another
I
use
case
and
category
common,
diverse
lifecycle
model
I'm
going
to
talk
about
that
further
on
and
something
that
came
in
recently
use
cases
for
or
to
flow
will
be
able
to
make
sure
that
we
addressed
in
your
art
requirements
and
the
flows
that
are
needed.
So
these
are
is
the
current
list
in
the
initial
lists
and
we're
working
on.
E
We
have
decided-
and
we
want
to
shortlist
these
cases
to
make
sure
there
is
real
market
needs
and
also
to
make
best
use
of
limited
resources,
and
we
also
want
to
prioritize
use
cases
that
grow
the
IOT
market
in
general
and
also
develop
that
adoption.
So
we
want
to
focus
in
the
deep
level
requirement,
analysis
and
future
work
and
to
make
sure
that
it
meets
market
demands.
So
we
try
to
answer
the
primary
question
of
what
advantage
the
use
of
what
brings
to
spec
adapters.
E
So
this
is
basically
the
process
that
we
are
implementing
where
we
are
in
the
yellow
orange
block
at
the
moment.
So
you
can
imagine
timeline
on
the
bottom
of
the
end
of
the
diagram.
We
have
a
list
and
a
set
of
use
cases
who
we
are
doing
a
short
listing,
I'm
going
to
talk
about
the
process
in
a
minute
and
based
on
the
short
list.
We
do
kind
of
iteration,
where
we
go
into
gaps
identified
and
from
new
building
blocks
that
need
to
be
addressed.
One
obvious
candidate
is
a
discovery,
run
component
and
corresponding
directory.
E
Another
potential
outcome
can
be
a
gap
of
an
existing
specification
and
these
are
described
in
requirement
documents.
So
we
already
started
to
do
that
and
also
system
configuration
can
be
a
gap,
and
these
requirements
then
address
different
deliverables,
so
security
privacy
guidelines
and
documents
and
thing
description,
scripting,
discovery
and
profile.
E
We
are
almost
starting
to
have
a
to
ever
vote,
so
we
want
to
ask
all
working
group
and
interest
group
members
about
their
personal
company's
assessment
of
the
use
cases,
so
we
are
conducting
a
w3c
questionnaire.
We
plan
to
publish
this
week.
It
is
basically
asking
for
all
of
these
use
cases
whether
there
is
whether
this
is
a
business
critical
use
case
for
a
respondent,
whether
it
is
less
critical,
whether
it's
nice
to
have
or
completely
uninteresting
and
also
in
terms
of
future
work
and
during
the
deep
dive.
E
E
I
already
mentioned
that
we
create
a
one-page
requirements
document.
We
follow
a
template
and
there's
a
couple
of
examples.
The
work
has
started,
but
we
are
currently
more
in
the
consolidate
use
cases
and
things
and
just
starting
on
requirements.
We
have
I
think
two.
It
clumps
was
two
or
three
examples
at
the
moment.
E
One
more
word
on
the
interest
rate
interest
group
use
case
task
force
that
we
recently
started
for
collecting
additional
use
cases.
So
we
realized
that
if
we
are
doing
this
work
only
in
the
worth
of
things
working
group,
we
are
limiting
the
scope
and
we're
limiting
the
domains
to
only
working
for
participants
who
are
already
members,
and
we
want
to
make
sure
that
we
collect
input
from
a
wider
LT
market
audience
in
terms
of
scenarios
in
terms
of
use
cases
in
terms
of
requirements.
E
We
are
trying
to
be
as
open
as
possible
to
get
all
inputs
on
the
plate,
to
review
everything
every
contribution
and
to
make
sure
that
the
work
of
things
specifications
match
and
address
the
requirements
from
a
wider
audience.
So
we
are
trying
to
get
as
many
voices
for
us
as
possible,
and
this
is
an
open
invitation
if
anybody
on
this
call,
as
additional
requirements
has
additional
domains
that
go
beyond
what
we
are
currently
looking
in.
E
Additional
requirements
have
additional
ideas.
Please
let
us
know
please
participate
in
this
task
force
we
are
conducting
usually
bi-weekly
calls.
The
next
call
is
going
to
happen
on
Thursday
in
two
weeks.
This
week
is
a
public
holiday
in
Germany,
so
we
are,
or
in
concert
in
this
week's
call,
so
the
next
one
is
in
two
weeks
and
I
think
the
output
is
going
to
be
an
interest
group
document
where
we
are
collecting
and
describing
every
input.
So
everything
that's
contributed
is
going
to
go
into
this
document
without
any
short
listing
or
anything.
E
E
E
Things
group
to
make
sure
that
also
inside
the
different
specifications,
we
use
the
same
terminology
and
that's
a
general
objective,
also
of
the
architecture
spec
to
define
terminology
to
have
me
to
lay
the
groundwork
when,
in
terms
of
architecture,
in
terms
of
conceptual
introduction,
in
terms
of
terminology
across
different.
What
are
things
deliverables?
E
E
We
have
a
proposal
on
a
unified
state
model
which
is
in
discussion,
we're
planning
to
conclude
on
that.
Within
a
couple
of
weeks,
we
have
an
agreement
on
fundamental
states,
state
names
and
transitions.
There
may
be
some
changes,
but
we
are
pretty
much
aligned,
I
would
say-
and
this
is
the
current
draft,
where
we
start
so
we
have
differently,
as
we
have
the
manufacturing
layer
and
the
veterans
layer
and
the
bottom,
and
we
have
the
providers
who's,
offering
a
service
that
could
be
a
manufacturer
or
service
provider
or
also
the
device
owner.
E
On
top
of,
we
have
the
application
itself
application,
because
there
is
also
the
embedded
well
run
time
which
exposes
scripting
api's
or
a
consumption
of
the
underlying
web
of
things.
Thing
applications
I'm,
probably
not
well.
We
don't
have
enough
time
to
go
into
all
of
the
details,
and
things
are
still
in
discussion.
I
wanted
to
include
this
slide
to
give
you
the
general
idea
where
we
are
working
on
and
in
which
direction
to
go.
So
basically,
we
have
the
initial
state
which
is
manufactured
or
at
a
later
point
in
time.
E
This
date
we're
going
into
an
operational
state.
There
are
two
different
layers
here:
the
operational,
which
means
that
the
device
is
basically
connected
and
reachable
via
protocol,
and
what
operational
includes
a
little
bit
more.
It
includes
also
that
an
application
is
running
or
an
application
is
working
and
implementing
the
behavior
of
things
and
from
this
state
from
their
original
States,
which
may
be
on
a
specific
device.
It
may
be
a
single
state
and
also
when
we
have
simple
sensor
device.
There
is
no
water
application.
So
it's
just
a
plain
operational
state
went
from
there.
E
Representing
key
is
doing
software
updates,
and
things
like
that
and
from
this
maintenance
state
go
back
to
manufactured
or
decommissioned,
and
we
also
consider
a
destroyed
or
permanently
disabled
of
our
state
where
a
device
intentionally
there
is
no
longer
active
and
can
never
be
reactivated.
This
is
important
for
security,
critical
deployment.
B
So
in
Iran
for
for
almost
a
decade
and
it
turned
out
to
be
pretty
stable
and
it
would
be
nice
to
have
something
like
a
mapping
between
the
eight
five,
seven
six
terminology
and
the
technology
that
you
are
developing.
Of
course,
you
have
different
with
identifiable
components
that
that
we
are
not
discussing
in
576,
so
there
is
going
to
be
some
some
difference,
but
it
would
be
nice
to
have
some
mapping.
E
Yeah
I
completely
agree
Kirsten,
and
we
don't
want
to
introduce
or
invent
Orion
that
we
don't
want
to
impose
new
requirements
on
devices
we
want
to
describe
what's
out
there
in
the
field.
What
has
been
adopted?
We
have
this
additional
application
component,
which
may
have
some
additional
consequences
in
terms
of
key
provisioning
and
things
like
that
for
dedicated
use
cases.
But
you
should
be
able
to
find
your
model
in
this
picture
and,
if
not,
please
shout
or
reach
out
to
us
and
help
us,
sir.
C
E
E
E
This
is
just
an
example
to
illustrate
this
is
a
proposal,
so
it's
not
yet
to
consolidate
it.
It's
just
something
to
illustrate
also
things
that
we
need
to
look
into
when
we
have
a
device
and
we
have
a
consumer
and
on
the
left-hand
side
we
see
the
device
owner
on
the
consumer
side.
We
see
somebody
who's,
creating
the
consumer
or
owns
the
consumer.
It
can
be
the
same
time
and
at
some
point
in
time
the
device
of
that
has
been
initialized
or
started
it
as
we're
interested
in
the
directory.
E
It
is
lived
in
a
way
and
can
be
discovered,
but
somebody
who
wants
to
use
it
I
mean
took
it
upon
the
consumer.
We
need
to
work
on
the
state-transition
names
on
the,
if
names
here
and
align
them,
so
these
law
coming
from
different
from
different
sources,
and
we
need
to
make
sure
that
we
are
using
the
same
name.
So
you
won't
be
able,
at
the
moment
to
find
a
mapping
between
these
names
and
the
diagram
in
the
previous
picture.
Just
a
word
of
warning,
so
Michael.
C
Yeah
Mike
comment
here
is
note
that
discovery
is
actually
also
needed
during
onboarding,
so
they
have
a
new
device
and
I
have
to
like
a
register.
The
system
have
to
discover
the
places
you're
registered
with
so
discovery
isn't
just
about
discovering
devices
have
already
been
on
board.
It's
also
about
devices
figuring
out
how
to
connect
an
on
board
to
an
existing
system.
I.
C
Actually,
one
example
of
a
full
complication.
Discovery
can
go
either
direction,
so
I
might
discover
devices
there
that
want
to
be
on
word
or
an
onboarding
state,
and
we
also
have
devices
discovering
infrastructure
they
can
onward
to
and
different
protocols
approach.
This
different
ways,
which
adds
complexity
to
the
problem.
C
D
E
However,
there
is
intentionally
and
by
design
there
are
only
very
few
normative
requirements
on
devices,
and
we
have
a
couple
of
use
cases
that
require
more
yeah
info
probability
in
terms
of
out
of
the
box
in
terms
of
yeah.
If
I
get
a
new
device,
I
don't
want
to
create
a
new
client
and
in
general,
if
you
want,
if
you
wanted
to
implement
a
generic
generic
client
for
all
kinds
of
things,
as
preference,
it's
impossible
to
implement.
Just
imagine
one
flavor
of
a
protocol.
E
E
Improved
interoperability.
We
also
move
on
to
the
final
core
profile,
which
means
to
define
a
subset
of
a
thing
description
for
useful
select.
The
protocols
define
additional
constraints.
There
have
been
several
black
fests
that
were
conducted
in
the
workgroup
and
tests
were
done
during
development,
so
a
lot
of
work
has
been
already
done
and
things
have
been
identified
to
work,
and
things
have
been
some
some
reasonable
baseline
assumptions
have
been
made.
E
This
knowledge
is
in
the
interest
group,
it's
in
the
blood
first
participants,
heads
and
in
some
documents-
and
this
can
be
formalized
in
terms
of
our
former
profile
specification
profiles,
for
example,
for
thin
templates
or
other
protocols
will
be
defined.
This
may
be
happening
as
part
of
the
profile
work.
It
may
be
happening
also,
potentially
thing
description
specification
itself,
we're
going
to
see
how
the
work
turns
out.
E
This
is
just
straighting
at
a
very
high
level.
What
we
are
talking
about
when
we
consider
or
what
profile.
So,
if
you
consider
all
the
vertical
blocks,
just
be
expressiveness
of
what
we
can
describe
them
of
in
description
with
a
protocol
idea,
then
the
core
profile
is
defining
a
subset.
It
is
selecting
features
of
properties,
it's
making
additional
constraints,
the
same
on
actions,
the
same
on
the
events
and
on
legs
and
on
security.
E
Last
year
we
had
a
submission
of
a
profile
Stroman,
which
is
a
very
early
write
down
of
basically
thoughts.
That
I
was
having
when
I
was
thinking
about
what
needs
to
happen
in
terms
of
improving
the
probability.
So
it's
a
local
submission.
It's
available
publicly.
It's
in
the
github
repo
I
have
found
link
later
on
in
the
presentation
on
that.
It
also
defines
all
these
preps
and
uses
a
generic
profiling
mechanism.
It's
an
easy
to
read
document.
It
needs
significant
discussions
and
more
work,
and
it's
just
the
company
contribution.
E
So
it
is
not
something
that
has
been
agreed
on
so
far
only
that
this
output
of
a
working
group,
the
work
on
the
profile
specification,
unfortunately
stalled
for
several
months
since
the
architecture
task
force
has
limited
bandwidth
in
terms
of
cause
or
sometimes
of
time
that
people
can
work
on.
So
we
proofed
the
profile
work
a
little
odd.
E
A
Thank
no
more
questions.
We
could
move
the
next
part,
but
but
thanks
a
lot
for
doing
it,
especially
the
use
cases,
work
I
think
it's
highly
useful
for
us
to
share
those
use
cases
across
organizations
cause
that's
a
common
thing
that
we
need
in
our
standards,
work
on
different,
verticals
and
and
data.
So
I
think
it's
highly
useful
that
you
are.
You
have
a
very
open
process
for
that.
Yeah.
C
One
thing
we
should
mention
is
I.
Guess
we're
in
the
middle
of
consolidating
that
one
of
the
issues
is
categories
like
you
know
what
big
buckets
these
cases
fall
into.
The
other
issue
is
horizontal
versus
vertical
use
cases,
so
we
have
a
bunch
of
vertical
use
cases.
We
also
have
a
bunch
of
saying
horizontal
ologies,
let's
say
like
discovery
or
security
or
whatever
they
kind
of
cross
across
those,
and
so
we,
as
we
do
the
requirements,
we're
going
to
be
swinging
out
a
lot
of
that
I
and
trying
to
organize
things
better.
C
C
E
E
B
G
C
Okay,
so
people
hear
me
so
I
talk
about
the
work
of
discovery,
so
we
created
a
task
force
just
to
work
on
discovery
and
later
on,
and
the
presentation,
as
a
number
of
links
to
repository,
that
has
a
lot
of
designing
and
requirements
documents
that
kind
of
back
up
some
of
the
stuff.
We
don't
yet
have
a
a
draft.
You
know
public
working
draft
of
the
actual
spec,
but
the
intention
is
to
create
a
separate
specification
document
that
would
define
the
discovery
process.
C
One
of
our
challenges
with
discovery
is
not
reinventing
the
wheel,
so
we
we
don't
want
to.
You
know
conflict
with
existing
discovery
mechanisms.
In
fact,
we
want
to
build
upon
I'll
talk
about
that
in
a
minute.
The
other
thing
I
want
to
say
at
the
outset
is
discovery
is
defined
in
our
use
case,
as
the
mechanism
by
which
you
retrieve
things
questions
it's
not
necessarily
on
the
land
like
it's
not
like
a
broadcast.
You
know
mechanism
it
could
be
across
the
internet.
C
So
you
know
I
started
there
writing
down
number
of
requirements.
So
one
is
you
notice
a
set
of
things
we
should
be
able
to
do,
and
this
kind
of
relates
to
the
use
cases.
I
think
that
you
know
one
thing
that
came
up
was
people
want
to
do
localizable
discovery,
so
you
want
to
be
able
to
say
you
know:
I
want
things
written
in
a
certain
place
or
location.
This
actually
gets
tricky.
If
you
don't,
can
we
have
a
standardized
geolocation
mechanism
for
TVs,
and
we
also,
you
know,
want
to
be
able
to
do.
C
You
know
discovery
that
spans
network
theories
in
some
of
these
cases,
so
they
might
want
to
look
for
things
across
a
campus,
for
example,
and
you
know
maybe
over
several
different
network
domains.
We
also
did
a
lot
of
work
in
the
past
on
semantic
queries,
and
so
because
we
are
adding
semantic
annotation.
We
want
to
be
able
to
have
some
ability
to
use
that
information
and
there's
a
lot
of
great
technology
available.
The
same
time.
You
don't
want
to
burden.
C
You
know
simpler
devices
from
having
to
deal
with
a
bunch
of
RDF
stuff,
so
we
have
to
walk
the
same
longer.
If
the
TV
is,
how
do
we
support
semantic
query
without
burdening
smaller
mutations,
and
we
also
have
different
use
cases,
so
we
have
large
numbers
of
things
we
have
to
worry
about
and
might
need
a
directory
search
for
that.
We
also
want
to
do
self
identifying
devices.
The
devices
that
has
have
one
TV-
and
they
just
want
to
you-
know
make
it
available.
C
Make
this
all
more
interesting
and
complicated.
We
have
to
preserve
privacy,
so
TVs
contain
a
lot
of
metadata
about
devices
when
devices
can
be
associated
with
a
person
that
metadata
can
be
used
to
infer
things
about
a
person
and
even
just
getting
since
the
metadata
can
use
like
to
infer
things
like
location.
C
So
if
you
knew,
for
example,
what
set
of
devices
were
near
a
person,
you
might
be
able
to
infer
the
location
of
that
person,
they
even
care
about
the
actual
information
in
the
metadata
per
se
you're,
using
as
a
fingerprint,
so
there's
all
kinds
of
privacy
risks.
We
have
to
worry
about,
and
let
me,
if
you
see,
is
very
sensitive
about
privacy,
so
one
of
the
things
we've
come
up
with
is
a
way
to
do
this.
You
know
discover
metadata
without
blowing
privacy,
and
so
we
don't
worry
about
a
lot
of
things.
C
First,
we'll
work
is,
you
know,
distributing
things
only
to
authenticate
and
authorized
users.
The
other
thing
is,
you
know,
plugging
leaks,
so
not
broadcasting
metadata,
but
instead
putting
it
behind
a
firewall,
and
we
have
to
be
tricky
because
we
have
to
worry
about
inferencing
products.
So
it's
not
just
you
know
this.
You
can't
just
say:
there's
no
PII,
no
personal
information
and
T's
don't
worry
about
it.
It's
not
true,
because
you
can
always
use
information
in
T
to
infer
things
from
relationships,
and
this
is
a
very
tricky
raffle.
C
And
finally,
you
know
like
I
said
we
don't
want
to
reinvent
the
wheel.
So
how
do
we
align
resistant
standards?
How
we
build
upon
mom,
come
and
so
forth?
And
finally,
there's
discovery
support
in
the
scripting
API?
We
make
sure
that
you
know
that
works
and
it's
simple
to
use
and
in
context
in
which
privacy
is
an
issue.
It
shouldn't
be
leaking
information
that
could
do
like
fingerprinting.
C
So
it's
a
it's
a
tall
order,
lots
of
things
so
as
a
first
step
ahead,
a
proposal
which
is
basically
using
a
tooth
age
architecture.
So
the
idea
is
to
have
you
know
an
introduction,
phase
and
exploration
phase.
Another
name
for
introduction
be
first
contact.
So
basically,
how
do
you
start?
You
know?
You're,
you
don't
know
anything
about
these
environment
Arend.
How
do
you
start
discovery
process?
And
so
you
know
one
of
the
issues
here
is.
It
needs
to
be
open,
so
we
don't
have
any
ax
right
to
start
with.
C
So
you
know
we
have
to
like
have
a
way
to
bootstrap
without
having
access
rights.
It
shouldn't
be
heavyweight,
so
you
know
small
devices
may
need
to
do
this.
They
may
need
to
do
it
even
when
they're
onboarding,
as
mentioned
before,
so
it
has
to
be
lightweight,
but
it
shouldn't
leak
privacy
information,
so
we
have
to
actually
because
we
were
having
it
as
an
open
process
that
first
bootstrap
phase
should
basically
no
metadata
about
devices.
It
should
just
be
kind
of
an
onboarding
process.
B
F
C
Yeah
some
more
information
on
this.
You
know
the
output.
The
first
contact
is
the
address
of
an
exploration
service
and,
for
example,
the
URL
for
directory
service
does
not
have
to
be
a
broadcast
mechanism.
So
one
of
the
things
we've
been
talking
about
is
using
DNS
and
using
DNS,
maybe
that
spans
the
network,
maybe
even
using
extension,
the
DNS
that
do
location-based
discovery
and
it
could
also
be
better
rector
ease.
So
actually
you
might
have
one
director
agency
to
another
one.
C
The
one
requirement
we
state
is
that
and
getting
URL
back.
You
shouldn't
be
baking
information
into
that
URL
tech
advice,
so
don't
return
the
URL
from
the
introduction
that
is,
like
my
insulin,
pump
right,
because
you
don't
have
any
inference
from
the
name
of
the
URL.
What
the
type
of
device
is.
So
even
if
it's
a
self
identifying
device
that
introduction
URL
needs
to
be
opaque
in
some
way,
we've
looked
at
multiple
ways
of
introductions,
so
you
could
have
all
kinds
of
things
to
do
introductions.
C
The
only
constraint
they
said
is
that
it
gives
you
a
link
at
the
back
end,
and
there
is
already
some
specifications
for
self
identifying
devices.
Like
the
bat
well-known
thing,
we
need
to
clarify
exactly
what's
used
and
then
for
all
actually
for
several
other
mechanisms.
We
need
to
add
a
few
bit
of
information,
for
example,
to
use
Dena's
as
Dee.
We
have
to
define
the
service
name
or
for
our
services,
there's
also
issues
with
certain
introductions
only
having
fixed,
URLs
or
fixed
addresses.
C
Now
there
are
the
relationship
I
mentioned
later
on
to
Cora
D
et
cetera.
A
lot
of
these
systems
basically
had
a
list
of
typed
links,
and
so
what
we
can
do
with
these
can
mechanisms
is
use
them.
As
introduction
services
have
a
typed
link
for
word
directory
service
and
then
point
to
the
directory
from
some
of
the
core
OID.
He
is
don't
pack
all
the
metadata
into
these
directories.
Are
these
kind
of
services
instead
use
them
as
an
index
into
a
directory
service?
C
The
reason
being
is
the
directory
service
can
have
strong
authentication
authorization
before
release
the
TV
bed
and
we
have
different
types
and
I
think
the
two
main
types
that
come
up
are
pointing
directly
at
a
device
that
self-identifies
its
te
and
pointing
to
a
directory
service.
So
I
think
we
might,
at
the
minimum,
have
two
different
types
of
links
that
need
to
be
added
to
things
like
car
keys
and
D
ID
documents
and
DNS.
C
Let's
get
that
okay,
so
then,
once
you've
gone
the
first
contact,
then
you
need
to
do
exploration.
You
need
to
authenticate
and
then
an
authentication
may
actually
requires
mokou
off.
You
could
go
off
somewhere
else
and
get
a
token
and
come
back,
and
then
you
can
get
access
to
a
directory
service.
No
directory
has
you
know
number
of
T
DS,
so
you
have
to
have
a
way
to
select
the
ones
you
want.
So
we
realized
that
there's
different
layers
of
query.
C
You
might
want
to
do
simple
query
or
you
might
want
to
do
full-blown,
rdf,
sparkle
queries
and
not
all
you
know
gateways
will
want
to
admit
a
sparkle
query
mechanism.
So
we
are
looking
at
some
intermediate
lightweight
mechanisms.
I'll
mention
some
later
based
on
JSON
patents,
there's
also
issues
with
timeouts
so
time
to
live.
C
Here's
the
problem
that,
if
Springs
registered
directory
and
the
device
dies
or
goes
away
or
moved
or
something
we
have
to
have
a
way
to
clean
out
the
directory
of
obsolete
devices
and
also
we
have
an
onboarding
mechanism,
Sullivan
devices
onboard
they
register
themselves
with
their
directory
or
the
directory,
discovers
them
in
the
opposite
way
and
let's
see
yeah
and
there's
also
this
issue
of
IDs.
So
one
of
those
that
came
up
in
the
privacy
discussion
is
rotating
identifiers
so
that
they
can
minimize
the
tracking
surface.
C
But
if
you,
if
a
device
changes
identifier
than
the
device,
the
directories
need
to
be
notified
of
the
change
and
the
directories
made
me
notify
users
of
the
change,
and
so
there
has
to
be
kind
of
a
well.
They
may
have
to
be
a
notification
mechanism
or
if,
when
I
rotate
identifiers
here
is
that
if
a
malicious
user
cashed
a
TD
from
long
ago,
they
have
the
old
ID.
If
they're,
not
in
the
notification
list,
for
the
updates,
they
don't
get
notified
of
the
new
change,
and
so
they
would
not
know
it.
C
C
Ok,
so
I
actually
wanted
to
point
at
a
number
of
things
that
we've
done
and
I'm
actually
gonna,
give
you
a
Grand
Tour,
but
what
we
have
in
in
the
wot
discovery
repo,
and
so
these
are
the
links
to
later
on
to
come.
Look
at
this,
but
basically
we
have
some
proposals
and
the
only
one
here
really
is
the
two-phase
directory
system,
but
we
also
are
collecting.
You
know,
implementation
and
one
of
the
one
that
up
later
on
is
the
front
hyperlink,
smart
system,
which
is
a
prototype
directories
for
us.
C
Basically,
we
also
have
you
know
the
collecting
requirements,
so
we
have,
you
know,
sets
of
requirements
about
things,
and
this
is
kind
of
realignment
on
on
what
we
need
here.
One
of
the
things
we
need
to
do,
though
here
is
connect
these
two
use
cases
so
once
the
use
case
stuff
sorts
itself
out,
we
need
to
look
across
it
horizontally
and
confirm
that
we,
you
know,
have
captured
these
the
right
requirements
for
the
use
cases
that
we're
actually
considering
it's
big
out
of
order.
C
Given
the
requirements,
then
we
have
a
bunch
of
design
decisions
we've
been
discussing,
so
we
basically
made
the
resolution
that
the
two-phase
architecture
makes
sense
and
we
will
follow
that
that
strategy
and
and
then
the
some
details
there
now.
One
thing
we're
in
discussion,
though,
still
is
what
exact
introduction
mechanisms
we
need
to
support.
It
turns
out
that
different
introductions
may
need
some
additional
work
to
enable
for
this,
for
example,
need
to
define
a
service
label
for
a
DNS
SD
e
IDs.
They
returned
about
two
typed
links.
C
We
needed
to
find
some
type
labels
for
D
ID
documents
for
those
to
be
enabled
for
D
IDs
for
QR
codes.
We
have
the
problem
that
the
QR
code
may
be
printed,
which
case
it's
fixed.
So
how
does
that
work?
How
do
we
maybe
we're
in
a
home,
environment
and
or
behind
the
nap?
So
we
don't
actually
know
the
URL
or
the
IP
number
of
our
device.
So
how
do
we
actually
go
from
the
QR
code
to
the
device
or
to
the
to
the
TD?
C
And
actually
it's
kind
of
late
of
the
problem
of
how
do
we
have
stable
URLs
for
TVs?
So
one
way
around
this
is
to
use
D
IDs,
which
are
decentralized,
enta
fires,
which
then
provide
a
stable
identifier
that
can
be
resolved
into
a
set
of
links
and
those
links
can
be
updated,
but
that's
still
in
flight
and
we're
not
quite
sure,
I
think
QR
codes
on
a
display,
though
it
becomes
a
lot
easier.
C
If
you
can
display
a
QR
code
or
in
some
way
display
our
broadcast
a
discovery
link,
then
you
can
update
it
and
one
version
of
that
is
actually
a
Bluetooth
beacon
which
can
be
used
in
broadcast
links
for
discovery.
Now
this
is
for
devices
they're
broadcasting,
their
label
or
their
directory
service.
The
other
way
around
is
devices
discovering
directories
and
registering
with
them.
So
we
also
have
the
issue
of
making
directories
discoverable,
there's
also
one
on
locations,
and
so
we're
we
to
define.
C
You
know
what
is
the
well-known
location
for
a
TV
and
the
basic
idea
here
is
a
very
great
remote.
The
simplest
possible
exploration
service.
Is
you
just
get
to
explore
location
and
you'll?
Get
the
TV
back,
however,
that
get
should
go
through
an
authentication
process
which
would
have
to
probably
have
to
follow
the
HTTP
protocol
for
requesting
authentication,
as
you
don't
know,
in
advance
necessarily
what
authentication
is
needed
for
for
this
link.
C
We
also
like
I,
said
looking
at
directory
service.
We've
made
some
decisions
about
things
that
you
know.
We
we're
gonna,
stick
to
tcp
ATP
for
now,
I
think
in
the
future.
We
might
consider
other
things
like
Co
app,
but
for
now
to
keep
the
scope
simple,
we're
going
to
define
it
in
terms
PACP
and
actually
TLS.
So
we
have
to,
of
course,
have
the
link
encrypted,
nor
we
provide
any
kind
of
security
or
privacy
later
sign
sitting,
which
actually
is
up
in
the
air
right
now,
because
we're
still
debating
it
is
jason,
vs.,
jason,
LD.
C
So
does
a
directory
return,
jason,
jason
LD!
If
it
returns
json-ld,
the
mutation
is
that
it
needs
to
have
a
context
and
it
needs
to
have
you
know.
Queries
should
also
you
know,
Bey
the
naming
rules
for
like
for
semantics.
This
actually
is
kind
of
tricky
and
we
are
currently
debating
how
to
do
this.
One
of
the
issues
is
a
lot
of
the
query.
C
So
if
you
want
to
do
full
semantics
with
Sparkle,
of
course,
it's
json-ld.
This
is
in
the
context
of
a
lightweight
keyword,
template
based
search.
Another
issue
that
comes
up
is
pagination.
If
you
have,
you
know
a
directory
service
with
safe
thousands
of
TVs,
you
give
it
a
query
that
basically
says
give
me
all
your
TVs
and
you
could
have
a
really
really
huge
download,
and
so
we
don't
want
to
do
that
in
a
single
transaction.
C
C
C
Finally,
for
query
mechanisms.
We
looking
at
query
support
and
different
ways
to
do
query.
I
think
Sparkle
is
kind
of
like
the
the
best
way
for
us
to
do
rdf
and
semantic
query,
and
it's
fully
general,
it's
also
very,
very
powerful
and
is
be
overkill
for
small
devices.
So
we're
looking
now
at
the
link.
Smart
system
I
mentioned
before
has
both
JSON
path
and
XPath
prototyping
and
we're
gonna
be
experiment
with
that
in
the
plugfest
next
week,
and
it
actually
does
support
page
nation.
There.
Things
there's
also
be
true
of
metadata.
So
what?
C
If
we
have
extra
data
about
a
TD
like,
for
example,
the
timestamp
at
which
it
was
registered?
How
old
it
is?
What
is
time
to
live
as
that's
our
the
thing?
So
we
can't
necessarily
add
that
data
to
the
TD
e,
because
later
on,
we're
contemplating
in
the
security
group
adding
a
way
to
sign
T
DS
with
a
json-ld
proof
section.
So
we
don't
want
to
invalidate
the
signature
by
having
the
directory
modify
the
TD.
So
we
have
to
figure
out
how
to
do
out-of-band
data
returns
and
so
very
likely.
C
One
final
thing
that
we
think
is
interesting:
I
have
this
line
decision
is
be
the
directory
network
API
you
want
to
describe
in
a
TV,
so
the
directory
service
itself
is
essentially
a
virtual
thing
and
why
this
is
interesting
is
that
allows
directories
to
index
other
directories?
So
that
means
we
can
have
federated
directories
where
we
can
search
a
directory
instead
of
flying
a
thing,
we
might
find
additional
directories
where
you
might
find
more
things,
so
a
discovery
process
might
not
being
recursive
and
walking
through
a
bunch
of
directories.
C
Of
course,
we
have
two
way
to
limit
this
and
one
logical
way
to
limit
it
would
be
by
spatial
location
or
doing
spatial
query.
So
what
we
have
to
then
look
at
you
know
how
do
we
get
spatial
information
or
number
of
network
hops
and
directory
ups?
So
we
we
just,
however,
right
now
we're
not
really
looking
at
that.
We
just
made
the
decision
make
the
directory
API
in
the
TV
as
a
description
that
allows
us
to
do
this
later
on.
C
C
I
I
have
a
couple
links
here
on
prior
work
and
background.
There's
been
a
lot
of
work
and
we're
trying
to
index
existing
mechanisms
for
discovery
and
figure
out
how
they
can
work
within
the
lot
so
architecture,
and
also
we're
still,
you
know,
willing
to
accept
additional
proposals.
Ones
you
want
to
do
is
capture
previous
work
in
previous
years
for
discovery,
especially
for
semantic
discovery.
Right
now.
The
link
smart
system
looking
at
is
really
focused
on
the
lightweight
keyword
and
template
based
search
not
on
semantic
search
per
se.
C
Well,
I
think
I'm
basically
done
I'll
skip
this
and
I
had
some
discussion
points.
I
guess
to
do
is
yes,
sorry
I
went
along
so
we
had
some
of
this
discussion
last
week
and
in
the
lovely
did,
but
not
who
was
here
with
at
that
discussion.
Maybe
I
can
simply
summarize.
Do
we
gonna
take
five
minutes
for
discussion
and
then
and
then
have
a
great
a
delayed.
B
B
C
C
B
C
Have
two
minutes
to
wrap
up
and
then
I
think
we
do
is
defer
discussion
to
some
later
meeting
I
wish
she
call
or
discovery
task
force
club,
so
I
think
I.
It's
tricky
because
about
to
go
into
his
face
to
face
so
I'd
like
to
identify
a
point
which
we
didn't
have
discussion
and
then
I'd
defer
it.
So
what's
our
what's
your
next
wish,
II
call.
B
C
C
C
C
A
C
We
have
to
defer
the
discussion
of
the
watt
discovery,
so
what
we
decided
to
do
is
push
it
to
the
next
wishy
call,
which
is
June
30th
and
on
the
chat.
Carsten
has
a
link
to
that
agenda
and
we
will
follow
up
on
the
discussion
at
that
point
and
basically,
I'll
discuss
the
last
slide
in
this
presentation
and
we
can
follow
on.
We
only
have
10
or
15
minutes
of
discussion
time
I'll
be
done.
Peccary.
C
B
C
H
To
give
a
quick
background,
of
course,
one
of
the
problems
that
gov
Tech
has
is
many
fragmented
protocols
for
sensors
and
robots,
and
so
this
is
why
we've
been
working
with
the
w3c
of
watching
me
to
to
look
for
solutions
that
can
solve
this
problem.
And,
of
course,
web
of
things
is,
is
what
we're
considering,
and
so
what
you
see
here
is
a
list
of
the
potential
use
cases
that
we've
discussed
with
the
team
here
on.
H
C
C
C
So
so,
basically,
there's
lots
of
different
use
cases
for
IOT
in
retail.
Now.
What
interesting
is
a
lot
of
these
also
involve
computer
vision
or
AI.
So
one
of
the
things
that
comes
up
is,
and
actually
one
of
the
reason
for
Intel's
interest.
Frankly,
is
that
there's
also,
you
know
orchestration
of
IOT
devices
with
AI
applications?
C
You
know
switches
on
doors,
so
so
if
you've
been
collaborating,
we're
working
with
Intel's
open
retail
initiative,
which
is
a
project
under
the
IOT
group
that
Intel
now
they've
sponsored
an
open-source
project
called
EDX
foundry,
which
is
actually
a
collaboration
among
many
companies,
and
so
part
of
the
POC
is
looking
at
integrating
watt
into
X
foundry,
which
will
enable
not
only
retail
use
cases
but
other
use
cases
and,
of
course,
Connexus
is
driving.
The
use
cases
and
kind
of
our
plan
was
to
get
things
done.
C
I
show
case
that
and
fall
for
a
conference
called
nax.
We're
not
quite
sure
it's
gonna
happen
because
of
chronic
coronavirus,
but
we're
assuming
it
is
and
we're
working
towards
that.
Okay
and
actually
we're
looking
at
a
particular.
You
know
concrete
use
case,
someone
walking
in
to
convene
store
and
buying
an
ice
cream,
and
the
idea
is
the
person
would
walk
in
they'd
open
the
freezer
door
that
might
have
a
sensor.
C
The
might
use
computer
vision
to
identify
here's
a
person
and
also
look
at
the
product.
That's
being
taken
out
or
maybe
I
have
RFID
sensor
identify
the
product
and
then
the
person
either
walks
to
the
counter,
and
if
we
assume
the
you
know,
the
associate
is
in
the
back
room.
They
had
to
be
notified
to
come
to
the
to
the
counter
to
check
to
check
out
the
person.
C
Alternatively,
the
customer
might
decide
to
let
go
walk
out
the
door
with
the
ice
cream,
in
which
case
we
have
a
different
kind
of
notification
process
to
worry
about,
and
we
might
just
want
to
simply
remind
the
customer,
hey
you
have
to
pay
for
that
or
to
like
you
know,
tell
the
associate.
You've
lost
some
inventory,
so
you
know
the
architecture
you
know
involves.
C
Doing
a
distinguished
POC
from
use
case,
I
think
of
POCs
were
actually
trying
to
build
something
whose
case
is
we're
defining
where
we
might
build
something
or
someone
might
build
something
I
think
they're
related,
because
very
often
we
have
a
use
case
and
then
we
also
build
it,
and
there
is
a
retail
dot.
Md
use
case
in
the
architectural
repo
that
captures
the
retail
news
case
and
there's
a
bunch
of
different
use
cases
for
smart
tsuki,
I.
B
C
It's
not
done
yet,
so
we
haven't
gotten
documentation.
Part
I
will
say
that
from
plug
fests,
one
of
the
things
I've
been
trying
to
do
is
more
formally
capture
our
results
from
plug,
fests
and
I.
Think
you
know
as
part
of
the
plug
fests.
We
definitely
want
to
walk
through
some
of
these
POC,
a
POC,
implementations
and
capture.
You
know
the
pros
and
cons
of
different
approaches.
I
think
that
you
know,
for
example,
for
this
POC
for
retail,
we're
going
to
be
going
ahead
and
using
the
link
smart
directory.
C
Okay,
even
though
it's
not
necessarily
normative
for
what
we
plan
to
do.
You
know
it's
not,
as
I
decided
that's
going
to
be
the
interface,
so
we're
gonna
do
something
we're
going
to
try
it
and
we'll
see
how
it
works
and
then
try
and
capture
the
results.
I
think
the
idea
of
those
we
have
a
report
out
on
these
pocs
that
would
write
the
feedback
into
our
use
cases.
C
Okay
list
it
for
Pope
Cory,
it
would
be
on
our
repos
most
likely.
So
we
have
a
use
case.
Repo
that'd
be
one
place
to
capture
this,
also,
a
testing
repo.
We
generally
capture
plugfest
reports,
I
should
say
we're
trying
to
capture
data
formally
now,
in
terms
of
you
know,
CSV
files
for
different
pairs
of
things
interoperate
and
how
well
and
so
I'll
have
to
think
about.
You
know
what
kind
of
data
we
can
capture
for
pocs,
because
they're,
essentially
a
a
complicated
plugfest
scenario.
C
I
think
a
POC
is
bit
more
because
kind
of
out
in
the
world,
so
plugfest
scenario
might
just
be
just
us
us
guys
talking
I.
Think
a
POC
is
something
where
we
actually
you're
out
in
the
world
and
there's
no
actual
real
users
using
it.
And
so
one
question
here
is,
you
know:
should
we
have
questionnaires
or
something
to
like
capture
information
or
more
formally
capture
a
feedback
from
users.
C
C
I
C
B
G
I
There
we
go,
you
don't
have
slides.
Let
me
just
summarize
really
where
we
are
with
one
data
model.
This
is
mostly
w3c
and
and
Tina's.
Here
we
have
a
website.
That's
about
almost
ready
to
go,
live
our
SDF
language
has
an
internet
draft.
That's
proposed
that
you
can
go
read
that
basically
contains
the
official
documentation
for
the
language
we
have,
among
other
things,
a
playground
and
the
playground
basically
has
a
fairly
comprehensive
collection
of
models
all
in
SD
format
and
all
more
and
less
valid.
I
You
noticed
a
couple
of
things
that
still
need
to
be
cleaned
up,
but
for
the
most
part
these
are.
These
are
all
valid
data
models.
So
what
I'm
basically
going
to
go
straight
onto
explaining
what
SDF
is
and
how
it
does,
but,
but
basically,
we
had
one
data
model
where
you're,
basically
managing
both
the
language
SDF
and
the
set
of
common
models
that
we're
working
on
to
converge
across
industry-
and
you
know
Carsten
Ani
jump
in
if
you
want
to
add
anything
to
that
summary.
B
We
had
a
pretty
extensive
discussion
of
SDF
in
in
Singapore
meeting,
and
actually
the
video
from
that
is
is
out
there
as
an
SDF
tutorial.
So
if
you
interested
looking
more
into
SDF,
there's
an
like
20
minutes
tutorial
that
you
can
watch,
but
the
basic
idea
is
that
it
makes
sense
to
have
a
very
high-level
view
of
the
data
model
and
interactions
provided
by
by
a
certain
kind
of
thing,
and
that's
actually
what
what
SES
allows
you
to
capture.
I
F
I
There's
Carsten
just
put
up
the
tutorial,
so
this
example
has
a
definition
of
a
switch
object,
which
is
some
functionality,
functional,
encapsulation,
on/off
switch.
It
has
a
non
action
and
an
off
action.
The
state
property,
the
data
defined
the
state
property
is
an
enum
with
the
string
values
on
and
off.
I
wanted
to
show
that
to
sort
of
illustrate
and
for
some
grounding
on
how
this
actually
would
be
used
as
a
thing
description.
I
The
thing
description
here
is
going
to
describe
a
thing
that
is
a
simple
switch
and
has
no
more
than
just
the
switch
in
it.
So
it's
type
is,
and
basically
I've
used
the
created
a
namespace
here
that
kind
of
points
to
where
the
definition
is
and
it's
it
uses
this
JSON
pointer
syntax,
which
is
the
same
as
used
in
the
as
model
22.2.
I
Respective
definitions
in
the
one
diem
files
of
the
type
is
SDF
objects,
which
must
be
of
action
on
sort
of,
uniquely
uniquely
defines
that
that
definition,
without
any
name
conflicts
within
that
namespace
and
across
namespaces,
and
points
to
these.
These
unique
definitions
now
there's
no
link
data
behind
there.
You
can't
go
there
and
expand
that.
That's
basically
going
to
point
to
this.
This
note
in
a
JSON
file,
so
there's
some
further
work
to
to
expand
these
through
the
IOT
schema
activity
to
to
give
them
a
little
more
semantics
behind
there.
I
But
but
this
is
basically
how
you
would
point
to
elements
of
a
different
definition.
We
don't
really
need
to
worry
about.
What's
behind
that
at
this
point,
so
this
is
basically
the
obvious
way
of
using
thing
description
of
using
SDF
one
data
model
definitions
in
the
thing
description,
so
I
can
build
thing,
descriptions
that
are.
I
You
have
semantic
anchors
in
them
that
are
based
on
these.
These
definitions
in
one
data
model.
That's
why
mouthing
descriptions
now
so
to
point
out
this?
These
have
no
protocol
bindings
at
all
that
completely
protocol
agnostic,
in
fact
they're,
mostly
representation
diagnostic.
The
idea
is
to
not
even
to
try
them
pardon
me
to
try
to
not
even
nail
down
enums
to
a
specific
set
of
representations,
but
allow
some
simulate
finding
and
over
writing,
even
even
on
those.
I
Same
description
basically
describes
instances
of
things
using
the
same,
descriptive
ontology
of
actions,
properties
and
events,
and
it
then
has
these
protocol
bindings.
It
has
a
specific
enum.
It
has
a
form
that
points
to
it
and
that
work
address
where
you
can
go
go
do
this
and
basically
we're
using
the
default
operations
here,
but
with
the
form
you
could
tell
it
to
effuse
hood
instead
of
host
or
patch.
You
could
do
a
lot
of
different
things
with
the
form.
So,
basically,
the
thing
description
adds
the
the
bound
protocols
and
bound
representations.
I
I
Works
from
the
github
issue,
Sebastian
asked
me
to
just
work.
Work
from
this
I
think
there's
been
some
introduction
of
description
templates
and
then
those
folks
in
in
the
lot
working
group.
Please
please
help
me
out
here,
but
basically
a
thing
to
spring,
so
some
descriptions
themselves
have
a
lot
of
requirements
and
constraints
and
they
have
they
require
they're
required
to
be
complete
and
what
we.
I
It
might
have
a
partial
protocol
binding,
it
might
have
the
data
schemas,
but
it
might
not
have
the
forms
or
it
might
have
the
data
ski
schemas
in
the
forms,
but
not
the
not
the
hrs
part,
and
the
idea
is
that
you
can
build
these
templates
as
building
blocks.
Who
are
thing
descriptions
essentially-
and
you
know,
really
a
number
of
different
ways
that
you
might
use
them
in
the
workflow.
But
this
is
really
what
we're.
I
What
we're
working
on
is
trying
to
figure
out
what
what
these
look
like,
and
so
we
thought
well,
what
would
description
templates
in
one
data
model?
Sdf
definitions
have
some
some
common
attributes,
but
some
differences
as
well.
So
you
know
the
one
thing
I'd
say
about
one
data
model
definitions
is
that
they
provide
stable
URIs
for
all
of
the
things
that
are
defined
so
they're
they're,
basically
a
vocabulary
reference.
I
So
these
are
what
we
started
off
with
and
looking
at
this
one
of
the
did
one
of
the
working
working
threads
or
work
streams
in
these
defining
templates
was
looking
at
how
one
DM
SDF
instances.
If
you
will
and
thing
description,
template
instances
might
might
work
together
or
might
there
do?
Can
we
use
thing
description
templates
to
definitions?
The
way
we
do
with
one
data
model
or
do
we
use
them
in
some
other
way.
So
what
are
the
use
cases
and
how
do
they
map
and
overlap?
I
E
I
Well,
but
so
that
that's
an
interesting
question
when
you,
when
you
say
how
does
it
actually
convey
the
semantics
of
that?
What
what
would
either
there
are
basically
a
lot
of
layers
to
that
right,
so
the
SDF
definition
so
currently
SDF
is
in
development,
so
this
construct,
UCSD,
F
enum,
is
not
officially
part
of
the
language.
It's
one
of
the
extension
points
that
we're
working
on
in
order
to
allow
SDF
to
do
what
you
what
you
just
asked
about,
and
that
is
to
rather
than
just
saying
here's
an
enum,
that's
on-off.
I
This
is
really
how
we
could
say
this
in
SDF
as
well,
could
hey
without
the
SDF
enum,
but
SDF
enum
is
meant
to
provide
a
URI
reference
for
each
term
in
the
enum,
for
each
choice
the
enum
offers
and
then
allow
it
to
have
its
own
set
of
descriptors
and
constraints.
So
currently,
what
we've
done
in
this
example
is
only
provided
a
default.
Well,
this
is
actually
probably
say
default
in
that
constant,
because
you
should
be
able
to
override
it,
but
you
know
you
might
want
to
do
it.
I
The
other
way
also
and
fix
it
for
semantic
depths,
we're
only
really
providing
a
human,
readable
description
that
says
the
on
state
in
the
off
State.
Now
you
could
expand
that
and
have
more
human
readable
description.
But
when
you
start
giving
into
machine
readable
descriptions
of
there
are
a
lot
of
different
ways
you
could
go
and
one
of
the
ways
that
we're
looking
at
is
well.
How
couldn't
we
had
a
state
machine
language
to
describe
on
and
off
as
two
different
states?
I
That
would
get
a
little
closer
to
talking
about
what's
supposed
to
happen,
but
it
still
doesn't
really
say
what
on
and
off
mean
in
fact
that
that
may
even
acquire
special
meaning
according
to
the
device
that
the
on/off
switch.
You
know
on/off
switch
here.
The
definition
is
meant
to
be
reusable
across
a
wide
range
of
devices.
So
exactly
what
is
meant
by
on
an
off
state,
that's
probably
different
for
each
device.
I
So
I
guess
that's
a
long
answer,
but
I
think
it's
a
really
interesting
topic
and
I'd
like
to
hear
your
thoughts
on
on
what
would
be
relevant
for
you
and
say
a
digital
twin
environment.
For
a
description
of
them
well,
how
can
we
extend
this
model
to
help
semantically
make
digital
twin
models
easier
to
build
right,
I,
think
that
would
be
one
one
good
question.
C
C
C
I
C
E
Refer
to
it,
the
point
that
the
example
is
showing
is
illustrating
if
we
omit
the
description,
and
if
we
give
this
to
somebody
who
does
not
speak
English,
it
does
not
have
anybody.
It
has
a
constant.
It
has
two
strings
which
consists
of
two
or
three
characters,
but
it
does
not
convey
any
kind
of
behavior
in
terms
of
turning
something
on
or
offer
yeah
right.
C
I
You
know
why
not
right
and
then
you
can
go
say
Oh
on
and
off.
Well
those
you
can
look
up
them
up
on
Wikipedia
and
you
can
the
other
thing
that
we
do
just
briefly
with
smart
thing
and
smart
things.
We
don't
really
need
machine,
readable
semantics,
but
we
need
human
readable
semantics
across
the
globe,
so
we
need
good
systems
for
internationalization,
and
the
system
like
this
of
enums
allows
you
to
put
in
labels
that
can
be
internationalized
through
some
standard
and
directory
systems,
for
example
that
tends
to
work
out
pretty
good.
I
B
But
if
you
are
talking
about
cheese
phone,
which
is
our
standard
example
for
that,
the
the
various
grades
of
cheese
found
for
firmness
are
not
going
to
familiar
to
a
lot
of
people
a
lot
of
people,
so
you
want
to
be
able
to
have
a
source
for
the
definitions
of
cheese
firmness
and
the
same
thing
is
true
for
on
and
off
and
all
the
other
things
as
well.
So
we
need
those
semantic
references
at
some
point.
B
J
Yes,
thank
you
very
much.
First,
the
micro
cosas.
So
this
is
the
approach
is
very
interesting.
Bonded
and
yeah
I
was
wondering
whether
it
would
be
really
appropriate
and
nice
or
easier
to
use
this
just
based
format.
200
state
transition
in
general,
for
example,
gavrillac
secured,
combat
a
four-state,
truncheon
controller
itself
and
as
well
yeah
and
also
there
was
a
payroll
to
data
model
named
the
EMA
as
well.
So
this
kind
of
combination
might
be
easier
to
handle
the
combination,
all
the
storage
on
itself
and
data
more
there
itself.
J
C
Again,
actually,
I've
kind
of
met,
a
a
method
question
so,
put
aside
the
issue
of
how
do
we
define
semantics
formally,
which
is
a
very,
very
deep,
ol
I'd
like
to
talk
about
just
the
process
for
how
we
kind
of
make
progress
here?
So
we
have
the
one
thing:
description
that
supports
descriptions
of
device
instances
we
have
SDF,
which
supports
you,
know
high
level
descriptions
of
semantics
of
devices.
So
what
is
our
our
path
forward
for
a
former
relationship?
I
think
we
have
several
different
ways
in
which
they
can
be
used
together.
C
I
think
we
have
a
bunch
of
examples.
I
think
you
know.
Maybe
we
need
to
talk
about.
You
know
if
we
were
gonna
formally
cite
SDF
inside
see
the
new
TDS
back,
what
role
we
put
put
it
into
and
and
what
would
we
recommend
people
to
do
I
also?
A
side
of
this
is
also
certain
feet,
STF
that
on
the
corresponing
aspect
in
tvs
like,
for
example,
st
of
objects
that
we
probably
need
to
figure
out
how
to
do
the
mapping
up.
So
can
we
address
the
the
process
issue?
How
do
we
make
progress
here.
I
I
Maybe
not:
okay,
sorry
it's
not
here.
After
all
so
and
I
had
a
slide,
there's
some
discussion
about
workflow
and
how
this
is.
Actually
you
know
in
in
the
workflow
and
and
clearly
it
makes
sense
to
use
these
definitions
as
annotation
in
a
TD,
and
we
should
probably
just
bring
that
into
the
plugfest
because
pointed
to
these
in
the
playground
they
exist.
Anyone
can
use
them
they're
relatively
stable.
I
So
if
we
want
to
use
these
definitions
and
plugfest
from
a
motion
sensor,
definitions
or
whatever,
I
think
we
could
do
that-
we
could
do
that
tomorrow.
Right
exactly
I
mean
literally
tomorrow,
because
they're
all
there
and
they're
all
defined
and
there's
plenty
there's
plenty
there.
There's
like
I,
don't
look
like
a
couple
hundred
of
them.
I
I
think
the
bigger
question
is
around
the
noose
back
in
templates
and
how
we
construct
templates
and
what's
the
relationship
of
SDF
to
templates
are
now
SDF
is
basically
attracted
the
device,
the
device
of
specifiers
and
makers
for
the
most
part,
and
also
a
lot
of
folks
who,
who
want
to
just
engage
developer
tools
to
write
down
their
definitions
and
json,
and
so
what
we've
done
is
provided
a
real
simple.
You
know
just
give
you
an
idea
of
where
we
think
SDF
is
going
in
speech.
I
There's
this
organization,
sun
spec,
that
makes
solar
energy
credentials,
color
energy
models
that
are
used
in
controllers
and
an
energy
accounting
and
things
like,
but
not
exactly
like.
What's
in
ZigBee
energy,
but
it's
kind
of
similar
to
that
also
just
think
the
energy,
the
folks
that
work
in
ZigBee
energy
are
really
interested
in
having
these
bigger,
broader
models
to
work
with
and
not
just
be
constrained
with
the
device
models
that
are,
you
know,
literally
for
constrained
devices.
I
So
there
are
going
to
be
a
lot
of
things
that
are
semantically
defined,
but
there's
no
real
obvious
way
to
use
them.
There's
no
protocol
binding.
So
some
spec
will
have
their
sort
of
way
of
using
whatever
they
have
RMI
system,
maybe
they're
using
or
whatever
at
Google.
We
will
have
to
convert
them
to
protobuf
files,
to
use
them
and
weave
things
like
that
right.
So,
basically,
there's
some
conversion
and
I
think
what
we
could
do
is
make
things
ascription,
really
easy
to
use
and
and
I
think.
I
The
question
is
how
these
templates
work
and
I
the
main
question,
or
we're
going
on
around
right
now.
I
think
is
whether
we
translate
and
I
think
this
is
true
of
IOT
schema
as
well
the
same
question
whether
we
take
these
1dm
definitions
in
JSON
and
translate
them
to
thing
description
templates
and
provide
Ankur.
You
are
eyes
in
the
thing
description
namespace.
I
We
make
templates
that
still
link
back
to
the
1dm
models
and
I
think
there
were
some
advantages
and
disadvantages
of
doing
both
what's
possible,
though
I
think
is,
and
I
think
the
easiest
way
to
reuse
them.
So
we
have
to
think
about
what
happens
when
a
1dm
model
changes
we're
going
to
rely
on
those
our
source
data.
We
probably
don't
want
to
just
copy
them
forward.
We'd
probably
want
to
link
to
them.
We
can
easily
expand
the
definition,
so
what
I?
I
What
Isis
expect
or
what
I
would
propose
we
look
at
is
when
we
create
a
scene
description,
template
point
to
the
1bm
space
that
you're
representing,
if
you
know
as
if
you
really
want
to
reuse
the
1dm
definition
and
then
the
semantics
in
the
TV
template
that
are
needed
to
get
it
closer
to
so
that
by
that
I
mean
at
the
payload
definition.
If
you
want
additional
constraints,
select
which
definitions
are
actually
present
in
the
instance.
So
if
I'm,
making
a
TD
template,
I
can
see
this
being
useful
as
a
device
manufacturer.
I
If
I
wanted
to
organize
my
device,
builders
I
would
use
TD
templates
that
are
anchored
in
one
DM
concept
so
that
they're
interoperable
with
other
devices,
but
but
those
those
TD
templates
then
would
have
my
protocol
binding.
So
they
would
have
the
profile.
I
was
going
to
use
the
watt
profile.
Those
TD
templates
would
be
watt
profile,
so
I
guess.
I
C
I
Yeah,
so
the
current
discussion
is
that
you
can
make
a
TD
template
for
an
object,
and
then
you
can
figure
out
how
to
combine
those
templates
in
your
device
design
according
to
your
own
way
of
making
your
device
TD's.
But
that's
still,
maybe
there
should
be
a
web
profile
standard
way
of
what
watt
profiles
standard
way
of
doing
that.
Right.
C
So
I
think
there's
a
set
of
activities
around
specification
alignment
I
think
there's
no
sort
of
activities
around
examples,
and
you
know
best
practices
and
and
and
having
more
informative
things
which
could
go
in
appendix
in
the
spec
I.
Think
it's
a
third
class
of
activities
which
is
tooling
right,
which
is,
if
there's
an
automatic
way
to
do
things,
people
more
likely
to
use
it.
C
I
This
might
inform
are
some
of
the
questions
about
what
level
templates
operate
at
and
I
think
the
answer
is
all
of
them
in
a
way
because
you
could
I
could
see
there
being
a
base,
TD
template
that
has
no
more
information
than
an
SDF
file
and
even
less,
but
typically
not
more.
In
other
words,
it
doesn't
add
any
constraints
it
doesn't.
It
just
translates
it
to
TD
and
and
gives
it
a
context
and
brings
it
into
the
linked
data
world.
I
Then
you
know
on
that
on
that
I
could
say
well
now,
I
have
a
way
of
building
it
for
co-op
right
well
way
of
building
it
for
HTML
or
MQTT
or
smart
things
or
whatever,
and
I
can
see
that
as
being
a
really
useful
and
then
that
could
be
driven
through
through
CI,
and
this
is
really
what
I
was
encouraging
us
to
do
and
then
template
design.
You
know.
E
I
I
think
what
you
just
said
is
is
really
key.
You
can
express
things
in
SDF
that
we
have
not
provided
in
TD
such
as
like
the
full
set
of
constraints,
but
there
aren't
there
aren't
that
many,
because
SDF
is
meant
to
be
just
a
defining
of
the
basic
classes
for
things,
but
there
are
some
things
we
have
in
SDF
that
aren't
in
TD
that
have
to
do
with
what
we
call
qualities
and
there
are
some
mainly
in
SDF.
There
are
compositional
things
and
modularity
features
that
aren't
in
TV,
as
McCool
was
getting
out
earlier.
I
There's
just
this
layering
of
SDF
object
and
SDF
thing
where
you
can
define
even
reusable
things
as
components
for
more
complex
things
and
that
doesn't
exist
in
TV.
So
that's
actually,
but
TV
only
describes
instances.
So
maybe
that's
that's.
You
know,
as
we
said
well,
that's
kind
of
up
to
how
you
build
infinitely.
We
don't
have
a
standard
way
to
do
that.
It's
the
punt,
because
really
there
when
you
try
to
do
it,
there
are
some
issues
and
you
would
like
to
have
this
ACOG,
the
modular
semantics
as
well.
I
B
I
B
Gonna
go
back.
Thank
you.
Go
ahead,
you
don't
have
cortical
bindings
and
so
on.
So
one
of
the
points
about
the
SDF
effort
is
to
make
it
really
easy
to
map
the
existing
data
models-
interests
yes
and
preferably
back,
and
so
that
the
focus
really
has
me
here
has
been
on
model
interoperability
and
that's
a
very
different
focus
from
the
one
that
that
TD
ahead
and
I.
B
B
Thank
you.
Organizations
has
has
a
hundred
or
couple
hundred
data
models
already,
and
what
we
are
trying
to
do
is
find
a
way
to
translate
all
these
data
models
into
a
common
language
and
impact,
and
that,
of
course
creates
some
some
the
need
for
some
compromises
on
accessibility.
So
we
are
not
in
the
business
of
extending
SDF
a
lot
just
because
there's
that
one
model
over
there
we
cannot
map.
We
are
currently
more
in
the
process
of
making
sure
we
can
access
all
those
ecosystems.
B
I
You
know
we
have
even
got
to
the
point
of
some
of
those
ecosystem,
folks,
looking
at
SDF
and
looking
what
other
folks
have
contributed
and
kind
of
thinking
about
extending
their
ecosystem,
so
that
that
might
be
the
pace
at
which
SDF
common
evolves.
Even
though
we
have
extension
points
that
we
can
use
to
get
out
ahead
of
things
a
little
bit
too.
I
B
Work
together
can
can
go
too
and
so
right
now
we
have
SDF
1.0,
which
was
published
on
last
friday,
and
the
next
step,
of
course,
will
be
to
do
an
SDF,
1.1
and
not
drop
in
the
kitchen
thing,
but
really
put
in
those
features.
We
need
to
widen
the
scope
to
even
more
things,
bluetooth,
ZigBee
and
so
on
and
I'm
sure
we
will
discuss
these
things
in
the
vichy
cause
over
time
and.
I
I
A
C
And
I
mean
technically,
we
could
invite
you,
but
if
you're
interested
in
joining
the
wot
cluckfest
give
me
a
ring
and
I
will
forward
you,
the
WebEx,
so
you
can
come
in
I
would
say
it's
an
open
invitation
to
people
who
are
interested
in
working
in
IOT.
So
all
the
the
WebEx
is
not
public.
Just
cuz
we
avoid
spammers,
so
just
email
me
and
I
can
email.
You
too
thanks.
C
B
B
K
K
K
Proposals
that
we
have
in
the
description
repository
and
so
the
these
proposals
are
in
this
proposals,
folder
and
there
are
two
of
them,
so
our
media
control
and
a
Prezi
control,
and
so
the
first
one
is
proposed
by
Victor,
sharp
and
I,
and
the
second
one
is
proposed
by
me.
Since
the
second
one
is
based
on
the
use
case
of
the
first
one,
I
will
start
with
the
first
one.
I
will
also
just
quickly
check
if
Victor
is
here.
K
Yes,
he's
here:
okay,
yes,
so
I'll
start
with
the
first
one.
K
Okay,
Victor,
okay,
so
of
since
we
have
time,
I
will
start
with
explaining
the
whole
idea
and
basically,
until
now,
in
thin
descriptions,
we
had
actions
that
were
so
that
we
are
focusing
mostly
on
actions,
but
maybe
it
could
be
applied
to
other
interaction
affordances,
but
basically
and
now
in
ten
ascriptions,
we
had
actions
that
would
be
started
and
by
the
client
or
the
consumer,
and
but
we
would
not
do
anything
more
on
the
actions,
so
basically
they
would
be
started.
Maybe
the
response
would
return,
something,
maybe
nothing
so
in
case.
K
We
are
fading,
a
light.
It
would
fade
and
we
wouldn't
be
able
to
know
anything
more
about
the
ongoing
operation
and
since
there's
already
some
sort
of
existing
implementations
regarding
hypermedia.
We
such
as
the
mozilla
permutation
and
the
oracle
device
cloud.
We
want
to
be
able
to
describe
the
hypermedia
use
cases
in
thing
descriptions,
so
the
so
the
first
one.
So
the
example
that
the
bot
proposals
use
is
a
is
a
light
that
fades
to
a
certain
value
or
for
a
certain
amount
of
time
when
the
client
invokes
it.
K
K
Exactly
so,
as
it
is
stated,
the
the
first
request
is
very
much
possible
in
the
current
standard,
but
the
subsequent
requests
on
the
created
resource
are
are
not
is
easily
describable
yeah.
So
in
the
usual
case,
we
would
have
something
at
the
ending
description
like
this,
so
we
have
an
action
that
fades.
That
takes
a
number
duration
in
milliseconds,
and
this
is
understandable
completely
by
with
a
current
thing.
We
current
the
consumer
of
this
thing.
K
K
Exactly
so,
as
we
know,
hypermedia
in
general
means
that
we
can
expect
that
the
thing
indicates
the
consumer.
What
can
it
do
later
on
with
created
resources?
So,
in
this
case,
is
that,
if
the
thing
answers
with
talk
to
a
one
and
feed
one,
we
can
do
some
further
operations
on
this
fade.
One,
and,
in
our
case,
the
further
operations
that
we
can
do
is
such
as
get
put
and
delete
and
what
they
would
actually
do
to
the
action.
K
K
The
the
arguments
that
also
differs-
the
two
proposals
is
that
here
we
want
to
not
explain
in
this
case
all
the
possible
interactions
in
a
certain
sequence
or
not
in
the
team
description
says
it
will
so
overload
the
TD
and
and
the
the
more
concrete
difference
is
that
this
proposal
allows
for
piecewise
consumption
of
TDS
or
where,
where
we
can
have
T
DS
that
change
over
time.
Based
on
the.
K
C
Just
some
comments,
so
they
were
straight
to
issues
that
no
use
cases,
so
one
is:
do
I,
have
all
the
information
up
front
as
developer
to
understand
the
API
completely
for
a
thing.
So
that's
that's
one
issue:
how
do
I
get
a
complete
description
of
all
possible
interactions
that
my
code
might
have
to
deal
with?
The
other
is
RTD
static
or
dynamic.
They're
going
to
point
out
the
dynamic
TVs
have
all
kinds
of
complications
with
registry
and
directories,
signing
identifiers,
etc.
C
K
L
If
I
I
can
continue
humans
about
this
proposal
so
far
there
was
activity
in
my
office.
Sorry
for
that,
I
couldn't
really
talk
so
that
essential
idea
of
the
proposal
is
to
reuse
the
hypermedia
vocabulary
that
is
defined
as
a
module
at
the
description
model.
So
for
every
new
affordance
the
thing
provides
there
would
be
a
new
form
somewhere
in
the
thing
description
and
we
wouldn't
need
to
add
much
to
the
to
the
thing
description
model
to
allow
for
this.
We
would
only
need
to
create
new
operation
types.
L
K
Yes,
so,
as
we
mentioned
these,
these,
these
form
forms
can
be
appended
to
the
forms
array
of
the
thing
once
the
this
resource
is
created,
so
the
consumer
could
reconvene
the
thing
and
so
like
this.
Basically,
so
we
getting
description,
we
do
a
post
request
and
then
we
once
we
know
that
it
results
in
creation
of
a
resource.
We
get
ting
description
back
and
then
learn
what
is
possible.
K
So
the
this
is,
this
part
is
an
extension
from
my
point
of
view,
the
different
regarding
different
versions
of
the
ting
description
as
well,
so
I
go
on
to
the
Steve
operation
types
that
Victor
mentioned.
So
the
proposal
includes
redaction
protection
and
canceled
action
that
are
then
mapped
to
the
get
put
post
in
the
case
of
HTTP.
K
So
here,
like
usual,
the
input
is
what
we
use
to
invoke
the
action,
and
here
you
can
see
the
out
so
update
and
which
also
takes
a
number
and
then
these
are
then
mapped
to
the
forms
here,
where
you
also
see
the
new
operation
types,
and
this
TD
is
also
what
is
created
once
the
fade.
One
resource
is
created.
K
K
K
Okay,
so
this
is
the
second
proposal
they're
very
similarly,
we
have
the
new
operation
types.
We
have
the
new
fields
and
I
just
called
you
reaction
is
the
reduction
in
the
in
this
way,
and
what
is
different
is
that
for
each
of
these
terms
that
are
on
the
action
levels
or
not
the
operation
types,
they
also
have
input
and
output
fields,
and
this
is
again
like
the
the
previous
case.
The
this
is
the
fate
operation
and
again
a
simple
thing
description.
That
is
the
respect.
Any
current
standard.
K
K
K
Yes,
so,
basically,
with
this
tactic
is
a
victor.
We
solve
how
to
do
the
subsequent
operations
and
but
of
course
the
consumer
has
to
know
that
invoke
action
should
be
in
what
is
done
the
first.
So
in
contrast
to
Vickers
proposal
in
the
victors
case,
only
invoke
action
can
be
done
in
the
beginning.
Then
it's
very
clear
what
the
thing
should
do
first,
whereas
in
this
case
the
thing
has
no,
that
invoke
action
has
to
be
the
first
thing
that
needs
to
be
done.
K
Yes,
so
in
this
case
the
ID
is
not
clear
how
to
get
the
ID,
and
we
can
ignore
it.
If
the
case,
if
the
idea
is
always
static,
also
at
the
same
time,
it's
not
clear
how
to
request
payload
or
response
bailout
for
different
operations
should
be,
and
the
takeaway
from
this
is
to
is
that
in
case,
the
HTF
of
different
forms
are
dynamic.
We
need
to
with
a
way
to
describe
how
this
is
retrieved
and
we
will
need
to
be
able
to
better
express
different
requests
and
response
payloads
offer
of
an
action.
K
So
I
start
with
the
second
one
and
then
go
to
the
first
one,
but
very
simply
here,
I
I.
Add
the
these
three
different
terms,
so
cool
query
action
is
a
curry,
update
and
cancel
on
the
action
level
that
all
have
input
and
output
fields.
So
if
we
think
of
a
sort
of
a
tree
with
always
say,
I
have
the
title
and
then
in
the
action
for
the
fade,
we
have
the
usual
input
and
output,
but
then
we
can
have
these
other
fields
which
all
have
again
input
and
out.
K
K
Thus,
in
this
case
the
pedal
would
look
like
the
following.
Sorry,
the
TD
would
look
like
the
following
where
we
have
the
query,
which
gives
a
payload
when
at
the
response
that
includes
the
brightness
value
to
current
brightness
and
then
it
can
also
tell
the
status
of
the
action
and
then
we
can
have,
as
usual,
the
update
and
so
on,
and
this
hasn't
changed
from
the
previous
one,
so
the
the
IDS
have
either
dynamic
IDs
or
static
ones.
So
we
will
go
in
this
now
way.
There
are
actually
three
questions.
C
Think
my
question
is
related
to
what
you're
talking
about
now
you're
talking
about
the
first
proposal,
the
second
one.
This
is
the
second
one
second
yeah
yeah,
so
I
just
want
to
address
the
issue
of
URI
templates.
So
one
thing
you've
done
here
if
you
put
in
the
different
options
down
under
forms
under
action
and
if
you
can
just
scroll
up
almost
example,
please.
C
So
these
all
share,
you
know,
you
know
the
same
thing
on
action.
So
to
me
the
logical
thing
to
do
would
be
to
have
for
each
different
thing:
I
can
do
with
an
action,
you
know,
create,
cancel,
request,
status,
etc.
I
should
have
input
and
output
data
schemas
for
those
interactions.
Yes-
and
it
seemed
to
be
the
logical
thing
to
do-
is
to
be
able
to
define
if
I
use
the
same
name
for
an
element
of
data
schema,
then
it
actually
corresponds
to
the
same
entity.
C
So,
for
example,
if
I
create
an
action
and
I
get
back
a
result,
but
I
label,
as
an
ID
later
on
at
the
URI
template,
where
I
define
an
ID
to
be
used
in
that
URI,
template
I
think
we
could
simply
say
those
are
the
same
thing
so
that
the
system
understands
that
that
data
is
to
be
carried
forward
from
the
response
back
into
the
to
the
other
interaction.
I.
C
K
C
C
K
K
Okay,
then,
so
about
the
dynamic,
a
shifts
by
the
way.
So,
as
Klaus
had
pointed
out
on
Friday,
we
could
have
the
entire
hf
as
a
variable.
So
it
could
be
that
there
is
only
the
ID
in
the
Ashraf
okay
and
then
for
the
case
of
HTTP.
And
so
how
can
we
explain
and
construct
the
dynamic
HSV's?
So
as
the
HTTP
standard
and
like
most
of
the
Brooke
tells,
is
that
in
the
in
the
status
code
of
2
or
1?
K
So
within
the
response
that
has
2
or
1
in
the
service
code,
it
can
actually
be
that
this
location
is
supplied
in
the
header
of
the
response
or
it
could
be
in
the
body
of
the
response.
So
in
case
it
is
in
the
header,
then
we
would
have
to
have
a
form
like
this,
where
we
say
that
the
headers
are
like
this,
where
the
location,
so
it's
it's,
always
called
location
and
early
by
the
standard,
and
then
this
ID
should
be.
K
There
already
mapped
back
to
the
forums
that
we
had
shown
before,
and
the
consumer
should
understand
that
this
is
the
headers
of
the
response
and
not
the
request
that
it
has
to
supply,
for
example,
and
that
location
is
I,
think
always
in
the
response
and
and
then,
if
it
is
in
the
body
of
the
response,
then
we
would
have
to
have
a
TD
where
we
have
the
input
again.
But
then
the
response
of
this
first
post
operation
has
and
let's
say,
a
key
called
hhf,
and
then
this
is
linked
back
to
ID
and
not
supersets.
K
D
Want
it
to
ask
that
so
it
looks
like
you,
have
three
standard
actions
associated
an
action
and
in
some
cases
I
still
probably
would
prefer
to
configure
some
events
for
the
updates
and
an
action
for
the
canceling,
which
leads
to
the
question
that
if
it
would
return
something
like
I
think
it
will
be
easier
to
model
with
properties,
actions
and
evens.
What
it's
possible
to
do
it
on
that
interaction.
D
K
L
H
K
L
K
L
D
E
B
C
Way
to
discuss
this
is
there's
an
API
specification
conference
coming
up
which
will
actually
involve
open
API
as
well
as
others,
and
we're
contemplating
doing
a
submission
to
that.
This
might
be
able
using
topic
to
bring
up
in
that
community
and
I.
Think
it'd
be
interesting.
Also.
The
wish
II
people
also
participate
so
like
bringing
up
earlier,
but
I
think
interesting
to
look
at
this
at
this
conference
as
a
venue
for
discussion
with
a
wider
group.
C
Always
we,
the
web
of
things,
we've
been
discussing
this
in
the
main
call
web
participate
in
the
API
specification
conference.
We
have
an
issue
discussing
that
right
now
and
actually
I
noticed
I
get
posted
posed.
Abstract
I
do
think
this
topic
of
how
to
handle
media
controls
is
a
very
interesting
one
and
is
likely
to
be
a
subjective
conversation
at
that
conference.
A
It's
over
time,
but
thank
you,
everyone
for
very
good
discussions
and
clear,
there's
much
more
interesting
work
for
all
of
us
to
be
doing
together.
So,
as
Crafton
pointed
out
already,
I
think
we
can
use
the
upcoming
we.
She
calls
to
take
more
focused
step
on
a
specific
items
that
we
have
discovered
today
and
we
certainly
need
to
keep
on
going
on
this
ongoing
work
on
aligning
team
description,
templates,
I,
think,
description
and
I
don't
want
the
MSDS
but
I
think
the
next.
A
We
she
call
is
going
to
be
a
good
venue
for
all
of
those.
So
looking
forward
to
see
as
many
of
you
as
possible
on
June
30th,
we
should
call
it's
gonna
be
most
likely
on
a
later
time
than
usual,
so
also
people
from
us
should
be
able
to
join
it,
but
apologies
for
everyone
in
Asia.
For
for
that
particle,
or
instance,
and.
B
Wanted
to
point
to
the
link
with
the
agenda
to
the
next,
which
she
called
it
would
certainly
have
some
form
of
sync
of
England
research
group
meeting
it
again
in
the
second
half
of
July,
but
we
are
still
trying
to
find
out
the
details
for
that
so
for
now.
Thank
you
all
for
joining
and
hopefully
see
you
in
that
research
meeting.