►
From YouTube: IETF115-EMAILCORE-20221110-1530
Description
EMAILCORE meeting session at IETF115
2022/11/10 1530
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
A
Good
afternoon
John,
do
you
hear
me
John
cleansing.
A
And
Todd,
yes,
I
hear
you:
okay,
fine,
all
right!
Okay,
let's
get
started
as
this
is
email
core
in
preparation
for
this
section.
I
think
she
has
realized
that
we
probably
can
use
couple
of
hours.
We
only
have
one
we'll
try
to
do
as
much
work
as
we
can
certain
issues.
If
we
are
making
progress,
we
might
spend
a
bit
more
time
on
them
and
then
we'll
take
the
rest
to
the
mailing
list.
A
John
cleansing
suggested
that
we
might
want
to
do
an
interim
in
you
know
next
month
or
so
I
think
I
put
you
know.
Obviously
we
need
to
agree
whether
this
is
a
good
idea,
but
this
sounds
like
a
reasonable
thing
to
me
and
let's
get
started.
A
A
Be
nice
to
each
other,
we
kind
of
have
a
note
taker
for
part
of
the
meeting,
but
thank
you
Ken,
but
if
we
get
to
the
applicability
statement
somebody
will
need
to
take
notes
then
can
somebody.
A
Yes,
please
log
in
into
metako,
if
you
can,
if
you
are
in
the
room,
please
use
masks
unless
you're
presenting
at
the
mic.
A
A
A
Okay,
so
very
quickly.
A
Pete
posted
a
new
version
of
53
22
bits.
He
did
a
change
in
response
to
rata,
about
obsolete
time
zones.
A
A
B
There
are
definitions
for
Trace
that
occur
in
both
5321
and
5322,
and
let's
be
clear,
there
are
three
different
things
we're
talking
about.
There
are
things
that
are
named
slightly
differently,
Trace
in
the
ABN
f.
There
are
things
that
different
documents
call
Trace
headers
like
an
adjective,
and
then
there
are
things
that
get
stuck
on
top
of
messages
as
they're,
going
through
transport
and
other
systems,
and
those
may
or
may
not
be
Trace,
so
that
that's
sort
of
the
setup
for
what's
going
on
here.
B
So
5322
currently
defines
a
very
general
Syntax
for
their
seed
field
and
points
to
5321
and
says:
go
see
there
for
what
the
exact
syntax
is
and
and
and
stops,
and
then
5321
has
a
much
more
restrictive
syntax.
Okay,.
A
B
One
thing
about
the
5322
syntax,
which
was
mentioned
on
the
list:
is
it's
really
General,
so
you
could
generate
from
it
things
that
definitely
do
not
conform
to
5321
in
any
way
shape
or
form,
including
particularly
things
that
have
one
of
those
receive
tokens
and
not
a
pair.
So
you
could
come
up
with
an
odd
number,
which
is
definitely
what
button
in
5321,
but
it
does
limit
the
syntax
somewhat.
B
And
so
the
question
is:
is
that
limit?
Well,
we
can
go
on
to
the
next
slide
and
you
can
see
what
the
differences
here
are
but
go
on
to
the
next
slide.
So.
B
There's
the
5321
question
about
whether
the
attributes
are
ordered
the
way
they
are
currently
specified
in
the
a
b
and
F
we've
got
the
5322
question
about
whether
we
need
to
be
more
specific
and
make
it
pairs
in
the
ABN
F
or
make
it
even
more
General
and
make
it
just
unstructured
stuff
and
the
definition
is
elsewhere
and
or
possibly
should
there
just
be
one
a
b
and
F
definition,
and
then
the
other
document
likely
5322
says,
go,
look
there
for
the
definition.
We
don't
even
bother
specifying
it
here.
B
So
here
are
some
possible
choices.
Just
to
give
you
lots
of
fun.
So
number
one
is
exactly
what
5322
does
at
the
moment,
which
is
one
star
receive
token
receive
token
includes
word,
which
includes
Adam,
which
allows
you
to
do
atom,
followed
by
the
value
atom,
followed
by
the
value
atom,
followed
by
value,
but
allows
for
an
odd
number
of
them.
A
And
just
a
quick
clarification,
the
you
know,
it's
typically
atom
include
Ford
white
comments,
so
there
are
spaces
automatically
between
tokens,
so
don't
be
alerted
yeah.
It's
kind
of
the
way
the
gram
is
written,
which
is
also
slightly
curious,
but
yeah.
Just
the.
B
Way
it
is
okay.
Number
three
is
the
same
as
number
one,
so
no
change
to
the
syntax,
but
put
a
comment
in
specifically
pointing
over
to
the
53
21
I
think
it
should
say
syntax.
That
was
a
typo.
Sorry
about
that
number.
Four,
yes,
sorry
is
basically
move
the
5321
syntax
entirely
into
5322.
A
Well:
okay,
that
wasn't
quite
what
I
intended.
What
I
intended
is
well
move
a
copy
and
because
opt
info
includes
all
the
extension
Fields.
Then
basically,
extensibility
is
explicit.
B
A
Let
me
actually
be
late
in
the
queue
and
John
John
John.
Yes,.
C
I
think
we
should
give
up
and
do
number
six,
because
my
experience
which
I've
been
you
know,
which
is
just
mine,
is
that
received
headers
fall
into
two
general
categories.
One
is
people
who
read
the
spec
and
they
match
5321
pretty
well,
and
the
other
is
organizations
such
as
those
in
Redmond
Washington
they
put
in
random
crap,
and
if
we
want
to
describe
reality,
six
is
basically
it
I
mean.
If
we
want
to
encourage
people
to
to
follow
the
rules
we
can,
but
after
50
years,
I
think
they're
going
to
do
what
they
do.
D
Another
argument
for
six
is
that,
if
we're
seeing
fields
are
inserted
by
not
SMTP
transports,
there
is
no
guarantee
that
they
are
going
to
use
the
stuff
semicolon
date,
time,
syntax
that
we're
now
specifying
in
both
documents
and
and
not
only
the
semicolon
date
time,
but
the
precise
date
time
version
that
we're
specifying
in
both
documents,
which
is
inconsistent
with
date
times.
These
are
being
specified
elsewhere,
like
in
sedation.
D
This
is
like
that
and
that's
again,
a
strong
argument
for
for
number
six
I
think
I
have
very
mixed
feelings
about
all
of
this,
which
really
complicates
place.
Nice.
A
A
All
registered
attributes
have
values,
I
think
probably
not
having.
This
is
going
to
break
some
stuff,
maybe
as
a
possible
thing
to
help
us
out.
If
we
decide
to
investigate
this,
I
can
probably
write
a
parsa
and
run.
You
know,
digest
a
big
mailing
list
and
see
if
existing
received
headers
satisfy
the
pair
requirements
if
I
get
any
errors,
but
obviously
I
cannot
do
this
information
on
the
spot.
B
E
B
B
Section:
yeah,
okay,
so
speaking
for
myself,
one
and
three
are
my
personal
favorites
only
because
my
gut
has
always
been
least
change.
I
would
hate
for
us
to
change
something
in
this
document
and
have
it
screw
up
some
implementation
down
the
road
that
attempts
to
change
things.
B
D
D
If
we
do,
something
which
looks
more
restrictive
than
the
current
text
looks
as
this
thing
for
me
is
then
I
fully
agree
with
your
concern,
but
if
we
put
something
in
there,
which
says
completely
unstructured
as
far
as
this
document
is
concerned,
goes
to
the
other
document,
if
you're
looking
for
some
additional
syntax,
which
is
what
six
does
or
an
appropriate
paragraph
which
says
this
stuff
is
really
covered
by
the
density,
go
look
at
5321
bits,
which
is
what
Ken
suggest
and
what
I
suggested
some
months
some
weeks
earlier,
then
I,
don't
think,
there's
a
problem
with
somebody
looking
at
it
and
saying:
aha,
this
has
become
more
restrictive.
D
We
have
to
run
off
and
start
rejecting
valid
Fields,
and
indeed
that's
my
concern
about
even
leaving
the
semicolon
date
time
again,
because
if
you're
worried
about
people
rejecting
ballot
Fields,
then
the
validity
of
that
field
becomes
an
issue
where
things
which
we
would
consider
perfectly
reasonable.
Don't
fail
the
test.
B
If
there
is
Legacy
code
out
there
expecting
a
53-22
date
time,
and
we
loosen
this
structure,
then
what
you've
done
is
increase
the
likelihood
that
some
piece
of
code
is
going
to
blow
up
by
saying
completely
unstructured,
and
maybe
we
think
the
chances
of
that
are
low.
But
the
the
you
know
the
whole
principle
here
was
moving
to
full
standard,
and
my
gut
is
that
that
means
don't
change
things
that
we
haven't
seen
as
currently
causing
a
problem.
B
That
seems
less
likely
to
cause
harm.
Even
though
I
I
mean
you
know,
I
agree
there
there's
something
very
attractive
about
sex,
there's
something
very
attractive
about
too.
As
far
as
I'm
concerned.
D
D
I
I
understand
that
and
my
difficulty
is
that
I
am
having
trouble
figuring
out.
Why?
If
what
we're
worried
about
here
is
rejection
from
some
specials
from
some
of
this
code
that
follow
the
specification
carefully
earlier
and
and
now
we
relax
the
rules
and
they
get
confused
and
start
rejecting
things
which
they
would
have
accepted
before
no.
B
No,
no,
no,
the
opposite,
the
opposite
I.
What
I'm
worried
about
is
we've
got
something
as
As
an
interpreter
as
a
reader
of
messages
that
conforms
to
the
current
rules,
and
now
we
have
a
piece
of
software
that,
because
we
relax,
the
rules
starts
generating
lots
and
lots
of
messages
that
do
not
conform
to
the
old
rules.
And
now
we
have
increased
likelihood
that
those
messages
will
get
through
to
things
that
will
be
broken.
D
D
D
and
so
again,
if,
if
you're,
if
the
concern
is
the
putting
in
six,
would
make
this
less
restrictive
and
therefore
cause
problems,
I
don't
see
it
if,
if
the
purpose
of
having
this
stuff
in
5322
at
all
is
to
is
to
Define
and
accept
syntax
in
a
parsing
Syntax
for
something
which
your
text
already
says,
they're
not
supposed
to
pay
any
attention
to
Sprint
yourself.
D
B
So,
rather
than
have
the
two
document
authors
up
here,
going
back
and
forth,
does
anybody
else
want
to
see
if
they
can
unlock
this.
A
F
I'll
say
I'm
I'm,
with
Pete
on
the
minimal
change
ambivalent
between
one
and
three,
but
maybe
the
reference
is
good.
So
three
but
yeah
I
I,
understand
John's
concern
but
I
think
minimal
change,
especially
in
the
grammar,
is
important.
B
E
This
is
Kent,
having
advocated
for
the
reference
back
to
21,
which
may
not
be
realistic.
I
also
agree
with
Pete
that
minimal
change
in
22
I
think
will
be
the
least
disruptive.
A
B
I'm
happy
to
put
in
AC,
for
example,
instead
of
C.
A
B
B
F
We'll
go
and
we'll
get
John
when
he
comes
back.
How
often
does
in
the
real
world
do
we
actually
see
received
lines
put
in
by
transports
other
than
smtps
such
that
we
should
jump
through
hoops
I.
F
F
B
B
D
Sorry
for
first
answer
to
Barry's
question
is
20
years
ago.
Definitely
now
I'm,
not
sure
if
we've
got
that
stuff
being
put
in
and
if
John
Levine
has
an
example,
then
that's
definitive
are
all
of
them.
Actually
following
the
syntax,
including
the
date
time
in
RMC,
5322
form.
D
Then,
if
the
goal
is
to
avoid
breaking
existing
implementations
or
the
next
implementation
to
come
along,
that's
an
argument
for
reducing
the
syntax
in
the
direction
of
unstructured.
Even
though
it's
not
an
argument,
necessarily
if
you're
going
all
the
way
to
unstructured
I,
don't
know
where
we're
going.
D
If
we
do
what
other
thing
which
does
not
affect
the
syntax,
which
indicates
a
careful
look
at
the
paragraph,
exposed
this
and
attempts
to
say
well,
don't
really
look
here,
look
at
5321
or
look
somewhere
else,
because
that
paragraph
is
very
hard
to
follow
unless
one
knows
what
it's
supposed
to,
what
is
intended
to
mean
so
I
would
be
happy
to
work
with
you
on
that
paragraph
if
we
stay
with
the
existing
more
or
less
with
the
existing
syntax,
but
I
think
stay
with
the
existing
syntax,
Without
Really
touring
up
that
paragraph
on
your
mistake.
D
B
That
that's
fair
enough,
so
here.
B
Paragraph,
the
yes
that
paragraph
that.
B
So
but
I
I
think
your
answer
is
reasonable,
insofar
as
what
we
do
is
if
we're
going
to
go
that
path.
The
two
of
us
work
on
this
paragraph.
B
We
make
a
proposal
to
the
working
group
and
if
we
can't
come
to
consensus
on
this
paragraph,
then
we
have
to
go
back
and
figure
out
whether
there's
consensus
on
the
syntax.
I
I
mean
this.
This
is
not
making
life
Pleasant
for
the
chairs
and
and
I'm
sorry,
but
at
some
point,
you're
gonna
have
to
call
this
consensus
rough
because
it's
gonna
be
rough
one
where
the
other.
F
B
B
I
think
so,
and
and
you're
gonna
have
to
determine
how
weak
that
support
is
and
or
how
strong
that
support
is
once
the
once
the
paragraph
comes
out,
but
yeah
I
think
that's
that's
what
we're
proposing
at
this
point.
D
Yeah
I
I'm
I'm
very
unhappy
about
this
and
we'll
do
a
lot
of
nose
holding
while
we're
working
on
it,
but
but
in
a
sense
this
problem
should
have
been
solved
with
in
in
yam
and
if
we
didn't
get
to
it,
then
Pete's
argument
has
some
Merit,
despite
the
fact
that
I
don't
like
its
implications.
B
A
B
So
the
question
is:
do
we
make
a
registry
if
we
do?
How
does
it
interact
with
the
existing
registry
of
message?
Header
Fields?
Do
we
have
a
separate
registry,
or
do
we
somehow
combine
them?
Do
we
want
to
add
a
discussion
of
any
sort
about
Trace
header
Fields
as
comments
in
the
current
registry?
B
Do
we
want
to
just
do
nothing
and
keep
everything
the
way
it
is
and
again
for
purposes
of
discussion,
I'll
remind
everybody
that
we
tend
to
Mush
together
things
which
meet
the
syntax
of
trace
a
b
and
F
element,
things
that
are
stuff
that
gets
stuck
on
the
top
messages,
as
it
goes
through
the
system
and
things
that
happen
to
be
called
trace
and
are
dealt
with
semantically
by
ignore
this
stuff.
Unless
you
know,
if
you're
parsing
messages,
this
is
for
information,
only
don't
act
on
it
in
any
particular
way.
A
The
transport
system,
and
it
it
applies
to
msas,
mtas
mdas
everything
right
before
we
get
the
discussion.
I
did
talk
to
Graham
about
registry
and
about
the
question
on
whether
it
will
be
a
good
idea
to
remove
any
fields
from
it
and
put
it
into
a
separate
registry.
A
B
B
F
Is
Barry
so
the,
but
that
covered
some
of
what
I
was
going
to
say.
The
first
thing
I
was
going
to
say
is
that
if
we
have
a
separate
registry,
we
must
leave
these
in
the
existing
registry
and
the
definition
of
the
new
registry
has
to
say
that
nothing
can
go
in
here
unless
it's
already
in
the
other
one.
F
But
the
other
thing
that
that
Alexei
said
was
what
I
was
going
to
suggest.
God
I
hope
not
that
we
don't
need
another
registry.
I
would
rather
have
information
in
the
existing
registry.
That
says
this
is
one
of
those
things
and
whether
that
be
a
column
for
it
is
or
it
isn't,
or
whether
it
be
a
description
that
that
just
verbally
tells
us
or
whatever
it
is
that
that's
the
way,
I
think
we
should
go.
A
F
A
C
Yeah
I'm
going
to
agree
with
Barry
in
substance,
but
I'm
going
to
tweak
the
emphasis,
which
is
no
registry,
no
new
registry.
No,
no,
no,
no,
no
I,
think
adding
a
new
column,
adding
a
column
to
the
existing
Registries
would
be
straightforward,
and
then
we
can
bike
about
what
goes
in
the
column,
and
my
inclination
would
be
blank
by
default.
Yes,
if
it's
a
normal
one
or
a
footnote,
if,
if
people
do
do
weird
things
with
it,.
A
Okay,
who's.
Next
me
speaking
as
a
participant,
I
I
think
I
prefer
a
new
registry
because
it's
it's
kind
of
easy
to
find
if
you're,
only
looking
for
these.
The
reason
why
a
while,
like
this
is
because,
for
somebody
writing
MUA,
there
is
a
common
function
for
edit
existing
message
as
new
message,
and
this
function
typically
requires
stripping
all
Trace
header
Fields,
because
for
security
reasons,
so
for
to
implement
this
I
kind
of
would
like
to
have
this
information
somewhere.
A
I,
don't
mind
if
it's
an
extra
column,
existing
registry
or
a
comment.
So
I
would
like
to
have
this
information.
You
know
kind
of
available
about
the
three
choices.
D
First
of
all,
I
I'm
sorry
I
pose.
This
is
a
question
because
I
don't
have
an
answer
or
strong
preferences,
except
to
say
that
if
we
are
going
to
single
out
Trace
fields
from
other
kinds
of
extension,
Fields
with
syntax
rules
somewhere,
then
we
or
or
with
rules
about
what
goes
at
the
top-
that
we
better
be
able
to
identify
Trace
fields
in
the
registry.
D
Now
whether
that
means
two
Registries
one
registry
with
comments,
two
Registries
with
pointers
to
each
other
and
which
way
the
pointers
should
go
I'm
almost
completely
agnostic,
I
just
want
to
be
sure.
They've
traced,
Trace
fields
and
extension
Trace
fields
are
different
from
extension
fields
that
we
have
a
clear
way
to
identify
that
from
the
Registries
or
whatever
documentation
we
require.
But
since
that
header
field
registry
is
if
I
recall,
first
come
first
serve,
we
don't
require
any
documentation.
This
has
been
registered.
E
Hi,
this
is
Ken
I
just
want
to
plus
one
with
John,
Levine
and
Barry
said
no
new
registry
new
column.
Please.
B
So
editor
hat
off
for
sure,
but
I
have
a
question
which
is
what
are
the
semantics
of
this
column,
going
to
be
because,
as
I
tried
to
harp
on
before,
there
is
a
big
distinction
between
thing
introduced
by
the
transport
system
thing
introduced
by,
for
instance,
a
Spam
checking
engine
and
thing
that
happens
to
be
added,
showing
some
action
with
this
message,
whether
or
not
it
was
so
a
submission
and
or
delivery,
and
this
happened
to
end
up
up
here
at
the
top
of
the
message
which
we
clearly
know
are
not
Trace
fields.
B
What
are
the
semantics
of
being
in
this
column?
Are
they
trace,
as
in
mtas,
are
only
allowed
to
do
this.
A
We
had
a
long
discussion
over
a
year
and
a
half
include
when
Ned
was
still
around
about
definition
of
a
trace
header
fields
as
a
semantic
of
it.
This
is
what,
in
the
current
draft,
I,
would
like
not
to
reopen
this
discussion.
I
agree
and
the
question
I
asked
earlier
was
assuming
that
definition.
This
is
what
the
registry
is
for.
So
if
you
want
to
register
other
Hydra
fields
which
are
not
Trace,
they
will
well,
they
will
still
go
to
message
how
they
feel
names
registry
anyway,
but
they
will
have
nothing
in
this
column.
B
B
B
B
D
Your
syntax
may
want
to-
and
if
this
has
been
said
on
the
list,
that
your
syntax
may
want
to
drop
the
attempt
at
distinguishing
in
the
ABN
app
between
Trace
fields
and
other
things
that
we
do
that
in
Pros,
because
the
what
goes
to
the
top
stuff
is
getting
very,
very
confusing
in
the
ABN
F
it's
hard
to
follow
and-
and
it's
not,
and
it's
not
clear,
given
other
stuff
which
goes
at
the
beginning,
which
is
not
what
an
irrational
person
would
call
a
trace
field.
It's
not
really
helpful
anymore.
B
B
D
B
All
right,
I
think
I
have
my
marching
orders
for
what
I
need
to
do.
The
registry
thing
ain't
my
problem,
but
I'm
comfortable
with
understanding
what
tasks
I
have
for
5322
well,.
A
A
A
Fun
Okay
so
we're
way
over
our
you
know
time
allocated
for
this.
So
what
we'll
do
is
Johnny.
You
quickly
talk
about
recent
changes.
Then
we
try
to
talk
about.
Are
they
under
Registries,
because
hopefully
it's
not
too
difficult.
Well,
I'll
just
keep
my
all
my
fingers
crossed.
You
know
because
I
can
never
know
now
and
then,
if
we
get
time
to
talk
about
SMTP
extensions
again,
we'll
try
to
do
that
after
that,
I
suspect
we'll
run
out
of
time.
D
Okay,
let
let
me
try
to
go
through
this
slide
almost
instantly
by
saying
that
we
aren't
going
to
have
time
to
discuss
any
of
these
issues
today.
I,
don't
think
we're
going
to
need
to
discuss
any
of
these
issues
today,
but
I
wanted
to
call
people's
attention
to
them,
because
if
they
do
have
problems
or
objections,
we
should
hear
about
them
quickly
on
the
mailing
list
or
or
if
necessary,
to
get
that
interim
scheduled
real
quickly
and
do
it.
Then.
D
The
only
thing
here
which
has
not
been
talked
about
extensively
is
a
arbitrary
small
group
decision
that
we
were
getting
ourselves
into
a
hole
if
a
server
was
unavailable,
but
only
temporarily
and
if
whoever's
was
responding
is
a
TP
connection
was
able
to
respond
to
that
connection
and
whether
one
could
rationally
use
a
code
there
and
if
so,
what
the
code
should
be
and
if
we
start
inventing
new
codes
at
this
stage,
we're
going
down
a
serious
Rat
Hole.
D
So
the
arbitrary
decision
was
to
repurpose
450,
if
used
in
that
context,
to
mean
server
temporarily
unavailable
mailbox
temporarily
unveiled.
But
those
are
the
only
new
issues
here
and
it's
all
covered
in
much
more
detail
in
the
in
the
relevant
appendix
to
5321,
Biz,
15
and
I
would
encourage
people
who
haven't
read
that
to
do
it.
A
Yeah
and
speaking
as
individual
about
450
and
server
temporarily
unavailable
I
think
it's
very
much
in
the
spirit
of
definition
of
the
reply
code
so
I
as
far
as
I'm
concerned.
It
seems
very
sensible
change,
but
obviously
again,
if
you
agree
with
this
or
if
you
disagree-
send
the
email
to
the
mailing
list.
A
If
you're
agreeing
that
you
know
your
silence
will
be
considered
as
consent
right,
so
John
did
quite
quite
a
good
job
on
SMTP
extensions
to
which
we'll
hopefully
get
to
today,
but
he
also
identified
that
mod.
We
have
three
other
registries
that
have
now
subsections
and
after
looking
into
this
in
more
details,
it
looks
like
they
don't.
Actually,
you
know
be
very
exact
about
the
ion
registration
procedure
for
them
so
are
just
literal
tags.
A
A
Yeah
so
I
think
you're
basically
saying
it
should
be
standard
section.
I
think
these
are
rare
enough
that
if
somebody
you
know
creates
a
new
underlying
protocol
will
need
to
think
about
it.
We'll
need
an
RFC,
so
standard
section
right.
A
Right
so
I
think
my
suggestion
here
is
that
the
text
still
needs
to
be
clarified.
Request
standardization,
you
know
by
specifying
you
know,
I,
you
know
standard
strike,
RFC
kind
of
thing
so
just
make
it
explicit.
What
exact
registration
passage
is
any
comments
on
this
any
objections.
A
Obviously,
we'll
still
need
to
verify
it
on
the
mailing
list,
but
I'm
just
kind
of
trying
to
get
the
sense
in
the
room
right.
Next,
one
is
male
transmission
types
for
Via
and
with
clauses,
and
the
current
text
is
says
only
by
standardization
or
by
way
of
rxc,
documented
isg,
approved,
experimental
protocol
extension
again.
I
think
it's
not
actually
using
the
most
modern
Ayana
registration
procedure
language.
A
F
Yeah
I,
if
you
want
to
go
with
BCP
26
current
BCP
26
language,
then
the
right
thing
to
do
is
to
say
not.
Standards,
action,
but
ietf,
review
I
think
is
what
it's
called.
Yes.
F
Yeah
there
is
ietf
review
that
that
allows
theoretically
allows
informational
or
BCPS,
but
in
practice
it's
you
know,
nobody's
going
to
write
that
as
informational.
So
if
you
want
to
explicitly,
you
can
say,
I
ietf
review,
but
not
informational.
If
you
want
to
go
there
but
I,
don't
think
we
need
to
yeah.
A
A
A
D
A
Additional
registered
Clauses
that
that's
basically,
what
new
attributes
going
to
receive
credit
field
and
again
it
kind
of
the
text
is
slightly
confusing.
It
says
standard
stuck
in
one
place,
then
mention
experimental
again.
A
I
suggest
we
probably
want
to
just
say
ITF
review
and
it's
also
keeping
consistency
between
three
Registries,
probably
a
good
idea,
any
objections.
So
any
arguments
for
doing
something
else.
A
Okay,
well
I.
A
I,
don't
think
we
I
personally,
don't
think
we
care
enough
here
in
the
working
group
and
when
you
have
experimental
you
might
as
well
allow
information,
especially
if
it's
documenting
something
which
is
in
use.
So
you
know
it's
kind
of
okay,
all
right
and
now
for
the
final
12
minutes,
everybody
wake
up,
do
a
little
bit
of
exercises.
A
F
F
A
Let
me
try
to
rephrase
it
for
for
the
audience
who
haven't
seen
the
message
and
then
John
you
can
tell
me
whether
I'm,
right
or
wrong
I
think
basically
proposal
is
to
use
something
like
URI
registry,
which
has
a
permanent
registration
that
requires
full
template
and
more
strict
procedure
and
provisional
registration.
That
requires
very
many
work.
D
It
is
I
I
would
prefer
that
we
get
rid
of
the
word
provisional
and
yes
and
find
the
term
was
more
closely
approximates.
We
wanted
to
register
this
name,
but
we
don't
have
any
interest
in
pursuing
the
studio.
Itf
Israel
has
the
implication
of
the
two-step
process.
This
is
really
not
a
two-step
process.
D
This
is
a
some
people
care
about
what
the
ietf
thinks
and
want
that
recognition
and
others
don't
and
we
just
separate
them
and-
and
that
should
allow
us
to
to
move
forward
and
move
forward
with
the
with
the
fcfs
rule
on
the
on
the
on
the
I.
Don't
care
about
the
iatf
stuff,
which
is
much
better
than
trying
to
screw
around
with
redefining
specification
required.
So
it's
almost
for
his
first
come
first
service,
quite
which
is
where
I
think
we've
been
going
around
in
circles.
F
Yeah,
so
how
about?
If
we
call
one
section
reviewed
by
the
ietf
and
the
other
section
other
registrations,
or
something
like
that.
D
I
I
think
that's
the
right
direction.
I
would
be
delighted
if
Alexi
were
to
just
to
to
assign
you
and
I
to
be
a
small,
commit.
You
sort
that
out
or
they're
trying
to.
D
F
A
That
and
speaking
as
a
participant,
I
actually
I
quite
like
this
direction
as
well
that
that
works
as
well.
I
I
was
thinking
about.
Some
of
my
questions
were
about
registrations
for
extensions
defined
in
rfcs
and
I.
Think
that
kind
of
addresses
addresses.
It
is
it's
nicely
and
you
will
do.
You
will
need
to
update
the
document,
but
I
think
some
of
the
work
you've
done
will
still
be
useful,
so
you
don't
have
to
actually
go
back
to
the
previous
version
and
restart
I.
D
Well
that
that
that
was
my
remaining
question.
What
I
did
with
with
Dash
15
was
slightly
at
14,
but
entirely
in
15
was
to
was
to
pull
all
of
the
text.
Also,
the
text
recommending
that
people
really
should
ask
for
advice
and
listen
to
it
or
get
advice
and
listen
to
it
out
of
the
Ianna
stuff
and
into
2.2.2,
and
unless
somebody
objects,
I'm
inclined
to
leave
that
there,
because
asking
for
advice
is
still
a
good
idea.
D
To
adjust
that
by
saying
there
that
if
they
go
through
the
standards
through
the
ietf
procedures
that
they're
getting
that
advice,
whether
they
like
it
or
not,
but
I,
don't
want
to
go
off.
I'll
pull
out
all
the
text.
A
Some
of
the
other
ones
might
be
knit
I.
Think
I
noticed
that
in
your
text
we
probably
should
say
that
registration
that
done
in
proposed
standards
should
have
it
as
a
change
controller,
that's
kind
of
very
standard
for
other
registers,
so.
F
D
Well,
I
I
think.
The
quick
answer
is
that
most
of
this
is
going
to
be
solved
in
a
fairly
automatic
Way
by
sweating,
this
registry
in
half
and
and
and
other
than
that,
I'm
more
than
happy
to
take
Barry's
suggestion.
A
Yes,
okay,
we'll
have
five
minutes
for
and
we'll
let
cam
just
quickly
tell
us
what
the
recent
changes
are
to
a
lot
of
people
of
things
they
might
not
have
been
fully
paying
attention
to,
but.
E
Yeah
so
briefly,
John
and
I
crafted
some
new
text
for
the
introduction.
The
the
introduction
that
was
there
was
more
of
a
placeholder
than
an
actual
introduction
to
what
the
the
current
draft
is.
E
So
please
take
a
look
at
that:
I
added
a
very,
very
minimal
security
sections
section
just
to
get
people
to
focus
on
it
and
bash
and
help
add
text
where
needed,
issue
51,
that's
kind
of
been
split
into
the
HTML,
specific
stuff
and
more
General
stuff
and
very
graciously,
provided
me
with
a
bunch
of
texts
for
the
general
stuff,
mostly
case
sensitivity
and
stuff.
So
thank
you
for
that.
E
Barry
added
a
little
bit
of
text
that
was
posted
on
issue
55
and
used
to
the
four
claws
again.
It's
there
for
bashing.
If
you
are
so
inclined,
please
provide
replacement
or
augmented
text
issue.
65
I
think
this
was
pretty
straightforward,
I
think
we'd,
probably
just
close
this
stating
the
implications
should
or
are
expected
to
support
mine.
We
didn't
use
BCP
14
language
there.
E
Lastly,
well
not
quite
lastly,
but
I
did
it
at
an
acknowledgment
section
with
the
list
of
people
that
have
provided
text
both
on
the
list
and
in
the
GitHub
if
I've
missed
anybody,
including
yourselves,
please
just
send
me
a
note
and
I
will
be
more
than
happy
to
add
you
to
that
section
issue
38,
that
this
is
the
78
versus
998
line,
limit
stuff
and
I
failed
to
reach
out
to
Pete,
as
I
was
supposed
to
in
time
to
get
text
in
this
draft,
so
we
will
get
together
and
work
on
that
66,
I
figure.
A
Okay,
we
have
three
minutes.
I
will
try
to
ask
two
questions:
John
noticed
that
some
people
are
trying
percent
in
code,
known
as
Gmail
addresses
so
I
think
we
want
to
add
some
text
saying
that
you
cannot
do
this,
because
you
cannot
actually
expect
all
systems
to
follow
this
I
think
it's
very
fair,
Fairly
straightforward.
Can
you
happy
to
authorize.
A
And
in
regards
to
the
email
addresses
in
the
Forum
I'm
going
to
skip
two
slides
about
what
you
can
edit
again
I
encourage
people
to
read
the
latest
draft
and
comment.
A
But
I
want
to
actually
T
is
one
issue
related
to
this
is
basically
the
as
at
the
moment
is
pointing
to
HTML
document,
and
this
is
ABN
F
from
this
document.
The
question
for
this
group
is:
are
we
happy
with
this
ABN
f.
A
And
also
the
related
question
I'll
be
happy
to
reference
HTML
document,
or
do
we
have
to
have
one?
Do
we
prefer
to
have
our
own
definition
because,
obviously
HTML
what
what
working
group
can
probably
change
the
definition
without
consulting
with
us
and
if
we
don't
or
if
we
keep
the
reference
to
their
document,
and
if
we
are
not
quite
happy
with
that
definition,
we
need
to
fit
this
information
back
to
them.
E
Real
quick
before
John
speaks
my
reasoning
for
just
putting
the
link
in
was,
if
that
topic
document
changes.
It
does
not
make
the
as
incorrect
at
any
point
in
time,
it's
always
pointing
to
whatever
the
lives.
The
most
current
for.
A
C
Levine
yeah,
my
answer
to
most
of
your
questions
is
no
I
am
not
happy
with
I
am
not
happy
with
this
grammar,
but
I,
don't
think
we
can
ignore
it
and,
in
particular,
I'm
not
happy
that
it
allows
consecutive
dots
which
nobody
which,
in
practice.
C
C
A
D
As
I
think
I
mentioned
on
list,
there
is
already
a
discussion
going
on
with
nw3c
between
the
HTML
group
and
the
internationalization
group
about
this
syntax,
and
maybe
it
will
change,
and
maybe
it
will
not
change,
and
maybe,
if
it
does
change
what
WG
will
pick
we'll
pay
attention
to
it,
and
maybe
they
won't.
But
I
would
really
like
to
see
us
figure
out
how
to
avoid
getting
tangled
up
with
that,
because
even
if,
if
John,
with
my
help
and
I
guess
I
sort
of
volunteered
to
do
that,
go
off
and
approach
them.
A
A
So
would
you
rather
us
cut
and
pasting
ABN
F
and
you
know
maybe
fixing
it
up
or
the
wish.
D
D
But
if
you
expect
things
to
interoperate
really
better
follow
our
specifications
rather
than
whatever
is
made
up
somewhere
else
as
as
part
of
an
interface
to
other
kinds
of
systems,
and
if
you
want
to
set
it
that
way,
that
one
needs
to
pick
the
the
common
subset
of
whatever
else
is
going
on,
but
but
I
think
that
if,
if
the
HTML
definitions
are
a
little
bit
broken
and
are
going
to
get
either
better
or
worse
over
time,
that's
setting
them
in
something
which
sounds
like
normatively.
It's
just
looking
for
trouble.
A
A
Can
I
suggest
you,
you
suggest
you
review?
What's
Ken
wrote
in
the
draft
because
I
think
some
of
what
you're
suggesting
is
already
covered
other
than
you
know,
obviously
referencing
HTML
and
you
suggest
edits.
D
A
Okay
right
on
that
note,
we
are
three
minutes
over
time.
Can
I
have
a
quick
show
of
hands?
Who
who
is
happy
with
having
interim
early
December
to
I,
have
slides
now.
A
Okay,
at
least
three
people
plus
me
John
you're,
you're,
happy
God
is
Happy.
Okay,.
C
A
Okay,
all
right?
Well,
let's
do
that
and
in
the
meantime
we
actually
people
can
work
on
various
tickets.
Maybe
we
can
make
progress
on
stuff.
We
we
agreed
here
today.
D
Thank
you
very
much,
obviously
the
more
progress
we
can
make
on
the
mailing
list,
the
better
off
we
are,
and
if
that,
if
that
results
in
canceling
the
internet,
because
we'd
rather
go
to
IHF
last
call
that
would
be
delightful.
Absolutely.