►
From YouTube: ACE WG Interim Meeting, 2021-05-11
Description
ACE WG Interim Meeting, 2021-05-11
A
C
A
A
E
A
A
B
F
F
G
B
B
B
F
Okay,
there
was
one
thing
in
murray's
review
where
he
was
wondering
if
we
had
to
there's
this.
This
part
where,
where
the
the
access
token
is
updated
and
and
replaced,
and
at
some
point,
we
found
that
we,
according
to
the
to
the
framework
document,
had
had
had
a
language
in
there.
That
says
that
the
new
access
token
should
replace
previously
issued
access
tokens,
and
we
had
a
discussion
about
that.
F
B
Clarification
of
the
comet
yeah,
I
know
for
me,
it's
the
same.
If
I,
if
I'm
not
working
on
something,
I'm
always
surprised
so
I
yeah
it
seems
we're
on
good
track
for
that
document.
Probably
by
the
end
of
the
week
I
mean
the
reason
I'm
asking.
That
is
that
I
want
to
to
tell
ben
the
status
of
those
comments
being
addressed
by
comment
rates
by
the
ih
iasg
are
being
addressed
so
so
that
he
can
approve
them
further.
B
F
G
B
E
No,
I
actually
wanted
to
say
that,
but
I
mean
there
is
one
one
of
the
so
there
is,
there
is
the
discuss
which
you
lifted
so
now
it's
a
no
no
object
ballot
and
there
are
the
feedback
from
from
ludwig
and
there
is
a
one,
a
single
issue
we
should
discuss
at
this
meeting.
Maybe
you
want
to
elaborate
on
that.
G
Yeah,
so
basically
I
wanted
to
say
that
thank
you
to
the
first
to
take
my
my
comments,
and
I
think
that
is
this,
like
that.
The
clarifications
that
were
added
are
good
enough
for
me
to
to
to
like
not
not
discuss
the
document
anymore,
but
there
is
a
number
of
comments
that
I
think
the
working
group
should
talk
about.
It
would
be
better
if
ludwig
was
here
as
well,
but
I
don't
know
if
you
want
to
take
it
now
or
later.
G
E
I
I
mean
it
doesn't
matter
if
we
can,
if
we
I
mean,
maybe
we
can
start
and
see
how
far
we
get
and
maybe
ludwig
needs
to
chime
in
as
well.
I
mean
he's
not
present
and
he's
been
doing
most
of
the
updates.
So
so
he
should
have
a
final
say,
but
if
I
understood
right
there
was
one
major
comment
about
about
the
combination
of
profiles
and
was
there
other
major
comments?
You
think
we
should
talk
about
in
this
meeting.
G
G
G
Of
course,
uh-huh.
Another
thing
that
I
was
saying
is
that
there
is
this
very
useful
table
figure,
a
document
that
summarizes
the
parameters
that
that
are
can
be
part
of
the
access
information
and
it
does
great
and
would
be.
I
thought
it
would
be
great
to
have
the
same
type
of
table
for
the
acceptable
parameters,
for
the
request
and
look.
G
E
G
E
E
G
Need,
even
if
we
don't,
even
if
we
don't
need
to
discuss
these
points,
I
wanted
to
bring
them
up
just
to
just
clarify
yep,
it's
fresh
in
my
mind.
So
that's
good
okay.
This
is
just
clarification
and
yeah
and
then
the
last
point
is
this
one
about
com
buying
profiles,
so
this
might
require
some
discussion
and
people
might
have
opinions
here.
So
there
is
this
one
paragraph
in
the
document
this
is
this
is
37.
G
G
Exactly
what
paragraph
says-
and
I
am
not
sure
of
how
this
work
works
or
yeah?
If,
if
it's
enough
to
just
say
you
can
combine
profiles,
I
mean
also
like
what
are
the
implications
for
implementers
to
mix
and
match
different
files.
Ford
friend,
you
know
between
client,
nas
and
client
and
resource
server.
It
sounds
like
interoperability
could
not
could
like
yeah.
It
could
not
interoperate
if
you
mix
profiles
and
also
you're
getting
different
type
of
king
material,
for
example,
for
the
oscar
profile.
How
do
you
combine
that
with
something
else?
B
G
Now
the
current
state
is,
is
I
mean
if
you
remove
the
paragraph,
then
you
will
be
in
the
status
where
what
you
said
that
it
you
don't
prevent
it
and
you
don't
define
it,
but
this
products
kind
of
makes
you
think
about
it.
How
it
says
that
there
may
be
a
use
case
where
profiles
are
combined,
but
it
doesn't,
it
doesn't
say
how
this
would
work.
So
it's
kind
of
to
me
that
this
is
not
enough
text.
H
G
So
I
did
between
client
and
resource
server,
client
nas,
but
I
mean
to
me
if
you
take
two
different
profiles
that
can
interoperate
and
you
make
them
interoperate
to
me.
This
could
be
part
of
the
profile,
so
you're
not
really
combining
profile
you're
rather
defining
a
profile
that
that
works
in
a
certain
way.
G
G
I
don't
know
why
it
was
added
or
what
use
case
it's
trying
to
to
cover,
but
I
think
that,
right
now
this
is
bringing
possibly
bringing
more
issues
than
it's
solving.
I
think
that
the
goal
of
this
paragraph
was,
to
just
add
the
security
consideration,
but
as
it's
written
right
now
it
just
to
me,
it
opens
up
the
kind
of
worms
that
we
might
not
want
to
discuss
in
this
document.
F
G
C
Just
a
question
here:
do
you
want
to
mention
the
possibility
of
combining
profiles
or
not?
That
would
be
my
question.
I
agree
that
the
definition
of
how
that
interoperability
happens
and
how
the
other
profile
is
made
use
of
is
on
the
profile
that
makes
use
of
another
profile.
So,
if
profile
a
is
using
profile
b,
they
should
describe
how
they
use
that
profile
and
how
it
works
together
and
and
the
main
document
I
don't
think,
can
scale
to
explaining
all
interactions
of
different
profiles.
C
C
G
So
the
the
problem
I
had
with
this
type
of
formulation
is
that,
for
example,
in
the
appendix
we
have
this
appendix
requirement
on
the
profile
requirements
include
to
specify
the
communication
between
client
and
aes
and
communication
and
and
security
between
cl
clients,
communication
security
and
rs
cetera.
So
the
one
profile
already
specifies
all
the
legs
of
the
exchange.
G
G
C
Why
that
might
be
happening
because
mqtt
profile
is
given
as
an
example
a
lot
it's
when
we've
written
the
document
we've
written
from
a
perspective
of
http
and
json,
and
then
there
were
questions
raised,
whether
we
could
just
use
co-op
there
and
that's
perfectly
fine
as
well
and
co-op
and
ace
can
be
used
for
those
legs.
If
you
prefer
it
to
use
that
way
and
get
the
you
know,
client
as
interaction
using
those
protocols.
So
we
didn't
want
to
stop
that
from
happening
either.
C
If
it's
the
same
yeah,
in
any
case,
the
description
in
the
mqtt
tls
profile
with
the
client,
as
is
that
with
one
way
you
know
either
we
describe
the
http
json,
but
you
know
using
the
co-op
way
as
well.
You
can
get
the
token
from
the
as
and
its
client's
responsibility
to
be
able
to
use
that
token
in
an
mqtt
conversation.
G
C
G
Of
the
problem,
I
have
searched.
Sorry
go
ahead.
Sorry,
no,
the
the
profile
is
clearly
defined
by
having
a
number
of
characteristics
and
requirements
and
when
I
think
of
profile,
I
usually
think
of
this
appendix
that
everything
that
is
needs
to
be
specified
for
that
profile.
So
when
we
talk
about
combining
profiles
to
me,
it's
suddenly
like
I'm,
not
sure
what
that
means,
but
understanding.
C
G
C
Okay
good
point:
I
agree
that
a
combination
is
not
an
exact
combination
that
it
describes
how
each
flag
is
combined,
and
you
know
it's
not
a
pure
combination,
it's
just
taking
some
parts
of
another
profile
and
then
using
another
part
of
another
profile.
I
I
see
your
point
then
I
wouldn't
mind
the
removal
of
the
text.
If
that
is
acceptable
to
the
rest
of
the
working
group
about
combining
profiles,
if
there
is
no
other
example
that
can
combine
profiles,
but
in
mqtc
case
I
I.
I
accept
the
view
that
it's
not
an
exact
combination.
G
C
I
think
you
write
that
the
definition
of
a
combination
may
vary
across
different
people
and
if
the,
if
the
profile
is
weak
about
that,
that
might
confuse
people
what
we
mean
by
combine.
If
we
don't
understand
the
same
thing
from
combine,
which
was
obvious
that
we
didn't
when
we
were
discussing
the
mqtt
case,
then
maybe
it's.
The
removal
of
the
sentence
isn't
better
to
avoid
any
confusion,
because
the
mqtt
draft
already
explains
how
different
transport
protocols
can
be
used
in
different
legs.
G
E
E
Okay,
so
we
hear
breakups
of
you
francesca
for
some
reason,
and
then
there
are
two:
let's
see
it's
not
one
sentence.
There
are
three
sentences
in
this
highlighted
text
and
the
first
one
is
saying
that
there
may
be
use
cases
where
you
combine
profiles
and
the
other
is
an
example,
and
the
third
is
a
normative
statement
about
security
for
the
profiles
that
they
must
not
depend
on
the
assumption,
and
I
think
it
it's
this
third
sentence.
E
We
have
a
problem
with
pro
er,
probably
because
it
might
for
the
for
what
people
has
been
saying
here,
that
we
cannot
take
into
account
non-existent
profiles
and
security
or
combination
with
those
in
in
and
that's
not
possible
to
do
when
you
design
the
profile.
Is
that
my
is
that
the
correct
understanding.
F
E
E
F
E
F
But
but
the
problem
is
that
you,
when
specifying
one
profile,
you
don't
necessarily
know
all
other
profiles
that
at
some
point
may
start
to
exist
and
that
that's
the
reason
why
this
paragraph
or
these
three
sentences
are
very
important,
that
you
must
be
aware
of
the
fact
that
your
profile
can
be
combined
in
the
future
with
other
profiles
and
it
needs
to
or
the
security
will
be
affected.
If,
if
the
combination
is
poorly
done,.
G
Yeah,
but
I
don't
think
that
two
profiles
can
just
be
combined
without
any
text
specifying
how
they
are
combined.
So
if
one
profile,
let's
say
profile,
a
e
and
b
is
finder
and
b
wants
to
use
something
from
a
b
will
have
to
define
yeah
what
what?
What
carson
is
saying
be
prepared
that
some
other
profile
may
want
to
combine
with
you,
but
it's
I
don't
see
it
as
there
is
two
profiles
defining
and
they
can
be
combined.
I
don't
know
how
that
that
can
be
combined
can
happen.
G
This
combination
needs
to
be
specified
somewhere
and
I'm
fine
if
it's
specified
in
a
profile
and
that's
maybe
some
text
that
could
be
added
to
this
paragraph
and
and
yeah,
and
I
just
wanted
to
also
say
I
hope
I'm
not
breaking
up
that.
None
of
these
comments
are
so
I
we
can
find
a
resolution
for
it,
but
if
not,
I'm
also
good
with
moving
the
text
forward.
G
B
B
B
G
B
B
J
A
B
B
B
J
So
I
heard
no
objections
on
the
list
either
and
what
you
see
in
the
hydroscopy
is
the
result
of
option
two
that
seemed
to
be
the
the
best
one
so
also
for
the
second
review.
I
suppose
I
can
submit
that
version.
12.
The
only
difference
would
be
that
little
appendix-
and
at
least
it
can
be
the
one
to
consider
for
reviews.
B
J
B
B
C
C
The
mailing
list
with
francesca
as
well,
who
was
raising
the
question
why
we
needed
it
and
shared
some
of
jim's
earlier
comments
on
it,
so
we
I
think
we're
going
ahead
with
it.
I
haven't
heard
no
from
the
rest
of
the
working
group
and
that's
the
update,
so
a
new
version
will
be
pushed
hopefully
tonight
and
the
registration
will
start
and
we
are
still.
B
A
D
D
H
D
D
H
D
H
So
I'm
just
wondering
whether
we
can
relax.
This
is
why
I
mean
this
is
good
example
for
how
a
server
would
what
specify
the
the
uri,
but
maybe
we
can
relax
this
and
and
just
say
each
time
we
have
a
new
state.
There
is
a
location,
location
path
in
the
response
that
gives
the
ui
for
the
new
state
and
it's
up
to
the
server
to
make
up
that
ui
and
here's
one
way
of
doing
that.
D
Okay
yeah,
as
long
as
long
as
as
both
entities
are
able
to
understand
that
we,
if
we
finished
the
current
ips
change,
that
that
is
processed
correctly
and
in
the
next
step,
which,
whichever
value
we
have
from
the
uri,
both
entities
are
able
to
understand
that
that
belongs
to
the
next
exchange.
That
that's
enough.
So
I
I
we
put
that
because
we
thought
that
was
the
the
the
most
easy
way
of
understanding
the
concept.
D
D
D
Can
you
hear
me
yes,
okay,
so
in
the
next
slide
there
is
the
exchange
with
the
process,
though
so,
for
each
exchange,
the
server
is
creating
a
new
resource
that
is
specified
in
the
in
the
location
path
as
we
just
start
with,
but
because
of
carsten
discussion
we
may
change
that
in
the
future.
So
but
that's
the
idea,
and
next
we
only
have
a
couple
of
in
the
next
slide.
We
have
a
couple
of
statistic
cases
where
we
try
to
define
what
would
happen
if
some
messages
are
lost
or
retransmitted.
G
D
D
D
When
we
get
the
response
from
this
state
machine,
then,
if
everything
goes
okay,
we
generate
the
the
new
resource
that
would
be
left
for
the
specific
way
we
we
would
generate
it
as
a
person
set.
We
may
relax
that
in
a
way
that
we
just
make
sure
both
entities
are
aware
that
this
is
the
next
step
and
then
we
would
send
back
the
the
new
resource
in
the
location
path
response
with
the
2.01
created
code.
D
We
have
a
characteristic
of
what
happens
if
a
previous
message
is
sent.
It
gets
in
the
in
the
network
and
the
the
the
client
sends
again
the
the
message
in
a
retransmission
and
the
first
one
arrives
later.
So
we
understand
that
it
could.
Two
things
could
happen
if
this
is
managed
by
the
co-op
engine
and
it
takes
care
of
it.
It
recognize
that
this
is
a
previous
message
and
it
would
just
send
a
retransmission,
then
the
co-op
client,
since
the
conversation
continued
before
that
last
message
got
in
the
way.
D
D
The
the
application
would
recognize
that
the
resource
was
deleted
and
a
new
one
was
generated
and
an
error
of
4.04
code
will
be
sent
and
in
any
case,
we
understand
that
the
client
would
recognize
that
the
conversation
continued
long
after
the
the
first
message
that
got
lost
got
back
and
it
may
also
just
drop
it
because
the
message
id
was
received
again.
These
are
the
two
characteristics
that
we
understand.
That
may
cause
doubt
and
that's
why
we
highlighted
that
here,
and
I
think
that
with
this,
if
everyone
agrees,
we
can
just.