►
From YouTube: IETF112-EMAILCORE-20211110-1200
Description
EMAILCORE meeting session at IETF112
2021/11/10 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
Hello,
everyone-
this
is
todd
herr
co-chair
of
the
email
core
working
group,
I'll
be
facilitating
the
session
today.
Alexi
is
unable
to
make
it
due
to
a
work.
Commitment
looks
like
we've
only
got
18
or
19
people
showed
up
so
far,
so
I'm
going
to
wait
another
minute
or
so
to
let
everybody
trickle
in
and
then
we'll
get
going.
A
Okay,
well
we're
two
minutes
past
starting
time.
Now
again,
my
name
is
todd
herr,
I'm
co-chair
of
the
working
group
I'll
be
facilitating
the
session
today.
I
don't
know
if
we
can
blame
the
early
hours
here
in
the
u.s
or
what
but
attendance
isn't
as
heavy
as
I
hoped
it
would
be,
but
we'll
we'll
muddle
through
not
just
the
same.
A
Reminder
that
this
is
being
recorded,
you
can
there's
the
url
for
the
session.
There's
also
the
jabber
room.
We
do
have
a
notetaker
already
braun
has
volunteered.
Thank
you
very
much.
A
A
lot
of
stuff
on
the
agenda
today,
but
it's
mostly
just
bringing
a
number
of
tickets
to
closure,
we'll
start
with
a
status
update
on
5322
bis,
run
through
well.
What
is
that
eight
tickets
talk
about
potentially
have
an
interim
meeting
in
december
and
then
a
little
bit
about
the
applicability
statement.
A
A
What
status
is
right
now
he's
kind
of
fixed
one
bit
of
awkward
text
and
put
back
an
optional
field
in
trace.
Recent
block
still
need
to
clean
out
the
editor's
notes,
and
he
thinks
he's
ready
for
the
working
group
last
call.
Unless
something
comes
up.
A
A
All
right,
first
ticket
5321,
further
clarification
needed
to
duplicate
source
routes.
Last
week,
alexey
posted
essentially
the
contents
of
this
slide
to
the
list
presenting
various
options
on
how
to
handle
source
routes.
In
the
current
version
of
the
spec,
it
seemed
that
the
mailing
list
had
a
preference
for
option
a
which
is
to
strip
all
strip
all
mentioning
of
handling
of
source
routes
in
the
text
in
the
abnf
other
than
specify
their
historical
use.
B
Yeah,
I
I
I'm
certainly
okay
with
with
that
consensus
interpretation,
but
I
just
want
to
point
out
this
that
this
stuff
is
scattered
to
the
document
and
it's
significant.
It's
a
significant
change
and
I
think
we
should
make
it
only
if
people
are
willing
to
agree
to
look
carefully
at
what
I
do,
because
I
may
screw
it
up
and
we
don't
want
any
scopes
to
get
into
the
in
the
final
document
right.
The
next,
I
believe,
I'm
very
reluctant
to
make
significant
changes
here
without
a
lot
of
cross-checking.
A
Sure
the
next,
the
next
eight
or
nine
slides
in
the
deck,
I
believe,
are
all
of
the
content
that
references
source
routing,
so
that
will
get
the
first
pass
at
that
cross
check
that
you're
looking
for
during
this
meeting
today,
but
certainly
there
will
be
a
lot
more
cross-checking
going
on.
I'm
sure
well
hope.
So.
Thank
you
sure.
A
Okay,
moving
on,
as
I
said
during
the
conversation
with
john
a
moment
ago,
the
next
several
slides
are
the
relevant
content
within
5321
that
addresses
source
routes,
starting
with
the
the
last
sentence
in
section
2.1
regarding
explicit,
shows,
explicit
source
routing
should
not
be
used.
The
proposal
is
changed
to
must
not
be
used
and
remove
any
reference
to
section
5,
since
section
five
doesn't
discuss
source
routing.
A
Also
in
the
fifth
paragraph
of
section
three
three
under
mail
transactions
proposal
here
is
to
change
the
should
not
use
source
routing.
Two
must
not
use
source
routing.
A
Okay
again
in
the
mail
transaction
section,
there
is
a
reference
to
contemporary
smtp
clients
should
not
use
source
routes,
and
the
proposed
change
here.
C
Hey
todd,
there's
there's
a
message
in
the
chat
that
you
may
want
to
really
hear
there.
A
Was
a
message
in
the
camera
yeah
yeah
yeah
see
I
apologize
for
missing
that
I've
been
glancing
at
the
chat
on
the
different
screen
and
I
missed.
A
A
A
I
don't
know
that
we're
I
mean
option
b
was
to
allow
source
routing
in
the
abn
f,
but
strengthen
existing
text.
All
right,
you're
right,
you're,
correct
that
is
option
b
alexi
wrote
these
slides.
I
didn't
I
apologize
for
the
the
seeming
misalignment
here,
so
yes
you're
correct.
So
then
the
proposal
ought
to
be
in
keeping
with
option
a
here
on
on
this
slide,
to
remove
the
sentence
entirely
with
the
fifth
paragraph
in
mail
transactions.
A
I
guess
we
would
just
remove
everything
after
the
semicolon.
The,
however
contemporary
system
should
not
use
source
routing.
A
Yeah,
okay,
so
ned's
ned's
comment
is
just
remove
the
discussion
entirely.
Does
anybody
have
any
any
disagreement
with
that
and
I
wasn't
thinking
when
I
was
reviewing
these
slides
last
night
to
notice
this.
C
A
So
every
slide
regarding
this
text
regarding
every
slide
regarding
this
option
that
comes
afterwards
seems
to
be
in
support
of
option
b,
not
option
a
despite
it's
saying
it's
in
support
of
option
a
so.
Let's
revisit
this.
This
slide
here
with
the
the
various
options,
and
it
seems
like
the
recollection
of
everyone
from
the
mailing
list.
Is
it
option
a
was
where
people
expressed
a
preference?
A
So,
yes,
they
answered
your
question
that
we
would
be
stripping
the
info
out.
Barry.
D
Barry
lee,
but
so
the
in,
in
which
case
there
should
be
text
somewhere.
That
says
that
has
a
paragraph
that
says:
smtp
originally
specified
source
routing
c
here
in
rfc
821.
This
has
now.
This
is
now
deprecated
and
implementations
that
need
to
use
need
to
have
backward
compatibility
with
source
routing
should
see
that
for
for
syntax
or
whatever,
and
that's
it
and
then
every
place
else,
we're
pulling
the
text
right.
E
E
Hey
good
morning,
good
afternoon,
good
evening
to
everybody-
forgive
me
for
jumping
in,
but
I
I
I
just
like
to
express
a
preference
for
the
more
traditional
approach
of
must
not
be
generated.
Maybe
parsed
approach,
because
for
the
reason,
for
the
very
reason
that
john
put
into
the
the
chat,
which
is
you
know
you,
you
certainly
want
to
be
able
to
parse
historical
mailboxes
there.
I
think
people
have
some.
E
So
sorry,
the
parsing
return
route
occurs
in
both
the
smtp
command
stream,
and
it
also
can
be
found
sometimes
in
the
what
the
return
path
slash,
what
what
people
call
the
from
space
header
right,
so
it
can
be,
it
can
be
in
all
three
places
now.
Obviously,
some
of
that
is
in
53,
22,
right
or
more
might
be
referenced
in
5322,
but
I'm
just
saying
it.
E
C
Was
just
gonna
try
and
respond
to
elliot?
I
I
was
checking
to
see
whether
it's
in
the
parse
syntax
from
5322.
C
B
B
It
can
put
it
in
a
mailbox
file
and
and
nothing
prevents
someone
from
putting
parts
of
the
envelope
in
the
in
that
file
along
with
parts
of
the
content
and
and
I've
certainly
seen
it
done
so.
Yes,
it
has
to
do
with
parsing
mailboxes.
B
We
wouldn't
want
somebody
who's,
trying
to
look
at
an
old
mailbox
to
find
one
of
these
ugly.
Looking
creatures
and
say
wtf
is
that
so
elliott's
scheme
works,
ned's
scheme
works.
B
Taking
all
of
this
out
and
pretending
that
it
never
happened,
probably
doesn't
work
and-
and
it's
exactly
this
discussion,
which
is
why
I
made
the
comment
earlier
about
wanting
to
make
certain
that
that
people
are
clear
to
me
about
what
it
is.
They
want
and
then
check
and
make
certain
they
get
it
right.
B
C
Let
let's
be
clear
about
53
22's
approach
to
this
stuff,
because
5322
is
about
parsing
messages
wherever
they
may
be,
and
so
there
is
explicit
text
saying
hey.
If
you've
got
this
stuff
locally
stored
and
you've
got
a
message
locally
stored,
you
may
want
to
be
able
to
parse
that,
and
so
there
is
the
route.
You
know
this
return
path.
It's
called
obs
route
in
5322.
C
That
makes
it
legitimate
to
parse
it
in
a
message
but
5321
as
far
as
I
can
tell
isn't
talking
about
that.
It's
talking
about
the
use
of
them
in
protocol
and
specifically
the
use
of
them
in
receipt
twos
in
mail
froms,
and
so
it
seems
legitimate
to
say
we're
not
going
to
do
some
sort
of
old-fashioned
stuff
in
5321
and
yet
leave
it
in
53
22
for
parsing
purposes
for
messages
that
exist
wherever
they
might
exist.
B
Except
for
one
problem
page,
which
is
that
there
is
no
text
in
5322
which
says
when
you're
storing
this
stuff
for
for
further
use,
you
are
forbidden
to
put
anything
there,
which
5322
doesn't
say
and
and
while
you're
absolutely
correct
about
the
things
from
the
envelope
which
are
record
or
extracted
in
the
envelope
which
are
recorded
in
5322
headers
received
deals,
return
pads
whatever.
B
B
So
there's
still
an
issue
there
and
it's
that
issue
won't
try
to
speak
for
ned
or
elliot.
But
it's
that
issue
which
motivates
me
to
say
there
ought
to
be
a
backward
pointer
here
somewhere
and
whether
we
state
that
backward
pointer
by
putting
into
5321
the
thing
which
532
does
frequently
and
5321
is
so
far
avoided,
which
is
to
say,
must
not
generate
but
may
do
odd
things
with
uc,
which
is
my
version
of
elliot's
proposal
or
or
to
take
all
of
it
out
and
say.
B
C
B
C
And
and
since
I've
I'm
here
I'll
I'll
mention
the
latter,
which
sounds
more
like
choice,
a
to
me
seems
to
be
my
preference,
which
is
no
real
mention
of
source
routing
in
5321
bits,
except
for
the
backward
pointer
to
821.
A
Okay,
anyone
else
want
to
speak
on
this
topic.
A
B
Option
a
variant
one
is
we
take
everything
which
ever
referred
to
these
things
out
of
the
document
and
pretend
they
never
happened
option
a
variant.
Two
is
we
take
all
of
this
out
and
we
put
in
new
text
in
an
appropriate
place
which
said
that
which
says
they
used
to
be
these
things
and
and
if
you
encounter
them
and
need
to
figure
out
what
they
are,
go.
Look
at
a21.
B
A
What's
on
the
screen
for
option
a
says
b,
that
source
routing
should
be
stripped
of
all
mentioning
of
handling
of
source,
routing
in
text
and
abnf
other
than
to
specify
their
historical
use
in
rc,
821
and
yeah,
though,.
B
Subject
to
subject
to
editors
interpretation,
the
warning
that
editor
may
get
it
wrong
option
a
in
on
the
slide
is,
is
what
I
refer
to
as
variant
two.
A
Okay
and
that
that
was
the
option
that
was
seemed
to
seem
to
draw
consensus
on
the
mailing
list.
That
is
not
the
option
supported
by
the
follow-on
slide,
but
we
will
use
the
follow-on
slides
to
mention
the
text
that
will
have
to
be
stripped
out
and.
A
A
F
A
A
A
Possible
reply
to
seeing
a
source
route-
that's
not!
I
don't
know
that.
That's
a
topic
that's
been
discussed,
but
elliot's
question
in
chat
is
the
expectation
here
is
seeing
a
source
route
is
a
500.
A
That
is
a
topic
worthy
of
discussion.
I
think
either
today
or
on
the
list.
D
B
B
B
B
B
That
seems
like
a
good
approach
and,
and
from
that
standpoint,
this
set
of
slides
to
tell
you
prepared
and
which,
for
the
record,
I've
seen
first
time
now,
is
simply
a
pointer
for
me
as
to
what
to
look
at
and
take
out
correct.
B
B
A
A
There
are
two
tickets
that
reference
quoted
strings,
an
email,
comparison,
tickets,
21
and
49..
A
B
The
the
general
tone
of
of
everything,
mate
21
forward
toward
local
parts,
is
that
they
don't
have
semantics
and
nothing
smtp
is
gets
involved
with
anything
which
involves
their
semantics.
B
A
B
Yeah,
no,
I
I
I
agree
and
and
we'll
try
to
put
some
in
and
again
the
key
change
here
is
is
is
is
what
is
now
stated
as
I
should
use
minimal,
quoting
possible,
and
if
I
had
my
brothers
we'd
say:
must
there
too
as
well?
G
H
Well,
I
was
giving
an
alternative.
I'm
sorry!
This
is
a
long
time,
mail,
user.
First
time
caller.
I
don't
follow
the
email
groups
in
the
atf
enough,
but
you
know
I
work
with
a
lot
of
other
specifications,
including
dns
and
other
things
where
the
process
of
doing
comparisons
involves
doing
all
the
replacements
to
convert
something
down
to
a
canonical
form.
That
is
the
basis
for
comparison.
H
So
on
the
screen,
for
example,
you
know
you
would
handle
the
escaping
for
the
you
know:
food
example.com
you
would
convert
one
or
the
other
to
you
know
the
base
form
that
would
probably
strip
the
quotes
or
keep
them,
and
then
you
do
the
comparison
and
that's
that's
typical.
That's
one
way
that
we
put
wording
in
iets
specifications
about
things
like
this.
B
Yeah,
well,
it's
it's!
It's
a
matter
of
wording,
I'm
a
little
reluctant
to
go
there
to
go
in
that
direction
here,
because
the
potential
interactions
with
with
sftput
have
aided
its
friends
where,
because
of
in
my
judgment,
it
might
have
been
your
badge
you're,
not
judgment
on
unicode's
part,
canonical
form
means
a
whole
lot
of
other
things,
and,
and
those
things
include
things
which
we
specifically
do
not
want
mta's
messing
with.
A
A
Related
to
this
topic,
the
next
slide
recommends
moving
some
text.
The
the
mention
right
now
in
the
current
document
of
the
backslash
comes
after
the
text
on
the
previous
slide
that
uses
the
backslash
and
there's
there's
a
recommendation
here
to
move
this
paragraph
regarding
the
backslash
and
its
usage
before
that,
so
that
it
sort
of
flows
better
talk
about
the
talk
about
the
the
character
before
you
use
its
first
example:
sort
of
thing.
A
Topic
in
the
abstract
is
the
paragraph
shown
here
and
the
the
highlighted
text
in
that
abstract
is
a
discussion
of
mail
submission
protocol.
A
B
I
I
was
afraid
of
making
the
extra
much
longer
getting
us
tied
in
knots.
So
this
is
a
is
an
attempt
at
saying
the
same,
mostly
the
same
thing,
but
but
minimizing
the
side.
References,
especially
the
abstract.
A
A
B
Yeah
part
part
of
what
I'm
trying
to
do
here
is
to
there's
been
some
extensive
offline
discussion
about
this.
I'm
I'm
I'm
confident
that
we
are
going
to
finish
the
as
and
finish
the
ass
in
a
timely
way
with
the
content
we
are
now
expecting
it
to
have,
but
there
are
no
guarantees
about
any
of
that,
and
I
want
to
minimize
references
in
5321
to
the
as
especially
references.
B
A
I
definitely
I
I
personally
like
the
phrasing
here
because,
as
you
said,
it
is
purposefully,
vague.
A
Which
mentions
should,
as
far
as
compliance
with
the
applicability
statement,
which
of
these
protocols,
must
be
compliant
or
must
be
supported
and
which
should
be
supported.
We
do
know
that
there
is
some
difference
in
this
proposal
here
with
what's
in
6409,
because
all
five
of
these
are
shoulds
or
four
of
these
are
sheds
in
6409.
At
the
moment,.
B
I
would
say
get
behind
with
the
understanding
that
when
we
start
seriously
addressing
the
as
we
we're
going
to
review
these
decisions
anyway,
the
short-term
scoop
from
my
standpoint
is
making
certain
that
there's
no
strong
argument
for
saying
anything
about
any
of
this
in
53-21
biz
right,
because
some
of
the
mailing
lists
discussion
implied,
they
were
actually
he'll,
say
this
in
53
21.
This
and-
and
this
particular
approach
says
we're
not
going
to
do
that.
A
A
This
is
mention
of
changing
one
word
in
section
3.9.2
there
is
mentioned
there
is
the
use
of
the
word
forwarding
in
the
sentence.
Difference
difference
between
handling
aliases
and
forwarding
is
the
change
to
the
backward,
pointing
address
in
this
case.
We
believe
this
to
be
a
cut
and
paste
error,
and
the
word
should
be
redistribution.
There,
not
forwarding.
A
A
F
A
I
think
today's
session
may
illustrate
the
need
to
have
this
at
a
time
more
convenient
for
u.s,
east
coast
and
west
coast.
It's
currently
7
45
a.m.
Here
on
the
east
coast
and
I
don't
know
4
45
west
coast,
so
this
seems
a
bit
early.
A
Our
participation
numbers
aren't
again
what
I
thought
they
might
be,
but
does
anyone
feel
strongly
about
having
an
interim
or
not
having
an
interim
on
the
week
of
december
6th,
the
10th?
A
A
Mr
levine
you're
just
joining
the
queue
to
say,
you'll,
show
up
and
then
leaving
the
queue
is
that
what's
going
on
here,.
A
Okay
seems
to
be
support
for
interim.
B
A
And
then
the
last
slide
suggested
scope
for
the
core
applicability
statement.
A
D
Yes,
this
suggested
scope
looks
about
right,
the
we
are
going
as
we
build
the
applicability
statement.
We
are
going
to
be
suggesting
specific
things
to
put
in,
and
those
details
will
get
sorted
out
at
the
time,
but
for
setting
expectations.
A
A
B
Yes,
straight
strictly,
as
participant
or
other
editor
of
anything
that
happens
involved
here,
I
think
we're
gonna
have
trouble
keeping
some
of
these
things
out
of
there
in
practice,
in
particular,
the
the
interconnections
between
6409
and
and
and
nsmtp
are
are
probably
going
to
require
comment,
but
these
are
things
which,
but
but
as
as
statements
of
principles
and
targets,
as
barry
suggested.
I
think
this
is
about
right
and
we
can
sort
it
all
out
as
we
get
there.
F
Yeah
hi
it's,
it
came
up
at
the
last
atf,
the
large
files
emailing
problem.
I
have
not
prepared
anything
for
this
itf,
but
at
some
point
the
dispatch
outcome
last
time
was
that
we
were
going
to
form
a
working
group
for
that
as
well.
So
that
will
probably
also
want
to
to
deal
with
the
email
applicability
statement
at
some
point
it
won't
be
touched
directly,
but
we'll
have
to
be
aware
of
it.
F
So
they
basically
the
large
file
problem,
is
you've
just
taken
a
30
minute
video
with
your
iphone,
and
you
want
to
send
it
to
someone
via
email
or
via
any
protocol
that
doesn't
have
the
capability
to
send
all
of
that
yourself.
And
so
what
we're
winding
up
with?
F
Is
each
provider
having
their
own
way
of
basically
creating
a
url
and
then
sticking
that
somewhere
deep
inside
the
email
in
an
html
as
an
html
link,
with
with
no
context
to
say
that
this
is
an
attachment,
or
this
is
something
that
you
might
want
to
download
and
keep
yourself
at
the
other
end,
there's
something
that
might
want
to
be
virus
checked
on
the
way.
So
the
the
plan
is
to
look
at
what
can
be
done
there,
but
I
did
not
get
to
do
it
in
the
four
months
since
the
last
atf.
F
G
Yeah,
apropos
of
that
particular
comment,
we
actually
we
have
most
of
the
way
to
sketching
out
an
improved
version
of
external
body,
which
is
an
existing
mime
thing
to
make
it
slightly
more
robust.
So
it
so
like
it
has
a
check
summit.
It
has
a
and
it
has
a
date.
G
So
you
can
see
you
can
you
can
virus
scan
it
when
you,
when
you
receive
the
message
and
then
look
at
the
checksum
to
make
sure
it
hasn't
changed
and
stuff
like
that,
so
I
think
it
actually
might
wherever
wherever
we
do,
mime
updates,
that's
where
it
should
go.
I
don't
know
whether
that's
53.22
or
that's
something
else.
G
F
Ron
you're
still
in
the
queue
well,
that
is
the
the
storage
component
that
you
need
to
need
to
define,
how
it
gets
stored
and
how
long
it
gets
stored
for
and
and
whether
the
receiver
takes
a
copy
and
maintains
a
copy
locally
as
well.
So
there'll
be
a
bunch
of
work.
That's
not
just
the
mime
format
itself,
it'll
be
authentication
and
transport
stuff.
H
A
A
Okay
ron
has
left
the
queue
okay,
we
reached
the
end
of
our
slide
deck,
seeing
no
one
in
the
queue
and
nothing
in
the
chat
to
prolong
our
meeting.
I
think
we
can
bring
it
to
a
close
I'd
like
to
thank
everybody
for
showing
up
look
for
further
discussion
on
the
working
group
email
list,
obviously-
and
thank
you
all
for
productive
meeting
and
there'll-
be
a
note
coming
out
soon
about
an
interim
in
early
december.
B
Yeah,
I
I
was
just
about
to
mention
that
there's
been
an
office
conversation
with
the
with
the
co-chairs
about
that
schedule
and-
and
I
and
pete
is
talking
about
pete
mentioned
earlier,
he's
talking
about
spinning
up
and
a
five
three
two
two
revisions
soon
and
and
my
expectation
is
that
we'll
have
a
a
five,
the
next
version
of
five
three
two
one
biz
before
the
end
of
this
month,
so
that
december
schedule
kind
of
assumed
that.