►
From YouTube: CORE WG Interim Meeting, 2021-02-04
Description
CORE WG Interim Meeting, 2021-02-04
A
So
the
note
will
apply
is
if
you're
not
familiar
with
this
point
already,
please
get
familiar
with
them
and
let's
say
we
can
move
on
to
the
main
topic
of
today.
It's
progress
on
the
dynamic
document,
especially
the
new
parameters,
and
we
can
also
revisit
open
issues
on
the
github
so
bill
floor
is
yours.
I
can
navigate
a
slice
for
you.
B
B
Right
so
the
oh
sorry,
I
think,
there's
a
there's
an
artifact
there
from
from
the
first
bullet
point
and
sorry
that
that
shouldn't
have
been
there,
but
there
are
changes
from
version
version
11
to
version
12.,
mostly
mostly
from
this
okay.
So
there
are
several
words,
several
several
issues
and
and
this
issue
that
you
see
now
issue
number
25
was
closed.
C
D
B
C
C
Probably
I
guess
we
could
consider
that,
but
we
are.
We
are
basically
setting
expectations
for
what
happens
and-
and
there
are
a
bunch
of
other
cases
in
this
draft
where,
where
we
were
asked
to
explain,
you
know
the
behavior
for
different
corner
cases,
and
so
I
think
this
is
definitely
one
that
that
requires
explanation
and
behavior.
B
D
C
I've
even
observed
best
effort,
so
I
I
see
no
problem
in
extending
the
idea
of
best
effort
to
these
parameters
and
not
not
representing
it
as
a
contract,
but
as
a
a
sort
of
programming
of
a
state
machine
that
does
the
notification
and
I've
always
seen
it
that
way,
and
it
always
has
worked
out
in
implementation.
That
way,
I
mean
so,
and
I
guess
that's
the
way,
it's
the
way
it's
sort
of
implemented
in
lightweight
mtm
implementations,
the
way
it's
implemented
in
the
arm
embed
server.
B
B
C
Yeah,
I
think
I
think
that
could
be.
That
could
be
good.
I
think
that
if
you
really
need
to
hit
periodic
bounds
like
in
a
process
control
system
in
a
in
a
in
an
industrial
field,
bus
or
something
like
that,
you're
going
to
be
using
tsn
and
you're
going
to
be
using
some
kind
of
delay,
you
know
dll
kind
of
thing
on
the
nodes
to
do
that,
and
that's
not
what
this
is
for
and
we
think
we
could.
We
could
make
that
clear.
E
F
B
Okay,
thank
you,
so
I'll
get
get
that
next
version
then
going
on
to
the
other
changes.
So
this
this
has
already
been
been
in
in
the
in
the
pipeline
for
a
long
time,
and
and
now
it's
in
version
12..
So
there
are
these
two
attributes,
epmain
and
ebmax,
which
suggested
was
suggested
by
ellen
and
which
talk
about
evaluation
periods
at
the
server.
So
so
this
is.
B
This
is
something
that
is
in
the
drop
now
and
also
while
we
were
doing
this,
we
had
a
small
editorial
change
and
then
we
realized
that
some
of
these
attributes
were
conditional
notifications
and
some
of
them
were
controlled.
So
now
there
is
in
drop
12.
There
is
a
separation
between
which
attributes
are
conditional
notification
attributes
and
which
are
conditional
control
attributes
and
in
the
conditional
control
attributes
we
left
p
min
p
max,
ep
min
and
epmax,
and
then
in
the
conditional
notification
part
we
we
have
the
others.
E
Hey
guys,
you
know
I'm
fine
with
evaluations.
I've
used
both
so
there's
there's
a
separation
of
responsibilities.
When
you
actually
go
read
a
value
versus
when
you
can
compare
that
value
and
so
to
me,
and
this
one
I
was
actually
doing
two
measurements
so
reading
the
sensor
itself
versus
comparing
the
doing
the
evaluation
of
what
was
read.
So
in
this
case
I
thought
consecutive
measurements
was
correct,
but
evaluations
is
probably
better.
I
think
well.
E
B
G
C
C
B
B
C
Okay,
so
the
the
idea
here
is
that
I
guess
to
to
try
to
re-summarize
it's
maybe
not
needed,
but
that
this
is
a
hint
to
the
sampling
system
about
what
frequency
you
expect
it
to
work
at,
even
though
it
doesn't
really
affect
the
notification.
In
other
words,
you
could
look
at
the
notification
parameters
and
the
type
of
sensor
you
have
and
make
a
decent
judgment
about
the
sample
rate.
But
what
you're
trying
to
do
is
sort
of
provide
a
hint
to
the
sensor
to
to
change
that
right.
C
E
E
C
So,
okay,
basically,
this
normally
wouldn't
really
be
part
of
the
design,
except
that
it's
such
a
a
common
thing
to
do,
and
also
this
is
the
place
to
do
it.
I
mean
it's
like
it
would
definitely
as
sort
of
in
in
band
with
the
whole
reporting
and
sampling
system.
So
I
kind
of
I
kind
of
would
advocate
for
having
this,
because
I
guess
we've
already
decided
to
have
it
anyway,
but
it
seems
like
it's
even
though
it's
not
a
reporting
parameter
and
you
could
conceivably
do
without
it.
E
And
you
know,
michael
it's
interesting,
because
when
we
started
to
go
down
this
path,
what
we
figured
out
is
we.
We
really
have
two
sets
of
parameters
or
attributes
here,
one
doing
with
the
actual
evaluation
of
the
measured
value
and
then
the
the
second
was
really
the
the
control
attributes
of
reporting,
or
in
this
case
both
sampling
and
reporting
so
yeah
it,
it
kind
of
makes
sense
to
have
both
dimensions.
E
C
I
don't
want
to
bring
up,
but
you
could
actually
report
multiple
samples
when
you
report,
so
you
could
have
a
system
that
samples
at
one
rate
and
reports
at
a
lower
rate,
but
reports
all
of
its
samples
and
so
and
that's
really
useful
for
like
seismic
and
stuff
like
that.
So
maybe
that's
outside
the
scope
of
what
we
want
to
limit,
but
that
that
should
probably
be
allowed.
Also.
A
G
Then,
oh
yes,
sorry
last
thing
it's
for
the
minute
for
this
the
minute,
so
I
think
we
have
the
latest
version
of
live
within,
but
if
you
alan
could
be
so
kind
to
copy
paste.
The
section
with
the
if
you
mean
that
max
is
fine
for
the
minutes,
that'll
be
great,
just
copy
paste
it
in
the
in
the
link
in
the
chat
you
can
please.
B
Okay,
then,
if
we
move
forward
the
next,
the
next
page,
the
next
slide.
Sorry
so
this
is.
This
is
a
what
what
is
planned
in
the
in
the
versions
of
the
of
the
version
12..
So
there
has
been
some
discussions
previously
about
with
with
klaus
and
some
others
who
indicated
that
that
the
way
the
the
the
text
is
written
now
does
not
does
not
reflect
a
very
restful
way
of
of
doing
doing
notifications
between
a
server
and
a
client.
B
But
that
also
means
that
I
I
started
to
look
at
the
current
text
in
pma
and
pmax
and
and
and
step
about
sampled
values
and
there's
a
lot
of
text
there.
That
says
that
that
the
new
values
that
that
are
being
transferred
to
the
client
will
be
sampled
from
the
server
side.
So
I'm
gonna
try
to
see
if
it's
possible
to
restrict
this
this
text
so
that
when
we
talk
about
sampling
and
and
values,
we
try
to
limit
that
to
epma
and
epmax.
E
B
That's
the
most
important
changes
that
will
be
made
and
then
also
there
was
a
discussion
about
the
possible
impact
of
having
proxies
between
the
client
and
the
server
and
the
behavior
of
these
conditional
modification
systems
on
on
receiving
the
the
correct
notifications
to
the
client.
If
there
is
a
process
in
between,
I
don't
think
we
reached
a
consensus
on
how
to
proceed
with
that
yet,
but
that
is
that
is
in
the
pipeline.
A
H
C
Yeah
yeah
yeah,
because
the
proxy
it
depends
on
the
proxy
policy.
This
could
be
made
to
work
with
a
pub
sub
protocol
proxy
that
you
know,
but
the
caching
proxy.
The
way
we
normally
think
of
it
in
a
restful
system
was,
I
think,
the
the
main
issue
with
being
able
to
just
transparently
cache
things,
and
there
was
some
specific.
I
think
I
wanted
to
capture
that
there
was
some
very
specific.
C
You
know
we
talked
through
it
and
and
yeah.
You
couldn't
just
apply
a
regular
caching
proxy
up
and
have
a
bit
different
policy.
If
you
want
the
notifications
to
come
through,
but
I
don't
remember
the
you
know,
we
don't
have
to
walk
through
the
specifics
of
it,
but
it
I
think
it
had
to
do
with
both
the
proxy
and
the
caching
that
that
was
the
problem.
B
C
There
was
also
some
concern
that
you
know
values
might
be
sent
that
were
not
changing
and
how
that
affected
things,
but
whether
you
wanted
to
just
keep
the
value
the
same
or
whether
you
wanted
to
actually
send
a
notification
of
the
unchanged
value.
And
there
was
some
confusion
that
had
had
scratching
about
what.
What
that
even
meant
again.
E
C
A
C
I
think
that
my
my
issue
that
I
took
away
from
that
discussion
was
that
there
were
things
that
what
we
couldn't
agree
on
was
whether
to
prohibit
things
that
were
allowed
now,
and
I
think
there
are.
I
think
we
need
to
circle
back
with
christian
and
klaus
both
to
find
out
specifically,
maybe
get
point
put
a
tighter
sharper
point
on
those.
But
I
don't
see
a
problem
with
adding
things
to
provide
mechanisms,
but
also
we
need
to
probably
standardize,
what's
already
being
done.
C
If
we
can-
and
I
didn't
really
see
any
show
stoppers,
it
was
just
that
there
was
a
better
way
to
do
it.
That
did
include
caching
proxies
that
had
a
different
set
of
had
a
kind
of
a
different
state
machine
and
used
different
scent
values
were
sent.
Values
were
critical
to
this
and
we're
trying
to
stay
away
from
you
know
what
what
actually
gets
spent
and
having
the
value
be
part
of
the
I
don't
know
the
value
is
part
of
the
state
machine
and
that
it
gets
evaluated
by
the
limits.
C
But
that's
that's
all
we
wanted
to
do
and
then
there
were
some
other
things
about
deltas
or
something
like
that.
I
don't
remember
the
exact
designs
being
proposed,
but
it
was
a
different
set
of
designs
and
I
think
if
we
could,
we
could
restart
that
discussion
and
figure
out
whether
we
could
do
it
in
an
additive
way
that
didn't
prohibit
some
of
the
things
that
were
currently
being
done.
Specifically,
I
remember
christian
didn't
like
the
idea
that
you
could
set
the
parameters
by
that
were
constant.
C
He
wanted
to
only
allow
parameters
that
were
per
request
and
for
a
session.
If
you
will
the
observed
session,
and
I
think
that
lightweight
mtm
and
some
other
implementations
do
need
to
basically
just
if
you're
looking
at
a
point-to-point
thing,
especially
like
with
them
to
m,
it
goes
from
a
single
sensor
to
the
server.
We
don't
even
allow
multiple
connections,
so
you
know
in
that
sense
it
makes
sense
to
just
store
them
for
for
resource,
but
I
think
we
need
to
actually
check
that
out.
C
C
Just
to
close
that
off,
I
was
proposing
that
we
allow
three
ways
of
setting
the
parameters
and
two
of
them
were
per
session
and
one
was
being
stored.
But
I
don't
remember
the
exact
and
we
didn't
have
to
say
that
the
way
lightweight
mtm
works
and
storing
them
with
a
payload
on
a
get
or
something
like.
No,
I
don't
remember
what
it
was.
It
was
a
foot
with
an
empty
payload
or
something
like
that,
but
query
parameters.
C
We
don't
have
to
specify
that
particular
method,
but
we
should
be
able
to
say
that
it's
okay
to
store
the
parameters
per
resource
like
there
could
be
a
stored
set
of
parameters
that
can
be
also
parameters
per
observed
session,
and
I
think
that
that's
that's
what
I
was
proposing
and
then
there
are
two
different
ways
of
setting
it
for
session
on
the
query
parameters
and
one
some
other
way.
I
don't
remember,
but
that's
where
I
think
that
was
lapse,
and
I
think
we
are
meaning
to
circle
back
with
christian
and
find
out.
C
You
know
just
sort
of
propose
that
and
say
is
that,
okay,
that
you
know
again
it's
an
additive
thing
where
I
don't
think
we
need
to
be
prohibiting
things
that
the
people
are
doing,
but
we
don't
have
to
specify
them
either
if
we
think
they're
anti-patterns.
So
I
think,
there's
a
happy
medium
in
there.
A
B
B
Okay,
so
not
very
much
slides
left.
I
think
if
we
move
to
the
next
one
marco,
you
have
it
so
thanks
yeah.
So
there
are,
there
are
three:
there
are
three
attributes,
and-
and
actually
I
also
raised
them
at
the
last
meeting-
I
haven't
received
any
replies,
but
but
since
we
have
a
slug
involved
targeted
group
here,
it
might
be
good
to
raise
that
again.
So
three
new
attributes
were
proposed.
B
C
Specs,
so
michael
costa,
again
of
course
the
the
spec
as
it's
written
requires
notification
at
any
time,
one
of
the
fixed
limits
is
crossed,
and
I
think
that
I
think
this
is
for
the
fixed
limits
and
not
for
the
moving
limit,
but
maybe
it
applies
to
the
moving
limit
in
some
sense
also,
but
you
were
able
to
then
track
the
band.
That's
about
you
know
they
had
this
concept
of
there
being
like
three
bands
high
medium
low.
C
If
you
have
two
limits
and
five
bands,
if
you
have
four
limits,
etcetera,
because
the
basic
algorithm
is
extensible
they're
more
than
just
two
limits,
it
works
scalable,
but
you
were
able
to
track
which
band
the
sample
samples
last
notification
was
in
because
you
had
notifications.
Of
course,
this
limits
your
ability
to
do
that,
but
also
it's
not
required.
You
can
still
have
both
edges,
so
it
seems
like
we
had
this
discussion
in
lightweight
mtm
that
sometimes
you
really
only
need
to
know
the
positive
crossings.
C
G
E
I
cannot
see
it
on
the
back
so
the
way
I
did
this
is
I
just
nope.
Sorry
I
mean
the
the
I
didn't
I
didn't
propose.
The
changes
in
I
didn't
create
a
pull
request
or
only
created
an
issue
because
the
issue
represents,
what's
when
within
lightweight
m
lightweight
m
to
m,
but
I
didn't
it,
I
guess
it
wasn't
really
my
goal
to
get
it
adopted
into
the
din
link
draft.
E
G
B
Github,
I
I
actually
had
a
question
on
this
edge
attribute
because
it
specifies
the
first
thing
it
specifies
is
that
it
says
the
edge
attribute
indicates
a
transition
of
a
boolean
resource,
and
then
it
goes
on
to
talk
about
observed,
resource
and
and
so
on.
So
could
you
could
you
explain
the
significance
of
a
boolean
resource
in
that
sense
that
do
you?
Does
it
necessarily
need
to
be
either
zero
or
a
one,
or
can
it
be,
for
example,
just
true
or
false?
Does
it
have
to
be
zero
or
one.
E
E
C
Right,
okay,
so
this
is
when
you're
observing
a
boolean
and
the
boolean
changes
both
directions.
The
the
existing
specs
says,
you
know
report
both
ways,
and
this
says,
if
you
want
to
know
both
transitions
with
edge,
you
could
set
up
one
for
positive
reporting,
one
place
and
one
for
negative
ones,
reporting
someplace
else.
If
your
system
works
that
way,
and
that
might
be.
E
I
think
it's
a
little
bit
different.
You
would
not
define
edge
in
that
case
because
the
default
behavior
is
you
track
both
transition
states
also
true
and
true
to
false.
That's
the
default
right,
that's
the
behavior
we
already
have.
This
is
if
you
already
know
that
you
only
want
to
track
one
direction.
You
can
use
this.
G
E
E
I
don't
think
we
care
about
it
quite
as
much
in
the
in
a
call
it
a
normal
deployment,
but
if
this
stops
a
a
an
uplink
message,
which
is
very
costly
to
just
to
say
that
we
went
from
true
to
false,
even
though
we
don't
care
about
it,
then
that's
what
they're
trying
to
prevent
through
this
attribute.
So
I
don't.
E
I
don't
really
know
how
prevalent
it's
going
to
be
and
if
it's
a
lightweight
m,
explicit
thing,
that's
fine.
You
know
I.
I
have
no
problem
with
supporting
the
fact
that
it's
not
a
a
common
use
attribute
and
if
somebody
wanted
to
find
this
for
lightweight
eminem
they're
more
than
welcome
to
so
we
can
ask
for
additional
justification.
If
we
want-
or
we
can
just
say
it's
rejected,.
C
So,
but
to
to
address
what
time
he
said,
I
don't
think
there's
a
way
to
specify
this
entirely
in
co-op,
because
this
is
really
a
resource
value
kind
of
thing,
just
like
a
numeric.
So
if
you
look
at
the
example
code,
we
really
are
talking
about
three
types
here:
we're
talking
about
scalar
types
and
string
types
and
and
boolean
types
which
or
we
guess
could
be
expanded
to
any
kind
of
enum
type
or
or
category
type.
C
This
is
sort
of
like
a
special
case
of
a
value,
but
there
are
only
two
values,
and
this
is
you
know
it's
not
really
greater
than
or
less
than,
but
you
can
say
positive
or
negative.
So
I
think
this
is
just
a
special
case
of
value
where
this
attribute
only
applies
to
values
that
that
have
true
false
and
we
could,
you
know,
there's
one
zero,
true
false.
Sometimes
it's
even
text
values
that
are
true
and
false
and
we'd
have
to
define
whether
whether
this
edge
would
apply
to
whether
you're
sending
like
a.
E
C
C
C
Also
true
of
just
general
sort
of
resources
in
general,
like
if
you're
talking
about
I'm,
not
sure
about
sibor
but
json,
has
true
and
false,
and
I
think
seabor
has
a
probably
a
built-in
boolean
type
also,
and
that's
really
what
we're
talking
about
is
when
you're
using
that
type.
That's
when
this
attribute
applies,
that's
the
way
I
understand
it,
and
I
think
we
should
just
clarify
that
in
the
text.
If
we
include
it,
I
think
it's
useful.
B
So
as
time
goes
by,
let's,
let's
assume
the
the
the
original
state
of
the
resource
there
is
is
false
and
it
goes
to
true.
So
then
the
server
sends
one
notification
right
and
the
state
will
be
set
to
true
now.
Does
that
mean
that,
okay,
when,
when
it
moves
back
to
false,
you
don't
send
anything,
but
then,
when
it
goes
back
to
true,
you
send
another
true,
so
does
this
mean
that
the
client
will
be
continually
getting
state
obser
observed
states
that
are
the
same.
D
Well,
my
answer
would
be
that
that
this
is
just
a
request
to
the
server
to
spend
more
more
of
a
best
effort
in
notifying
one
edge.
Then
then
notifying
the
other
edge.
But
it
doesn't
mean
that
the
servers
prohibited
from
notifying
the
other
edge
just
means
that
that
it
should
try
really
really
hard
to
notify
the
one
edge.
F
C
Well,
it
doesn't
have
to
try
at
all,
and
the
other,
on
the
other
edge
is
really
what
we're
saying
yeah
I
I
guess
I
would
agree
that
it
we
wouldn't
prohibit
it
from
sending
extra
notifications.
I
guess,
but
if
you
were
building
a
system
that
was
conscious
of
you,
know
energy
and
resource
use.
It
wouldn't
do
that
very
often.
B
D
B
B
Okay,
okay,
excellent,
oh
rush,
okay
and
then
there
is
the
the
the
next
attribute
is
also
it's
about
whether
the
notification
should
be
sent
over
confirmable
transport.
So
this
is
this.
Is
this
text
obviously
is
extremely
lagging
and
specific,
since
it
talks
about
objects
and
instances
and
resources
and
resource
instances.
C
E
E
B
E
C
Oh
yeah,
I
would
echo
that
in
my
in
my
experience
using
this,
this
conditional
notification
and
some
practical
applications
like
sending
light
dimmer
setting
values
to
a
light,
and
things
like
that.
Sometimes
con
works
better.
Sometimes
it
works
worse,
and
so
you
definitely
need
to
set
it,
and
what
I
had
to
do
in
my
implementation
was
go
and
change
some
defaults
and
some
c
header
files-
and
I
would
rather
not
have
done.
E
C
E
The
reason
we
did
it
is
it
essentially:
if,
if
it's
a
fire
and
forget
so
it's
non-confirmable,
you
tear
down
the
radio
connection
as
soon
as
you
send
this
you're
done,
you
sent
it,
I'm
done
throw
down
the
radio
connection
with
whatever
you
know
time
to
live.
You
may
have
for
that,
but
the
if
it's
confirmable
you
have
to
leave
the
connection
up
waiting
for
that
confirmation
and
so
you're
you're,
actually
using
up
more
radio
resources.
E
If
it's
non-confirmable
you
send
it,
you
drop
your
radio,
it's
lost
you're,
like
hey,
you
know
I
can
live
with
that,
but
if
this
is
an
alarm
a
in
other
words
my
building's
on
fire,
you
don't
want
that
to
be
sent
non-confirmable.
You
want
to
be
acknowledged
from
the
the
the
the
client
side
and
you
have
different
behavior
based
upon
that
allowance
versus
another
alarm.
So
the
the
use
of
it
is,
I
think,
important,
the
verbiage.
We
we
need
to
make
it
more
generic
agreed
and
get
rid
of,
maybe
not
even
confirmable
transport.
C
G
Really
think
it
has
to
do
just
a
second
michael.
I
would
also
like,
if
you
could
build
just
or
the
alphas
for
all
of
these
new
attributes,
just
make
sure
that
all
the
live
attention
jargon
is.
They
will
remove
generalized
to
co-op
endpoints
and
to
avoid
the
usual
confusion
between
resources,
in
line
with
n2m
and
resources
in
the
co-op
sense,
the
client,
server
roles
etc.
Because
that'll
be
important,
and
this
clarification
that
alan
just
made,
I
think
it
could
be
useful
for
the
reader
to
it
doesn't
have
to
be
long
but
like
to
explain.
C
View
I'd
suggest
we
look
at
even
not
being
co-app
co-app-specific,
but
just
being
generic
and
saying
whether
you
expect
acknowledge
acknowledgements
to
these
notifications
or
not,
because
that's
really
what
you're
doing
with
khan
and
there
are
other
places
you
might
want
to
use,
observe
outside
co-op
protocols
where
you
could
map
it
to
some
other
kind
of
behavior.
I
guess
we
could
use
collab
con
as
an
example,
but
but
not
not
in
a
normative
way.
I'd
suggest.
B
Yeah,
I
think
I
think
this.
This
is
the
point
I'm
trying
to
think
of
of
whether
these
these
draft
maps
match
into
the
respiratory
or
is
it
quite
specific,
and
I
think
a
lot
of
the
the
draft
is-
is
not
necessarily
only
focus.
So
when
we
talk
about
confirmable
transport,
there
are
two
parts
with:
are
we
talking
about
non
and
cone,
or
are
we
talking
about
transport
in
a
sense
that
it's
a
udp
versus
tcp,
for
example?
E
I've
got
reliable
transports.
I
now
understand
the
the
comments
from
earlier.
I
was
thinking
co-op
specific
because
I
always
map
things
to
co-op
yeah.
This
is
this
is
more
about
acknowledgement
and
acknowledgement
at
co-app
is
confirmable.
So
if
acknowledgement
is
provided
through
some
other
layer,
then
you
wouldn't
need
a
an
acknowledged
transport.
You
need
an
acknowledged
message.
F
E
E
Yeah,
this
is
definitely
violating
some
layers
or
trying
to
incorporate-
let's
say
a
device
state
with
the
ability
to
report.
So
if
the
device
knows
that
it
doesn't
have
a
connection,
then
it
can't
it
knows
that
it
can't
even
send
a
non-confirmable
message
right,
so
it
does
violate.
I
don't
know
when
I
say
violate
it.
It
includes
an
evaluation
of
a
communication
state
to
be
realistic.
C
Maybe
it
wouldn't
need
to,
though,
because
maybe
what
we
could
say
is
that
you're,
so
one
thing
is,
it
seems
like
you're,
probably
ignoring
pmax
or
something
like
that,
so
never
mind
tmax,
but
what
you
could
say
is
simply
that
you're
allowed
to
send
multiple
notifications,
and
this
is
how
many
your
the
maximum
that
you're
expecting.
If
that's
really
what
you're
saying
here.
In
other
words,
you
don't
really
have
to
talk
about
online
offline.
You
can
just
say
when
you
notify
yeah.
You
know.
E
But
if
you
have
an
a
priori
knowledge
that
you
cannot
notify,
do
you
throw
it
into
the
queue
or
do
you
only
throw
it
into
the
queue?
If
it's
confirmable,
because
you
assume,
if
it's
not
confirmable,
it's
fire
and
forget
which
then
you
don't
really
care,
whether
there's
a
a
current
con
link,
all
you
care
about
is,
I
know
it
can't
get
there.
So
I'm
going
to
forget
it.
C
Well,
it
could
be
an
app,
it
could
be
a
system
policy
whether
to
queue,
and
you
could
cue
all
the
messages
and
when
your
queue
gets
full
you
can
start
throwing
away
a
non
non-act
one
one's
adobe
player.
I
mean
you
know
how
much
do
we
have
to
couple
all
the
behavior
of
the
different
parameters.
That's
my
question.
I
don't
want
to
get
talked
about
it
too
long.
E
I
I
I
I'm
glad
we
were
able
to
introduce
it.
I
don't
think
we're
going
to
work
through
all
the
logic
on
the
next.
Oh
on
this
call,
because
I
actually
have
to
drop
sorry
about
that,
but
I
I
think
it's
an
important
concept
that
if,
if
the
observation
is
not,
I
don't
know
if
yeah-
and
I
think
you
guys
know
the
questions,
it's
really
along
the
line
of
you
know.
If
do
you
actually
create
a
cue
if
you
know
that
message
is
not
getting
through
and
how
deep
is
it.
D
B
B
C
Right
we
could
enable
it
as
application
behavior
and
also
not
if
it
wasn't
tied
to
co-app.
So
in
co-app
you
do
have
a
question
about
observe
and
what
the
meaning
of
the
values
you
get
on
observe
is.
But
if
it's
not
coap,
if
it's
just
being
used
in
general,
I
think
just
allowing
the
idea
of
cueing
them
and
maybe
it's
an
application
layer
question
I
mean
I
can
write
a
co-app
notification
handler
that
handles
multiple
values.
It's
just
not
it's
not
specified.
I
don't
know
if
it's
even
prohibited.
C
I
think
that's
that's
an
issue
in
and
of
itself.
You
know
how
that
break
collapse
or
whatever,
but
that's
really
what's
being
done
here
and
I
again,
I
think
that
there
are
other
cases
where
you
might
want
to
do
it
like,
even
if
you
just
had
pmax
reporting
and
wanted
to
report
samples
within
that,
I
think
that's
a
valid
use
case,
but
I
think
we
do
have
to
answer
what.
What
does
that
mean
in
terms
of
what
we
expect
from
a
co-op
system.
B
Yeah
and
I
I
can't
understand
how
this
might
work,
for
example,
if
assuming
this
behavior,
if,
if
the
server
comes
back
up
online-
and
there
are
notifications
in
the
queue
to
be
sent
and
there's
a
team
in
value,
and
then
you
have
to
send
these
messages
from
the
queue
at
the
same
time
as
state
changes
that
might
be
occurring
while
it
is
off
or
while
it
is
online.
So
well.
C
You
could
do
this
if
there
were
time
stamps.
You
wouldn't
really
have
an
issue
with
that.
I
think
this
is
basically
to
support
a
functionality
like
logging
and
things
like
that,
where
you
want
to
store
some
things
and
not
lose
them
and
just
send
them
later
as
data,
but
but
you
want
to
be
able
to
to
specify
some
size
to
minimize
network
consumption
right
and
even
just
to
prevent
tdos
attacks.
You
might
want
to
have
this
kind
of
parameter
in
your
system.
C
C
Is
historical
it
is,
but
so
again
co-op
observe.
Has
this
doesn't
really?
This
isn't
what
we
expect
from
co-op
observe,
but
it
maybe
is
a
different
kind
of
notification
where
you're
not
trying
to
treat
it
as
state
changes
on
a
single
value,
and
so
that's
that's
really
what
we
need
to
reconcile.
I
think
we
do.
We
add
this
to
our
cueing
and
batch
notification.
Behavior
at
all.
C
Well,
so
this
is
what
you
would
do,
and
this
is
done
in
a
lot
of
systems
today,
if
you
want
to
have
co-op
as
part
of
the
system
that
has
this,
we
need
to
figure
out
what
the
best
practice
would
be
for
implementing
it,
because
to
do
efficient
log
notifications
and
efficient
transmission
of
this
kind
of
data.
This
is
kind
of
what's
done
and
whether
it's
part
of
our
protocol
or
not,
I
guess
we
can
still
decide.
G
Just
one:
well,
we
are
trying
to
talk
at
the
same
time.
We
might
have
to
start
moderating,
maybe
a
bit,
but
let
me
just
jump
in
with
some
clarification
for
the
notes
and
also
for
myself,
so
to
my
understanding.
Link
actually
was
still
intended
for
co-op
and
points
about,
because
we
are
mentioning
multiple
times
in
the
discussion
that
it
might
be
for
other
kind
of
endpoints
and
and
it's
great
if
we
can
generalize,
but
it
should
support
rfc
7252
and
similarly,
it
was
intended
for
observe.
G
B
So
when
I
came
on
what
is
the
editor,
I
think
I
think
it
was
more
than
just
coil.
So
there
is
the
observe
attributes.
There
is
one
part
of
that,
but
then
again
later
in
the
draft,
there
is
the
the
concept
of
link
bindings
and
in
the
link
bindings
it
I
mean
the
draft
is
oriented
towards
mostly
supporting
co-op,
but
that
there
are
other
risk
methods
that
it
starts
to
support
and
and
especially
later
on,
we
talk
about
leak
bindings.
G
C
I
think
that,
but
another
point
with
the
draft
like
this,
just
speaking
as
one
of
the
draft
authors
is
that
we're
providing
a
pattern
that
you
know
is
is
will
work
on
co-op
for
sure,
but
also
we
recognize
that
this
is
a
higher
level
application
pattern.
It's
sort
of
like
the
way
we
align
pub
sub
with
other
pub
sub
systems
and
stuff,
like
that,
so
having
it
to
be
useful
in
a
system
that
so
I
guess
what
I'm
saying
is.
C
We
shouldn't
really
build
things
in
a
way
that
restricts
systems
to
only
have
co-op
end-to-end
and
that
we,
we
probably
want
to
be
able
to
do
some
communication
and
proxy
and
have
collapse
to
be
part
of
other
systems,
and
so
in
designing
this
in
a
way
that
everyone
can
use
it.
Just
it's
just
useful
to
design
a
general
pattern,
but
of
course
yeah
you
know
so
the
question
of
does
it
break
observe?
C
Well,
if
I
can,
I
use
observed
just
to
notify,
I
can
use
co-op
as
a
protocol
just
to
notify
data
without
having
any
any
particular.
You
know
I
can
send
one
and
then
I
can
send
through
and
then
I
can
send
a
string
and
you
know
I
can
really
do
that
and
nothing
is
preventing
me
from
from
changing
the
type
of
data
that
I
send,
because
collab
doesn't
really
restrict
that.
So
I
I
don't
know
what's
what's.
What
do
we
want
to
prohibit?
C
So
if
someone
uses
co-app
to
create
a
spec
like
ocf,
they
get
to
decide
whether
it's
part
of
their
spec
or
not.
If
I
just
implement
co-app
as
a
contractor
on
somebody's
industrial
control
system,
I
might
decide
to
use
this
on
my
my
scada,
because
it's
efficient
and
it
doesn't.
I
don't
really
care
it's
just
in
dan
and
but
I'm
still
using
co-op,
because
all
my
endpoints
already
support
it.
I
don't
want
to
just
switch
to
modbus
just
for
this.
You
know,
I
don't
know
enough
sad.
I
guess.
D
B
B
B
C
Is
there
anything
one
more
comment
to
make
that
I
wanted
to
make
earlier,
and
that
is
that
this
this
may
be
a
case
where
we
close
off
the
additions
to
this
draft
and
we
have
follow-on
drafts
that
describe
additional
parameters
and
and
it's
sort
of
easy
to
break
it
up
that
way,
and
maybe
we
should
think
about.
Although
we
do
have
a
minimum
set
of
things
they
want
from
lightweight
mtm,
but
also
we
could
think
about
closing
off
the
draft
with
the
steps
that
we
all
agree
on
and
know
and
then
figuring
out.
C
But
I
guess
there's
something
to
be
said
for
like,
as
carson
said,
if
we
decide
to
switch
to
using
series
transfer
pattern
for
a
lot
of
these
things,
then
that
might
be
a
different.
You
know
another
question
of
a
separate
draft,
so
I
think
that's
still
an
option
of
saying:
let's
keep
this
draft
simple
and
add
the
additional
material
and
additional.