►
From YouTube: IETF108-EMAILCORE-20200729-1100
Description
EMAILCORE meeting session at IETF108
2020/07/29 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
Here
I
can
hear
you,
okay,
good,
I'm
just
trying
to
organize
myself
to
present
slides.
I
haven't
done
this
this
week
yet
so
just
give
me
a
few
moments.
A
A
So
this
me
tech
we're
using
the
taco
this
time
this
new
taco
session
is
being
recorded.
If
you
just
got
the
slides,
you
have
a
link,
you
have
a
jabba
room.
If
you
log
in
into
jabber,
you
will
show
up
in
my
taco
chat
box
and
vice
versa,
and
we
have
a
shared
note,
taking
kodi
md
that
replace
other
part.
Braun
has
agreed
to
be
our
note
taker.
Thank
you.
Braun.
A
If
you
are
new
email,
core
is
a
part
of
itf,
we
are
covered
by
noteworld,
which
covers
ipr
and
other
things.
A
This
is
a
short
reminder
of
various,
not
well
issues,
and
other
things
to
note
is
just
please
be
respectful
to
other
participants.
Even
if
discussions
get
heated,
they
can
still
be
respectful,
and
if
you
want
to
read
a
bit
more,
you
have
a
list
of
rfcs
and
bcps.
A
A
Then
we
talk
about
three
types
of
documents
and
we'll
explain
the
difference
between
them.
One
is
53
22
revision,
153,
21
revision
and
then
coronal
applicability
statement.
A
The
discussions
will
affect
what
exactly
ends
up
being
in
the
charter.
So
so
that's
why
we're
spending
so
much
time
discussing
various
issues
or
potential
issues,
we're
not
planning
to
resolve
all
of
them,
sometimes
just
triage
just
to
sort
of
get
an
idea.
What
kind
of
issues
we
might
run
into
in
the
working
group
and
then
we'll
go
through
the
chat,
propose
chapter
text.
A
A
We
had
rc
821
and
822,
which
are
the
best
well
known
and
their
internet
standards.
We
revised
them
once
to
become
28.
21
28
22
then
end
up
being
proposed
standards,
but
we
we,
when
I
say
we
here-
is
the
community
revise
them
again
to
become
53,
21
and
53
22
and
their
draft
standards
now
process
has
changed.
Draft
standards
doesn't
exist
as
a
level
anymore,
so
the
proposal
on
the
table
is
to
revise
them
to
become
internet
standards.
A
Details
so
proposed
scope
is
I
mean
there
are
so
many
email
standards
that
if
we
start
doing
everything
we'll
just
try
to
build
the
ocean
and
we'll
we
don't
get
anywhere
so
proposal
is
to
start
with
the
two
main
documents.
A
And
as
per
requirements
for
moving
documents
to
internet
standard,
we
can
take
the
stuff
out
and
either
delete
it
completely
or
move
it
to
the
proposed
applicability
statement.
Bcp
document
that
we'll
talk
about
later
at
this
point,
different
people
asked
for
various
things.
We
don't
propose
to
include
inter
internationalized
email
at
the
moment,
just
because
it's
not
the
same
level
of
maturity
and
as
much
as
we
would
like
to
revise
mine.
A
This
is
yet
another.
You
know
four
five
six
documents,
and
we
should
do
this
at
a
later
point.
D
Right
so,
and
yep
and
I'll
take
this
slide.
So
our
proposal
as
chairs
is
that
we
review
for
these
three
documents
right:
the
existing
errata
other
known
issues
and
are
you
on
system.
B
Yes,
I
just
wanted
to
highlight
on
alexei's
previous
what
alexa
previously
said
that
the
main
goal
right
now
the
main
goal
and
for
the
initial
bit
here,
is
to
correct
the
anomaly
that
the
two
obsolete,
specs,
821
and
822,
are
at
a
higher
standard
level
than
the
current
standard
is,
and
so
that's
that's
the
reason
for
keeping
changes
minimal
and
just
getting
that
anomaly
corrected
and
trying
to
defer
whatever
changes
we
want
to
make
beyond
that,
to
the
applicability
that
that's
that's
all
I
wanted
to
highlight.
D
Thank
you,
barry
and
so
just
to
keep
us
on
time.
I'm
gonna
do
this
proposal
relatively
quickly
because
we'll
get
into
the
meets
in
a
second
that,
basically,
we
want
to
address
existing
errata
and
known
issues
and
revise
three
documents
right.
We
want
to
do
the
the
5321-bis
up
5322-bis
and
then
the
the
core
email
applicability
statement.
It
could
be
a
bcp.
D
What
we
call
the
thing
is
less
important
than
it's
the
place
for
understanding,
issues
that
are
cross-cutting
and
that
may
not
need
to
live
in
either
5321
this
or
five
three,
two
two
bis,
but
need
to
exist
as
part
of
the
revision
process
to
bring
those
two
documents:
internet
standard
and
again
to
alexis
point
about
restricted
scope.
D
We
can't
triage
everything,
but
we
do
want
to
discuss
what
we
need
to
on
the
mailing
list,
and
we
do
expect
to
have
most
of
the
conversation
today
to
be
about
the
scope
for
these
documents
and
what
this
group
believes
should
should
and
should
not
be
in
them,
and
so
we're
really
looking
to
find
the
rough
consensus
of
everyone
here.
So
please
speak
up,
use
the
mic
as
we
go
through
this
and
then
from
the
output.
D
E
Sure-
and
let's
see,
am
I
being
heard
well,
you
are
reasonably
yes
all
right,
so
5322
I
am
hoping
is
going
to
be
the
simpler
of
the
documents
to
deal
with
I've
already
put
in
a
bunch
of
errata
changes.
E
If
you
take
a
look
at
the
current
draft
of
5322
abyss,
you'll
notice
that
all
but
three
of
the
changes
from
5322,
which
I've
listed
in
the
last
section
there
are
all
fixes
from
reported
errata
so
except
for
three.
Those
are
a
typo,
some
changes
to
the
references
and
a
small
change
to
the
message:
ied
syntax,
to
split
it
up,
so
that
it's
in
smaller
pieces.
E
That
leaves
me
with
only
three
errata
that
are
waiting
to
be
fixed.
We've
got
one
in
section
3.6,
oh
the
header
field
length
limit,
which
is
basically
someone
reported.
There
is
no
current
limit
on
the
number
of
characters
in
a
header
field
name,
and
should
we
put
that
into
the
syntax,
and
I
was
ambivalent
about
doing
that
because
it
might
affect
other
things.
E
There
was
the
last
one
which
is
simply
putting
a
count
on
the
recent
fields
and
whether
that
would
be
problematic
or
potentially
change
things,
and
then
there's
the
empty
quoted
string.
Let
me
get
back
to
the
empty
quoted
string
in
a
moment.
The
other
two
seem
to
me
fine,
to
make
the
change
if
we
can
figure
out
how
to
do
it
safely.
On
the
other
hand,
I
don't
think
there's
been
any
particular
note
that
these
things
have
caused
implementation
problems.
E
So
one
question
is
yeah:
technically
we
could
put
in
more
clear
abnf,
but
we
don't
want
to
mess
things
up
and
we've
got
a
current
document
that
seems
to
be
implemented
well,
as
far
as
the
empty
quoted
string,
this
may
impact
5321
bis
as
well.
There's
the
question
of
do
we
want
to
allow
for
such
things,
which
the
5322
syntax
allows
much
more
addresses
than
5321
and
we've.
E
E
And
the
question
is:
do
we
want
to
deal
with
that?
All
three
of
these
seem
to
be
the
the
sticky
points,
but
none
of
them
are
exciting,
and
so
what
I
need
excuse
me
for
the
5322.
F
D
Just
jumping
in
quickly
as
an
individual
is,
I
have
actually
seen
an
operational
problem
with
the
headerfield
name
length.
There
was
an
issue
in
open
dkim,
for
I
think
a
decade
with
a
buffer
overflow
that
lived
for
a
very
long
time
that
no
one
hit
until
there
were
some
larger
messages
recently
and
it
caused
some
interrupt
problems.
It
was
mostly
hidden,
but
it
was
a
big
deal
had
to
get
quickly.
E
Oh,
but
that
weren't,
that
was
not
the
proposal
for
the
change.
It
was
simply
the
header
field,
namely
oh
the
field
name,
you're
right,
yeah
yeah.
So
anyway,
dave
you
had
a
question
dave
keeps
popping
in
and
out.
G
Oh
there
we
go,
I
think
I'm
on
now.
Yes,
sorry
about
the
confusion,
so
I
put
this
into
the
jabber
I'll
raise
it.
It's
always
been
bothersome
that
there
are
two
places
that
define
an
email
address
seems
to
me
not
too
traumatic
for
the
goals
here
to
change
it,
so
that
there's
only
one
place
and
the
other
one
just
points
to
it.
E
Yep
and
the
only
trauma
is
at
this
point
in
history:
changing
the
documentation.
You
know
you
know
in
a
way
that
might
cause
some
disruption
and
that's
a
very
nebulous
kind
of
concern.
E
E
Right
and
I
I
will
repeat
that
for
all
three
of
these
things,
for
the
most
part,
the
reason
they
are
still
in
there
is
because
your
dutiful
document
editor
was
ambivalent
about
what
the
right
solution
was
and
would
rather
leave
it
to
someone
else
to
make
the
call.
E
D
D
I
Yeah
just
remember
two
things
as
we're
thinking
about
this.
One
of
them
is
that
there
are
already
a
num
many
cross
references,
typically
between
53
21,
21
and
53
22,
but
maybe
not
exclusively
where
we
have
tried
to
reconcile
differences
by
pointing
one
to
the
other.
The
other
thing
to
remember
is
that
whatever
we
do,
we
probably
cannot
completely
harmonize
needs
to
address.
Seed
seek
syntaxes,
because
5322
permits
the
notorious
name,
phrase
and
and
5321
does
not,
and
allowing
the
name
phrase
in
smtp
would
be
really
disruptive.
I
So
so
we
can't
get
complete
harmony,
even
if
we
can
harmonize
the
mailbox
names.
The
other
observation
I
would
make
if
we
want
to
unify
these
things
at
this
stage
of
the
game,
we
should
probably
unify
them
using
the
ai
model,
bringing
a
third
piece
into
the
puzzle
rather
than
than
unifying
these
two,
but
not
that.
I
H
B
So
my
suggestion
was
to
yes,
but
I
I
agree
that
it
would
be
good
to
merge
them.
I
I
agree
that
it
would
probably
be
best
to
put
them
in
53-22
to
clearly
mark
any
additional
stuff.
We
want
5322
to
have
as
to
mark
that
part
of
the
syntax
separately.
So
it's
it's
clear
that
this
is
only
used
in
message
body
or
you
know
in
message
format
and
not
on
the
wire
in
smtp
and
perhaps
to
deprecate
it,
just
as
we
did
with
the
obsolete
constructs
in
the
23
21.
B
What
are
28
21
and
53
21.
yeah,
like
22,
you
meant.
K
Victor
hi,
can
you
hear
me
yep,
just
fine,
okay,
one
thing
that
I
used
to
run
into
a
bunch
in
5322.
I
don't
know
how
much
of
a
problem
it
still
is.
K
Is
I've
seen
user
agents
failing
to
fold
the
references
header,
making
it
grow
longer
and
longer
and
longer
until
the
the
logical
what
the
physical
line
exceeds
nine
nine,
eight
bytes
and
then
various
mtas
would
start
folding
it,
but
not
necessarily
at
the
expected
boundaries
between
elements
you
know
not
everybody
is
that
clever
and
then
the
thing
starts
becoming
a
soup
of
bad
syntax.
K
It
would
be
nice
to
recommend
that
the
thing
be
strictly
folded
at
each
new
added
references
at
each
new
added
reference
so
that
whatever
logical
length
limit
it
might
ultimately
hit
by
the
time
there
are
a
thousand
replies
or
something
at
least
as
each
one
is
being
added.
It's
not
going
to
push
the
line
limit
because
it's
strictly
folded.
K
I
don't
know
if
that's
the
kind
of
thing
that
you
know
belongs
at
this
stage
5322,
but
it
might
add
a
little
bit
of
interoperability
in
in
that
header,
because
it's
the
one
thing
that
keeps
growing
and
growing
as
messages
go
round
and
round.
So
within
that
header.
E
So
let
me
make
a
suggestion
along
those
lines,
because
that
sounds
like
clarification
text
which
may
be
reasonable
and
the
the
way
that
I
remember
one
particular
as
we
were
going
along.
Someone
reported
something.
Can
you
just
throw
this
in
and
my
suggestion
was
go
ahead
and
put
it
as
an
editorial
errata
or
something
if
you
can
figure
out
a
way
to
do
that
and
say
this
was
not
clear
in
the
original
document.
E
It
would
normally,
I
think,
have
been
flagged
and
the
current
ad
can
confirm
this,
for
me
would
be
flagged
as
hold
for
document
update,
because
it
wasn't
a
change
that
you
know
necessarily
was
yes,
that's
a
clear
intention
that
the
working
group
originally
had
or
something
like
that,
and
then
you
know
we
can
mark
it
as
fixed
once
we
get
it
done.
E
I
you
know
that
at
least
has
been
the
way
I've
been
running
this,
although
a
clarification,
a
short
clarification,
doesn't
seem
to
violate
the
moving
things
to
internet
standard
process,
so
I'm
open
to
whatever
the
ad
wants
to
do
on
this,
but
that
seems
like
at
least
one
way
to
go.
K
E
Because
all
you
want
is
a
short
note
which
just
says
you
know
these
must
be
folded
at
whatever
boundary.
Well,.
E
And
I
think
going
through
places
where
there
have
been
implementation
problems,
especially
if
they're
just
clarifications
would
probably
be
in
scope
for
what
we're
doing
but
yeah.
Let's
try
and
figure
out.
If
we
can
do
something
like
that.
K
Okay,
the
other
thing
I
don't
know
is
some
people
seem
to
think
that
the
individual
header
line,
not
not
the
not
the
field
name,
but
the
individual
header
lines
are,
you
know
somehow
really
restricted
to
the
727,
whatever
characters,
one
typically
expects
for
message
body,
but
in
fact
you
know
we
can
go
up
to
about
the
998
plus
crlf
without
too
much
trouble.
K
K
Those
can
easily
blow
at
98
characters
by
the
time
you
have
a
full
internet
domain
name,
perhaps
repeated
more
than
once
in
a
received
header.
It
easily
approaches
a
thousand
bytes,
but.
K
Unfolded
even
even
in
a
single
component
right,
the
that
you
can't
fold,
you
know
a
lexical
thing
like
received
from
boom.
Hostname,
that's
you
know
200
bytes.
Where
do
you
call.
E
Yeah,
so
I
think
for
both
of
these
at
least
post
a
message
to
the
list
and
we'll
get
to
which
list
in
a
bit,
and
let's
talk
about
whether
we
should
file
the
miserada.
These
don't
sound
completely
like
urada,
but
whether
that's
a
good
bookkeeping.
I
think
they're.
Both
clarifications.
A
I
Yeah,
I
want
to
repeat
a
comment
I
made
several
times
in
the
list,
which
is
the
with
regard
to
most
of
the
things
in
in
appendix
gene.
I
I
I
will
certainly
get
to
on
the
list
that
I
I
would
privately
oppose,
but
I
try
to
keep
that
text
minimal,
neutral
and
people
should
understand
that
with
this
particular
one,
we've
noticed
over
the
years
that
the
quoted
string
syntax
in
smtp,
at
least
is
it
gets,
gets
tied
up
with
various
things
in
various
operating
systems
which
do
their
own,
quoting
and
unquoting
or
or
think
that
quotes
belong
to
them
or
that
single
quotes
versus
double
quotes
or
double
quotes,
versus
single
quotes
have
special
syntax
and,
as
a
consequence,
things
get
quoted
and
unquoted,
and
nobody
knows
what
they
mean
regardless.
I
What
whether
specs
are
clear,
there's
been
confusion
over
the
years
about
whether
a
space
needs
a
backslash
quote.
If
the
whole
string
is
inside
double
quotes
or
not.
I
There
are
some
funny
interactions
with
male
2
uris
and
what
that
syntax
means,
as
as
illustrated
by
the
example
at
the
bottom
and
and
the
fact
that
the
backslash
may
not
need
to
be,
does
not
need
to
be
there
given
watson,
five
three,
two
one,
five,
three,
two,
two
and
and
a
variety
of
other
things.
So
the
question
is
whether
this
is
causing
at
this
stage
in
the
development
of
email
on
the
internet,
enough
confusion
and
complication
in
real
life.
I
Implementations
that
we
either
should
should
take
it
out
entirely
or
or
should
somehow
strip
it
down
to
make
it
less
complicated
and
easier
to
explain-
and
this
obviously
interacts
with
the
with
the
harmony
between
the
address
and
taxes
of
the
of
the
two
specs
and
and
and
so
on.
So
so
that's
an
explanation
of
the
issue
again
at
the
moment,
taking
no
particular
position
on
on
whether
we
should
do
something
or
not.
I
But
noting
that
this
is
one
also
one
of
the
cases
where
we
need
to
be
aware
that
there
are
our
gateway
systems
that
that
transport
male
headers
just
fine
but
but
may
not
use
smtp
for
all
of
their
life
spans
and
that
may
interact
with
this
a
little
bit.
K
Victor
sure,
I
think
spaces
have
worked
well
enough
over
the
years
that
I
don't
see
a
need
to
require
backslashes.
That
seems
a
radical
departure.
Mind
you
in
postfix,
which
you
know
I
work
on
from
time
to
time.
If
you
put
two
spaces
in,
they
may
collapse
to
one,
but
that's
a
bug,
not
a
two
consecutive
ones.
K
I
think
this
660
temporarily
splits
and
then
rejoins
such
things
in
the
recipient
and
mail
commands
though
it
may
be
misremembering
and
the
rejoining
inserts
one
space,
so
maybe
addresses
with
two
spaces,
would
at
the
moment
cause
an
inferability
informability
problem,
but
if
they
do
and
it
becomes
a
problem
in
practice,
it's
a
bug
for
us
to
fix.
I
don't
view
it,
as
you
know,
requiring
any
special
treatment
in
the.
A
Spec
all
right,
thank
you
victor
john,
very
quickly,
and
then
we
need
to
move
on
to
next.
One.
C
A
Next
issue,
so
when
you
see
g
dot,
something
on
the
slide,
it
means
that
it's
from
jones
appendix
g.
Does
anybody
want
to
talk
about
one
yz
reply.
F
A
Sorry,
I'm
trying
to
are
they
ever
used
in
the
wild.
A
A
A
The
proposal
on
the
table
is
that
it's
best
practices
for
use
of
smtp
email
format-
maybe
mime
suggestion
is
not
to
say
anything
about
pop
imap,
jmap
or
civ.
A
A
Practices
like
dmarc,
dkim
and
spf,
they
do
have
a
demarcus,
however
separate
working
group
so
which
is
revising
demarcus.
So
all
the
work
on
dmarc
itself
and
possibly
the
kmspf,
should
happen
there.
So
with
that
in
mind,.
A
Just
another
quick
warning
or
or
note
this
is
a
proposal
straw,
man
from
chairs.
We
put
a
lot
of
issues
raised
again
against
5321
base
into
the
applicability
statement
bucket.
If
you
don't
agree-
and
this
is
a
really
issue
that
needs
addressing
this
5321-
this
say
so-
it's
okay
to
disagree
with.
A
D
So,
let's
see
something
she
is
now
okay
and
then
alexis
before
we
move
on
dave
wants
to
speak.
G
Yes,
thank
you
so
applicability
statements
are
things
that
always
have
very
strong,
intuitive
appeal.
It's
never
clear
to
me
how
useful
they
actually
are,
but
independent
of
any
of
that
this
is
this
would
be
new
work
and
it,
including
it
at
this
point,
seems
like
an
addition
that
isn't
necessary
for
moving
the
the
other
specs
to
full
standard,
and
so
I
suggest
taking
this
out
of
the
critical
path
of
that
effort.
A
Yes,
I
think
the
idea
is
for
if
there
are
some
practice
you
know
like,
for
example,
5321
bis
can
have
some
syntactic
restrictions,
which
is
quite
or
specifies
ingress,
which
is
quite
liberal,
and
then
there
are
some
practices
saying
that
in
reality
you
should
use
a
more
restricted
sub
subset.
A
D
B
Well,
so
the
intent
here
is
that,
specifically,
the
applicability
statement
will
not
get
in
the
way
of
the
other
documents
that
the
proposed
charter
text
says
that
the
moving
5321
and
5322
to
internet
standard
comes
first
and
the
work
on
the
applicability
statement
is,
after
that.
D
E
Yeah
and-
and
this
may
have
been
in
some
way
said
by
others,
but
to
put
a
point
on
it
when
alexi
and
seth
mentioned
this
idea
in
the
first
place.
E
This
seemed
to
me
that
this
was
a
document
that
would
be
at
least
the
internet
draft
form
a
dumping
grounds,
for
this
really
doesn't
belong
in
5321,
biss
or
5322
bis,
or
can
be
removed
in
some
way,
and
we
can
discuss
it
in
a
more
coherent
way
in
this
other
document,
and
so
it
was
a
way
to
drive
those
two
documents
to
completion
and
still
be
able
to
say.
But
we
can
have
the
discussion
that
people
want
to
have
over
here
in
this
document.
E
A
I
was
struggling
with
the
term
for
that
right,
so
there
are
three
types
of
typical
issues
that
we
want
to
triage
today,
because
they
will
inform
the
charter
text
proposal
and
one
set
is
on
the
mailing
list.
There
were
discussions
of
various
recommended,
smtp
extensions
that
should
be
mentioned,
and
what
I
would
like
right
now
is
for
us
to
discuss
whether
they
should
be
must
implement,
should
implement,
can
be
mentioned
or
not
mentioned
at
all.
We
have
four
of
them
if
we
can
talk
about
them
one
at
a
time.
K
K
Pipelining,
it's
just
a
performance
optimization,
so
I
don't
see
it
being
mandatory
to
implement.
There
is
some
history
of
it
being
implemented
incorrectly.
I'm
not
sure
that
much
can
be
said
about
that
other
than
implement
it
correctly.
K
K
8-Bit
mime,
however,
does
feel
like
something.
That's
at
this
point
can
be
reasonably
required
if
the
overall
consensus
is
that
we
can
do
that
not
having
it
just
causes
pain
in
encodings
that
break
dkim
and
so
on
in
mid
transfer,
and
so
it
would
be
good
if
8-bit
mine
were
universal.
K
L
L
A
F
A
Yeah
there
was
quite
a
big
discussion
on
dsns
and
stuff
like
that.
If
I
can
just
quickly
talk
as
a
participant,
I
think
enhanced
reply
codes
is
really
no
brainer.
They
should
always
be
used
and
implemented.
A
D
B
B
A
All
right,
if
do
people
still
hear
me,
can
you
people
confirm?
I
think
I
lost
audio
first.
A
Right
if
there
are
no
more
comments
on
this,
let's
talk
about
the
next
topic.
A
Terminology
there
are
various
set
of
roughly
related
issues:
john
talks
in
g11
about
smtp
client
and
servers,
senders
and
receivers
how
this
this
changed
in
5321
and
whether
they
should
be
rolled
back
to
the
earlier
terminology.
A
B
A
A
Harold,
if
you,
if
you
can
talk,
talk
first
and
then
victor
after
you.
A
Okay,
did
you
hear
me?
Yes,
yes,
we're
here.
I
think
I
can
hear
you
now,
so
I
suspect
other
people
can
do
as
well.
Okay.
So
the
point
I
was
trying
to
say
is
that
if
we
use
the
terminology
in
eight
to
one
and
eight
to
two,
then
we
cannot
put
it
in
the
applicability
statement
because
we
need
it
need
it
before
it's
ready.
A
K
Good
point:
victor
yeah,
I
think
the
only
thing
I'd
add
to
that
is
that
by
reference
to
5598,
it
sounds
a
pretty
good
idea
to
me,
where
it's
not
required
in
the
core
document,
but
is
something
additional
words
in
the
applicability
statement
should
probably
reference
rather
than
redefine.
K
F
F
A
Right
anybody
else,
john,
it
doesn't
seem
like
we
can
hear
you.
So
if
you
like
to
maybe
type
your
comment,
crew
very
quickly,.
A
D
A
K
Yes,
victor:
are
we
still
going
to
talk
about
53,
21,
biz
and
specific
items,
or
did
I
miss
the
opportunity
to.
A
Items
the
there
are
follow-up,
slides,
okay.
Well,
I
mean
a
lot
of
a
lot
of
according
to
chairs
a
lot
of
issues
rate
land
and
you
know,
seem
to
be
more
applicable
for
applicability
statement.
That's
why
they're
in
this
section,
basically.
K
K
K
One
is
that
we
have
this
552-452
thing,
that's
kind
of
a
sore
spot
in
5321
that
I
would
like
to
see
corrected
the
you
know
that
turned
out
to
be
a
disaster,
and
we
quickly
yanked
the
treating
552
is
4-5-2
and
positive
certainly
does
not
do
any
such
silly
thing,
but
respect
tells
us
to,
I
believe,
john,
has
an
issue
for
this.
One.
A
K
Sorry,
okay
and
the
other
one
was.
I
also
asked
about
554
greetings,
I'm
not
sure
if
that
got
recorded
the
sort
of
a
question
as
to
whether
that's
a
message,
level,
failure
or
a
try.
Another
mx,
you
know
a
response
and
that
could
be
clarified.
B
J
J
A
A
C
K
K
Victor
go
ahead,
so
mostly
what
john
said.
The
only
thing
is
that
on
port
25,
right,
not
submission
if
you're
using
I
address
literals
in
a
low,
expect
friction.
I
know
there
are
some
strong
feelings
about
folks
who
say
that
that
you're,
then
you
know
in
cardinal
sin
and
it's
taboo
and
so
on,
but
that
that
horse
has
left
the
barn
and
so
elo.
C
M
Keith
yeah,
I'm
I'm
pretty
firmly
against
a
prohibition
on
ip
address,
literals
in
mail
and
receipt,
because
there's
a
lot
of
things
that
use
smtp
that
aren't
connected
to
the
public
internet
and,
I
think,
there's
a
general
problem
that
we
have
in
ietf
is
to
assume
that
our
protocols
are
only
for
use
on
the
public
internet
and
that
doesn't
really
match
reality.
So
I
think
we
need
to
recognize
that
the
scope
of
this
is
is
wider
than
that.
So
that's
that's
the
short
version.
D
H
D
I
guess
not
dave
you're
up.
G
So
I
will
also
suggest
that
there's
a
difference
between
what
is
acceptable
practice
in
the
public
internet
versus
what
needs
to
be
allowed
in
the
protocol
engine
and
that
there
are
environments
in
which
it
is
convenient
and
safe
to
use
ip
address.
Literals
and,
in
fact,
may
be
the
only
viable
choice
because
they
don't
have
or
don't
want
the
rest
of
the
infrastructure,
that's
different
than
the
public
internet
and
that's
fine.
G
And
so,
let's
distinguish
between.
I
shudder
to
say
this,
given
my
earlier
posting
the
applicability
restriction
in
the
public
internet
versus
what
the
protocol
engine
allows.
A
D
A
How
much
that,
how
much
time
ahead
of
the
schedule
are
we.
D
A
A
M
The
same
comment
or
kind
of
saying
comment
as
last
time:
I
don't
think
this
should
be
a
restriction
imposed
by
the
smtp
protocol.
I
think
there
are
contexts
in
which
you
might
say
only
public
fully
qualified
domain
names
are
applicable
here,
but
I
don't
think
it
should
be
strictly
aligned
with
smtp.
K
K
You
know
it
should
be
as
qualified
as
you
know,
makes
it
unambiguous
between
sender
and
client.
In
other
words,
don't
strip
off
components
and
send
only
part
of
the
name.
Whatever
you
think
the
name
is,
you
know
the
whole
name
send
the
whole
name
and
that
that's
what
fully
qualified
means
to
me
doesn't
imply
anything
about
the
dns
per
se,
rather
that
you
just
shouldn't
arbitrarily
truncate
names.
Assuming
that
that's
a
good
idea.
A
F
E
We
go
victor
significantly
shortened
my
comment,
but
I
think
this
is
the
ideal
case
of
get
it
out
of
the
protocol
document
and
into
a
separate
applicability
statement
where
you
could
describe
where
it's
reasonable
to
use
non-fully
qualified
domain
names,
whatever
that
might
mean
where
it's
reasonable,
to
use,
non-resolvable
ones,
etc,
that
that's
what
the
document
this
kind
of
document
should
be
doing,
and
the
protocol
document
should
be
clear
about
what
the
syntax
is
to
use.
Otherwise,.
A
Sounds
good
anybody.
I
Yeah,
yes,
you
can
just
just
an
observation
about
keith's
comment.
I
Unfortunately,
or
fortunately,
icann
decided
this
to
allocate
a
few
thousand
top-level
top-level
domains
and
fortunately,
unfortunately,
when
we
did
53-21,
we
decided
it
was
okay
for
them
to
have
mx
records
and
as
a
consequence
of
that,
we
cannot
prohibit
single
component
domain
names
because
they
may
be
fqdns
whether
we
should
have
introduced
years
ago.
The
the
possibility
of
domain
names
into
email,
with
trailing
periods
like
the
dns
spec
allows,
is
a
separate
issue,
but
I
suggest
that
adding
that
feature
now
might
cause
more
problems
than
it's
worth
right.
A
Okay,
let's
go
I'm
not
sure
who
was
first
I'll.
Let's
keep
first.
M
I
Well,
well,
I
I
I
I,
I
think,
we're
free
to
disallow
them
an
email.
The
difficulty
is
that
when
we
did
fight
321,
we
made
an
explicit
decision
parenthetically
over
my
objections
to
allow
them
to
allow
mx
records
there.
So
for
the
last
company
years,
this
has
been
explicitly
valid
and
I
don't
see
how
we
can
invalidate
it
without
getting
ourselves
into
trouble.
Much
as
I'd
like.
K
Yeah
on
the
topic
of
single
label,
fqdns
with
mx
they're
dead
on
arrival,
they
they're
not
going
to
be
interoperable
nobody's
using
them.
Currently
we
can,
you
know,
even
though
the
dns
allows
publishing
over
mx
records
there,
they
won't
work
in
in
internet
email,
so
we
should
say
so.
A
Right,
john,
the
other.
C
John,
I
have
actually
been
tracking
the
mx
records
in
the
root
zone
for
a
couple
of
years,
and
I
can
confirm
that
john
is
correct.
There
are,
there
are
a
bunch
of
mx
records
and
victor
is
correct.
They
don't
work,
so
I
think
we
would
be
doing
the
world
of
favor
to
to
say
that
wouldn't
mistake
and
don't
expect
them,
you
know
we
don't
allow
them
and
don't
expect
them
to
work.
I
We
should
probably
we
should
probably
take
this
the
mailing
list,
but
but
for
whatever
it's
worth,
that
decision
would
make
me
personally
very
happy.
Okay,.
G
So
my
understanding
is
that
with
the
creation
of
tlds
for
organizations
and
the
like,
there
is
a
move
to
permit
mx
records
and
the
like
in
tlds.
G
So
I
think
this
is
another
case
of
distinguishing
between
what
protocol
engines
should
allow
or
not
allow
versus
what
operational
practices
might
be
at
a
given
time.
We
shouldn't
bake
in
operational
practices.
That
might
actually
be
sorry.
We
shouldn't
bake
in
prohibitions
into
the
protocol
engine
against
practices
that
actually
are
quite
reasonable
in
a
technical
sense,
but
might
not
be
operationally
permitted
now,
but
then
tomorrow
they
might
be.
D
D
If
we
can
delete
things
great,
but
we're
only
looking
to
add
things
if
they're
clarifications,
and
we
want
to
make
sure
that
the
applicability
statement
reflects
modern
practices
but
to
the
extent
we
can
keep
five
through
two
one
and
five
to
two
changes
minimal
that
that's
the
absolute
intent
here,
barry
or
alexi
to
either
do
anything
else.
You
just
want
to
say
before
you
jump
into
the
charter
text.
D
A
A
Yeah,
so
this
slide
is
basically
talking
about.
We
are
going
to
follow
process
in
rfc
6410
for
booming
documents
to
internet
standards,
limited
review
restrictions,
corrections
clarifications
only
dealing
with
the
rata
and
describing
that
it's
verified
the
rata
or
errata
martyrs
held
for
document
updates.
A
A
E
It
just
is
still
there.
Yes,
I
accidentally
clicked
myself
off,
so
the
only
complaint
I
have
about
this
bit
is
already
published
as
standards
track
rfcs.
I
think
this
clearly
needs
an
addition
of
published
to
standards
track
rfcs
that
are
eligible
to
move
to
internet
standard.
E
I
I
you
know,
I
I
don't
want
arguments
about
well.
We
should
really
include
this
and
it's
in
a
standard
track.
Rfc.
Unless
that
standard
track,
rfc
is
dead,
clear
that
it's
already
widely
deployed
and
interoperable
and
could
move
to
internet
standard
itself.
It
shouldn't
be
included
in
5321,
business
50-22-bits.
G
So
the
going
off
on
this
reference
to
standards
track
rfcs.
It
occurs
to
me
that
that's
that
for
including
references
to
standards
track,
the
kind
of
concerns
pete
is
raising
are
really.
G
A
All
right
dave,
I
will
encourage
you
and
others
who
think
that
a
specific
informational
rfc
should
be
considered
for
inclusion
to
bring
this
up
on
the
main
list.
G
A
Right,
I
initially
had
concerns
about
this
standards
truck
as
well,
and
I
had
a
couple
of
documents
in
mind
when
I
looked
at
them.
I
realized
that
one
of
them
is
already
internet
standard
and
the
other
one
is
proposed.
A
B
I
know
I
I
think
the
right
wording
here
might
be
unless
they
are
already
at
a
sufficient
maturity
level
to
be
to
move
to
internet
standard,
and
that
should
cover
us.
B
Well,
so,
unless
they
are
of
sufficient
mature
already
of
sufficient
maturity
to
be
considered
as
internet
standard
or
some
some
texts
like
that
that,
when
I
say
maturity,
I
don't
mean
the
formal
maturity
levels
in
the
ietf
sense.
But
we
all
know
what
a
mature
mature
spec
is
and
what.
E
I
I
want
to
reinforce
what
dave
said
here
about
informational,
because
the
the
presumption
is
if
one
of
these
documents
refers
to
an
informational,
it's
going
to
non-normatively
reference,
it
right.
It
may
point
to
a
document
that
is
informational
that
fills
in
a
gap
and
I
think
that's
perfectly
reasonable.
E
I
I,
the
idea
of
the
charter
is
to
limit
stupidity
in
part,
and
we
definitely
want
to
be
able
to
say
no
we're
not
including
things
that
are
random
proposed
standards,
but
we
don't
want
to
preclude
making
an
informational
reference
to
some
informational
document.
That
really
is
well
understood
and
and
well
accepted,
and
it's
never
going
to
be
at
a
level
that
is
considered
internet
standard,
it's
just
a
sufficiently
mature
informational
document.
E
D
Fine
yeah-
and
I
I
think,
potentially
taking
what
barry
dave
and
peter
said,
we
could
probably
do
all
this
with
just
saying.
However,
no
new
normative
protocol,
extensions
or
amendments
would
be
considered
unless
they're
at
a
sufficient
inventory
level
to
move
to
internet
standards
or
something
like
that.
So.
D
Yeah,
I
think
we
can.
We
can
thread
that
needle
in
the
charter
text
and
make
sure
dave's
point
is
handled,
but
also
keep
the
bar
very
high
for
anything.
Someone
wants
to
fold
in
right.
Thank.
E
Yes,
pete
to
address
something
dave
said
earlier:
maybe
some
text
in
here
making
it
clear
that
this
document
is
not
locked
with
5321
bis
5322
this
or
that
we're
working
on
the
the
protocol
specs
first
and
this
will
be
published
after
even
though
we're
going
to
be
dumping
things
into
here.
At
the
same
time,.
F
D
A
All
right,
if
there
are
no
other
comments,
then
we
are
basically
nearly
done.
There
is
one
more
slide.
A
Basically,
several
people
suggested
that
we
don't
need
to
say
this.
A
A
A
True,
it
is
true,
but
you
know
some
people
were
concerned
that
we
are
trying
to
you
know
this
is
all
we're
doing
and
you'll
never
be
able
to
to
do
anything
else
again.
Kind
of
thing
so.
N
I
don't
have
strong
feelings
there,
but
it's
always
seemed
odd
to
me
when
working
charters
say
things
about
you
have
to
recharter
to
do
things
when
we
can
always
recharge
it
to
do
anything
right.
E
Yeah
dave
made
a
similar
comment
on
the
list
and
while
I
tend
to
agree
that
this
particular
item
is
utterly
superfluous,
you
know
charters
do
have
a
social
aspect
to
them
and
one
of
the
things
that
we've
already
sort
of
heard
inklings.
F
E
On
the
list
is
people
who
think
that
their
extension
that
needs
to
be
dealt
with
needs
to
be
dealt
with
immediately,
and
the
answer
is
we're
not
shutting
you
out
we're
simply
saying
that
it
gets
done
later
after
we
get
this
stuff
done,
and
I
don't
think
it's
bad
to
say
such
a
thing,
but
it
is
completely
a
fluff
absolutely
at.
B
J
We
have
heard
similar
things
in
academy
and
I
think
it's
one
of
the
good
things
about
that
is.
This
gives
the
expectations
of
what
the
working
group
is
supposed
to
do,
and
it
also
gives
you
the
idea
that,
yes,
after
these
three
documents,
while
we
are
working
on
these
three
three,
these
three
documents-
we
are
not
taking
any
other
work.
After
that
we
can
start
working
other
things,
so
it's
people
are
expecting
to
okay,
we
might
start
working
later.
D
Thank
you
and
I'm
of
a
similar
opinion
that
I
think
it's
worth
the
fine
post,
even
though
it's
obvious
there's
lots
of
other
work
that
might
come
out
of
this
and
to
say
we
do
intend
to
look
at
this
other
work
and
we'll
make
decisions
about
it.
D
That
explicitly
feels
valuable
in
the
charter,
but
purely
from
a
signposting
like
you'll
know,
we
are
going
to
look
at
other
proposed
work,
not
that
you
know
the
the
general
case
that,
of
course,
we
can
take
out
more
work
later,
but
that
we
intend
to
take
on
more
work
later.
But
this
is
the
rest
of
the
charter's
muscle
scope.
A
D
We
have
about
15
minutes
left,
so
I
think
what
barry
had
said
earlier
is
once
you're
at
the
end
of
the
charter.
We
might
even
look
at
some
of
the
work
or
we
could
probably
break
early,
but
does
anyone
here
have
a
strong
opinion
about?
Do
we
want
to
actually
dig
into
things
or
do
we
want
to
anyone,
have
any
items
they
want
to
address
with
respect
to
the
charter
or
the
scope
of
work
we've
discussed
so
far.
B
Well,
let
me
throw
in
one
thing
here,
so
let
me
ask
somebody:
are
there
any
objections
to
a
charter
approximately
along
these
lines?
Does
anyone
think
we
should
not
proceed
with
this.
B
And
while
we're
waiting
for
people
to
ring
in
for
that
I'll
ask
the
chairs,
do
you
have
a
sense
of
when
I
might
expect
to
get
this
charter
on
my
e-desk.
A
B
Anyone
ring
in
to
object
so
carry
on
with
getting
started
with
the
issues.
A
So
if
people
want
to
talk
about
any
other
issues
in
5321,
I
do
have
sort
of
like
I
don't
have
extra
slides.
I
have
I
can
project
agenda,
which
has
mentioned
a
few
other
issues.
So
actually,
before
we
dig
into
the
issues,
can
you
go
to
the
last
slide?
A
Fine,
I'm
very
happy
for
you
to
short
circuit
this
and
then
just
if
people
want
to
discuss
smtp
extensions,
they
should
still
use
itf-smtp
atf.org.
A
Which
is
what
we
were
using
for
discussing
the
charter
so
we'll,
but
we
will
get
the
mailing
list
set
up
for
us.
B
As
soon
as
I
can
get
that
requested,
and
and
that
will
be
the
worst
mailing
list
when
the
working
group
is
charged.
F
F
E
Yeah,
I
think-
and
I
think
victor
was
the
one
who
brought
this
up.
I
don't
think
there's
any
harm
in
bringing
all
of
those
sorts
of
suggested
clarification
kinds
of
issues
to
the
list
to
sort
of
put
on
the
docket
of
things
we
have
to
figure
out
whether
they
go
in
or
not.
I
don't
think
it's
worth
discussing
any
one
of
them
here.
I
think
they're,
all
pretty
straightforward,
it's
more
a
question
of
do
they
belong
in
the
document
or
not.
F
K
Oh
okay,
I
don't
know
that
I
originally
stepped
from,
like.
I
noticed
that
there
was
the
suggestion
to
add
star
tls
as
a
required
extension
and
certainly
most
of
my
work
on
smtp
in
the
tls
space.
But
one
thing
I
wanted
to
get
a
feel
for
is
you
know
how
strongly
do
people
feel
about
setting
floors
and
then
you
know
tracking
ietf
recommendations
on
the
latest.
You
know
preferred
version
of
tls.
K
You
know
if
we
include
tls
in
the
as
a
required
extension.
You
know.
Do
we
then
start
saying
things
like
you
must
do
at
least
tls
1.2,
or
else
the
world
ends
in
smtp.
What
I
find
often
is
that
folks
will
insist
on
very
stringent
tls
and
then,
when
it's
apps
and
say,
oh
well,
I
can't
do
tls.
K
Let's
do
clear
text
instead,
that'll
be
more
secure,
so
I
would
like
to
see
a
little
bit
of
sanity
prevail,
but
I
know
the
issue
gets
contentious
when
one
tries
to
to
say
that
in
this
protocol
you
know
the
usual
requirements
about
you
know.
Minimum
versions-
and
you
know
absolute
security
and
so
on,
can
be
relaxed,
and
so
you
know
we
need
to
be
a
little
bit
careful
about
how
we
go
about
that.
You
know,
I
would
say
something
like
barring
cross
protocols,
attacks
support
all
reasonably.
K
You
know
current
early
currently
in
use
tls
versions,
even
if
they're
deprecated
elsewhere,
but
you
know
some
folks
may
be
strongly
opposed
to
such
a
radical
ideas.
K
But
but
tls
opens
a
can
of
worms
because,
unlike
this
very
stable
specification,
it
keeps
changing
on
us
from
time
to
time
and
causes
bitra,
and
I
don't
know
how
we
deal
with
that.
A
This
issue
on
the
mailing
list-
please
do
raise
it.
I
will
so
that
at
least
we
can
track.
A
L
Gem
hi,
I
guess
I'm
on
yes,
thanks
in
in
response
to
victor's
comment,
yeah
I've,
I've
kind
of
got
the
same
dilemma.
Regarding
start
tls
I
mean
there's,
there's
just
a
whole
slippery
slope
of
things
that
that
you
could
require
there.
So
I
guess
my
feeling
is
at
this
level.
We
should
require.
L
I
mean
it's
a
it's
a
good
idea,
but
I
mean
there's
if
you're,
if
you're,
not
since
implementations
currently
are
typically
not
verifying
the
certificates
or,
as
victor
points
out,
they're
they're,
frequently
falling
back
to
to
clear
text
anyway,
there
isn't
a
whole
lot
of
security
benefit
in
being
very
specific
here.
As
far
as
I
can
tell.
I
Yeah
with
regard
to
tls
issue,
I
think
a
a
pointer
that
says
there's
a
strong
recommendation
in
a
non-normative
player
that
says
it's
a
strong
recommendation
that
that
all
this
stuff
be
encrypted
would
be
entirely
appropriate.
I
But
if
we
start
making
it
a
requirement,
we're
gonna
open
a
whole
series
of
can
of
worms,
cans
of
worms,
some
of
which
have
been
mentioned,
and
the
other
is
the
the
rather
complicated
problem
that,
despite
current
iatf
recommendations,
there
are
are
still
complex
issues
about
the
the
trade-offs
between
link,
encryption
and
and
relay
vulnerability
versus
end-to-end
encryption,
which
therapy
always
off
in
a
way
which
would
hide
addressing
information.
I
So
again,
I
think
an
informational
and
recommendation,
and
as
or
bcp
pointer
here
might
be
reasonable
and
we
should
discuss
it,
but
a
normative
requirement.
Reference,
I
think,
gets
us
in
deep
trouble
and
I
want
to
note
for
anybody
who
hasn't
been
noticing
that
there's
been
a
thread
in
the
in
the
jabber
room,
which
may
be
relevant
to
several
discussions.
We
had.
A
Earlier
in
relationship
to
this,
would
anybody
want
to
relay
any
of
the
comments
made
in
java
earlier.
A
H
Yeah
do
a
comment
certainly
about
the
single
component
domain
parts.
John
talked
about
that
quite
a
bit
in
jabber
and
it
I
think
everyone
came
to
the
same
agreement
on
it,
but
maybe
it's
not
particularly
well
documented
in
the
notes.
Yet
maybe
I
better
go
back
and
fix
that
that
the
the
low
level
substrate
should
not
specify
that
you
can't
have
single
component
parts,
because
not
only
they
used
a
lot
in
in-house
setups,
but
they
have
been
made
legal
in
the
past.
H
But
certainly
again,
we
could,
in
the
advice
say
you
shouldn't
be
using
all
these
things
on
the
public
internet,
even
if
they
are
allowed
by
the
the
low-level
technology.
I
think
that
that
covers
most
of
what
was
said.
We
shouldn't
we
shouldn't
start
denying
things
or
making
things
illegal
that
we
have
allowed
in
the
past,
but
we
should
certainly
say
we
strongly
recommend
against
using
these
parts
in.
F
I
Yeah,
on
the
other
hand,
one
of
the
things
we
should
put
in
our
queue
somewhere
is
it.
If
we're
going
to
allow
these
single
component
names,
then
we
go
through
both
documents
and
make
certain
that
all
of
the
text
about
short
names
and
abbreviated
fpdns
be
taken
out
of
the
be
out
of
there.
I
hope
it's
out
of
there
already,
but
I
don't
have
much
confidence
in
it,
and
this
this
interacts
with,
with
some
of
the
comments
very
early
in
the
in
the
session
about
5d22
requirements.
I
So
again,
I
no
no
specific
comments,
but
we
should
should
definitely
give
give
ourselves
an
action
item
to
very
carefully
make
that
review.
D
Okay,
I
think
we
are
at
the
end
of
everything,
any
final
thoughts,
alexi
or.
A
D
In
that
case,
I
think
we're
at
the
end.
Thank
you.
Everyone,
thank
you,
pete
and
john
for
leading
the
discussions
of
your
documents
and
look
for
a
new
mailing
list
in
the
next
couple
of
weeks.
Oh
barry.
B
And
thank
you
guys
for
sharing.