►
From YouTube: IETF-CORE-20230301-1500
Description
CORE meeting session at IETF
2023/03/01 1500
https://datatracker.ietf.org/meeting//proceedings/
A
C
C
Scrolling
through
the
slides
of
of
us
of
ethoc
Oscar
I,
now
see
where
my
impression
came
from
that
it
has
always
been
a
concatenation
another
seagull,
byte
stream,
because
it's
depicted
in
the
last
slide
in
in
a
way
that
doesn't
imply
that
there
is
some
sibo
wrapping.
That
that
explains
my
error,
which
I'm
glad
to
have
found
because
I
looked
through
the
old
documents
and
I
was
like
what.
A
A
D
As
you
know,
we
we
still
have
Rob
Wilton's
discuss
outstanding
and
we
had
a
lot
of
discussions
and
and
quite
a
few
edits
and
yeah.
It
has
turned
out
to
be
difficult
to
keep
the
feedback.
Cycles
short,
so
we
are
going
to
do
a
couple
of
open
loop
things
right
now
and
I
submitted
this
20
based
on
what
the
authors
think
is
is
addressing
Rob's
concerns,
but
we
haven't
had
feedback
from
him
yet,
and
this
is
intended
to
cover
all
open
items.
D
As
always,
you
can
always
improve
a
document
editorially.
There
were
also
some
young
clerical
things
that
needed
to
be
done:
version
numbers
and
things
like
that,
but
the
the
main
change
is
that
we
now
have
a
per
Sid
fire
status,
which
can
be
unpublished
or
published
and
per
item
visit
item
status
that
can
be
unstable,
stable
or
obsolete,
where
obsolete
is
the
same
thing
as
they
will
just
with
a
kind
of
a
deprecation
mark
on
it.
D
We
also
completed
the
move
from
Yang
data
to
this
structure,
Yang
future,
which
is
a
little
bit
of
a
problem,
because
you
we
no
longer
have
a
tool,
but
that
we
can
use
to
validate
our
examples.
And
yes,
this
struck
us
right
away
turns
out
that
the
Yang
Json
representation
of
un64
in
the
iitf
system-
that
said
example,
was
wrong.
So
we
have
fixed
that
as
well.
D
A
Yeah
Marco
here
I
think
working
group
law
school
here
a
hotel,
even
it
would
be
the
third
one
if
I'm
not
wrong
on
this
document.
Well,
we
have
a
meeting
with
Jaime
tomorrow,
I'd
like
to
double
check
with
him,
but
I
think
we
can
do
that
soon,
just
to
be
sure
cards
and
you
want
to
give
a
few
days
to
rob
in
case
he
no.
D
So
I
have
one
more
slide
on
this,
which
is
maybe
really
more
for
your
amusement.
But
while
I
was
working
on
these
things,
so
I
I
really
was
fed
up
with
not
having
a
way
to
validate
them.
So
I
actually
wrote
a
sit.cdl
and
while
I
was
doing,
this
sent
me
an
Excel
sheet
of
all
things
with
some
some
silly
locations,
and
that
got
me
thinking
and-
and
some
of
you
may
know,
that
I
have
a
draft
out
there
for
doing
cdda
for
CSV
files.
D
So
this
is
so
much
easier
to
to
work
with
than
the
Json
file
we
have
modeled
in
Yang
and
which
now
has
all
these
these
Yang
things
in
it
anyway,
just
just
as
a
little
bit
off
of
sneak
view
into
the
process
that
that's
got
this
document
at
least
partially
validated,
and
of
course,
if,
if
people
want
me
to
review
any
zip
files,
I
will
convert
them
into
this
font
or
to
read
them
okay.
But
that
was
just
Amusement,
so
the
next
item
is
called
komai.
D
So
again
we
can
probably
parallel
lies
a
little
this
a
little
bit.
We
wanted
to
make
sure
we
have
course
hit
under
control
and
we
can
work
from
the
hypothesis
that
this
is
so
and
now
address
Carl
comma.
At
ihf115
we
had
discussions
which
I'm
not
I,
haven't
repeated
on
this
slide
here
about
applying
some
simplifications
based
on
implementation,
experience
that
we
had
they
are
sitting
at
the
table
in
in
the
hackathon
and
well.
D
A
D
D
Oh
okay,
so
we
passed
the
working
of
Last
Call
on
the
document
yesterday
and
we
had
all
the
working
group
last
call
comments
addressed,
submitted,
Dash
O2,
with
those
comments
addressed
and
the
changes
mostly
were
I
added,
an
acknowledgments
paragraph-
that's
probably
the
biggest
change,
but
there
are
lots
of
editorial
improvements
in
the
regular
blast,
color
comments.
So
thank
you.
Everyone!
D
That's
why
I
just
said
at
the
acknowledgment
section
and
one
interesting
addition
is
to
point
to
the
core
parameters:
mailing
list
for
a
potential
discussions
between
registrants,
the
designated
expert
and
The
Wider
community,
so
I
think
that
that's
I
think
a
good
idea
to
to
have
a
place
to
involve
the
community
and
the
curation
of
of
this
registry
and
I.
Think
it's
it's
a
good
idea
to
mention
this
year.
D
C
My
rough
take
on
how
RT
is
working
is
that
resource
types
can
be
mutually
exclusive,
so
base
ETD
and
and
EP
as
their
used
resource
directory
wouldn't
become
like
for
all
other
users,
but
just
for
those
that
that
don't
explicitly
conflict
with
something
being
a
resource
directory
but
registering
registering
things
is
all
kind
of
is
a
good
start
and
how
those
conflicts
would
be
resolved.
I,
I,
don't
know
whether
people
will
actually
want
to
go
so
far
as
to
explicitly
clear
the
conflicts
to
reuse
particular
names,
don't
know.
Well,
that's
realistic.
D
D
Okay,
that's
the
voting
collisions
part.
The
other
part,
of
course,
is
that
the
version
without
the
the
a
flag
may
be
in
wide
use,
and
if,
if
that
conflicts
with
something
that
is
in
the
Target
attributes
registry,
then
then
essentially
you
cannot
add
an
f-track
yeah
exactly,
but
you
think
that's,
okay,.
C
I
think
I
think
that's
okay,
yeah,
because
so
the
the
Rd
thing
is
there.
There
were
two
design
considerations
that
went
into
that
Rd
registry.
One
is
that
you
can
use
particular
at
particular
entries,
even
though
their
name
would
conflict
with
other
uses,
for
example.
This
is
this
is
an
impagnation
pagination
page
numbers
don't
show
up
in
results
period
so
this
world,
so
this
won't
create
an
issue
and
the
other
design
consideration
was
that
even
when
they
show
up
in
attributes,
it
is
known
where
they
show
up
so
like
a
base.
C
A
A
A
B
See
here:
okay,
there
we
have
the
slides,
ready,
yes,
yeah,
so
hello,
everyone,
so
today,
I
will
be
presenting
some
open
points
in
this
profiling,
head
of
proven
Oscar
draft
and
yeah.
Just
to
summarize,
the
outcome
of
the
working
group
last
call
a
number
of
reviews
came
in
specifically
from
from
Christian
and
John.
B
So
thanks
a
lot
for
that,
and
we
discussed
among
the
authors
regarding
how
to
address
these
comments
and
suggestions
for
updates
in
the
text
and
in
fact,
a
lot
of
the
non-controversial
and
editorial
comments
have
already
been
updated
in
the
editors
copy,
and
you
can
see
that
in
the
link
there.
But
the
goal
for
today
is
then
to
discuss
the
more
than
controversial
topics
we
would
need
where
we
would
like
input
from
the
group.
Essentially,
so
we
have
six
Commons
from
Christian
five
from
yon
and
then
we
have
an
extra
point.
B
We
also
want
to
raise-
and
let
me
go
straight
into
this
first
comment
from
Christian-
and
this
was
regarding
the
payload
of
the
end
of
class
Oscar
request,
which
we
currently
Define
as
a
silver
sequence
of
two
sibo
data
items,
the
force
being
end
of
message,
three,
which
is
a
zebra
by
string,
followed
by
the
old
score
ciphertext,
which,
in
the
current
version,
is
also
intended
to
be
a
silver
by
string,
so
yeah
sequence
of
2C
data
items,
two
silver
by
strings
now.
The
proposal
from
Christian
was
to
change
this
payload
format.
B
D
Yeah
I
didn't
want
to
interrupt
you,
but
I
could
add
that
this
is
not
a
new
format
for
doing
things.
So
pre-pending
a
sibo
data
item
in
front
of
some
random
data
is,
for
instance,
done
in
appendix
D
of
RFC
9277.,
so
that
we
already
have
a
word
for
that
called
a
sibo
header,
and
this
is
essentially
what
we
would
be
using
here,
and
it's
also
quite
quite
fitting
to
what
we're
actually
trying
to
do
here.
B
Yeah
I
think
exactly
right:
I
I
got
that
feedback
from
you
separately.
I
think
is
a
very
good
point
and
there
is
also
the
already
precedence
for
for
doing
this
sort
of
thing
and
even
a
a
name
associated
with
it.
So
that's
very
good,
but
essentially
I
mean
our
proposal
from
the
authors
is
to
yeah,
adopt
this
new
payload
format
suggested
by
by
Christian
and
update
the
draft
accordingly
yeah.
So
any
feedback
or
or
thoughts
on
that
direction
is
is
very
welcome.
B
I
see
someone
wrote
in
the
chat
there,
yeah
Malaysia
agrees
plus
one
yeah,
so
then
I
think
we
will
go
for
that
direction
and
continue
with
the
next
comment
and
yeah
feel
free
to
jump
in
or
even
jump
back.
If
you
think
of
something,
but
this
is
the
second
comment
from
Christian
regarding
error
handling
at
the
server,
and
the
point
here
was
that
if
the
decrypted
Osco
request
after
decryption
includes
another
option,
then
we
were
saying
to
respond
with
an
error.
If
tells
corruption
is
not
also
present.
B
So
essentially,
we
want
to
see
that
handle
score
option
together,
but
Christians
Point
here
was
that
this
is
all
good
and
correct
for
the
this
precise
use
case.
However,
it's
not
future
proof,
considering
also
what
is
coming
with
regards
to
nested
oscore
and
the
nest
combined
requests.
So
his
point
there
was
to
avoid
normative
language
to
describe
what
cannot
factually
happen,
and
he
proposed
an
alternative
text
which
is
stated
here,
which
would
be
when
the
decrypted
request
is
checked
for
any
critical
options
as
it
is
during
regular
core
processing.
B
The
presence
of
analog
option
must
be
regarded
as
an
unpross
critical
option
unless
it
is
processed
by
some
further
mechanism.
So
essentially,
this
is
leaving
the
door
open
for
this
further
mechanism,
which
course
can
be
other
things
coming
up
in
the
future.
But
specifically
one
thing
that
could
be
is
the
nest
that
was
core
so
again
here.
Our
proposal
was
to
adopt
this
current
alternative
text
suggested
by
Christian,
because
it
yeah
it
seems
good
to
leave
that
to
have
some
future
proofing
in
mind
already
at
this
stage,.
B
Yeah
I
move
to
the
next
point.
So
this
third
comment
was
three
with
regards
to
web,
linking
and
just
to
recap
with
web,
linking
you
can
use
Target
attributes
to
describe
an
edit
resource,
meaning
specifically,
how
can
a
server
run
edoc
through
that
resource?
And
you
see
there
on
the
right
hand,
side
a
list
of
the
currently
defined
Target
attributes,
so
we
can
Define
the
edoc
method
supported
the
side,
Pursuit
supported
Etc,
but
Christian
pointed
out.
B
So
based
on
these
two
pointer
proposal
is
well,
then
we
simply
Define
four
additional
Target
attributes,
one
for
the
forward
message
flow
one
for
reverse
meta
flow,
one
for
initiator
and
one
for
responder,
support
and
yeah.
This
would
not
be
repeatable
and
they
do
not
have
any
value.
Their
presence
indicates
the
support
of
of
that
relevant
aspect.
So
Christian.
C
Given
that
these
web
link,
Target
attributes
are
all
on
a
resource
that
is
by
being
by
having
a
URI
and
being
a
resource
in
the
server
role,
what
is
the
difference
between
indicating
support
for
forward
or
reverse
flow
and
indicating
support
for
initiative
or
responder
I
mean
if
the
resource
that
is
advertising
the
being
be
serving
as
a
network
server
thingy
says
it
is
usable
with
forward.
Then
it
has
to
be
a
responder,
and
if
it
says
it's
usable
with
reverse,
then
it
has
to
be
initiator.
C
B
D
A
B
D
D
B
B
Now
considering
the
profile,
we
were
still
wanting
to
keep
the
individual
Target
attributes,
but
that
could
be
reconsidered.
Possibly
if,
like
you
say
it's,
it
becomes
an
excessive
amount,
there's
also
yet
another
relevant
point,
which
is
we
wanted
to
prefix
these.
So
it's
clear
they
are
specific
to
edoc.
We
wanted
the
prefix
them
with
like
Ed,
for
instance,
but
yeah
you're,
saying
basically
to
have
like
that.
We
could
have
like
one
target
attribute
and
a
bit
a
flag
set
of
bits
there
to
to
indicate
the
same
yeah
but
I
see.
B
Then
we
take
that
the
more
or
less
feedback
also
yeah
thanks
a
lot
so
I
think
we
yeah.
We
come
already
actually
to
this
point,
so
this
was
yet
another
comment
from
Christian.
So
the
idea
here
was
can't
we
have
a
Target
attribute.
That
indicates
the
whole
application
profile,
so
you
can
compile
an
application
profile,
let's
call
it
mystio
ad
hoc
P1
and
to
concrete,
really
Define
our
proposal
if
yeah,
because
you
want
to
jump
in.
D
B
D
Define
this
yeah,
okay,
there.
There
was
a
document
that
defined
this
for
the
web,
but
that
didn't
mean
that
that
people
knew
what
a
specific
profile
value
was
going
to
mean.
So
nobody,
nobody
dared
to
put
that
somewhere,
because
there
will
always
be
some
nodes.
Some
implementations
that
don't
know
a
new
profile.
So
you
will
always
have
to
indicate
the
same
information
in
a
pedestrian
way
as
well,
and
that
makes
the
profile
useless.
B
D
B
Yeah
yeah
I
mean
our
idea
here
was
to
have
like
I
guess,
like
your
your
mentioning,
we
wanted
to
have
a
registry
in
the
head
of
draft
to
Define
an
application
on
profile
registry
in
the
head
of
draft
and
then
in
this
document
a
new
Target
attribute
to
indicate.
But
your
point
is
that,
well,
even
if
we
have
that
registry,
we
cannot
know
that
implementation
is
actually
supported
profile.
So
we
would
have
to
also
indicate
using
the
individual
Target
attributes.
D
Yeah,
so
so,
if
you
can
make
sure
that
the
the
piece
of
software
that
processes
this
profile
is
also
the
piece
of
software
that
that
is
specific
to
this
application
profile,
then
it's
not
such
a
big
problem,
but
if
you
actually
have
things
like
adult
libraries
or
even
proxies
that
do
something
with
ad
hoc
that
simply
may
not
know.
What's
going
on
in
in
that
profile,
you
have
this
problem.
D
C
It
it
might,
it
might
be
interesting
good
to
notice
here
that
this
is
all
about.
This
is
all
optimization.
This
is
all
avoiding
one
round
trip
which
I
think
may
not
even
be
worth
it
worth
doing
all
these
attributes,
but
even
if
it
is
worth
it,
the
profile
here
would
just
a
producer
can
easily
just
indicate
a
profile
value,
because
the
worst
thing
that
happens
if
the
consumer
doesn't
know
the
profile
value
is
that
they
can't
expand
it
to
this
method.
B
B
B
C
B
B
A
Yeah
and
to
clarify,
we
take
this
direction
at
all,
and
it
has
practically
to
start
in
edoc
with
Define.
This
registry,
for
this
document
is
just
about
one
more
attribute
to
to
transport.
That
name
so
if
this
doesn't
happen
all
together
with
the
registry,
this
is
just
not
going
to
happen
here
either.
Yeah.
B
Indeed,
I
mean
the
final
call
is
for
the
authors
of
10.
craft
if
they
wish
to
introduce
this
registry
or
not
if
they
don't
well,
this
will
not
happen
in
this
document
either
and
just
to
finalize
the
slide
I
mean
the
idea
was.
This
is
repeatable
values.
You
could
indicate
multiple
profiles,
one
resource
and
you
could
still
use
a
single
future
Target
attributes
if
you
wish
to
append
to
this
indicator
process,
but
I
think
I
can
take
a
next
thing.
B
We
got
a
lot
of
good
feedback
on
this
one
right
Christian,
you
wanted
to
say
something
more.
No
I
just
forgot
to
mute
again,
okay,
but
then
we
come
to
the
comment
number
five
from
Christian.
So
the
point
here
was
about
a
specific
example.
We
show
in
the
draft
and
in
the
current
example
of
the
web,
linking
we
show
Two
end
of
resources,
one
endoc
slash
sa
and
the
other
edoc
slash
recipe.
B
So
the
question
here
is:
why
do
we
do
this,
or
rather
the
preferred
solution
would
be
to
actually
use
well-known
endoc
instead
of
these
to,
let's
say,
custom,
different
resources,
and
we
think
this
is
a
good
idea
from
the
authors.
In
fact,
this
was
actually
the
case
until
version
two
of
the
draft
and
it
changed
after
a
intermitting
there
in
October
of
2021.,
because
then
we
got
some
feedback,
the
the
basically
the
the
summary
of
that
feedback
was
well.
B
If
you
use
well
known
edoc,
it
means
that
the
client
knows
how
well-known
edoc
works,
so
you
wouldn't
need
to
have
these
Target
attributes
to
indicate
to
the
client
how
the
resource
works,
but
we
thought
about
that
a
bit
more
and
I
mean
well
known.
It
doesn't
really
mean
that
the
adult
client
would
know
the
application
profile
for
this
resource
well
known
adult.
Rather
it
just
means
that
the
path
and
the
fact
that
this
is
used
for
edoc
or
well
known.
B
B
C
I'm
not
sure,
maybe
we're
diverging
a
little
bit
on
on
what
this
thought
profile
would
State
as
I
understand
it.
This
default
profile
would
just
basically
State
the
obvious
things
that
are
that
that
were
implied
from
using
it
over
Co-op.
That
is,
we
are
you
all
those
details
about
that
we
are
using
that
we
are
using
the
the
role
identifiers
just
in
one
direction,
from
the
client
to
the
server
and
not
on
the
other.
One.
D
C
It
would
not
that
profile
would
not
make
anything
mandatory
to
implement
as
I
understand
those
profiles
and
I
might
easily
be
wrong
here.
They
are,
they
have
a
wide
dynamic
range
of
how.
How
narrowly
can
be
a
profile
can
be
like
we're
doing
sending
exactly
those
messages
and
we're
using
that
Cypher
suite
and
and
we're
using
that
error
Styles,
but
it
can
also
be
like
we're
using
it.
Our
transport
is,
our
transport
is
Co-op.
B
Not
sure
I
see
what
you're
saying.
Actually
we
were
also
discussing
yes,
I
agree.
Our
point
of
view
is
also
that
the
profiles
can
be,
let's
say
wide
in
the
sense
of
what
they
Define.
They
can
Define
very
little
or
they
can
Define
very
much
I.
Think
our
idea
on
this
well-known
profile
would
be
that
it
defines
sufficient
amount
to
be
quite
specific
because
if
you
only
Define,
what's
in
the
like
Endo
compliance
requirements
and
I
I
wonder,
does
it
add
very
much
value?
Then?
C
B
I
think
this
is
a
good
point,
because
I
think
what
we
have
in
mind
on
on
your
suggestion
would
be
that
this
profile
would
be
quite
fleshed
out
and
not
a
minimal
profile,
and
we
felt
that
having
a
two
minimal
profile
would
mean
that
it
doesn't
really
give
any
guidance
at
the
end
of
the
day.
So
you
still
have
to
do
the
kind
of
normal.
You
know
negotiation
and
trial
and
error
and
such
but
yep.
B
B
We
can
take
this
and
discuss
further
among
the
authors,
then,
on
this
idea
of
having
a
the
concept
that
okay,
these
people
are
well
known
and
let's
say
the
default
profile
could
be
a
very
minimal.
Well,
not
defining,
like
you
said,
not
making
adding
something
like
mandatory
to
implement
in
apple
right,
yeah,
I,
see.
B
A
B
B
Then
we
got
a
few
comments
from
John
Madison
also,
and
the
first
was
regarding
the
document
title
So.
Currently,
the
title
is
profiling,
endoc
for
Co-Op
and
all
score,
but
the
answer
he
asked
well:
can
we
change
this
title
essentially
because
this
document
does
not
really
profile
edork
and
I.
Think
we
can
like
simplify
the
title.
So
after
discussion
with
authors,
we
came
up
with
this
proposal
simply
using
ad
hoc
with
Co-op
and
all
score
and
there's
a
lot
of
profiles
out
there,
or
this
word
profile
is
used
in
a
lot
of
context.
D
B
B
A
it's
a
good
way
forward:
I
move
to
the
next
Point.
This
was
regarding
error
handling
on
the
server.
So,
basically,
the
point
was
that
well,
if
adult
fails
during
processing
of
the
combined
request,
an
endoc
error
message
will
be
sent
as
a
response
to
the
combined
request
and
John
wants
to
clarify
or
wants
us
to
clarify.
B
B
He
has
to
always
send
this
unprotected,
and
the
text
in
section
3.3
would
be
elaborated
as
you
see
in
bold
there
to
add
that
the
server
must
not
establish
a
new
score
circular
context
from
the
present
education
with
the
client
and
hence
the
Corp
response
is
not
protected
with
all
score.
So
yeah
Carson.
D
Yeah
I'm
wondering
whether
this
decision
doesn't
create
more
disclosure
than
we
actually
want
to
have
I
mean
this
is
really
difficult
to
say.
This
is
less
a
question
about
the
protocol,
but
one
question
about
how
people
will
be
using
this
and
what
will
be
divulged
in
these
error
messages,
and
so
on.
So
I
cannot
answer
this
question,
but.
A
B
Yeah
I
mean
I
would
say
normally
like
the
way
edoc
is
defined
as
normal.
The
error
messages
would
would
always
be
unprotected.
So
it's
that's
like
the
base
case,
and
so
this
would
be
like
what
we
could
possibly
do
here
is
add
on
top
of
that
or
what
other
quality
provides,
but
they
may
also
be
difficult
to
determine
in
which
cases
should
you
actually
go
ahead
and
derive
the
context
and
which
case
it
should
be
not.
A
C
Yeah
I
think
it's
safe,
given
that
other
ad
hoc
scenarios
do
not
protect
I.
Think
it's
safer
to
make
to
to
put
the
responsibility
always
on
the
error
on
the
produce
of
the
error
message
not
to
do
any
undue
disclosure
and
thus
keep
the
error
handling
easy
and
to
not
introduce
bugs
in
really
used
code
paths.
C
Plan
with
sending
unprotected
and
I
think
that
custom
suggestion
would
create
would
possibly
create
dangerous
situations.
For
example,
people
not
not
only
implementation
errors,
but
other
people
using
this
in
using
ad
hoc,
In,
This
Very
scenario,
where
the
errors
are
protected
and
then
switching
to
another
mode
of
network
where
suddenly
the
errors
are
not
protected
anymore,
and
then
being
surprised
that
some
that
there
is.
B
A
B
A
D
But
if
you
have
an
authentication
error
for
instance,
then
maybe
it
would
be
in
the
interest
of
the
application
to
divulge
a
little
bit
more
information
yeah,
but
I
haven't
thought
this
through
I
just
wanted
to
bring
up
the
the
issue
of
the
weather
security
context
that
comes
up
but
doesn't
fulfill
some
requirements
when
it's
might
still
be
used
for
the
project.
The
error.
C
B
A
Yeah
I
know
that
the
position
of
John
is
that
about
this
topic,
something
has
to
be
said
somewhere,
it's
just
bad,
not
to
say
anything.
Last
time
we
discussed
with
him
in
detail,
it
was
actually
about
the
open
issue
which
is
about
this
topic,
and
he
he
was
happy
to
say
something
along
these
proposed
lines
in
this
document,
but
of
course,
unless
edoc
in
the
first
place
says
something
different
to
just
inherit.
B
C
As
soon
as
we
start
using
deriving
the
Oscar
context
and
putting
an
ad
hoc
message,
error
message
in
there
that
Network
message,
error
message
might
have
the
right
content
format
attached
to
it,
but
it
could
still
be
ambiguous.
So,
for
example,
you're
requesting
for
you're
requesting
the
state
of
a
pub
sub
topic
which,
as
far
as
I
understand,
can
have
an
arbitrary
content
format.
Whatever
is
sent,
there
is
kind
of
a
representation
of
of
that
pops
up.
Channel,
okay,.
B
B
B
C
D
C
D
B
A
lot
for
the
feedback,
so
this
was
about
John
was
asking
basically.
Is
it
clear
what
happens
if,
if
the
ad
dot
plus
old
score
request
is
re-transmitted
and
well,
we
discussed
it
amongst
ourselves
and
from
our
point
of
view,
it
should
be
clear
because
here
will
really
inheriting
from
what
edoc
says,
which
is
basically
that
you
know
different
instances
of
the
same
message
must
not
be
processed
in
one
session,
so
eddock
has
designed.
This
is
really
forbidding
and
any
kind
of
incorrect
handling
or
like
reprocessing
of
the
same.
D
B
B
B
I
go
to
the
next
one,
so
this
was
more
on
web.
Linking
so
John
was
saying
basically,
like
you,
have
this
Ed
one
needed
283
and
84
Target
attribute,
but
you
need
to
know
what
kind
of
EAD
is
actually
supported
and
that
it
should
be
using
values
from
the
endoc
external
authorization
data
registry
for
these
items,
but
indeed
this
is
already
our
intent
and
we
do
refer
to
this
registry.
B
So
the
intent
is
really
that
these
torque
attributes
should
use
the
integers
register
in
that
registry
and
point
to
specific
Eads
that
are
supported
so,
but
what
we
want
to
do
is
is
clarify
this
more
in
the
actual
text.
So
you
see
the
proposed
change
they're
in
bold.
To
add
this
few
words
about
if
present,
that
the
server
supports
specific
external
authorization
data
items
to
use,
and
then
the
second
bullet
is.
B
B
Yeah
I
can
go
to
the
next
one,
straightforward
yeah,
so
another
point
from
your
own
that
came
in
quite
recently
more
on
the
web.
Linking
so
John's
proposal
here
was
that
we
have
this
cred
Target
attribute
defined,
which
indicates
the
supported
type
of
trend
for
the,
for
that
particular
resource
and
Matt.
B
Jones
is
suggesting
to
create
a
new
registry
under
the
FML
development
of
the
code,
C
producer
group,
either
in
this
document
or
in
the
actual
head
of
document
itself,
and
you
see
there
in
the
bottom
right
a
proposal
basically
of
what
it
could
contain
and
among
the
authors
we
discussed
out
at
this
point,
and
we
said
that
yeah.
This
can
indeed
be
a
good
idea,
and
but
if
it's
created
well,
let's
create
it.
B
A
C
B
D
B
C
A
C
A
B
B
B
B
D
B
B
B
A
B
C
B
A
B
B
B
But
yeah,
let
me
go
to
the
somewhere
in
the
next
step,
so
well.
What
we
want
to
do
address
all
the
working
group,
less
comments
and
yeah
then
submit
the
version
7
before
the
upcoming
cutoff,
and
there
was
also
a
plan.
We
had
to
submit
a
pull
request
to
this
Target
attributes
draft
regarding
renaming
and
addition
of
Target
attributes.
Now
that
may
be
no
longer
relevant
depending
on
them.