►
From YouTube: IETF-EMAILCORE-20230307-1700
Description
EMAILCORE meeting session at IETF
2023/03/07 1700
https://datatracker.ietf.org/meeting//proceedings/
A
B
A
C
A
A
A
A
A
A
B
A
C
D
Let
me
make
sure
there
I
am
yeah.
I
may
have
been
a
little
too
subtle
in
these,
such
as,
but
5322
has
no
normative
reference
to
5321.
The
idea
here
was
just
giving
an
example
that
further
restrictions
can
be
applied,
such
as
5321
and
to
add
Alexis
bid
defining
more
specific
syntax
as
used
by
SMTP.
But
if
you
you
know
you
could
follow
that
with.
D
But
if
you
wanted
to
use
it
somewhere
else,
you
would
Define
more
restrictions
or
less
restrictions
somewhere
else
that
you
know
that
this
was
basically
the
the
soft
here's,
an
example
of
how
you
might
further
restrict,
but
it's
got
to
at
least
follow
the
syntax,
the
the
broad
syntax.
That's
in
5322
Miss.
A
A
A
A
But
John
raised
I
think
a
good
point
about
extensibility
and
whether
we
really
want
to
encourage
creation
of
new
type
of
credit
field
blocks
and
what
exactly
the
semantic
is.
What
does
it
mean
so
in
reviewing
this
Pete's
posted
version,
zero,
five,
which
actually
removed
this
and
Pete-
can
talk
a
little
bit
about
why
he
proposed
this
change.
D
D
D
We
don't
see
any
particular
reason,
and
this
might
be
the
controversial
bit-
that
a
new
block
needed
to
be
added
that
wouldn't
require
some
new
specification
to
do
so
anyway,
because
how
would
it
behave
and
that
the
obsolete
or
whatever
we
want
to
call
it
syntax.
The
read-only,
but
do
not
generate
syntax,
already
allows
you
to
chop
crap
in
here
that
is
otherwise
undefined.
D
We
sort
of
came
to
the
conclusion
that
that
additional
optional
field
up
at
the
top
really
didn't
add
anything
that
anything
anybody
was
generating
right
now
was
perfectly
legit
syntax,
given
everything
else,
and
so
we
might
as
well
get
rid
of
it,
and
it
only
got
added
in
in
5322
I
think
it
wasn't
in
28,
22.
I
think,
because
we
didn't
think
through
that.
Oh
it
already
appears
in
the
trace.
You
don't
really
need
it
for
anything
else.
D
A
E
History,
I
remember,
is
that,
prior
to
focusing
on
Trace
field
placement,
the
header
Fields
were
not
order
dependent
and
so
in
the
the
ABN
F
presentation
that
appears
to
indicate
order
dependency
that
wasn't
actually
intended.
That
could
probably
be
fixed
by
doing
a
level
of
indirection,
which
then
makes
the
order
occurrence
not
matter
I,
I'm
I'm
also
a
little
confused
about
what
problem
this
is
fixing
and,
more
importantly,
whether
this
problem
has
manifest
itself
in
the
last
40
years.
D
So
the
interesting,
the
more
interesting
question
was:
what
problem
was
it
fixing
when
we
introduced
it
into
5322
that
wasn't
there
in
2822
and
I?
Think
the
problem
that
was
trying
to
fix
was
additional
stuff
in
the
trace
block,
which
is
more
cleanly
fixed
with
the
extension
in
the
the
trace
syntax
itself,
so
I
think
we
were.
D
D
A
Yes
and
the
reason
why
I
specifically
wanted
to
bring
this
up
because
we
made
the
opposite
decision
a
few
years
back
and
the
issue
was
reopened
even
though
we
didn't
have
a
ticket
for
it,
we
didn't
track
it
properly.
So
now
we
are
doing
it
kind
of
correctly
just
to
make
sure
that
it's
all
minuteed
and
recorded
all
right.
So,
assuming
you
know,
I
already
posted
the
message.
You
know
you
and
I
posted
messages
to
the
mailing
list,
saying
that
please
object
if
you
have
a
good
reasons
and
that's
there
are
any
objections.
A
A
B
Let's
see
first
of
all,
I
I
am
persuaded
by
your
comment
at
the
bottom
of
this
slide
that
that
53-22
base
is
probably
a
better
place
than
5321
Miss,
but
I
would
encourage
the
working
group
to
put
things
which
are
fundamental
like
this
in
the
base
documents.
So
if
we're
defining
Trace
fields
and
extension
Trace
fields
in
in
5322
bits,
then
instructions,
no
matter
what
how
they
should
be
registered,
ought
to
be
there
rather
than
trying
to
add
them
on
to
the
As
and
hope
somebody
will
see
them.
D
D
E
E
So
the
the
more
generic
comment
first,
my
general
view
is
an
applicability
statement,
should
talk
about
application.
It
should
not
go
and
be
a
spec
for
core
technology.
It
might
have
normative
language
about
use
of
the
technology.
It
may,
in
fact,
be
Innovative
in
that
that
that's
an
interesting
discussion
to
have
about
the
document,
but
it
shouldn't
go
and
be
defining
the
technology,
that's
what
specs
are
for
and
as
soon
as
you've
got
normative
language.
E
That
goes
for
example,
and
defines
what
a
trace
header
field
is
or
defines
a
a
registry
for
them.
I
think
you've
moved
into
being
a
specification
rather
than
an
as
that's
the
general
comment.
The
the
specific
one
is
the
degree
of
energy
and
discussion
and
time
that
has
been
spent
on
Trace
header
fields.
E
Arguably
already
moves
this
document
into
an
area
of
new
content,
far
beyond
what
was
in
the
previous
version
of
this
document,
and
so
I
suspect.
What's
going
on
right
now
would
be
haggling
about
price,
to
use
the
cliched
reference
and,
if
essentially
from
what
I
can
tell
what's
happened
in
in
the
crystallizing
of
the
trace
discussion
is
the
sense
of
a
semantic
contest
concept
that
was
a
vague
at
best
in
the
earlier
documents
and
is
trying
to
be
made
much
more
concrete,
operationally
and
syntactically.
E
The
question
then
I'm
just
going
to
move
on
to
the
next
point.
The
the
question,
then,
would
be:
what's
the
right
way
to
signal
that
something
is
a
trace
field
if
Trace
Fields
have
fundamentally
different
syntax
and
I,
think
they
don't,
then
having
a
new
registry
might
make
sense
if
they
are
in
fact
only
a
matter
of
where
they
appear
in
the
header
in
the
header
and
how
they're
handled
in
the
header
and
I
think
that's
the
definition.
E
B
B
Oh,
but
but
if
the
conclusion
is
that
5321
should
only
talk
about
its
Trends
fields
and
everything
else
and
and
all
other
discussion
definition
at
the
specification
level
of
Trades
Fields
should
be
in
53-22,
then
this
goes
in
53-22
and
Dave's
argument
that
the
particular
details
of
where
it's
played
in
the
registry
are
are
small.
Potatoes
is,
is
in
that
sense,
exactly
right,
and
if
the
right
solution,
as
Pete
suggested,
was
to
pull
all
of
this
stuff
out
of
both
documents
and
put
it
into
something
separate
I
would
lose.
D
D
I
think
it
is
just
a
flag
in
the
registry,
but
there's
all
sorts
of
operational
implications
that
people
think
they
have
when
they
call
something
a
trace
field.
Some
of
it
is
remove
this
when
you
resend
it.
Some
of
it
is
other
operational
instruction
about
how
you
might
where
it
belongs.
When
you
add
it
doesn't
belong
at
the
top.
Does
it
belong
at
the
bottom
I.
D
D
Finding
the
registry
flag,
if
you
have
to
go
into
any
kind
of
detail
about
what
that
registry
flag
means,
then
it
should
be
in
a
separate
document
if
it
really
is
just
a
flag
and
two
sentences
to
describe
it,
and
everybody
agrees
that
it's
just
two
sentences:
peachy
I'm
happy
to
put
it
in
5322.
right.
B
A
Still,
no,
it's
not
what
I'm
suggesting
maybe
completely
optimistically
I'm
thinking
that
we're
pretty
close
on
this
one.
But
what
I'm
suggesting
is,
let's
see
if
I'm
right,
you
already
wrote
the
text.
What
I'm
suggesting
is?
Actually
you
have
a
couple
of
sentences
in
your
document
about
ion
registration,
I
suggest
to
move
this
text
over
to
Pizza
document
and
see
if
it
sticks.
A
I
appreciate
that
people
might
not
remember
exact
text,
and
it's
probably
it
is
too
much
text
to
put
on
a
single
slide.
So
proposal
on
the
table
is
I.
Think
the
current
text
is
correct
and
know
for
the
changes
I
needed,
but
can
we
please
have
a
couple
of
volunteers
John
if
you
want
to
say
something
extra
of
course
please.
My.
A
B
A
Okay
and
another
thing
another
ticket
that
John
opened
was
about
operational
requirements,
I
use,
John
text
and
I
added
sex,
section
titles,
so
that
it's
more
readable.
So,
basically,
there
is
a
discussion
in
section,
7,
8,
local
operational
requirements
and
resistance
to
attacks
and
seven
nine
scope
of
operations
of
SMTP
servers,
and
there
are
Pointers
to
both
of
them
from
section
six.
Two.
F
A
Right
moving
on
now
to
a
couple
of
issues
in
AFS
related
to
the
trace
header
fields,
there
were
two
set
of
proposed
additions
to
the
applicability
statement.
One
is
based
on
my
tax,
which
John
extended
and
made
more
helpful
I
believe
it's
about.
Basically,
you
can
only
trust,
received
credit
fields
that
you
inserted
and
be
careful
about
what
kind
of
trust
you
place
and
all
other
header
Fields
inserted
by
the
agents,
as
well
as
what
kind
of
conclusions
you
can
derive
from
them.
A
F
Actually
find
received
headers
useful
for
like
sorting
a
mail
to
figure
out
where
it
came
from,
but
I
guess
that
would
be
covered
by
this.
So
I,
I
I
think
it's
okay,
I
think
this
is
one
of
those
things
where
it
describe
it
discourages
people
from
from
naively
trusting
and
people
who
actually
know
what's
going
on
will
understand
what
it
means.
So
it's
okay.
A
A
That
motivated
me
as
one
of
mua
writers,
about
what
are
the
trace,
how
the
fields
are
useful
for
or
you
know
what
can
you
should
or
shouldn't
do
with
them?
So
specific
suggestion
is,
if
message
is
being
resent,
you
know
a
lot
of
email.
Clients
have
added
as
new
message
when
they
basically
take
existing
messages
as
a
template
and
strip
it
and
sanitize.
It
and
specific
suggestion
is:
if
you
do
this
kind
of
operation,
you
should
strip
the
thresholder
fields.
A
F
F
Yeah
I
guess
I
mean
I
think
this
is
one
of
those
things
like
it's
not
wrong,
but
I.
You
know,
but
if
you're
going
to
say
that
you
know
I
would
say
it
more
strongly,
you
know
they
should
you
know
they
should.
They
should
only
include
headers
likely
to
be
relevant
to
the
newly
to
the
newly
edited
message
or
something
like
that.
F
A
E
Then
this
is
in
the
realm
of
another
one,
which
is
basing
a
new
message
on
an
old
message,
and
in
that
sense
it's
almost
like
reply,
but
of
course
the
the
target
recipients
are
different
and
there's
expected
to
be
some
added
content.
But
then
there
is
for
that
for
reply,
also,
as
such,
this
isn't
specific
to
trace.
This
is
specific
to
creating
a
new
kind
of
message
based
on
an
old
message,
and
that
is
either
a
big
topic
or
a
small
one,
depending
on
where
it's
put
in
the
document.
E
How
much
needs
to
be
said,
the
and
again,
as
was
said,
it's
not
as
if
this
text
is
wrong.
It's
that
it's
touching
a
general
a
more
General
topic
rather
than
one.
That's
specific
to
trace
header
fields
and
it
may
or
may
not
say
more
than
about
just
Trace
Center
Fields.
But
this
then
goes
back
to
the
question
of
whether
this
document
is
now
doing
more
than
just
moving
from
draft
to
proposed.
B
Some
of
this
discussion
excuse
me,
is
beginning
to
feel
like
we
should
be
attaching
new
text
to
the
to
the
document
about
principle
called
principles
for
writing:
male
userations
for
Fun
and
Profit,
which
is
which
is
document.
We
have
deliberately
avoided
trying
to
write
for
the
last
company
years
for
for
for
lots
of
good
reasons
which,
which
Dave
has
explained
in
the
past
much
better
than
I
can.
B
This
way
should
be
very
careful
to
clear
out
header
fields
that
that
are
relevant
to
the
previous
message
and
how
it
was
received,
rather
than
and
and
and
and
then
use
traces
an
example,
rather
than
making
this
a
specific
Saudi
statement
about
Trace
fields
and
I.
Think
that
Dodges,
the
bullet
that
that
Dave
and
John
rubine
have
been
talking
about
without
losing
this
probably
useful,
commentarily.
B
B
A
A
D
So
this
may
be
overtaken
by
events
of
the
past.
You
know
45
minutes,
because
this
really
does
go
to
what
needs
to
be
written
about
trace
and
where
sufficient
for
defining
what
that
registry
field
meets.
Right,
that
that's
really
the
the
standing
question
is
what
is
implied
by
ticking
that
column
in
the
registry.
D
A
A
Few
so
that
yeah,
that's
basically
my
position
that
other
than
talking
about
what
muas
can
do
all
other
agents
just
add:
Thrace
color
fields
for
some
specific
ones.
There
are
requirements
to
strip
them
at
various
points,
like
authentication
results
on
inbound
into
the
target
system,
but
I
don't
think
we'll
have
rules
that
applies
to
Old
Trace
study
fields.
So
I
think
we
shouldn't
try.
A
B
And
per
your
earlier
comment:
Alexi
there's
already
text
in
5321
this
that
that
answers
a
small
portion
of
this
question.
From
back,
we
were
trying
to
do
more
about
defining
what
a
trace
flip
was
there
and
I
think
per
your
earlier
suggestion.
If
we
could
take
that
text,
tweak
it
a
little
bit
and
drop
it
into
5322,
we
will
be
about
90
through
on
this
I
think
we
could
fairly
much
ignore
the
under
10
percent.
A
D
A
A
A
A
D
Yes,
okay,
mystery,
but
I
heard
you
the
entire
time.
My
only
comment
was
so
long
as
what
we're
defining
is
a
trace
field
is
just
something
that
is
information
as
the
message
traverses
different
systems
that
is
stuck
up
at
the
top
for
informational
purposes,
and
that's
all
that
tick
Box
means,
and
it
has
no
other
operational
implications,
glad
to
put
that
in
I'm,
not
sure
what
the
what
the
column
in
the
registry
buys
us
at
that
point.
B
D
No
one
wants
to
see
that
yeah
I'm
I'm,
okay,
with
minimalist
text
in
5322
bits
that
just
says
it's
part
of
that
and
and
actually
I,
don't
think.
You
know
there's
much.
That
needs
to
be
added
to
53-22
bits
at
the
moment.
There's
already
a
little
bit
of
text
in
there.
Maybe
a
sentence
or
two
more
and
then
put
the
put
that
in
the
registry
and
and
be
done
with
it
and
I
I'm
yeah.
A
A
B
A
B
And,
and
and
similar
problems
would
apply
to
to
overdoing
any
comments
about
are
about
Dane
or
demarc,
or
anything
else
that
somebody
might
feel
like
putting
in
there.
I
just
think
we
need
to
try
to
very
carefully
last
week
over
promise.
I
guess
would
be
the
easiest
or
appear
to
over
promise.
But
again
let
me
do
it
carefully
and
I'll.
Try
to
make
some
comments
on
the
mailing
list.
B
Pete
made
a
suggestion
in
a
pre-meeting
office
discussion
about
getting
specific
volunteers
to
check
any
or
all
of
this
stuff,
which
seems
seems
unresolved.
So
we've
got
a
clear
statement
on
the
mailing
list
about
about
agreement
rather
than
silence
there.
If
you're
satisfied,
we've
already
covered
that
that's
fine,
but
I
just
want
to
make
certain
that
belief.
Not
let
that
slip.
A
B
B
Even
careful
read-throughs
of
of
gifts
and
change
lists
on
on
5321,
especially
because
it
is
by
far
the
longer
document
and
by
far
the
more
convoluted
one.
The
thing
I'm
particularly
concerned
about
is
getting
ourselves
into
a
situation
in
which
different
sections
of
that
document
s
say
things
which
are
not
quite
consistent
with
each
other
and
I'm
right.
So
I
could
diligently
to
check
for
that,
but
it
needs
another
set
or
several
silver
sets
of
eyes.