►
From YouTube: IETF-CORE-20230118-1500
Description
CORE meeting session at IETF
2023/01/18 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
B
C
A
A
A
Okay,
but
it's
forecast
now
and
there's
a
few
nice
people
here.
So
let's
get
started.
Welcome
everyone
to
this
interview.
Meeting
of
the
co-working
group.
I
am
Marco
tiloka.
My
co-chairs
are
I'm
a
Jimenez
and
Kirsten
Borman,
and
this
is
an
officiality
of
meetings,
so
we've
been
recorded,
the
note
12
applies
so
get
familiar
with
it.
If
you
are
not
already-
and
it's
not
just
about
IPR,
it's
also
in
the
special
about
our
conduct,
so
please
be
nice
and
professional
with
each
other.
A
The
agenda
for
today
is
also
in
the
notes,
as
usual,
we'll
spend
some
time
with
the
conditional
attributes.
Document
that
we
will
present
is
still
in
working
group.
Last
call
more
reusing
comments
have
come
also
recently,
then
we
go
through
two
of
the
coreconf
documents,
mostly
young
seed,
that
Carson
will
present
and
I
will
actually
show
a
status
update
related
to
ongoing
points
that
we
are
discussing
for
the
href
document.
A
A
B
A
B
Also,
thank
you.
Okay,
great
so
hello,
everyone,
so
I'm,
Bill,
silverrojan
and
I'm
here
to
talk
about
our
draft
conditional
attributes
for
constraint,
respond
environments.
So
this
draft
is
co-authored
by
Michael,
Costa
and
Ellen
soloi,
so
I'm
going
to
present
just
a
few
slides
containing
what
we
have
done
since
the
last
ietf
meeting.
With
my
present
at
the
last,
the
last
slide
said:
okay,
so
the
current
status
is.
This:
is
the
old
slide
set
Marco
but
never
mind.
B
B
B
Then
there
was
one
other
issue
that
needed
to
be
resolved,
so
version
6
was
submitted
to
resolve
their
own
issue,
and
then
there
was
a
request.
I
mean
there
was
a
question
at
the
meeting
whether
we
should
request
an
early
review
from
the
iot
directorate
and
and
the
consensus
was
yes.
So
an
early
review
was
requested
and
then
more
reviews
were
also
welcome.
B
We
found
out
through
the
review
that
Marco
provided
before
the
idea
meeting,
that
that
there
was
some
issues
with
that
compact
code
and
also
it
was
possibly
a
little
bit
challenging
to
to
review,
because
it
was
a
rather
rather
compact.
So
we
took
the
decision
to
instead
move
the
code
away
from
the
section
that
improved
the
readability.
We
put
it
in.
B
B
Good
okay,
so,
as
I
was
saying,
we
moved
the
reference
code
away
from
the
main
body
of
the
text
and
edit
it
as
an
appendix
that
was
now
informative.
So
it
does
that
doesn't
completely
illustrate
all
the
conditional
attributes
which
I
would
have
been
rather
challenging,
but
I
think
it's
it's.
Rather
it's
rather
a
good
example
of
how
how
the
processing
can
be
done.
B
So
that
was
the
major
change
in
the
in
the
document
as
it
stands
now.
So
that's
at
version
zero,
six,
but
then
this
specific
slide
shows
what
actually
happened.
So
while
we
were
at
version
zero,
five
then
before
it
became
version
zero.
Six,
a
review
was
requested
for
early
review
from
iot
directorates
and
and
enes
graciously
accepted
to
to
to
review
it.
B
B
So
the
next
thing
is
that,
just
last
week
we
received
some
working
group
comments
on
the
core
mailing
list,
and
I
would
like
to
address
the
first
one,
which
is
a
little
bit
easier
and
then
and
then
we
can
discuss
for
the
second
one.
This
is
a
little
bit
more
involved,
so
the
first
one,
the
the
URL
is
there
it.
It
was
about
the
pmax
attribute
and
it's
it's
basically
the
how
it
can
be
used
for
the
amplification
attack
on
on
Co-op.
B
E
B
So
I
was
here
just
now
talking
about
the
first
first
mail
that
we
received
as
a
review
and
I
was
mentioning
that
PMX
specifically
was
mentioned
as
an
example
of
how
an
amplification
attack
can
become
worse
by
setting
the
attribute
to
to
very
short
timeouts,
and
the
reviewer
suggested
that
before
publishing
this
draft,
it
should
describe
describe
this
problem
and
also
normatively
require
some
mitigation
from
the
implementation.
So,
after
a
couple
of
short
discussions,
I
think
what
we
need
to
do
is
to
really
work
on
the
security
considerations.
B
Part
of
the
of
the
of
the
draft
to
discuss
basically
not
only
pmax,
which
is
now
aggregate
which
is
now
described
as
C
dot,
P
Max,
but
also
EP
Max,
because,
while
pmax
can
be
used
by
amplification
attacks,
epmax
is
used
to
adjust
the
Cadence
of
the
measurements
at
the
server
side,
so
it
can
potentially
be
used
for
resource
exhaustion.
Attacks
as
well,
and
so
I
think
that
that
is
not
that
difficult
to
to
include
into
the
draft.
So
we
will
try
to
to
do
that.
B
So
the
client
always
receives
the
the
latest
resource
state,
but
using
using
these
conditional
attributes
that
interferes
with
the
operation
of
observed
since
using
query
parameters
you
you
do
not
necessarily
get
the
actual
resource
date,
but
you
get
the
resource
state
that
is
obtained
after
filtering,
and
if
you
are
applying
observe
on
that,
then
you
cannot
really.
You
cannot
really
get
the
newest
resource
state.
So
that's
that's
the
justification
for
this
and
the
resolution
steps
are
still
open,
so
we
we
probably
need
to
discuss
this
further.
B
F
Oh
everything's,
taking
a
long
time
I'm
sorry
I'd
like
to
hear
for
some
other
comments
first,
because
we
kind
of
have
considered
a
position
on
this,
and
but
we
want
to,
we
want
to
hear
if
there
anyone,
like
Christian,
has
been
in
this
discussion
as
well.
Is
there
anything
anyone
else,
I
guess
no
one
else
has
raised
their
hand,
so
I
think
that,
fundamentally,
what
we're
looking
at
is
first
The
observed.
Oh
say:
Carson
has
his
hand
up
I'm
gonna
kind
of
let
Carson
go
first.
D
C
Yeah
I
understand
I,
agree
with
the
sentiment
Express
by
you
and
on
the
slide
that
this
is
not
the
latest
stage
of
the
resource
that
we
that
that
we're
not
altering
the
latest
state
property
of
7641.
We
are
just
creating
a
new
resource
that
now
has
a
new
latest
State
and
that
latest
state
gets
grounded
Faithfully.
So
all
is
fine
in
my
book
and
I.
C
B
E
F
Literally,
like
five
or
six
seconds
to
unmute
so
yeah,
thank
you,
Christian
and
Karsten
I.
Think
that
clarifies
what
what
the
real
concern
might
be
here
is
that
we
have
sort
of
created
a
little
subversion
of
Co-op
that
might
have
problems
interrupting
interoperating
with
other
endpoints
in
an
on
a
network.
I,
don't
think
we've
done
that,
but
I
think
it
deserves
further
consideration.
So
I'll
think
about
that.
But
I
think
that
my
main
point
was
going
to
be
what
Christian
said
and
that's.
F
Why
really
I
wanted
others
to
to
weigh
in
first
was
that
well,
first,
we're
not
really
saying
that
you
have
to
use
Query
parameters
here.
There
are
other
ways
to
use
these.
These
are
just
basically
a
set
of
definitions
of
filters,
but
I
see
the
concern
comes
about
when
we
suggest
that
you
could
use
them
as
query
parameters,
but
I
think
that
concern
is
mostly
mitigated
by
the
fact
that
or
the
con
by
the
widespread
agreement,
that
the
use
of
a
query
parameter
creates
a
new
resource
or
at
least
a
new
resource
State.
F
And
so
what
we're
observing
it's
actually
very
much
like
clouds,
proposes
we're
supposed
to
use
names
or
not,
but
that
that
what
we're
doing
is
we're
creating
a
new
sort
of
resource
state
that
gets
observed.
So
we're
not
really
changing
the
way
observe
happens,
we're
creating
a
new
progression
of
resource
States,
that's
derived
from
the
initial
one.
That's
a
filtered
version
and
I.
F
E
F
D
F
To
suggest
that
that
a
user
of
this
might
look
at
the
network
context
and
look
at
their
typical
Network
latencies,
and
all
that
and
provide
a
guideline
for
how
to
set
the
how
to
bound
pmax
so
that
an
attacker
could
not
set
a
value
smaller
than
a
certain
value,
that's
derived
from
your
own
network
installation.
So
we
could.
We
could
be
pretty
specific
about
the
remediation,
I,
think
and
I.
B
C
Yeah,
as
we've
come
back
to
to
the
to
the
pmax
stuff,
I
think
I'm
personally,
I.
Don't
think
that
it
is
up
to
this
document
to
say
anything
more
than
a
non-normative
remarks
that,
by
the
way,
make
sure
that
you're
adhering
to
7641,
because
any
amplification
mitigation
that
needs
to
happen
already
happens
by
a
proper
implementation
of
7641.
C
That
limits
the
number
of
outstanding
non-confirmable
notifications
and
creates
confirmable
notifications
in
between
and
doesn't
create
too
many
ongoing
ones
and
so
on.
So
that's
all
there.
If
what
is
there
is
insufficient,
then
we
might
want
to
update
7641,
but
not
everything
that
produces
values
that
can
be
observed,
and
that
might
do
that
in
a
short.
Pace
should
need
to
worry
about
this,
because
this
is
what
we
have
an
underlying
protocol
for,
and
the
underlying
protocol
should
provide
the
adequate
measures.
B
We
we
do
not
necessarily
need
to
prevent
the
server
from
sending
resource
State
updates
periodically
to
the
client.
This
is
what
I
believe
so
I
don't
think
this
is
the
idea
of
pmax
not
being
able
to
fit
into
this
into
this
idea
of
having
this
virtual
resource,
States
or
or
resource
States
is
a
problem.
A
F
Yeah
brief
comment
on
that
is
something
I
meant
to
mention
earlier,
and
that
is
the
idea
of
trying
to
build
in
the
idea
that
the
the
actual
value
of
a
number
has
to
change
for
the
resource
state
to
be
observed
as
being
changed,
that
there
are
a
lot
of
scenarios
where
an
update
occurs,
but
the
value
doesn't
change
and
you
want
that
to
create
an
observation.
So
pmax
is
just
a
special
case
of
you
know
these
things
only
being
hints
the
server
should
never
be
prohibited
from
spending
an
additional
notification.
A
Yeah
I
had
a
few
comments,
also
been
starting
from
epmax,
actually
yeah.
That
was
not
part
of
the
original
comment
from
John,
but
you
want
to
cover
it
as
well,
which
is
good.
The
applying
considerations
along
the
line
of
the
server
should
still
think
well
for
its
own
best
about
not
just
accepting
whatever
value
client
proposes.
B
B
F
A
C
Would
sound
like
reintroducing
a
lot
of
the
HTTP
cache
control
that
we
deliberately
left
that
we?
That
was
promo
time
that
was
deliberately
left
out
of
Co-op
Fair
Point?
The
way
it's
here
at
least
was
the
way
of
the
client
very
politely
asking
the
server
to
reduce
its
max
age,
which
at
least
doesn't
alter
the
caching
model.
Yes,.
D
D
So
that
is
useful
State
for
the
the
client
to
have
we
encode
the
lifetime
in
the
attribute
max
age,
and
that
actually
may
not
change,
because
it's
now
reference
to
a
different
point
in
time
than
than
the
previous
notification
so
yeah.
What
exactly
does
it
mean
for
the
state
to
be
different?
Another
thing
that
a
server
may
want
to
tell
the
client
is
actually
I.
D
Don't
have
a
new
management
measurement
and
I'm
I'm
a
little
bit
surprised
by
that
I
would
have
expected
to
have
a
new
measurement
now,
but
it
didn't
come.
So
here
is
the
measurement
with
a
smaller
max
age
than
the
previous
one
had
so.
The
the
next
Edge
plus
plus
the
the
time
when
it
actually
was
sent
in
this
case
stays
the
same.
D
D
What
we
mean
by
by
saying
there
is
new
stage
that
that
actually
warrants
doing
a
notification
and
I
don't
have
a
clear
opinion
on
what
the
right
result
is
here,
but
I
think
it's
a
little
bit
more
complicated
than
just
looking
at
the
payload
and
saying
only
the
the
payload.
A
change
in
the
payload
generates
a
new
notification.
F
Yeah
I,
that's
that's
pretty
much.
What
I
would
like
to
you
know
be
able
to
think
about
it
in
terms
of
that
each
resource
State
when
you're
using
conditional
notification,
particularly
when
you're
using
pmax
each
resource
state,
has
a
finite
Lifetime
and
whether
you're
using
I,
guess
using
max
age
seems
like
it
makes
a
lot
of
sense,
but
each
resource
state
has
a
finite
lifetime.
F
Therefore,
when
you
communicate
the
same
value
again,
you're
communicating
a
new
resource
state
with
a
new
end
time,
and
there's
no
reason
that
that
we
should
try
to
prohibit
that
interpretation
unless
someone
can
think
of
like
a
really
good.
What
what
does
that
actually
break,
because,
depending
on
the
value
changing
just
seems
to
be
really
artificial?
B
E
F
A
F
B
It
is
not
necessarily
the
conditional
attributes
by
any
query
pyramid
on
it.
Does
it
actually
change
the
way
observe
behaves
so
that
that
would
be
good
to
clarify,
maybe
in
the
things
that
things,
research
group
or
even
in
in
core,
because
it's
not
really
there
in
the
in
the
observed,
observed
RFC.
Sorry.
C
A
B
I
think
that
needs
to
be
done,
because
that
was
the
recommendation
that
that,
if,
if
we
are
including
that
kind
of
clarification,
then
then
that
the
draft
probably
will
benefit
from
the
discussion
and
and
going
forward
to
to
Future
reviews
and
that's
something
that
could
be
easily
explained
as
well.
Yeah.
B
F
Okay,
so,
just
to
summarize,
our
work
item
is
to
to
basically
update
the
draft
with
a
prototype
discussion
along
these
lines,
but
also
we're
going
to
take
that
discussion
broader
and
make
sure
that
we
have
agreement
on
some
of
the
basic
concepts.
Yes,
but
that
didn't
get
in
the
way
of
us
updating
the
draft
with
language
we
think
is
appropriate
foreign.
C
D
For
some
reason
you
cannot
use,
observe
so
proxy
number
one
has
actually
has
to
power
proxy
number
two
and
the
the
job
of
observe
is
to
enable
this
by
providing
all
the
information
that
proxy
one
needs
to
properly
poll
proxy2
and
to
to
send
notifications
in
case
this
is
actually
needed
and
I
think
we
we
need
to
describe
how
this
interacts
with
such
a
worst
case.
Proxy
concatenation.
D
F
B
F
B
It's
gonna
have
to
I
I
know
that
the
way
that
we
were,
we
did
have
one
section
talking
about
proxy
and
caching,
but
now
I'm
trying
to
I'm
struggling
to
find
that
section
implementation
considerations.
But,
oh
yes,
we
do
the
last
paragraph
in
implementation
considerations,
but
you
might
be
right.
We
might
be,
might
be
more
prudent
to
have
a
special
section
on
proxy
considerations.
F
E
F
D
C
So
just
because
we're
considering
that
such
a
lag
might
exist
doesn't
mean
that
such
a
lag
needs
to
Faithfully
represent
exactly
the
same
outcome,
because
this
is
there
is
a
degradation,
and
that
is
okay,
and,
and
that
may
happen,
it's
just
that.
Eventual
consistency
still
needs
to
be
there,
and
it
probably
is.
A
B
A
D
D
D
It's
really
a
problem
that
you
cannot
see
whether
people
are
fully
unmuted
or
half
unmuted.
Thank
you,
so
yeah
90
to
54
is
done.
We
are
working
on
course
hit
and
we
we
have
great
feedback
from
Rob
Wilton
that
that
is
improving
the
document.
We
have
Carl
comai
that
that
has
passed
working
glass
coil
for
a
while,
but
that
we
couldn't
really
progress
because
there
was
still
uncertainty
around
Yang,
sibo
and
Carson.
D
And
finally,
we
have
Carl
Yang
Library,
which
passed
working
with
us
called
a
while
ago,
but
then
the
the
Yang
Community
has
advanced
so
much
in
that
time.
We
may
have
to
revisit
this
set
at
the
time
when
we
get
to
it,
but
that's
not
on
the
agenda
today.
Let's
talk
about
corset
and
call
Kuma
for
the
for
this
meeting,
so
in
cause
it.
If
you
look
at
the
GitHub
repository
that
there
are
essentially
two
pull
requests
here,
one
I
think
is
mostly
done
and
it
could
be
merged.
D
That's
the
146
that
addresses
the
need
to
document
our
objectives
for
doing
seed
management.
So
what
do
we
want
to
get
right
here?
It
took
us
a
while
to
get
feedback
for
that,
but
the
feedback
is
getting
better
and
better
so
yeah,
maybe
that's
the
way
it
works,
and
the
other
observation
is
is
a
more
specific
one
about
the
need
for
a
stable
field
in
the
Sid
file.
D
So
that's
why
the
the
Sid
file
issue
comes
up,
and
only
a
couple
of
minutes
ago,
Michael
Richardson
made
a
comment
on
pr141
that
is
really
useful
and
that
really
addresses
this
aspect
by
by
making
sure
we
actually
can
channel
the
information
that
needs
to
flow
between
the
the
people
who
do
a
Yang
module
yeah,
so
I'm
not
expecting
that
we
can
fully
discuss
this
here
today.
Michael.
E
The
real
question
is:
how
do
you
how
what
do
you
do
to
Market
as
stable
and
how
does
that
work
and
who
does
that
and
that's
not
that's
a
little
bit
of
a
yeah?
What
what
what
option
do
you
put
on
the
Ping
command
line?
But
it's
also
who
puts
that
option
and
when-
and
you
know
that
is
actually
more
of
a
process
issue
so
I
would
suggest
we
don't
go
with
an
enumerated
as
I
said,
I
think
we
can
get
more
information
in
there.
E
That's
useful,
but
anyway,
regardless
of
what
we
put
in
that
Jason,
because
it's
all
Json
file
right
now,
so
we
could
actually
change
our
mind
several
times
without
changing
too
much
I
think
we
can
make
ping
mostly
work
and
I.
Think
I'm
hopeful
enough
now
to
do
it,
but
we
need
to
decide
what
needs
to
be
done.
D
D
D
D
Then
it's
probably
needs
to
be
a
way
to
carry
these
around
in
in
the
Sid
files.
So
there
may
be
some
tricks
to
encode
this
by
by
recording
high
water
marks
in
the
ranges
or
something
like
that,
but
I
think
that
gets
complicated
quickly
and
since
these
Sid
files
are
not
messages
you
send
back
and
forth
all
day.
We
don't
have
to
be
particularly
optimal
when,
when
encoding
this
information,
so
maybe
having
a
status
of
obsolete,
is
useful.
D
D
D
So
my
plan
is
to
to
spend
some
time
on
processing
Rob's
feedback.
This
will
certainly
take
us
into
the
next
week
because
he
also
has
some
some
new
issues,
some
of
which
may
be
very
simple
to
fix,
but
some
of
which
also
may
require
some
thinking,
and
we
also
have
a
few
issues
that
we
left
open
until
we
understood
our
Direction
on
141
and
146.
So
we
have
to
do
work
on
these
so
yeah.
D
D
D
D
D
You
are
a
safe
Basics
if
I
encoding
and
most
of
the
ones
that
don't
use
the
decimal
integer
encoding,
which
is
definitely
less
efficient
than
base64
encoding,
so
that
there
is
a
single
well
Boolean
is
a
special
case
and
the
single
case
string,
which
also
happens
to
be
the
most
likely
thing
you
you
want
to
put
into
where
you'll
get
requests
that
is
handled
transparently
and
yeah.
The
current
proposal
does
not
optimize
for
this
frequent
case,
so
we
might
have
a
three
to
four
expansion
here.
D
So
looking
at
this,
some
more
actually,
the
the
full
K
parameter
is
assembled
together
from
keys
that
are
encoded,
as
on
the
previous
slide,
by
separating
them
with
commas
and
yeah
that
that
doesn't
take
into
account
that
the
strings
you
might
have
as
as
Leaf
values
that
turn
into
keys.
These
strings
actually
also
can
contain
commas.
C
D
So
the
decision
to
have
both
Fetch
and
get
was
taking
some
three
four
five
years
ago,
when
there
were
still
Co-op
implementations
out
there.
That
didn't
do
that
and
that
didn't
do
fetch
so
I'm.
We
might
decide
that
this
simply
is
overtaken
by
events,
and
you
should
be
doing
a
fetch
yeah.
The
the
disadvantage
is
that
not
not
all
requests
actually
require
a
key,
so
just
sending
the
the
Sid
may
be
a
nice
way
of
doing
things.
I
don't
know.
Michael.
C
D
So
the
question
really
is
how
much
of
glaucoma
is,
is
already
deployed
out
there
in
weird
environments
that
that
make
using
fetch
hard,
because
the
DNS
staff
is
not
out
there.
So
we
really
have
a
green
field
situation,
but
komai
has
been
discussed
for
for
10
years
now,
and
this
draft
draft
11
has
been
out
for
a
couple
of
years
and
people
might
have
implemented
that,
and
we
probably
want
to
ask
people
whether
that
is
the
case.
D
D
Great,
so
the
the
question
really
should
be
it's
2023.
Do
we
still
have
to
cater
with
cater
to
non-fetching
implementations
and
if
not,
we
can
simplify
things
a
lot
so
that
that's
great
in
Butch
yeah.
My
plan
is
to
to
get
this
case.
Simplification
done
now
this
draft
I'm
interested
in
moving
this
draft
forward
because
I'm
actually
the
shepherd
for
that
and
foreign.
D
So
again,
the
the
next
step
is
doing
a
design
team
meeting
and
and
getting
as
many
of
the
original
authors
together
as
possible
and
then
decide
what
the
content
of
the
dash
12
version
of
the
draft
will
be.
Dash
11
has
been
expired
for
quite
a
while
now
and
yeah
dash
12
needs
to
get
out
at
some
point
in
time,
and
we
should
decide
what
we
want
to
have
in
there.
A
A
A
The
discussion
started
in
during
in
October
you.
You
can
check
the
means
for
the
details
and
right
after
the
interim,
a
pull
request
followed
up
from
Karsten.
It's
still
open
and
Carson
and
I
had
further
discussions
on
the
topic
end
of
last
year,
and
things
progressed
quite
a
bit
and
the
pull
request
got
updated,
but
there
is
especially
one
still
open
Point
deserving
attention,
we
think,
but
to
give
a
status
update.
A
Well
that
was
the
easy
one
defining
upfront
a
bit
more
URI
schemes
that
deserve
to
have
a
negative
integer
ID
already
from
the
href
document.
So
the
overall
CDL
definition
was
updated,
as
you
see
in
the
slide,
and
Carson
also
started
a
Wiki
to
collect
schemes
for
which
we
want
to
have
IDs,
also
defined
up
front,
but
that
was
pretty
easy
and
uncontroversial.
A
Then
the
main
thing
was
about
creating
the
the
registry
and,
of
course,
defining
proper
registration
guidelines
around
it.
So
the
register
was
also
added
to
the
pr.
It's
quite
simple,
I
think
the
original
idea
was
specification
required,
but
it
was
just
good
enough
to
to
go
for
expert
review.
Instead,
it
was
quite
clear
from
the
start,
and
so
that
was
also
added
that
you
really
need
to
be
careful
in
registering
IDs
in
the
OnePlus
zero
on
one
plus
one
space.
A
That's
really
for
iot
use
cases
and
especially
being
sure
that
you
are
considering
a
scheme
that
can
enjoy
a
wide
use,
and
otherwise
you
still
have
the
OnePlus
2
space,
which
should
be
kind
of
the
default
choice.
If
you
want,
and
after
some
discussion
with
Karsten,
we
thought
it's
just
better
to
consider,
especially
that
that
space
to
to
handle
the
corner
case.
A
A
Then
there
was
also
the
point
to
ensure
to
raise
awareness
about
the
existence
of
this
new
registry
in
the
first
place
and
of
Cris
all
together
as
a
side
effect.
So
what
was
also
added
to
the
pr
Indiana
consideration
was
a
request
for
Ayana
to
add
a
note
to
the
URI
schemes
registry,
about
mentioning
the
existence
of
the
new
URL
scheme,
ID
registry
and
the
policies
around
registration
there
and,
in
a
sense
so
far
so
good.
A
But
there
it
comes
the
the
big
open
point,
which
is:
when
exactly
should
the
scheme
ID
registration
happen.
We
want
to
avoid
a
situation
where
a
new
URL
scheme
is
registered
and
an
ID
is
not
and
then
later
on.
It
is
and
then
that
they
would
compromise
a
lot
interoperability
with
people
that
are
just
used,
maybe
maybe
for
years
about
using
the
textual
representation.
Only
that
of
course
remains
possible.
A
D
Yeah
I
just
would
like
to
remind
people
that
this
is
really
the
x-dish
problem
that
we
have
had
in
a
large
number
of
protocols
in
the
ITF,
where
there
was
a
way
to
have
a
provisional
identifier
for
something.
Often,
this
identifier
started
with
x,
dash
for
extension
and
then
at
some
point,
the
the
feature
went
mainstream
and
people
thought
they
might
now
be
able
to
allocate
a
permanent
identifier
for
the
future.
D
So
it's
as
good
as
only
using
the
old
implementation
with
the
old
name
all
the
time,
and
given
that
we
would
like
to
to
reap
the
benefits
of
using
numeric
identifiers
for
schemes
as
far
as
possible.
Instead
of
getting
stuck
at
the
text.
Identifier,
when
the
numeric
identifier
hasn't
been
registered
early
enough,
that
that
is
a
very
special
form
of
the
sex
Dash
problem.
A
Yeah
otherwise
I'm
sure
we'll
get
back
to
it,
Friday
this
week,
for
sure
and
by
the
way
more
in
general,
the
href
document
yeah
there
are
still
a
few
open
issues
and
PRS
other
than
this
I
think
some
issues
can
actually
be
closed
already,
like
53
and
54.
I'm,
pretty
sure
the
latest
revision
already
addressed
those,
but
we
can
also
do
some
clean
up
about
that
on
Friday.