►
From YouTube: IETF111-EMAILCORE-20210727-2130
Description
EMAILCORE meeting session at IETF111
2021/07/27 2130
https://datatracker.ietf.org/meeting/111/proceedings/
B
B
B
C
B
B
B
B
B
B
D
E
B
F
B
B
B
B
B
B
D
Okay
mean
it's
not
just
the
stripping
case,
which
I
guess
we
may
not
may
be
less
sympathetic
for,
but
there's
also
the
case
of
when
you're
constructing
you
know,
when
you're
doing
composition
of
a
message,
it's
sort
of
a
natural
thing
to
use
report
path
to
indicate
the
mail
from
and
you're,
certainly
not
going
to
have
received
fields.
At
that
point,.
E
E
G
F
J
J
If
you've
got
a
return
path,
then
it
must
mean
that
it
traverse
something
because
it's
coming
from
the
mail
from
the
smtp
stream,
but
ned's,
claiming
it's
a
perfectly
reasonable
use
to
use
return
path
for
something
other
than
that.
So
if
people
are
okay
with
that
justification,
I
think
that's
reasonable,
but
it
it's
not
about
the
presence
or
not
presence
of
received
in
general,
because
of
course,
that's
always
been
permitted
to
be
left
out.
A
G
G
G
B
B
J
B
I
J
B
So,
moving
on
to
the
smtp
spec
itself,
I
did
a
scan
of
the
document
where
everywhere,
where,
like
trade,
trades,
trace,
information
or
trace
header
is
mentioned
as
well
as
received
and
over
three
slides,
I'm
proposing
some
changes.
I
think
they're
relatively
minor.
One
thing
that
the
document
implies
that
the
trace
header
fields
is
can
can
include
other
header
fields,
but
it
only
defines.
B
So
basically,
I
suggest
that
the
current
definition
in
section
four
four
is
move
to
a
subsection
and
there
is
a
introductory
definition
of
a
trace
header
fields.
I
found
this
text
from
rca2,
which
you
can
see
on
the
screen.
I
mean
we
can
improve
on
this,
but
I
think
it's
probably
pretty
close
to
what
we
want
to
have.
B
B
B
A
Objection,
but
for
planning
and
meeting
running
purposes
you
should
assume
that
I
can't
really
read
the
blanket
of
any
of
these
slides.
It's
it's
my
issue
rather
than
more
general
one,
but
I
want
I'm
having
eyesight
problems
and,
and
the
combination
of
those
are
the
fine
print,
even
even
when
I
bring
the
slider
full
screen
with
me.
That
go
is
your
sense
that
I'm
gonna
have
to
take
people's
words
for
and
then
they
can
pick
the
slides
up
later
and
try
to
edit.
Here.
B
E
A
A
B
Right
so
in
section
363
there
is
a
mention
that
received
header
field
can
be
inserted.
I
suggest
adding
and
possibly
other
trace
header
fields
here
and
in
section
seven,
six
about
information
disclosure.
Again
it
talks
about
that.
The
received
header
field
can
disclose
public
information
about
hosts
and
stuff,
but
other
trace
header
fields
can
also
potentially
do
that.
So
I
suggest
add,
for
example,
received,
but
that's
sort
of
a
minor
thing
really
any
comments.
Any
objections.
H
H
H
G
G
I
G
B
B
B
K
B
This
is
section
two
to
two
definition:
registration
of
extensions.
I
think
pretty
much
most
of
the
text
go
goes
away.
There
is
a
related
change
which
we
discussed
on
the
mailing
list
about
extensions.
Changing
from
extensions
must
be
registered
unless
the
x
starts
with
x
to
extend
it
should
be
registered.
B
B
E
General
discussion
that's
been
happening
regularly
about
registries
and
what
the
criteria
for
registration
should
be
and
there's
a
natural
tendency
to
want
to
be
strict
because
of
quality
control.
But
ietf
approval
is
where
quality
control
is
supposed
to
happen,
and
the
real
goal
of
a
registry
is
to
make
sure
there
aren't
name
collisions
and
maybe
to
worry
about
allocating
a
scarce
resource
which
doesn't
apply
in
this
case.
Consequently,
I'm
not
sure
why
the
rule
shouldn't
in
fact,
be
quite
a
bit
more
permissive.
B
D
You
know
I
I
would
add
to
dave's
list
of
important
things
that
registries
do
to.
You
know
enable
people
to
document
existing
practice,
especially
widespread
existing
practice
without
having
to
go
through
our
processes.
I
would
dearly
love,
for
example,
the
example
I
give
on
the
mailing
list
is
the
you
know,
the
microsoft
stuff.
That's
used
to
authorize
clients
in
you
know
in
smp
auth
and
imap
off.
D
Someone
else
came
up
with
an
example
that
I
can't
remember
offhand
of
why
this
is
important,
for
you
know
smtp
extensions
as
well
I'd
rather
capture
data
in
some
form,
and
you
know
if
you
want
them.
If
you
want
to
make
the
registry
you
know
have
different
right,
you
know
criteria
levels
like
we
do
for
you
know,
for
you
know,
media
types
great
you
can
do
it
that
way
and
have
you
know,
have
the
better
set
of
extensions,
but
I
think
more
information
is
almost
always
better.
B
E
Application
issue-
and
I
can
imagine
situations
where
it's
just
fine
to
have
no
specification
available.
It
certainly
is
something
we
ought
to
always
provide
for
and
then
the
question
is
whether
to
require
it
and
I
hadn't
thought
of
not
requiring
a
specification.
So
that's
where
the
apology
comes
in
and
not
just
itf
specification.
Any
specification
would
seem
to
me
to
be
sufficient
to
handle
the
point
that
ned's
making.
B
A
John
part
of
the
point
I
was
going
to
make
we're
sliding
rapidly
toward
register
whatever
you
want
to
and
and
point
to
a
specification
somewhere,
if
you
feel
like
it
and
on
the
theory
that
we're
better
off
with
more
with
whatever
information
we
can
get
from
no
information
at
all.
I
guess
I'm
in
favor
of
that,
but
it's
a
fairly
major
departure.
G
All
right,
barry
in
the
chat
is
we've
successfully
used
fcfs
with
specifications
strongly
encouraged,
and
I
think
the
way
we
wrote
that
in
the
specs
was
we
wrote
it
as
fcffcfs,
but
we
put
in
the
template
in
the
registration
template
a
specification
pointer
and
we
have
no
vetting
of
the
specification
pointer.
There's
no
expert
review
of
the
specification.
B
B
A
H
This
last
paragraph
in
section
3.6.2,
there
was
list
discussion
that
seemed
to
land
on
just
a
simple
two-sentence
paragraph,
which
shows
there.
This
specification
does
not
deal
with
verification
or
return
path
for
use
in
delivery.
Notifications,
it's
outside
the
scope
of
the
specification,
two
questions.
One
is
proposed
text
acceptable
and
two
there
was
some
mention
of
perhaps
removing
the
phrase
for
use
and
delivery.
Notifications
from
that
proposed
paragraph.
G
G
I
K
G
H
A
H
There
is
a
proposal
to
strike
an
entire
paragraph
from
section
4.14,
I'm
not
going
to
read
it
to
you.
Y'all,
hopefully
can
read
it
on
the
screen
and
just
replace
it
with
the
sentence
that
says,
the
smtp
server
may
verify
that
the
domain
name
argument
in
the
in
the
yellow
command
has
an
address
record
matching
the
ip
address
of
the
client
and
then
have
further
discussion
about
the
topic
in
the
applicability
statement
rather
than
having
it
in
rit
of
5321
bis.
H
D
D
L
H
I
On
this
topic,
one
of
the
things
that
one
can
do
with
the
the
boolean
is
log
it
and
or
record
its
value
in
trace
headers
as
a
as
a
comment
which
can
be
useful
forensically,
even
if
one
doesn't
refuse
the
connection.
In
fact,
it's
mostly
the
sound
thing
to
do,
because
rejecting
on
that
basis
is
in
practice
as
we
I'm
seeing
on.
I
You
know
when
answering
user
questions
on
the
post-existence
on
is
really
too
fragile
to
be
a
generally
useful
policy
without
other
signals
that
the
message
is,
you
know
rejec
worthy
of
rejection,
and
so
the
idea
is
that
mostly
this
is
just
evidence.
One
might
record,
and
so
commenting
that
this
is
not
a
good
basis
for
rejecting
could
be
in
scope,
but
maybe
in
applicability
rather
than
the
main
standard.
I
don't
have
a
strong
opinion
about
that,
but
it's
probably
not
to
encourage
people
to
block
on
that
basis.
I
G
A
I
would
lose
no
sleep
over
finishing
finishing
this
and
having
it
go
into.
Our
sea
editor
hold
until
the
applicability
statement
is
finished.
It's
not
as
if
we
were
fighting
a
deadline
here
and
that
kind
of
forward
references.
The
backwater
is,
is
much
more
clear
and
much
more
likely
to
be
picked
up
than
simply
using
the
applicability
statement
to
update
this
value.
I
I
They
might
be
rejected
by
some
servers,
but
it
doesn't
give
anybody
the
impression
that
actually
doing
the
rejecting
is
likely
to
run
into
a
bunch
of
trouble
and
should
not
be
undertaken
lightly,
and
it
might
also
give
people
a
hammer
to
say
well,
the
rfc
says
you
know
I
can
do
it.
Therefore,
it's
your
fault.
You
know
whatever
you're
you're
a
bad
person
for
not
having
a
valid
elo
name
and
maybe
to
some
extent,
that's
true,
but
I
think
there
should
be
some
disincentive
to
adopting
reject
on
baddie
low
as
a
standard
practice.
H
I
G
C
C
H
C
B
M
Let's
see
is
my:
is
my
mic
working
yeah,
oh
good
yeah.
I
seem
to
I
seem
to
be
the
expert
on
this
topic
since
paul,
and
I
have
been
doing
this
for
a
couple
of
years.
I
I
would
go
stronger,
I
would
I
would
make
it
stronger
than
saying
not
interoperable.
I
mean
tlds
have
never
worked
in
mail.
You
know,
and
even
though
there
are
a
bunch
of
of
sort
of
people
who
do
it
sort
of
as
a
gimmick
for
for
cctlds
in
practice,
most
of
them
don't
work
so
yeah.
M
I
guess
I
I
guess
I'm
just
agreeing
that,
but
I
would
like
to
make
it
stronger
that,
like
it
should
say
it's
not
it's
stronger
than
saying,
not
necessarily
interoperable,
it's
just
it
like
you
shouldn't.
Do
it
and
you
shouldn't
do
it
and
you
shouldn't
expect
it
to
work.
You
know,
and
I
realize
there
are
people
who
do
single
component
names.
You
know
as
a
local,
alias
and
stuff,
but
people
do
all
sorts
of
local
extensions.
I
don't
see
any
reason
to
document
that.
I
E
The
reason
it's
worth
going
into
some
detail
about,
I
think,
is
because
it's
a
constant
issue,
certainly
there's
people
over
in
the
world
of
icann
who,
in
the
world
of
icann,
not
necessarily
at
icann,
who
keep
hoping
to
have
their
top-level
domain,
get
used
directly
in
this
way
and
so
having
the
aas
at
least
flag.
This
issue
and
its
history
enough
to
scare
people
might
be
useful.
M
L
M
M
Does
it
because
because
they
host
a
con,
basically
because
it's
cute,
so
I
don't
actually
see
that
you
know
I'm
not
just
agreeing
with
you,
but
I
don't
see
this
as
an
actual
problem
to
be
solved,
because
you
know
the
few
times
it's
come
up.
The
answer
has
been
don't
be
silly
and
that
you
know-
and
that
was
that.
B
B
B
A
Just
make
certain
we're
in
sync.
My
plan
right
now
is
to
wait
until
you
make
that
registry
consensus
call
wait
until
minutes
and
come
out,
and
I
can
shuffle
through
this
this
discussion
and
then
try
to
generate
a
a
new
version
of
five
three
two
one
this.
So
you
can
start
looking
at
more
specific
text.