►
From YouTube: IETF115-REGEXT-20221110-1700
Description
REGEXT meeting session at IETF115
2022/11/10 1700
https://datatracker.ietf.org/meeting/115/proceedings/
A
C
B
Let
me
do
a
quick
check
first
for
a
note
taker,
as
we've
done
in
the
past,
pretty
straightforward
for
us,
the
agenda's
already
in
the
notepad
thing.
We
just
need
some
help
from
one
or
more
people
to
just
put
some
actions
in
there,
so
we
got
at
least
one
hand
out
there
from
Wicklow
home,
but
please
anybody
even
remote
participants.
B
You
know
just
track
in
there
and
as
we
pass
through
things
just
capture,
whatever
actions
came
out
of
it
I
think
in
today's
world,
given
that
we
do
recordings-
and
you
have
the
agenda
there-
I
don't
know
that
we
have
to
have
detailed
summary
minutes,
at
least
not
for
us
and
our
discussions
as
a
rule,
but
capturing
the
actions
and
any
results
is,
is
kind
of
important.
So
a
quick
bullet
about
those
things
would
be
helpful.
B
All
right.
So,
let's
get
started.
B
I
am
Jim
Galvin.
We
have
Antoine
Boucher
in
here
it's
been
a
long
time.
So
if
you
had
the
two
of
us
sitting
at
the
table
together,
so
you
know
yay
for
the
working
group,
I
suppose
or
not
depending
on
how
you
feel
about
things
but
yeah
registration
protocols,
extensions.
We
have
an
hour
today
and
a
very
full
agenda
or
perhaps
we'll
end
a
little
early,
because
I
think
one
of
the
discussions
we
gave
a
lot
of
time
to
actually
is
gonna
might
work
out
pretty
well.
B
So,
let's
jump
in
here
by
now.
This
is
Thursday
night
last
session
of
the
week
of
Thursday
the
full
days.
You
all
know
the
note
well
you've
seen
it
many
times
before.
Please
remember
you
know
your
contributions
are,
are
public
and
and
part
of
the
ITF
as
we
go
through
this
and,
of
course,
our
code
of
conduct,
always
a
good
reminder
to
people
to
please
be
respectful
and
focus
on
the
substance
and
the
issues
and
and
not
each
other.
B
That's
always
a
good
reminder
for
us
and
so
and
of
course,
in
these
covet
times,
masks
are
required
unless
you
are
actually
standing
at
the
mic
and
or
actively
eating
or
drinking.
So
please
do
remember
to
keep
your
mask
on
okay.
This
is
our
agenda
for
today,
a
quick
opportunity
for
anyone
to
offer
up
any
agenda
bashing,
it's
pretty
pro
forma.
B
This
is
our
standard
agenda
that
we
do
here
and
the
last
three
items
are
just
some
presentations
that
we
called
out
because
they
got
some
time
allotment,
but
the
other
first
half
of
this
are
just
our
standard.
Gen
items
we'll
just
walk
through
things
quickly
and
not
seeing
any
hands
so
I'm
just
going
to
keep
right
on
going
here
and
into
our
welcome
and
introductions,
and
we've
already
done
the
note
well
and
the
note
scribe.
So
just
some
quick
notes
about
document
management
and
Antoine.
D
Yes,
so
this
is
the
part
where
we
usually
say
how
we
are
doing
our
work
in
this
working
group
and,
as
you
know,
we
have
we've
for
some
time
now
ask
for
document
Shepherds
when
we
adopt
a
document
in
this
in
this
working
group
and
that
works
actually
quite
well.
We're
very
pleased
with
that,
especially
because
we
always
imagine
that
not
to
be
too
much
work,
and
it
also
gives
the
opportunity
for
newcomers
in
the
in
in
the
ITF
to
understand
the
process.
D
But
for
this
time,
I've
I've
put
up
the
process
of
how
a
document
is
published
a
little
bit,
because
what
we
saw
well
over
the
over
the
past
not
recent
time,
but
but
for
a
longer
time
that
when
we
adopt
a
working
group
graph
and
that's
a
formal
process,
then
we
have
iterations
of
the
document.
And
then
a
document
moves
into
working
group
last
call,
and
the
intention
is
that
a
document
that
moves
into
working,
Google
Plus
call
is
a
stable
document,
because
we
are
a
small
working
group.
D
D
But
something
that
is
very
important
is
that
when
we
want
to
have
the
process
for
a
document
Shepherd
to
be
tracking
changes
during
working
group
last
call.
We
want
that
process
to
be
easy.
So
we've
seen
recently
that
during
working
Global
school
people
start
reviewing
the
document
and
the
number
of
iterations
take
place
so
that
there
are
multiple
documents
that
the
document
sheper
needs
to
review
during
working
on
Glasgow,
because
Alters
publish
a
new
version
of
the
of
a
document
during
working
group.
D
Let's
call
it
the
minute
that
they
agree
that
there
is
still
an
issue
with
the
document.
I
would
ask
people
not
to
do
that
to
make
documents
stable.
We,
as
chairs
have
decided
that
we're
going
to
call
outs,
working,
Google,
Plus
call
for
a
specific
document
and
number,
and
there
are
a
number
of
tools
that
authors
can
use
during
working
group.
Last
call
to
track
issues
we
that
some
people
use
GitHub.
There
is
an
issue
tracker.
D
You
can
use
a
Wiki
page,
but
please
publish
a
new
version
of
the
document
after
working
group
law,
school
changes,
because
that
will
give
the
opportunity
to
you
know
in
experience
audience
document
Shepherds
to
track
the
changes
and
and
make
sure
that
the
program,
the
the
the
the
process
works
out
quite
well.
So
that's
just
a
request
from
us.
D
You
know
be
sure
that
when
you
ask
for
a
working
group
last
call
that
the
document
is
stable
and
try
not
to
publish
a
new
version
of
the
document
until
all
your
issues
are
clear
during
the
working
group
last
call
and-
and
that's
basically
my
question.
B
Okay,
any
questions
or
comments
not
seeing
any
hands
or
things
in
the
chat
room.
So,
let's
move
along
here.
Let's
move
to
published
documents.
Sadly
none
this
time.
We
had
a
few
that
we
mentioned
last
time,
but
that's
because
we
were
catching
up
on
quite
some
distance,
but
I
think
we're
gonna.
B
We're
gonna
move
along
a
few
documents
for
next
time,
so
moving
right
along,
we
do
have
documents
in
working
group
last
call
actually
so
the
reverse
search
and
the
Federated
open
ID
to
spend
a
little
bit
of
discussion
on
the
mailing
list.
So
we'll
you
know
deal
with
those
on
on
the
list
and
I
think
the
Federated
eye
open
ID
is
probably
going
to
come
back
to
the
working
group.
Last
call.
B
There
was
a
side
meeting
yesterday
day
before,
where
a
few
people
got
together
and
raised
kind
of
a
an
important
technical
question
which
I
believe
is
is
well
is
material
enough
that
it's
going
to
suggest
bringing
the
document
back
to
the
working
group
to
take
a
look
at
those
changes
before
we
press
this
thing
forward.
So
just
look
out
for
that
on
the
mailing
list,
so
that
we
can,
you
know
formally
do
what
we
need
to
do
there
and
I
believe
the
reverse
search
is
is
headed
to
closure
right.
B
D
So
that
was
one
of
the
documents
where
there
were
multiple
versions
of
the
document,
and
you
know
the
the
another
issue
that
it
brings.
But
it's
just
more
for
us
as
chairs
is
that
it's
it
becomes
very
hard
to
claim
consensus
until
after
a
document,
Shepard
has
told
us
that
all
the
issues
were
resolved,
so
we're
still
waiting
for
that.
D
There
was
still
one
issue
that
had
to
be
called
out
on
the
mailing
list,
and
that
was
a
week
before
before
the
meeting,
and
so
apologies
that
we
didn't
react
to
that
immediately.
But
after
the
meet
after
this
meeting
we
will
we
will
close
it
and
and
move
forward
with
that.
B
Okay,
I'm
going
to
keep
plowing
through
here,
and
thus
somebody
wants
to
jump
up
and
get
in
the
queue
here
to
speak.
Moving
right
along
we'll
get
to
status
of
existing
work
and
chairs
here
are
just
going
to
ZIP
down
through
these
the
simple
registration
reporting
and
the
JS
contact
and
the
redacted
Fields
documents
are
all
imminently
ready
for
working
group.
Last
call
now
we
we
have
established
for
ourselves
a
bit
of
a
process
where
we
only
do
documents
one
at
a
time.
B
In
last
call
we
did
do
a
little
bit
of
overlap
on
those
other
two,
which
is
why
there's
two
out
there
at
once.
We
had
expected
the
one
to
close,
and
so
we
opened
up
the
second
one,
and
then
there
was
a
bit
of
delay
in
all
of
that,
but
on
for
the
benefit
of
our
group,
we
just
are
recognizing.
B
We
don't
have
that
many
active
people
here,
and
so,
even
though
these
documents
all
have
been
suggested
that
they're
ready
to
go
to
the
last
call
we're
just
going
to
issue
them
one
at
a
time
here,
serially,
so
that
we
don't
burden
everybody
with
having
to
read
them
all
all
at
once,
and
given
these
other
two
that
have
a
couple
of
I
think
they
they
might
turn
out
to
be
straightforward
changes.
So
we
might
wait
to
issue
the
next
working
group
last
call
till
those
come
back.
B
Think
we'll
do
that
unless
anybody
would
like
to
do
something
different
I
mean
this
is
just
the
process
we've
been
following
and
we're
telling
you
so
if
anybody
wants
to
jump
one
of
these
first
three
in
the
queue
here
in
terms
of
when
they
go
to
last
call,
you
know,
please
do
feel
free
to
let
us
know
say
something
on
the
mailing
list
really
and
Jim.
Gould
is
saying:
oh
reporting,
ready
for
work
and
good.
B
Last
call
fair
enough:
Jim
Gould
on
the
simple
registration
reporting,
you're
right
I
may
not
have
actually
said
that
on
the
list,
but
I
know
that
Antoine
and
I
have
talked
about
it.
But
let's
go
to
the
queue
here
on
a
couple
of
things
before
I
talk
about
data
dictionary,
so
Jim
go
ahead.
Please
Jim
Gould.
E
Good
yeah,
there
are
some
open
items
with
the
super
registration
recording
draft
that
were
discussed
on
the
list.
I
mean
specifically
around
splitting
the
draft
I
had
the
framework
defined
in
a
separate
standards
track
graph
and
then
have
the
actual
concrete
reports
in
a
informational
draft.
That
was
what
was
discussed.
B
Thank
you,
okay,
thank
you
for
that
I'll
make
sure
to
go
back
and
and
check
that
so
we'll
take
care
of
that.
Thank
you,
Rick
Wilhelm
next.
F
Thanks
Jim
Rick,
Wilhelm
PIR.
This
is
really
a
a
quick
comment
related
to
the
redacted
fields
and
rdap
responses,
as
Jim
knows,
because
he's
involved
with
me
in
another
front:
that's
one
that
over
in
land
of
of
icann
there's
some
policy
work
that
is
right
now,
leaning
on
the
on
the
ID,
and
so
it
would
be.
It
would
be
good
if
that
could
turn
into
an
RFC
so
from
the
technical
community
that
that
becomes
stable
more
quickly
rather
than
later.
F
So
that
would
so
as
we
look
to
see
which
one
of
these
is
going
to
kind
of
line
up
next,
there's
a
an
auxiliary
benefit
of
moving
that
one
ahead,
but
that's
something
you're
aware
of
Jim,
but
just
for
the
broader
group.
Thank
you.
B
So
thank
you
for
that.
Yes,
I'm
glad
that
you
brought
that
up.
So
you
know
that
that's
just
sort
of
a
suggestion
to
the
chairs
that
we
I'm
taking
that
as
a
suggestion
to
the
chairs
that
we
try
to
move
that
one
along
ahead
of
anything
else
as
quickly
as
we
can
choose
that
for
the
next
one
to
go
to
working
group
last
call.
So
let
me
ask
on
behalf
of
Antoine
and
I.
B
If
anyone
has
a
different
point
of
view
about
that
to
please
let
us
know
say
something
on
the
list
or
come
here
and
speak
up
and
Jim
Gould
I
see
you
in
the
Q
next,
please
go
ahead.
E
Yeah
in
relation
to
the
regret,
redacted
draft
there
is
that
normative
reference
dependency
to
the
Json
path
base
draft
we
reached
out
to
the
editors
for
that
draft
and
the
Milestone
set
for
this
month,
and
they
confirmed
that
that
was
accurate.
We
have
provided
review
feedback
to
that
draft
to
hopefully
move
it
along
really,
the
work
is
done
with
the
redacted
draft,
so
I
guess.
The
question
for
the
chairs
is
whether
or
not
we
can
go
to
working
in
class
call
in
parallel
with
this
normative
dependency.
B
Yeah,
so
the
answer
to
that
should
be
yes,
unless
we
are
expecting
something
material
to
happen
in
the
other
normative
reference
that
would
impact
our
document,
then
we
might
want
to
be
concerned,
but
as
I
understand
it,
the
other
normative
reference
is
fairly
stable.
The
JS
contact
has
a
similar
down
reference
at
the
moment,
but
you
know
we
can
submit
these
to
the
isg
for
publication
and
they
will
then
get
their
review
and
then
they'll
be
tagged
for
to
be
held.
B
While
we
wait
for
the
other
document
to
catch
up,
since
it
can't
be
published
with
a
normative.
You
know
down
reference,
so
we
should
be
okay.
Moving
that
forward.
E
Okay,
good
I
good,
so
we'll
go
ahead
and
put
a
request
on
the
list.
Is
that
The
Next
Step
then.
G
To
me,
redacted
and
just
contacts
should
be
the
most
the
highest
priorities,
especially
because
she
has
contact.
You
know
it
would
be
a
long
process
to
get
all
the
implementation
you
know
and
then
get
rid
of
G
cards.
So
the
more
we
wait
so
redacted
and
GS
contact
in
my
book
would
be
that
the
most
prior.
B
Okay,
thank
you
appreciate
that
and,
as
I
said
before,
anyone
else
who
wants
to
make
a
comment
about
priority
order
of
these
documents.
Please
do
let
us
know
and
and
speak
up.
Okay,
the
registration
data
dictionary
is
is
just
there.
They
haven't
requested
last
call
I
understand
from
talking
to
the
authors
that
they're
getting
ready
to.
B
They
consider
themselves
almost
ready,
like
really
close
to
asking
for
our
working
group
last
call
so
I
just
want
to
put
that
on
your
radar
to
be
watching
for
that
and
that'll
just
end
up
being
on
our
list
here
and
we'll
move
through
the
documents,
one
at
a
time,
as
we
said,
unless
anybody
wants
to
suggest
something
different,
okay,
not
seeing
it.
Oh
do
you
want
to
speak,
go
ahead,
yeah.
B
And
for
the
remote
participants,
we
had
two
people
in
the
room,
raise
their
hand
and
we've
got
a
room
of
about
20
people
here.
Not
quite
so
go
ahead,
Rick
so.
F
B
So
yes
good
to
know,
thank
you.
We
do
have
a
an
unfortunate
reality
in
our
group
of
silences
no
objection
and
tends
to
be
supportive.
So
it's
good.
It's
especially
important.
B
You
know
if
you
have
concerns
questions
issues
to
make
sure
those
get
on
the
list
so
that
we
can
take
that
into
account.
So
please,
please
do
make
sure
to
do
that.
Okay,
with
that,
we
will
jump
into
a
bit
of
substantive
work
that
we
have
here.
We
are
about
10
minutes
behind
schedule
at
the
moment,
but
we're
hoping
we
can
make
some
of
that
up
and
with
that.
Let
me
turn
this
over
to
everyone.
D
Yes,
and
so
the
next,
our
next
topic
is
going
to
be
about
a
document
that
had
quite
some
discussion
during
the
IDF
working
group
plans
to
order
for
the
ietf
last
call
and
a
lot
of
work
and
a
lot
of
discussion
has
been
taking
place
there
and
some
of
the
work
may
be
material
and
that's
why
we
want
to
well
bring
it
up
here
for
for
discussion.
I
want
to
give
some
some
people,
not
usually
in
this
working
group,
some
some
time
to
discuss
this
document
with
us.
D
H
H
Yeah
there.
E
Was
plenty
of
discussion
at
the
ITF
Last
Call
on
this
draft
and
really
there's
one
remaining
open
item
that
we
really
want
to
discuss
here
with
the
working
group.
You
can
go
ahead
and
click
the
next
slide,
please.
E
So
a
little
bit
of
background,
the
draft
version
10
entered
ietf,
Last
Call
on
May
27th,
lots
of
discussion,
lots
of
feedback,
and
we
made
updates
based
on
that
feedback.
Specifically,
we
removed
the
definition
of
a
functional
extension
and
changed
the
graph
to
be
a
command
response
extension.
The
last
version
is
version
16.,
so
the
one
remaining
issue
is
associated
with
the
email,
cardinality
and
I
cover
on
the
next
slide.
Examples
of
the
cardinality
actually
go
back
to
the
prior
slide.
I'm,
sorry,
I'm.
E
Sorry,
I
want
to
get
the
specific
feedback,
so
the
specific
feedback
was
if
a
non-ascii
email
address
is
to
be
supportive.
There
should
be
provision
for
an
all
ASCII
alternative
to
be
provided
so
having
an
alternative
email
changes.
The
cardinality
of
the
number
of
email
addresses
that
are
passed,
but
the
end
goal
here
is
that
we
want
to
be
able
to
support
the
SMTP,
TFA
addresses
and
EBP
and
existing
extensions
and
going
forward.
So
you
can
go
to
next
slide.
E
So
here
is
a
list
of
Epp
specifications
that
have
email
addresses
in
them.
Now
there
are
more
I'm
sure,
but
these
are
the
ones
that
I
were
aware
of.
So
the
contact
mapping
has
a
single
required
email.
The
mark
and
side
Mark
mapping
is
not
an
extension,
but
it's
used
by
extensions.
It
actually
has
a
required
holder,
issuer
email
and
a
optional
contact
email.
This
provides
a
little
bit
of
complexity
associated
with
creating
an
extension
of
that
particular
spec,
because
you
can't
really
identify
which
email
is
being
extended.
E
But
good
news
here
is:
that's
not
an
Epp
extension.
The
organization
mapping,
the
validate
mapping
have
a
single
optional
element
and
then
the
last
two
are
proprietary
extensions
that
have
a
single
required
on
it.
So
in
summary,
on
this
we
have
a
mix
of
extensions
that
have
either
zero
or
one
emails
or
one
email
so
go
to
next
slide.
Please
so
there
are
three
approaches.
E
E
The
ASCII
addresses
this
is
what's
currently
in
the
draft
right
now
and
then
this
next
option
is
to
change
the
cardinality
to
a
one
or
two.
This
means
that
there
would
be
support
for
an
alternate
email
element,
but
that
would
require
one
email
element
to
be
provided
when
an
alternate
is
used.
The
alternate
email
element
would
be
used
during
a
transition
period,
which
would
be
defined
by
server
policies.
So
it's
not
predefined
in
the
draft.
E
It
would
be
up
to
a
the
server
to
determine
when
it's
the
right
time
to
to
require
the
use
of
an
alternate
email.
J
E
Then
finally,
the
the
last
one
is
changing
to
a
list,
and
this
would
be
where
the
extension
would
provide
for
a
list
of
emails
and
there
may
be
support
for
types
in
that
scenario.
Go
to
the
next
slide.
Please.
E
Our
recommendation
is
to
go
with
the
second
option,
which
is
the
change
cardinality
to
a
one
or
two
in
the
draft
to
provide
a
guidance
related
to
the
transition
period.
This
would
mean
extending
the
create
command,
the
update
command
and
the
info
response
to
support
the
use
of
an
alternate
email
element.
E
This
will
provide
the
ability
to
set
an
unset,
the
alternate
email,
as
well
as
getting
an
indication
of
whether
or
not
it's
been
set,
or
it's
not
set.
E
With
this
recommendation,
it
would
follow
the
consensus
of
the
working
group
related
to
be
able
support
either
an
ASCII
or
SMTP
utf-8,
email,
value
and
I
believe
it
will
address
the
ietf
last
call
feedback
associated
with
being
able
to
support
alternate
email,
at
least
in
this
case,
during
a
transition
period.
Next
slide,
please.
E
There
you
go
so
in
conclusion:
we're
looking
for
feedback
from
the
working
group
related
to
what
is
the
best
option
to
move
this
draft
forward
and
then
I'll
just
leave
it
open
for
a
discussion.
D
Okay,
thank
you
very
much.
Jim
yeah,
I
wanted
to
say,
John
cleansing
is
in
the
queue,
so
John
go
ahead
and
give
your
answers
to
some
questions.
H
Okay,
having
been
the
one
who
raised
this
set
of
issues,
I
think
the
recommendation
is
the
correct
one.
I
think
from
a
semantic
standpoint.
Talking
about
this
in
terms
of
cardinality
is
the
wrong
thing
to
do,
but
that
may
be
just
a
vocabulary.
H
Question
the
key
here
is
an
operationally
SMTP
utf-a
addresses
not
asking
addresses,
are:
are
not
universally
usable,
they're,
much
more
usable
in
their
own
context
and
and
countries
and
languages,
but
if
they
there's
any
reasonable
possibility
that
they
could
need
to
be
accessible
internationally,
their
there
needs
to
be
provisioned
for
a
not
asking
address
whether
that
provision
is
sometimes
always
usually
usually
not
used,
as
a
policy
matter,
probably
beyond
the
scope
of
the
specification,
but
there
needs
to
be
a
way
to
provide
that
information.
H
At
the
point
you
start
talking
about
more
than
two
addresses
you're
talking
about
a
mailing
list
for
the
equivalent
and
not
about
this.
H
Why
not
ask
the
address
and
one
asking
address
so
I
think
the
recommendation
is
correct.
It
may
be
that
we
need
to
tune
the
text.
It
describes
it
a
little
bit
further
or
not.
I
just
have
not
had
time
since
that
draft
was
posted
to
do
a
really
careful
review
automatically.
D
Okay,
thank
you.
John
I
have
a
question
though,
but
I
think
Dimitri
was
first
in
the
queue
then
I'll
put
myself
in
the
queue
so
go
ahead.
Dimitri
you
first,
okay,.
K
D
K
Great
so
oh
I
agree
that
as
a
temporary
specification,
providing
a
backup
ASCII
address
is
the
best
proposal.
Solution
and
I
thought
I
totally
agree
with
John.
That.
K
Address
are
not
widely
not
used
nowadays,
but
I
want
to
say
that
ice
personalize,
his
life
contradiction
between
the
movement
to
make
SMTP
8
addresses
Universal
accepted,
in
particular,
bacon,
where
the
Epp
protocol
is
completely
relevant
and
the
idea
to
support
it
with
the
backup
asking
only
email
address
because
well,
it
means
that
we
don't
consider
SMTP
UTF
addresses
first
class
email
addresses
it's,
it
looks
sort
of
wrong,
but
of
course
yes,
I,
agree.
C
I'm,
just
watching
the
chatter
and
jabber
about
the
difference
between
what
we're
the
way
this
working
group
seems
to
be
using
the
term
EAA
or
was,
and
SMTP
utf-a
and
Pete
just
made
an
interesting
summary
which
is
one
is
an
email
protocol
and
one
is
just
an
email
address,
and
maybe
that
clears
up
some
of
my
confusion
about
it.
I
don't
know
if
that's
helpful
here,
so
he
I
was
going
to
get
it
done
to
say
this
at
the
mic.
A
I
also
agree
with
the
recommended
choice,
but
with
the
additional
comment
that
I
think
the
so-called
transitional
period
is
basically
forever
I.
Don't
think
the
alternate
address
the
need
for
alternate
addresses
is
likely
to
go
away
in
my
lifetime,
Lifetime
and
in
part,
because
different
communities
will
have
different
needs,
and
you
know
if
I
want
to
mail.
Somebody
in
the
script
I
can't
recognize.
I
always
pick
the
alternate
address,
because
I
know
what
I'm
looking
at.
L
This
Pete
Resnick
just
to
sort
of
explain
what
I
mentioned
in
the
chat
room.
I.
Think
thinking
about
this
in
terms
of
cardinality
of
email
addresses
that
you
have
multiple
email
addresses
is
the
wrong
way
to
think
about
this.
What
you're
saying
is
these
servers?
These
Services
support
a
second
email
protocol,
SMTP
utf-8
instead
of
SMTP,
and
to
support
that
protocol.
You
need
a
piece
of
data
which
is
the
the
eai
address.
L
The
non-ascii
address
the
thing
that
goes
into
SMTP
utf-8
that
is
different
than
if
you're
just
supporting
SMTP,
and
so
what
you're
doing
when
you
communicate.
This
extension
to
the
other
side
is
you're,
saying
I
support
the
sending
over
the
SMTP
utf-8
protocol,
and
so
any
messages
I'm
going
to
send
are
going
over
that
protocol
and
they're
going
to
use
this
other
address
or
they
could
use
the
email
address.
L
That's
also
valid,
but
I
mean
it's
just
a
different
way
of
thinking
about
it
either
way,
I
support
the
idea
that
what
you're
doing
is
you're
adding
another
field,
this
International
email
address
and
or
this
non-aski
email
address,
and
you
use
it
in
circumstances
where
the
extension
is
available.
D
B
So,
thank
you,
Jim
Galvin,
no
hats
I
think
we
probably
need
to
at
this
point.
It
sounds
like
we.
We
definitely
have
to
pull
this
back
to
the
working
group
for
a
bit
more
discussion
on
the
mailing
list,
because
now
I
have
the
following
questions
that
come
up
in
my
mind:
I,
like
the
distinction
that
Pete
is
making
and
I
get
it.
B
What
we're,
after
here
I'm
concerned,
that
someone
will
use
the
utf-8
field
to
push
up
and
and
ask
the
address
and
they'll
stick
that
in
the
in
the
non-ascii
field,
which
would
be
valid
because
a
naski
address
is
utf-8
and
the
discussion
that
we're
going
to
have
to
explain
in
this
technical
document
so
that
policies
on
the
other
side
can
do.
B
The
right
thing
is
whether
or
not
that
is
actually
a
utf-8
address
or
if
it
is
just
a
ASCII
address,
we're
going
to
lose
that
particular
bit
of
signal
right,
because
what
we're
trying
to
do
here
in
the
transition
step
is
distinguish
between
those
email
systems
that
only
support
ASCII
addresses
versus
non-ascii,
and
the
policies
have
to
be
able
to
support
that
so
that
in
the
registration
systems
right
I
can
I
can
make
the
right
choice
when
I'm
trying
to
send
something.
B
B
So
if
I
want
to
put
an
ASCII
only
address
in
the
optional
extra
element
because
I
like
that
model,
so
we
could
go
with
the
original
way
that
this
draft
was
written.
You're
going
to
signal
in
the
Epp
transaction
that
you're
that
you
understand
and
can
accept,
utf-8
addresses,
but
there's
nothing
that
prevents
a
registrar
from
just
sticking
a
asking
only
address
in
that
field,
which
would
be
fine,
but
what
you
really
want
is
you
need
the
extra
signal
that
down
the
road
when
somebody
retrieves
this
address?
B
They
know
that
they
can
still
use
it
in
an
ASCII,
only
email
system.
Otherwise
you
don't
want
them
to
think
that
they
have
to
reject
it
because
it's
a
non.
It's
in
a
non-ascii
email
address
element,
so
we
always
have
to
make
that
so
there's
a
lot
of
discussion
to
be
had
there
I
think
about
how
to
really
represent
this
and
how
much
we
want
to
say
and
and
what
the
right
order
is
and
how
it
has
to
be
used.
B
D
Okay,
thank
you.
Jim
I
put
myself
off
out
of
the
queue
because
I
wanted
to
make
some
some
final
questions.
But
if
there's
any
response
to
to
Jim's
story,
then
go
ahead.
John
your
next!
If
you
have
a
reaction
on
that.
H
Kim
I
think
this
is
really
really
small,
though
I
agree
with
you
that
Denise
come
back
from
work
text.
If
you
think
about
this
as
a
preferred,
not
ASCII
address
and
an
ASCII
address
fallback,
which
is
the
vocabulary
I've
been
using
since
this
discussion
started,
or
you
think
about
this
in
Pete's
language,
about
two
different
protocols,
but
with
a
preference
for
the
not
asking
address,
you
wouldn't
be
specifying
it
then
talking
about
this
gets
rather
easy.
H
Even
if
it's
limited
to
two
one
or
two
looks
like
the
hard
way
to
do
it,
because
it
involves
all
the
issues
that
you
just
raised.
L
Should
have
gotten
an
earlier
start,
this
is
Pete,
so
I
just
said
in
the
chat
room.
What
I
think
you
should
say
protocol
wise
is
that
if
you
implement
SMTP
utf-8
the
the,
if
you
implement
this
extension,
then
you
always
use
what's
in
the
field
right,
you
always
use
that
address.
Sometimes
that
address
might
be
identical
to
that
other
field,
which
is
the
ASCII
email
address.
L
Both
if
you
implement
the
new
stuff,
you've
got
two
fields
and
they
most
both
must
be
filled
in
don't
care
with
what
the
one
that's
the
internationalized
one
might
have
non-ascii
characters,
but
it
might
be
entirely
ASCII
characters.
If
you
only
implement
the
old
stuff,
then
you'll
have
one
field
and
it
will
be
the
ask
email
address
either
way.
You've
got
to
have
all
the
fields
filled
in
appropriately.
K
Thank
you,
I
won't
just
comment
about
the
context
of
the
contactability
I
agree
that
the
email
address
is
used
for
the
contact,
but
also
we
have
a
quite
limited
set
of
situation
when
this
address
is,
can
be
used
by
a
non-capable
beer
as
as
we
we
basically
have
three
participants
in
the
chain.
K
We
have
registered
Who
provided
non-ask
email
address
and
is
able
to
deal
with
it,
a
register
who
registered
that
client
and
should
either
be
able
to
deal
with
this
address
or
reject
the
registration
and
the
registry
that
normally
should
not
contact
with
the
registrant
or
using
any
address.
K
The
situation
becomes
more
difficult
in
several
cases,
for
example,
in
case
of
domain
transfer,
the
accepting
register
until
maybe
not
capable
to
deal
with
no
mask
address
but
well
I
think
that
it's
mostly
the
problem
of
resistance
business.
The
other
situation
that
is
more
difficult
is
the
case
of
oh
well,
registry
termination
or
register
termination
when
the
the
data
is
passed
to
to
a
new
companies
that
maybe
not
capable
to
deal
with
no
mask
addresses,
but
well
speaking,
frankly,
I
think
this
situation
is
quite
rare.
D
Thank
you
Dimitri,
as
you've
seen
with
close
queue
we
spent.
We
we
reserved
quite
some
time
for
this
discussion,
but
we
still
have
two
poor
presentation
so
next
for
reaction
John,
if
you
can
keep
it
short,
yeah.
H
I
will
try
first,
first,
first
of
all
what
I
said
in
the
chat
about
something
else
in
the
chat
earlier.
Is
this
transition
period
likely
to
be
forever?
It's
not
just
the
technical
problem,
it's
a
problem
with
language
and
with
local
mua
implementations
and
with
a
bunch
of
other
things,
and
as
long
as
the
working
group
continues
to
think
about
European
languages,
spaces
between
words
and
an
absence
of
not
breaking
characters
and
a
variety
of
other
things.
This
is
easy
and
the
point
you
start
thinking
about
it,
other
kinds
of
scripts,
very
different
inventions.
H
H
This
is
why
why
he's
talking
to
this
is
need
to
be
there
and,
in
addition,
why
you
need
to
think
about
less
just
what's
happening
in
this
particular
transaction
or
what's
happening
in
these
addresses
when
they
go
into
registry
databases
and
who
want
to
be
able
to
access
them
afterwards,
whether
voluntarily,
on
the
part
of
the
registry
side
or
involuntarily,
on
the
part
of
some
right,
sub-regulator
or
legal
side.
D
J
Okay,
sorry
I
looked
for
the
button
on
the
wrong
on
the
wrong
place.
We've
had
a
need
for
alternative
email
addresses
for
already
25
years
ago.
Specifically
when
the
email
address
ends
in
the
domain
name
itself
and
once
it
is
taken
down,
then
you
cannot
contact
the
the
party
so
wouldn't
that
be
good
opportunities,
you
just
be
totally
liberal
and
say:
there's
going
to
be
an
opportunity
to
put
more
than
one
email
address
and
not
care
about
distinctions.
Whether
this
is
UTF
SMTP.
D
Okay,
thank
you
Jim.
If
you're
gonna
go
back,
two
more
slides
and
I'm
gonna
have
some
final
questions
or
some
some
closing
questions,
because
that's
I
think
this
is
the
one
right.
D
So
the
the
question
now
is:
what
are
we
going
to
do
with
this
document?
This
is
basically
a
question
tomorrow,
Murray
because
I
think
that
James
agreed
that
some
of
the
changes
to
this
document
can
be
quite
material.
So
I
don't
know
if
we
need
to
how
the
process
works.
To
get
this
document
back
into
the
working
group
to
discuss
these
and
I
also
saw
that
James
said
that
you
know
the
create
command
and
the
update
command.
D
C
I
guess
I'll
take
input
from
you
about
how
big
the
Delta,
you
think
it
would
be.
If
it's
relatively
easy
to
settle
this,
you
can
just
leave
it
there
and
update
it
once
and
then
we
can
continue
it
from
there.
If
you
want
to
iterate
it
at
several
times,
I'll
just
return
it
to
the
working
group
and
we'll
do
a
an
abbreviated
last
call
the
next
time,
but
you
guys
can
like
you're
part
of
that
decision.
I
don't
have
to
tell
you
one
way
or
another:
okay.
B
So
I
would
say
that
Jim
Gould
has
already
indicated
he
has
a
a
revised
document
ready
to
go,
which
is
a
starting
point
discussion.
We
should
certainly
have
him
submit
that
get
that
published,
and
then
we
have
this
little
bit
of
nuance
about
when
when
we
require
both
or
not
requireable,
so
we'll
have
a
little
discussion,
we'll
see
what
that
turns
into
okay.
C
Okay,
I
I,
don't
want
to
sign
John
or
anyone
else
up
for
work
unnecessarily,
but
I
want
to
make
sure
that
that
they
get
those
like
it
gets
the
right
eyes
on
it.
So
right.
So,
if
you
want
need
me
to
help
coordinate
additional
external
feedback,
please
let
me
know:
okay,.
D
Thank
you
so
we're
just
this
all
right.
It's
close.
Thank
you
all
very
much
for
the
discussion
and
as
said,
we
will
continue
on
the
mailing
list
and
James
can
publish
a
new
version
of
the
document
to
start
that
discussion,
and
then
we
go
over
to
a
next
presentation,
which
is
by
Tom
Harrison
about
our
search.
D
I
So
this
is
a
fairly
short
document
that
defines
some
new
search
and
search
related
functionality
for
IP
ranges
and
asns.
The
first
part
is
sorry
searching
by
handling,
by
name
for
IPs
and
asns,
along
the
same
lines
as
for
domains
and
entities
in
the
existing
documents.
I
So
the
idea
here
is
that
an
RAR
that
implements
this
functionality,
in
conjunction
with
some
of
the
existing
extensions,
can
reach
feature
parity
with
the
who
is
server
and
that
helps
with
transitioning
people
offers
and
onto
art
app,
which
is
good
for
us,
and
it
also
can
help
with
potential
deprecation
of
whose
services
in
future
next
celebrity
foreign
just
shows.
The
requests
and
responses
for
the
searches
by
handling
name
are
pretty
straightforward.
I
The
only
real
difference
here
is
that
there
are
new
search
response
types
for
the
new
objects,
so
there
hasn't
been
an
IP
search
or
not
num
search
defined
before
so.
This
document
includes
that
content
next
slide.
Please
and
this
one
shows
how
the
link
relation
works,
so
there's
no
structure
defined
for
the
for
the
link
itself.
It's
entirely
up
to
the
server
and
the
response
is
the
same
as
for
a
search
for
the
relevant
objects.
Type
slide,
please
most
of
how
this
document
works
is
very
straightforward.
I
That
really
couldn't
work
in
another
way,
except
perhaps
for
the
link
relation
part.
So
the
reason
we
went
with
the
link
relation
here
it
keeps
the
interface
really
simple:
there
are
fewer
chances
for
things
to
go
wrong
for
clients
to
misinterpret
what
they're
getting
back.
It
means
we
don't
have
to
Define
behavior
in
error
codes
and
so
on.
I
So
that
was
the
first
reason
for
that,
and
then
the
second
reason,
which
falls
out
of
the
first
reason,
is
that,
because
there's
more
flexibility
on
the
server
side,
it
just
gives
the
server
options
as
to
how
to
handle
this,
so
one
server
might
do
inbound
searches.
Another
server
might
trade-off
disk
with
CPU
and
pre-generate
everything
ahead
of
time.
So
yeah
just
give
us
some
more
options
in
that
respect.
Next
slide,
please!
I
So
next
steps
we're
looking
to
get
this
adopted.
It
may
be
that
that
can't
happen
right
now,
because
there's
a
lot
of
stuff
in
train,
particularly
in
the
art
app
space,
so
you
can
put
that
on
input
on.
That
would
be
good.
We
need
to
get
input
from
the
various
sub-regional
Registries
that
do
add
up.
So
there
are
some
national
Registries
in
the
opening
region
and
in
the
laknik
region
that
do
this,
so
we
need
to
talk
to
them.
I
The
document
defines
an
idap
conformance
value
like
like
every
extension,
but
it
doesn't
actually
use
that
as
a
prefix
in
the
searches
and
the
reason
for
that
is,
it's
would
leave
these
searches
kind
of
misaligned
with
how
things
are
defined
in
the
core
documents.
You
don't
you'd
end
up
with
a
search
and
a
chord
document
like
slash
domains
for
for
a
domain
search,
but
if
a
prefix
were
used
here,
then
it
would
be
slash.
I
Rir
search,
underscore
IPS,
so
it's
a
little
bit
clunky,
but
the
existing
requirements
in
this
space
mean
that
we
really
should
have
a
prefix
there.
So
we
need
to
think
about
how
this
can
be
handled
if
at
all-
and
we
did
an
implementation
of
this
at
opening-
pretty
simple
all
seems
to
work
as
expected,
but
more
implementations
would
be
good.
D
I,
don't
see
anybody
in
the
queue
yeah.
Thank
you
Tom,
but
you're.
So
your
intent
is
to
get
this
adopted.
We
will
work
for
the
world
on
the
mailing
list,
I
presume
and
ask
for
for
some
more
review.
Okay,
so
yeah
so.
I
Oh
yeah,
that's
just
for
the
most
in
this,
so
we
probably
should
put
some
text
in
there
just
to
say
that
it's
not
intended
for
use
with
with
non-reverse
domains.
I
suppose
it
could
be
used
for
normal
domains,
but
yeah.
It
might
be
better
just
to
put
that
out.
M
All
right
and
I
I
support
the
adoption
of
this
of
this
work,
because
I
think
it's
it's
needed.
So
thank
you.
G
Hello,
adapt
for
space
objects
next
next
slide,
please
so
so
I've
been
involved
with
networking
space
and,
as
you
may
know,.
H
G
Getting
more
and
more
networks
in
space
and
spacecrafts
and
all
kind
of
stuff,
those
objects
in
networks
are
actually
owned
by
entities
of
locations
of
identity
or
network
address.
G
There
might
be,
there
will
be
IP
based
networks,
as
well
as
the
other
protocol.
That
is.
C
G
G
So
in
the
context
of
offering
access
an
access
protocol
to
those
objects
that
are
registered
to
owners,
the
requirements
were
essentially
99
in
line
with
the
requirements
of
rdap,
including
rest,
API,
Downstream
registries.
You
know,
objects
pointing
to
others,
and
also
things
that
are
being
discussed
in
the
currently,
which
is
authenticated
of
oops
authenticated
access
to
some
data.
G
Some
objects
redacting
some
Fields.
All
this
stuff
is
exactly
the
same
and
actually
rdap.
Space
object.
Server
will
eventually
Also
Serve
rdap
internet
objects,
for
example,
as
I
said,
there
will
be
IP
addresses
that
will
be
used
in
space
and
therefore
the
same
rdap
server
may
be
also
offering
that
information.
G
G
So
the
next
slides
are
just
examples
to
show
you.
You
know
what
it
could
be:
I
actually
used
to
create
a
prefix
in
the
path
for
the
queries
just
to
not
have
any
namespace
Collision
in
the
future.
But
you
know
that's
a
detail
next,
so
poor,
you
know
good
or
bad.
All
objects
have
been
identified
using
an
object
ID
from
the
official
ISO
oid
tree,
so
any
object.
For
example.
These
are
actually
you
know
real.
G
You
know,
objects
number
or
object
IDs
that
number
the
first
one
actually
is
the
ID
of
the
NASA
Mars
in
a
sense,
Arbiter
spacecraft
and
the
other
one
is
the
range
of
bundle
protocol,
node
numbers
for
NASA
Goddard.
So
you
know
these
are
real
numbers.
Next.
G
G
So
that's
an
example
of
a
range
very
similar
to
what
we
do
with
IP
addresses
next
slide.
Given
time
Json
responses.
Since
we
started
from
scratch,
we
preferred
to
use
GS
contact.
G
And
two
examples:
service,
site
and
aperture,
and
these
the
current
examples
are
actually
not
clean
in
terms
of
final
because
you
know
naming
is
actually
dumped
from
the
real
database,
so
you
get
it
in
that
sense,
but
as
ND
was
pointing
out
on
the
mailing
list,
you
know
these
should
be
cleaning
up
property
names.
Next.
G
G
M
G
Slide
so
before
you
start
usually
the
usual
question,
so
this
has
been
discussed
a
bit
in
within
the
space
community
and
one
of
the
question
was
transport.
Are
we
doing?
Are
that
queries
over?
You
know
a
link,
you
know
through
Mars
or
something
yeah,
maybe
maybe
not,
but
that
doesn't
matter.
The
fact
that
you're
querying
for
information
about
an
object
is
doesn't
mean
that
you
need
to
do
this
in
space
that
we
will
need
to
do
some
finding
automative
servers.
G
There
for
the
oid
bootstraps
registry,
maybe
others
next
slide
and
I-
think
I'm
done
so
question
to
the
group
is.
This
is
very,
very
similar.
You
know
examples
where
presented
any
interest
in
regex
I
think
it
would
be
very
viable
to
be
here,
probably
not
the
same.
You
know
lower
priority
than
others,
given
that
space
networks
are
deployed
slowly,
that's
it.
G
D
So
you
know
we
had
a
little
hallway
discussion
already
Mark
about
this,
and,
and
you
know
the
Epp
and
the
art
up
protocol
are
supposed
to
work
for
any
registry
with
I
think
in
our
Charter.
It
has
one
limitation
and
that
it
is
for
internet
identifier
objects,
but
anybody,
of
course,
is
free
to
use
the
provisioning
protocol
and
the
the
data
access
protocol
for
any
needs
that
they
need.
So
is
your
question.
Basically,
would
this
be
work?
G
I
think
it
is
valuable
that
that
regex
at
least
review
even
better
if
we'd
be
adopted,
but
you
know
it's
up
to
the
working
group.
Obviously,
and
I
would
punt
that
you
said
on
the
internet,
right,
the
internet
and
the
fire
well,
I
would
find
that
space.
Networking
is
actually
just
an
extension
of
the
internet
and
soon
we
should
be
the
same
yeah.
D
If
not,
then
thank
you
Mark
and
we're
looking
forward
to
having
that
discussion
in
on
the
mailing
list,
and
that
brings
us
to
our
next
and
last
item,
which
is
any
other
business.
A
Gavin
Brown
is
working
on
a
proposal
to
add
TTL
data
into
requests
from
registrars
to
Registries
I'll
probably
be
putting
my
foot
into
that.
If
people
are
interested
in
working
on
that
and
maybe
have
seen,
my
presentations
to
oark
and
I
can
I
encourage
participation
in
thinking
about
how
to
make
it
safer
to
roll
back
changes
that
are
regretted
whether
they're
DNS,
like
specifically
or
perhaps
not
even.
D
Okay,
thank
you
Victor.
So
if
you
have
anything
new
to
present,
you
know
send
it
to
the
list
and
if
you
get
any
positive
feedback,
then
ask
for
working
group
adoption,
that's
the
process
that
we
usually
take
right.