►
From YouTube: IETF110-EMAILCORE-20210310-1200
Description
EMAILCORE meeting session at IETF110
2021/03/10 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
Enjoy
the
beautiful
view
of
my
boiler
in
the
background
you
know
this
is
very
important
for
every
itf
meeting,
so
I'm
alexi
in
case
you
don't
know
we
have
a
new
co-chair
todd
todd.
Can
you
show
show
your
video,
so
people
can
have
a
look
right,
so
I'm
I'm
mostly
going
to
be
driving
slides
todd
will
present
several
issues
as
well.
I'm
thought
we'll
keep
a
look
for
the
queue
for
these
discussions.
A
We
have
two
hours
today,
we'll
use
as
much
as
as
as
we
can.
If
we
get
exhausted
early,
then
we'll
finish
early,
if
not
we'll
use
the
whole
time.
So
thank
you
for
coming.
A
A
A
You
are
assuming
you're
in
a
meeting
you're
in
the
right
place.
Hopefully
jab
room
is
integrated
with
meet
echo,
you
don't
need
to
go
to
meet
to
go
dmd,
so
we
braun
has
agreed
to
be
our
scribe.
He
will
be
taking
note
in
codemg,
which
you
can
see
the
link
here.
Everybody
is
attending
the
meet
echo
is
recorded
automatically,
so
you
don't
need
to
go
to
meet
to
the
dmd
and
add
your
name
there,
and
this
session
is
being
recorded.
A
Here's
the
agenda.
I
reshuffled
the
tickets
a
little
bit
because
we
had
the
recent
discussion
about
four
four
four,
five,
two
versus
four
five,
five,
five:
two.
I
moved
it
toward
the
end
just
because
I
think
it
might
take
a
bit
longer,
because
I
would
really
like
to
get
a
few
tickets
done
like
trace
header
fields,
or
at
least
you
know,
as
done
as
we
possibly
can.
A
If
not,
let's
get
started
with
the
first
ticket.
A
A
Some
definitions
in
53,
22
and
21,
a
lot
of
header
fields
were
added
in
other
rfcs
and
were
described
as
trace
header
fields,
whatever
it
means.
A
So
with
this
I'm
going
to
let
pete
talk
about
his
changes,
which
I
split
into
yeah.
He
pete
did
for
slides
for
us
so
I'll.
Let
him
talk
about
this.
A
So
there
was
sort
of
four
type
of
changes
proposed
pete
suggested
some
text
based
on
net
feedbacks
and
alessandros
and
mine.
A
A
C
So
yes,
this
was
already
posted
to
the
list.
I
guess
my
only
question
is:
does
someone
does
anybody
here
have
issues
with
this
particular
part?
This
seemed
like
the
non-controversial
bit.
A
I'm
personally
quite
happy
with
it,
I
think,
would
be
nice
to
okay.
C
E
D
C
I
mean
it,
you
know
this
is
actually
more
than
it
said
in
5322,
because
that
first
line
wasn't
even
there.
It
basically
totally
pushed
it
off
to
53-21.
So.
D
C
C
Next
slide
next
slide:
oh,
yes,
okay!
There!
We
go
sorry!
So
in
this
one
I
simply
at
the
top
in
the
syntax
portion.
What
describes
the
syntax?
It
adds
the
one
or
more
receive
fields
or
other
fields
indicated
by
optional
field
below
that
are
defined
by
other
specifications
as
belonging
within
the
trace
fields.
Grouping
again,
no
one
on
the
list
seem
to
have
a
problem
with
this
there's
the
question
of
the
actual
syntax
and
we'll
get
to
that
in
a
second.
But
the
wording
of
this
seemed
relatively
uncontroversial.
A
C
Yeah
the
change
to
here
is,
is
you
know
simple?
I
I
just.
I
wanted
to
make
sure
that
the
general
structure
of
this
was
okay
with
folks.
C
Okay,
now,
let's
get
on
to
the
nitty-gritty,
which
is
the
syntax
itself,
so
next
slide.
Okay,
so
currently
in
367,
we've
got
an
optional
return
path,
followed
by
one
or
more
received,
and
so
what
I
put
into
the
the
proposal
on
the
list
was
optional
return
path,
followed
by
one
or
more
either
received
or
optional
fields,
and
then
the
question
of
what
about
a
loan
return
path?
Can
you
do
that,
and
so
I
wrote
up
some
syntax
to
accomplish
that.
C
That
says:
okay!
Well,
you
can
either
have
a
lone
return
path
or
an
optional
return
path
and
one
or
more
received
or
optional
fields.
F
Oh
look,
it
works,
I
think,
on
the
mailing
list
I
was,
I
was
pushing
for
your
your
your
option
with
no
receive
fields
at
all,
but
actually
I
poked
around
as
far
as
I
can
tell
in
the
existing
practice
anything
that
anything
that
adds
a
return
path
will
add
at
least
one
received,
even
if
it's
injected
internally.
So
I
think
your
your
original
proposal,
with
at
least
one
actually
matches
reality
and
it's
somewhat
and
it
avoids
weird
situations
where
you
have
where
you
have
a
receive
block
that
contains
nothing
at
all.
F
A
A
Received
so
I
think
we
need
to
accommodate
that,
because
this
spec
net's
argument
is
that
this
spec
is
more
generic
than
just
for
smtp,
so
which
I
don't
agree.
C
Right
and
I
was
gonna
look
beforehand
and-
and
let
me
take
a
quick
look
here
yeah
so
I
mean
one
possible.
C
A
C
It's
not
but
there's
lots
of
things
in
obsolete
which
are
well.
We
accept
that
such
things
exist
in
the
universe,
but
you
shouldn't
send
them
on
the
wire
and
now
what
ned's
talking
about
is
in
an
imap
context,
which
is
wire.
So
I
I
don't
know
that
it
really
satisfies
that
and.
C
Right,
assuming
that
john
and
alexi
just
haven't
lowered
their
hands
yet
dave
did
you
want
to
hop
in
here.
G
So
what
what
I
think
I
heard
you
describing
is
imposing
a
requirement
for
fields
that
have
not
been
required
in
the
past
and
for
which,
even
though
there's
a
practice
that
might
match
that
requirement,
there's
no
operational
need
to
impose
the
requirement
so
demanding
that
there
be
trace
fields
doesn't
make
a
lot
of
sense
to
me
in
the
absence
of
a
compelling
operational
requirement
for
that,
similarly,
putting
things
in
obs
field,
I
I
don't
understand
the
utility
of
bob's
field.
G
C
Yeah,
well,
what
do
I
want
to
say
I
I
I
apologize
I'm
on
mute.
I
don't
appear
to
be.
Oh,
maybe
art.
Can
you
hear
me
now?
Oh,
the
system
is
more
intelligent
than
any
of
us
expected.
C
It
wow
it's
really
intelligent
yeah.
I
I
hereby
apologize
for
my
20-year
less
of
itself
yeah
the
ops
field
thing
had
we
had
to
do
it
over
again.
We
might
have
had
a
different
discussion
because
I
hate
it
now
myself,
but
so
dave.
Can
you
hear
me.
G
C
Right
so
I
I
apologize
for
my
20-year
less
age
ago
self
yeah,
the
obs
fields.
If
we
had
to
do
it
over
again,
I'd
have
argued
differently
that
they
were
meant
to
be
you're.
Gonna
have
to
deal
with
messages
that
have
these
things,
and
so
for
parsing
purposes.
C
You
might
look
at
the
obs
fields
to
explain
how
to
parse
what
might
otherwise
look
horrible
from
the
the
the
true
and
you
know,
correct
fields.
In
section
three,
I
I
yeah
for
whatever
that's
worth.
G
The
the
audio
issue
I
was
having,
I
think
I've
now
figured
out
and
it's
bizarre
if
the
microphone
is
on.
So
I
can
talk
like
I'm
talking
now,
then
I
can't
hear
you
probably
anyone
else
talking
and
I
have
to
go
on
mute
in
order
to
hear
you,
which
is
really
interesting.
G
I
mean
at
one
level
I
like
that
idea,
but
it's
not
actually
conducive
to
conversation.
At
any
rate,
what
you've
just
done
is
describe
an
interesting
idea
for
the
obs
field,
but
it
again
has
nothing
to
do
with
actual
practice,
and
so
imposing
a
theory
of
its
use
is
an
interesting
academic
exercise,
but
doesn't
have
much
to
do
with
the
real
world
and
I'd
advise
against
our
being
clever.
That
way.
C
Right,
I
I
don't
disagree
with
you
and
it,
like.
I
said
in
this
particular
case.
You
know
ned's
talking
about
well,
I'm
on
this
imap
server,
I'm
creating
a
message
where
I'm
you
know
somehow
editing
a
message
to
add
this
stuff.
That
is
currently
not
acceptable
in
the
syntax,
so
it
does
seem
like.
Maybe
we
should
make
a
change
somehow.
G
Comment
was
sorry
effort.
It
takes
to
deal
with
the
trace
field,
the
more
it
raises
the
question
of
why
it's
worthy
of
this
energy,
given
that
there
was
no
concern
about
the
trace
field
until
the
delivered
two
stuff
came
up
and
the
nature
of
this
working
group
is
to
fix
significant
problems
now
again
in
the
abstract.
I
get
what's
driving
this
because
there's
inconsistencies,
etc,
and
but
there
hasn't
been
an
operational
problem
that
this
is
solving.
There's
an
intellectual
problem.
G
A
A
C
G
Again
as
a
construct
that
sounds
great
what
what
and
and
were
the
goal
to
produce
a
much
much
cleaner
version
of
these
specifications.
That'd
be
great.
I
didn't
understand
that
to
be
the
goal
of
this
working
group,
I
thought
the
goal
of
this
grouping
was
dramatically
more
narrow
and
so
for
all
that
you've
just
said
and
described.
G
I
don't
believe
it's
actually
had
operational
problems
that
it's
caused.
It's
causing
problems
in
one's
desire
for
clarity
and
consistency
and
purity
about
the
term
trace
field.
I
get
that,
but
nothing
that
I
know
of
that
actually
has
affected
operations
or
implementations.
H
This
question
the
other
way
around
and
ask
I
guess
to
dave
if
we
did
define
this
in
this
way,
would
that
affect
operations
either?
If,
if
we
tied
this
document
up
more
than
more
than
strictly
necessary,
does
that
cause
problems.
G
H
G
H
Barry
who's,
our
area,
director
and
murray
who's.
Also,
an
area
director
are
both
in
the
queue
here,
so
maybe
they
can
have
some
comments
on
the
scope.
Question
I'll
pop
off.
B
Well
I'll
jump
in,
I
I
think
dave
is
correct.
We
made
the
scope
of
this
very
narrow
on
purpose
and
there
are
good
reasons
that
we
did
that.
So
yes,
let's
be
careful
about
making
changes
that
aren't
really
necessary.
B
A
B
B
C
Let's
back
up
a
second,
if
it
hasn't
recorded
any
trace
fields,
no
return
path,
no
receive
fields,
no
optional
fields
up
at
the
top,
it's
perfectly
valid
because
it,
the
in
section
the
top
of
section
3.6,
the
entire
trace
block,
is
optional
right.
There
are
two
things
being
done
that
we're
discussing
here.
One
is
whether
a
return
path
alone
in
a
trace
block
is
a
reasonable
thing
to
do
without
any
other
received
or
optional
fields
right
and
whether
that
should
be
made
legitimate
and
then
there's
a
a
separate
question
coming
up.
B
C
B
Okay
and
right-
and
I
guess
what
what
dave
is
suggesting
and
what
I'm
agreeing
with
is
that
that
they
have
floated
and
that
that
has
not
caused
problems
in
the
past.
Let's
not
try
to
fix
that
now.
B
D
That
or
it
is
only
okay,
but
it's
okay,
not
to
say
anything
about
it,
and
that
is
inconsistent
with
the
definition
of
a
of
internet
standard,
because
the
internet
standard
is
supposed
to
reflect
reality
and
and
the
fact
that
in
the
last
decade
or
so,
things
have
started
getting
done,
which
we
haven't
paid
attention
to
and
that
have
not
caused
532
to
to
collapse
into
disrepute
does
is
doesn't
align
with
that.
D
So
I
I
think,
I'm
okay
with
this
either
way,
but
but
the
argument
that
it
wasn't
in
five,
three,
two,
two
and
and
people
have
been
doing
it
and
and
therefore
we
don't
need
to
reflect
it
now
in
any
way
at
all,
seems
to
me
to
be
putting
us
on
a
slippery
slope.
And
since
some
of
these
things,
which
have
been
done
and
haven't,
worked
at
532
use
the
term
trace
field
explicitly
and
and
are
on
the
standard
track.
D
It
seems
to
me
that
we're
creating
some
nasty,
spaghetti,
threading
and
and
and
really
ignoring
what
the
the
goal
of
an
internet
standard
is
supposed
to
be
and
if
the
scope
of
this
working
group
is
defined,
as
do
things
which
are
not
consistent
with
what
an
internet
standard
is
supposed
to
be
about
that,
then
we're
in
serious
trouble.
D
A
Right,
I
I
sort
of
share
john's
concern.
I
think,
if
it
doesn't
reflect
reality,
I
believe
we
need
to
fix
it.
Can
I
just
attempt
lost
gowat
missing,
received
heavy
field,
and
then
we
can
move
on
to
the
next
slide,
which
is
we
already
started
discussing
in
yeah.
C
A
I
just
quickly
so
we
were
talking.
We
were
concentrating
on
imap,
but
actually
imap
is
no.
Not
the
only
thing
that
does
this
in
a
map
case,
we
potentially
can
fix
it
in
other
ways.
Consider
male
filters,
or
you
know,
I'm
very.
A
Basically,
system
that
strips
received
header
fields
on
leaving
the
main
for
security
reasons,
this
happens
all
the
time
to
hide
internal
information
about
internal
network.
C
C
The
milter's
question,
which
was
alessandra's
point:
let's
leave
aside
for
a
second.
Let
me
ask
about
the
the
stripping
case:
are
they
stripping
and
not
stripping
return
paths
or
they
just
they're
they're,
stripping
everything
and
the
the
issue
you're
pointing
out?
Is
they
want
to
be
able
to
strip
like
authentication
results,
but
don't
have
any
syntactic
justification
to
do
that,
because
it's
not
in
the
trace
block
that
I
don't
know
whether
they
stream.
A
Both
who
just
just
received.
H
This
union,
as
a
software
author
and
per
person
who
works
with
many
software
authors,
the
chances
are
they
strip
an
arbitrary
set
of
headers
that
have
been
encoded
into
a
regular
expression
somewhere
where
they
get
the
definition
of
what
should
be
in
that
regular
expression
is
90,
just
looking
at
a
few
emails
that
went
through
their
system
and
10
looking
at
our
documents,
and
hopefully
at
least
that
10
gives
them
something
that
is
actionable
right.
A
I'm
not
entirely
sure
whether
we
are
where
we
are
between
proposal
on
the
list
and
possible
proposal
at
the
bottom.
I
think
we
probably
need
to
take
this
to
the
main
list.
Still.
C
C
Okay,
so
currently
in
3.6,
that's
what
the
top
looks
like,
so
you've
got
an
optional
field
at
so,
let's
start
with
the
top.
There
is
an
optional
block
of
stuff
that
is
either
trace,
optional
fields
or
recent
blocks
right
and
that's
at
the
top,
and
then
what
follows
that
is
a
an
optional
block
of
as
many
as
you
like,
the
rest
of
the
header
fields.
C
C
A
There
is
no
more
slides
from
you.
This
is
the
slide.
Oh
you,
truncated,
the
oh,
really,
bummer.
Sorry.
C
So
the
proposal
that
I
made,
I
think
on
the
list,
was
if
optional
field
is
going
to
be
in
trace
anyway,
do
we
need
it
separately
as
an
optional
field
in
the
whole
top
of
the
header
fields
where
trace
recent
and
other
things
can
go
or
is
every
additional
field
that
will
appear
in
that
block
in
the
top
of
it,
in
the
top
of
a
header
block
going
to
be
either
trace,
which
includes
optional
or
the
reset
fields,
because
then
we
could
get
rid
of
one
occurrence
of
the
optional
field,
which
to
me
seems
like
a
good
cleanup.
A
Sorry,
if
I
can
jump
the
cue
for
me,
the
question
is:
can
non-trace
header
fields
be
inserted
at
the
top?
Do
we
have
examples
like
this
and
dan
says
I
I
don't
know
yeah,
I
I
didn't
know
either,
because
the
side
effect
of
removing
this
is
then
disallow
disallowing
them
if
they
already
existed
and
that's
what
I
suppose
it's
hard
to
prove
john.
D
I
have
not
fully
thought
this
out,
so
this
is
a
it's
a
snap
reaction
I
may
regret,
but
if
your
intent
per
earlier
conversation
is
to
put
the
actual
definition
of
most
or
all
of
these
trace
fields
into
five
three
two
one,
then
the
optionality
is
going
to
have
to
then
there
has
to
be
optionality
there,
regardless
of
what
additional
optionality
5322
provides,
because
there
might
very
well
be
transport
level
optionality
as
well
as
post
delivery.
C
H
Again,
I'm
coming
from
implementation
experience
here,
looking
at
what
cyrus
imap
does
and
what
my
subscript
does.
That
puts
a
little
header
in
that
I
just
randomly
added
to
stuff
and
the
edit
header
extension
just
pops
new
headers
at
the
top,
regardless
of
anything,
there's
no
smart,
regardless.
H
I
have
worked
with
systems
that
reorder
headers
in
all
sorts
of
different
ways,
as
the
messages
go
through
if
you're
really
lucky,
at
least
I'll,
keep
the
received
headers
in
the
same
order.
So
headers
with
the
same
name
won't
get
sorted
internally
as
well,
but
all
bets
are
off.
They
could
very
well
have
been
thrown
into
a
hashing
algorithm
that
just
spits
them
out
in
whatever
order
it
spits
them
out.
H
C
I
mean
there
there
is
already
and
note
here
that
this,
the
the
syntax
that
was
in
5322
does
impose
an
ordering-
which
probably
is
at
least
dodgy
with
regard
to
reality,
which
is
that
all
of
the
recent
and
all
of
the
trace
fields
need
to
be
above
from
sender
origination
date.
Everything
else,
but
there's
an
explicit
warning
in
5322,
which
says
these
things
can
be
reordered
and
you
should
try
and
keep
them
in
these
blocks
so
that
people
can
follow
the
path
of
transport.
C
But
you,
you
can't
depend
on
that
so
yeah
for
whatever,
for
whatever
it's
worth
cool.
A
C
C
A
C
Well,
but
it
extensibility
pure
extensibility,
you
could
do
in
oh
about
optional
received
right,
so
I
think
your
text
is
right.
A
But
the
abnf
is
still
in
question.
Basically,
okay,.
C
The
way
the
syntax
in
3.6
appears,
if
you
have
recent
or
if
you
have
some
optional
field
at
the
top,
then
you
must
have
at
least
one
received
field
which
may
be
not
what
we
want.
A
As
a
proposal
to
get
moving
on
this
specific
issue,
maybe
we
can
do
a
short
poll
on
the
mailing
list
where
the
people
know
whether
it's
just
received
in
strip
both
returned
received,
and
maybe
people
might
not
have
specific
knowledge
about
this,
or
we
can
find
people
who
can.
J
A
A
I
think
there
are
a
couple
of
related
issues
in
5321.
I
don't
think
at
this
point.
We
have
specific
suggestions
for
change.
The
only
related
issue
is
going
to
be
on
the
following:
slide
is
about
the
registry
for
trace
header
fields
and
proposal,
for
this
is
to
have
it
in
the
applicability
statement
document.
So
john,
if
you
want
to
say
anything
about
racecar,
refuels
and
5321.
D
I
I
I'm
going
to
need
to
think
about
this
with
my
snap
reaction
is
that
if
the,
if
the
trace
header
fields
plus
or
minus
optional,
are,
are
going
to
be
shifting
in
five
three
two
one
in
terms
of
precise
definition
and
semantics,
then
I
think
the
registry
definition
has
to
at
least
be
mentioned
there,
probably
that
particular.
If,
if
we're
keeping
a
separate
trace
field
registry,
then
that
should
probably
be
defined
in
5321
rather
than
5322.
D
But
again
that
that's
more
more
instinct
than
anything
I've
spent
time
thinking
about
so
so
do
you
prefer.
A
For
the
register
to
be
defined
in
five,
three,
two
one
or
applicability
statement.
D
My
instinct
right
now
would
be
to
define
it
in
one
and
and
then
mention
it
in
five.
Three,
two
two:
if
if
if
that
seems
to
be
appropriate
as
pete
unfolds
the
text,
but
I
don't
feel
really
strongly
about
it
yet.
A
A
few
months
ago,
I
proposed
initial
text
and
there
were
various
changes
suggested.
So
let
me
talk
about
this.
The
current
text
proposed
text
on
the
slide
suggest
updated
version
module
the
issue
at
the
end
about
registration
procedure,
so.
A
I
am
is
to
create
a
new
subregistry
for
email,
header
fields
that
can
be
added
to
a
message:
header
section
by
msa,
mta
mda.
The
new
subregistry
would
show
where
the
header
fields
can
be
added
by
message:
submission
relay
delivery
system
or
some
combination
of
them.
So
they
are
basically
various
columns
in
the
registry.
A
This
definition
got
expanded
initially,
I
think
it
was
just
too
late
delivery
and
then
people
asked
what
about
submission,
so
they
seem
to
be
support
for
mentioning
submission
here
that
the
next
change
is
earlier.
Version
was
saying
that
heather
fields
in
this
registry
must
be
registered
in
their
headfields
registry,
whether
permanent
or
provisional.
A
The
current
proposal
is
to
have
it
as
a
should
feedback
received
on
the
mailing
list
was
that
well,
various
implementations
have
their
own
huddy
fields.
They
don't
necessarily
want
to
be
forced
to
register
in
in
in
the
main
registry,
but
I
think
it's
still
a
good
idea.
So
hopefully
should
we'll
keep
people
happy
with
their
own
x-dash
version
of
header
fields,
and
then
the
final
question
is
registration
procedure.
For
this.
A
Initial
proposal
said
expert
review
again.
There
was
some
pushback
saying
well
what
if
I
want
to
register
my
own
proprietary
header
field
and
then
can
the
experts
say
no
and
possible
proposal
is
first
come
first
serve.
F
I
think
this
is
fine.
I
think
expert
review
makes
sense
so
long
as
we
understand
that
the
goal
that
the
expert's
job
is
just
to
weed
out
stuff.
That
seems
obviously
wrong.
You
know
if
I,
if
I,
if,
if
I'm
you
know
if
I'm
registering
content
type
as
as
a
as
a
trace
header,
perhaps
the
expert
can
push
back
on
that,
and
I
also
wondering
you
know
my
wearing
my
database
hat.
F
I'm
wondering
whether
this
would
make
more
sense
as
another
column
in
the
main,
in
the
main
table,
rather
than
as
a
separate
table
that
we're
trying
to
keep
keep
in
sync.
But
I
see
the
point
that
people
might
want
to
register
their
private
thing,
so
they
don't
so
they
don't
have
to
stay
in
sync.
So
basically,
I
think,
as
proposed
it
looks.
Okay.
F
A
B
In
I
strongly
suggest
when
you
propose
that
text
that
you
make
sure
you
put
in
text
with
instructions
to
the
expert
reviewer
along
the
lines,
that
of
what
john
said.
A
Yeah,
I
believe
so
that
that's
the
part
that
was
missing
saying
you
know
you
don't
want
to.
If
somebody
put
subject
or
content
type
there,
you
know
there
is
a
ground
to
to
registration,
but
other
than
that
yeah
just
register,
basically
yeah
yeah
great.
A
So
now
we
are
starting
with
the
fun
section
about
e-hello
everybody
get
your
coffee.
A
So
this
ticket
number
19
is
about
two
sentences,
talking
about
the
hello
and
checking
domain
name
against
the
corresponding
ip
address.
A
On
this
slide,
we
are
talking
about
the
first
sentence,
which
is
in
bold,
as
nsmtp
server
may
verify
the
domain
name
argument
in
the
if
hello
command
actually
corresponds
to
the
ip
address
of
the
client
and
the
proposal
is
an
smtp
server
may
verify
that
the
domain
name
argument
in
the
hello
command
has
an
address
record
matching
the
ap
address
of
the
client.
A
A
B
As
a
participant,
not
as
a
d
yeah,
I
like
the
change,
that's
proposed.
I
would
also
add
the
word
alone
to
the
end
of
the
second
sentence.
In
that
paragraph.
B
A
D
I
think
I
think
I
agree
with
barry.
I'm
I'm
not
certain
that
I
see
in
either
case
the
necessity
for
doing
this,
but
I
don't
think
it
makes
things
any
worse
might
make
it
a
little
better
and
the
dress
record
was
deliberately
left
a
little
vague
in
in
28,
21
and
53-21,
because
we
were
slightly
concerned
that
that
ipv6
might
implode
and
we
might
end
up
with
ipv
something
or
else
at
some
stage
and-
and
I
think
it's
probably
wise
to
to
preserve
that
that
flexibility.
A
Right,
I
think
my
gut
reaction
was
like.
Do
we
want
to
make
sure
that
people
don't
do
something
silly,
like
I
don't
know,
imax.
A
But
yeah
fine,
all
right,
braun.
H
Most
of
what
I
want
to
say
has
already
been
said
by
the
previous
two
people
I
mean
this
is
basically
an
op,
it's
a
they
may
verify.
Smtp
server
may
do
whatever
the
hell
it
likes.
You
connect
to
it.
It
decides
whether
it
wants
to
talk
to
you
or
not,
and
and
tells
you
to
go
away
for
whatever
reason
this
is
really
just
telling
people.
This
is
a
thing
that
smtp
servers
are
likely
more
more
likely
than
not
to
do
so.
Making
it
as
this.
D
Broad's,
right
and
and
as
I'm
remembering
this,
the
main
reason
for
the
first
sentence
there
in
either
the
old
form
of
the
new
form.
The
main
reason
for
the
first
sentence.
There
is
to
provide
an
introduction
in
the
second
sentence,
which
is
the
prohibition
against
doing
anything.
If
you
say
don't,
if
you
find
an
ip
address
and
say
you
don't
like
it
right,
okay
and,
of
course,
that
probably
slightly
overwritten
by
the
operational
necessity
clause,
but
that's
another
problem
or
issue
or
something.
A
Okay,
so
this
particular
change
seems
non-controversial.
So,
let's
move
on
to
the
next
slide,
which
is
slightly
more
controversial.
A
So,
in
regards
to
the
second
sentence,
I
think
basically,
various
people
observe
that
must
not
just
does
not
reflect
reality,
that
a
lot
of
implementations
check
that
in
violation
of
this,
and
actually
sam,
pointed
out
that
some
servers
have
option
whether
to
check
this
or
not
configuration
option
and
yeah.
This
is
very
true.
We
have
it
in
our
own
implementation,
for
example.
A
B
Yeah,
so
here's
where
we
get
my
thing
I
agree
with,
should
not,
and
I
would
add
either
the
word
solely
aft
after
the
word
message
or
alone,
at
the
end
of
the
sentence,
to
give
an
indication
that
they
can
certainly
use
that
information
as
part
of
the
decision.
But
it
shouldn't
be
the
only
basis
for
the
decision.
G
All
right
todd
I
I
disagree.
I
think
it
should
be
a
sole
basis
for
the
decision
and
just
based
on
established
anti-abuse
practice
if
hosts
hellos,
as
you
know,
say
mail.google.com,
but
they're
they're,
coming
from
some
random
consumer
space
in
romania
or
whatever.
That's
that's
enough
right
there
to
to
reject
the
connection.
G
If
you
haven't
already
blocked
it
just
based
on
the
source
ip,
you
clearly
have
you
clearly
have
a
client
at
that
point
that
is
trying
to
is
at
best
misconfigured
and
at
worst,
is,
is
trying
to
abuse
your
system
and
that's
enough
to
just
shut
down
the
connection
right
there
and
send
it
on
his
very
way.
H
H
D
Yeah,
I
think
brian
just
anticipated
my
comment.
If,
if
we're
good,
I
I
I
I'm
vaguely
in
favor
of
should
with
the
changes
change
that
barry
suggested.
But
if
we're
going
to
move
this
to
the
server
may
look
at
this,
and
if
it
does
look
at
this,
it
may
do
something
about
it.
Then
I
think
the
whole
that
I
think
that's
justification
of
the
whole
paragraph
being
taken
out
because
it
just
doesn't
have
any
meaning
at
that
stage.
D
Servers
may
look
at
whatever,
but
servers
may
look
at
whatever
they
feel
like
looking
at
without
having
to
say
anything
and-
and
you
know,
if
they
look
at
it,
they
may
pay
attention
to
it
and
they
may
not
so
so.
So.
Moving
this
to
applicability.
D
A
Are
you
happy
with
some
text
and
applicability
statement
about
this.
A
C
I
just
wanted
to
point
out
that
todd's
example
isn't
actually
a
problem
for
the
original
intent
of
this
sentence,
because
this
was
simply
if
the
ip
address
and
the
name
do
not
match
in
the
dns.
That
alone
is
not
sufficient
for
the
server
to
punt
it.
The
example
todd
gave
was
they
didn't
match,
and
I
have
this
information
that
they
don't
match
that
this
is
an
ip
address
somewhere
in
romania,
and
that
is
google's
domain
name
right.
That
additional
piece
of
information
is
not
it's
not
the
case
that
google
forgot
to
register
this
name.
C
This
number
to
go
with
this
name.
It's
that
there
was
a
simple
non-match.
Now
I
think
you
know
this
is
perfectly
reasonable
to
pull
and
put
in
the
applicability
statement.
But
there's
not
enough
in
this
sentence
is
currently
construed
to
really
explain
that
the
issue
here
was
don't
just
assume
that
the
dns
is
correct
about
names
and
numbers
assume
that
you
might
be
missing
a
separate
piece
of
information
so,
but
putting
this
in
the
eas
and
doing
a
fuller
explanation
is
perfectly
reasonable.
A
Fine
I'll,
let
todd
respond
to
you
in
case
he
wants
to
respond
directly.
G
G
A
Harold,
just
please
don't
use
mail.google.com
as
an
example.
If
you're.
A
Domains
for
mail.google.com,
you
will
find
that
it's
there's
nothing
even
remotely
like
a
a
simple
reverse
lookup.
Now
the
name
that
google
uses
in
e-hello
is
in
fact
something
that
maps
back,
but
that's
probably
because
it
spends
significant
time
fighting
with
people
withdraw
with
misguided
spam
skills.
A
G
So,
let's
see
if
my
headset
will
make
this
work
better
for
audio,
so
peter
koch
posted
a
quick
squib
in
the
middle
of
the
postings.
I
was
doing.
I
didn't
quite
understand
what
he
was
referring
to
at
the
time
and
in
listening
to
the
exchange.
That's
been
going
on
just
now,
whether
it's
what
he
meant
or
not.
I
think
it
applies.
What
he
wrote
was
I'd
suggest
this
confuses
protocol
and
policy.
G
Considering
taking
actions
like
removing
these
sorts
of
statements,
that
will
prove
to
be
wrong
over
time,
because
they're
not
essential
to
the
protocol
they're
essential
to
operations
which
is
different.
It
is
something
that
would
be
worth
considering
since
it
simplifies
the
document
quite
a
lot
now.
The
question
is
whether
I
will
actually
hear
anybody.
A
Well,
I
I
heard
you
so
hopefully
you
hear
me
so
thank
you.
I
do
right.
Okay,
so
basically
remove
this
text.
That's
what
you
suggest
from
this
document
and
move
it
to
here.
I
think
so.
H
H
The
behavior
of
the
survey
when
verifying
things
and
deciding
whether
they
are
valid
or
invalid
is
entirely
policy,
and
it
is
a
good
point
that
we
should
be
trying
to
remove
policy
as
much
as
possible
from
the
protocol
definition
because
it
doesn't
belong
here
and
on
on
that
grounds
I
say
still:
yes,
we
should
remove
it,
there's
no
point
putting
stuff
in
our
protocol
that
we
know
people
aren't
going
to
follow
and
to
leave
it
in
there.
A
Okay,
thank
you
braun.
I
think
I'm
hearing
that
obviously
subject
to
verification
on
the
mailing
list.
People
suggest
to
remove
the
the
whole
paragraph
and
possibly
add
something
along
this
lines
with
should
not
or
maybe
even
more
exp
and
even
more
expanded
version
into
the
applicability
statement.
So
I
think
direction.
453
21
seems
clearer
and
then
we'll
follow
up
on
the
mining
list
and
discuss
what
to
do
with
a
totality
statement.
A
We
had
various
discussion
on
this
people.
Some
people
say
that
it
should
be
syntactically
invalid
and
deprecated
and
other
in
particular,
for
iot
cases
think
that
it
should
be
still
allowed
and
sounds
like
we
need
at
minimum
some
text
in
applicability
statement
about
this.
A
C
I'll
try
and
channel
keith
since
he's
not
here
for
the
moment
and
say
syntactically.
It
seems
reasonable
to
leave
it
in.
Even
though
harkening
back
to
our
last
discussion
by
policy,
it
might
be
quite
reasonable
to
reject
a
whole
bunch
of
these
things,
but
there
are
iot
cases.
There
are
other
cases
where
you
want
to
say
by
policy
I'm
going
to
allow
an
ip
address
literal,
because
this
is
a
space
where
I
really
can't
use
domain
names
in
a
legitimate
way.
C
So
I
think
protocol
wise
it's
okay,
to
leave
it
in,
and
policy
wise,
it's
okay
to
say,
nope,
not
accepting
those.
D
Take
that
a
little
further,
I'm
I'm
seeing
still
seeing
a
number
of
of
smtp
clients
that
that
we
describe
as
iot
devices
today,
but
but
we're
designed
to
build
long
before
the
term.
Iot
came
into
fashion
and
some
of
which
are
pretty
big
objects
using
ip
addresses,
because
they
are
using
smtp
to
send
messages
of
once
or
another
to
local
servers
and
and
don't
have
access
dns
and
don't
even
speak
dnx
and
and
before
those
things
get
to
the
get
past.
D
The
the
the
relay,
the
first
relay
they're
using
the
relays
domain
name
so
they're
not
showing
up
on
the
public
internet
they're
showing
up
in
land
and
land-like
and
isolated
network-like
environments,
but
they're
using
ip
addresses,
because
they
don't
have
any
choice
and-
and
that's
of
course,
the
reason
why
we
retained
ip
addresses
into
2821,
because
we
had
a
piece
of
this
discussion
back
at
that
point.
D
So
anything
in
the
af
which
says
that
ip
addresses
in
the
public
internet
are
probably
a
bad
idea.
I
think,
is
fine.
But
as
far
as
5321
is
concerned,
I
don't
think
it's
healthy
to
make
a
change.
A
So
looks
like
with
this
ticket:
we
have
no
change
for
53
21.
This
and
various
checks
suggested
for
for
the
applicability
statement
and
we'll
discuss
it
on
the
mining
list.
D
I,
I
guess
I'll
say
some
things
about
it:
I've
I've
seen
implementations
in
which
all
of
these
things
are
considered
equivalent.
I've
seen
implementations
which
they're
not
this.
D
This
interacts
with
the
5322
question
about
about
quoted
strings,
although
that
particular
question
is
much
narrower
than
this
and
and
I
think,
there's
an
argument
for
figuring
out
what
it
is
we
meant
in
narrowing
it
down,
even
if
we
end
up
saying
that
that
there's
some
legacy
things
out
here
and
and
servers
better,
be
prepared
for
them.
I
think
the
the
combination
of
operational
experience
and
and
an
argument
for
clarity
are
used
for
for
looking
at
this
again.
D
In
the
most
extreme
case,
we
may
want
to
start
deprecating
some
of
these
combinations
because
they
just
cause
confusion.
The
other
part
of
the
story
here
is:
we've
got
a
history
of
of
operating
systems.
Getting
hold
of
these
things
after
the
users
put
them
in
and
deciding
that
some
quote
characters,
but
not
others
are
the.
Are
the
property
operating
system
designating
local
symbols
and
things
like
that
and
as
they
then
try
to
apply
those
rules,
things
get
very,
very
confused.
A
Well,
there
is
I
I
switched
to
the
second
slide
and
there
is
a
bit
a
part
of
the
proposal
how
how
to
go
about
it.
So
I
think,
which
is
fair.
D
Yeah
that
that
that
that
comment
on
the
second
slide
is
right,
and
I
think
that's
one-
we
can
get
our
hands
on
the
various
combinations
of
blanks
and
and
slashes
within
quoted
strings.
D
I'm
I'm
more
worried
about
in
terms
of
of
not
knowing
of
not
knowing
what
the
right
solutions
are,
but
I've
seen
some
of
this
stuff
in
the
wild
be
caught
in
in
one
historical
case,
because
that's
what
the
operations
required,
because
that
was
how
usernames
worked,
but
but
more
often
in
a
in
a
strange
kind
of
security
by
obscurity
sort
of
thing,
because
the
the
spammers
don't
know
this
cut
these
combinations,
spammers
and
fishers.
D
Don't
know
these
kind
of
kinds
of
combinations
exist
and
and
consequently
putting
them
into
a
a
mailbox
name
is
a
is
a
way
of
keeping
noise
down.
But
I
I
don't
think
that's
a
very
strong
justification.
A
A
Well,
almost
yeah:
I
think
that
shouldn't
affect
53
22.
D
Yeah,
I'm
I'm,
I
I'm
not
sure
there.
There
may
be
some
syntax
productions
that
we
either
need
to
change,
or
we
need
to
make
some
explicit
statements
about
what
what's
equal
and
not
equal
to
various
other
things,
because
the
way
these
quarter
streets
get
messed
with
they,
they
may
be
an
exception
to
the
rule
that
that
nobody,
but
but
the
delivery
server
configurations
figure
out
what
an
address
means.
A
Right
so
yeah,
this
is
the
sort
of
the
second
part
of
the
proposal
is
saying
that
if
people
want
to
compare
this,
we
need
to
say
probably
be
more
clear
about
this.
A
A
D
It
may
be
useful,
let's
see,
to
separate
those
those
two
possible
resolution,
paragraphs
from
each
other,
because
the
first
one
seems
pretty
obvious
to
me
and
it's
reasonably
well
fleshed
out
and
the
second
one
is
hand
waving,
maybe
important
hand
waving.
But
at
the
moment.
A
Okay,
do
you
think
we
need
a
separate
issue
for
the
second
one.
D
A
A
Okay,
if
we
can
minute
that
maybe
create
a
second
second
issue
about
comparison.
That
would
be
good
right
if
there
are
no
further
comments
on
this.
Let's
move
on.
A
This
is,
we
had
a
long
discussion
on
this
last
time.
I
think,
where
we
landed,
is
we
shouldn't
change
syntax,
but
applicability
statement
need
to
talk
about
where
it's,
okay
and
not
okay,
to
have
empty
quote
strings,
so
I
just
wanted
to
have
a
bit
of
a
feedback
on
what
might
go
into
applicability
statement,
and
this
is
the
next
slide.
A
D
Pushing
this
bas
is
okay.
We
just
need
to
make
certain
that
we're
sufficiently
coordinated
that
that
five
three
two
two
oh,
does
not
end
up
prohibiting
anything
that
five
three
two
one
allows.
A
C
A
All
right,
so
I'm
looking
at
this
slide
specifically-
and
maybe
you
want
you
want
to
stay
online.
I
did
a
bit
of
research
about
where
quoted
strings
are
allowed.
A
I
think
the
obvious
case
where
it's
okay
is
display
name
in
name
construction.
I
think
it
probably
going
to
cause
practical
issue
in
local
parts,
probably
in
receive
tokens
and
keywords.
A
I
don't
know
how
many
people
are
using
keyboards,
but
does
this
look
roughly.
A
A
And
when
I
say
cannot
be
empty,
that
will
go
to
applicability
statement,
so
this
index
will
allow
it,
but
we'll
just
add
text
saying
that
certain
things
are
not
a
good
idea.
J
C
Yeah
we
we
could
do
that,
and
you
know
we
can
do
a
little
testing.
I'm
sure
people
would
be
amused.
C
D
It
seems
to
me-
and
this
becomes
entirely
appropriate
for
the
as
but
it
seems
to
me
that
what
a
lot
of
this
stuff
is
about
is
a
is
a
warning
that
that
some
of
these
constructions
are
are
not
likely
to
work
in
in
the
general
case
and
and
if
you
create
mailboxes,
that
look
like
this
in
in
local
parts
and
things
like
that
that
that
it's
not
gonna
work
and
unless
you
in
the
again
in
the
general
case
and
operationally
and
if,
if
what
you
want,
is
for
it
not
to
work
in
many
cases
because
it's
obscure
the
journey
is
deliberate,
then
that's
a
whole
issue,
a
whole
different
issue.
D
But
but
I
don't
know
how
much
else
you
could
say
about
that,
and
and
of
course,
the
decision
we
made
earlier
moves
the
question
of
most
receipt.
Token
question
about
this
into
into
an
821
issue
and
and
pete
is
correct-
that
a22
permits
the
5322
permits
almost
anything
that
that
one
could
possibly
imagine-
and
maybe,
in
this
case
that's
okay.
D
But
keywords
keywords
are
particularly
important
here,
because
the
purpose
of
using
keywords
is
to
is
to
have
something
which
works
and
is
comparable
and
and
if
you
use
these
things,
then
it
may.
D
A
Okay,
so
it
seems
to
that
you
are
roughly
agreeing
with
preliminary
analysis
on
the
slide,
but
obviously
the
devil
is
in
details.
D
A
H
H
Stuff,
the
one
thing,
as
I
guess,
an
end
user
of
this
stuff
is
it
would
be
nice
to
have
guidance
on
this
stuff
is
very
likely
to
work
and
hereby
dragons
don't
mess
around
here.
So
things
like
using
empty
strings
or
using
lots
of
specially
quoted
stuff
in
your
local
part
is
likely
to
break
things.
H
Whereas,
if
you
stick
within
this
set
of
characters
and
this
set
of
behavior,
then
you
can
expect
everything
to
interoperate
and
at
it's
really
at
the
stage
where
you
are
then
talking
to
whoever's,
receiving
your
email
or
sending
your
email
or
your
providers
up
and
down
stream
and
saying
to
them:
hey
you're,
not
behaving
properly.
Here's
what
the
rfc
says
you
should
do
this
and
we
we
need
to
cut
a
line
where
we
say
things
in
this
area
should
be
expected
to
work
things
in
this
area.
H
You're
you're
playing
in
dangerous
territory,
and
I
think,
having
defining
that
edge
somewhere,
is
valuable
and
saying
it's.
It's
just
all
undefined
you
anything
might
work.
Anything
might
not.
Work,
isn't
useful
to
anybody
right.
I'd
like
to
see
some
kind
of
his
the
things
that
are
generally
considered
to
be
safe.
H
H
Yeah
but
yeah,
certainly
having
having
a
pretty
strong
plus
plus,
is
expected
in
a
local
part
and
if
your
web
form
doesn't
allow
someone
to
enter
that,
it's
not
accepting
email
addresses
but
double
back
quoted.
A
A
Right
moving
on
I'm
changing
to
something
slightly
different.
A
A
So
there
was
a
suggestion
that
to
clarify
on
the
assumption
that
the
client
will
receive
it
after
the
next
command
is
issued.
A
A
D
I'll
do
whatever
the
working
group
decides
and
wants
to
do,
but
but
I'm
still
not
convinced
that
there's
a
real
problem
here
and
and
if
the
working
you've
decided
it
wants
changes,
then
I
think
we
should
put
in
something
resembling
a
a
specific
example
of
a
case
where,
where
where
where
this
is
relevant,.
A
A
If
you
want
to
say
something,
oh
wait
to
see
your
slide.
I
think
a
non-blocking
client
is
probably
the
most
obvious.
So
basically
the
order
of
event
is
server.
Rights
photo
one
shutting
down
and
close
its
side
of
the
connection.
Gracefully
then
client
decides
to
send
some
commands
at
a
later
point
and
then
it
this
is
using
non-blocking
sockets.
A
So
the
client
use
paul
or
e
paul
on
unix
or
any
other
kind
of
similar
event
framework
to
wait
for
read
and
write
events
and
close
events,
and
this
will
complete
immediately
and
the
client
will
get
the
text
sent
by
the
server
before
it
gets
notified.
The
connection
got
closed,
so
actually
client
already
have
it
in
its
tcp
buffer.
A
The
closing
message
from
the
server
in
some
cases.
So
I
think
the
suggestion
behind
the
text
was
just
to
make
it
clear
that
it's
okay
and
maybe
even
a
good
idea
to
do
this
sort
of
thing.
Not
just
because
the
original
text
seems
to
suggest
that.
A
B
So
yeah
I'm
kind
of
with
john,
I
don't
I
I
don't
think
the
text
really
needs
to
be
fixed
here.
I
think
this
is
stuff
for
the
applicability
statement
to
discuss
in
more
detail
how
clients
should
handle
this,
but
that,
what's
in
5321
now
is
okay.
A
I
think
that
I
haven't
submitted
this
ticket,
I'm
just
trying
to
proxy
there,
whoever
submitted
it.
I
think
the
current
text
seems
to
be
can
be
read
as
prohibiting
this
behavior,
where
it's
quite
common
actually
in
clients.
B
D
Barry,
I
don't
read
the
current
texas
prohibiting
this.
This
is
this
is
an
operational
detail
about
how
the
the
client
behaves
and
your
your
example
is
making
a
lot
of
assumptions
about
how
the
client
interacts
with
the
tcp
interface
on
image,
and
that's
that
ought
to
be,
I
think,
sufficiently
lower
level
to
not
be
in
scope
for
five
three,
two
one
but
and
and
as
I
say,
I
don't
think
the
text
prohibits
this.
But
if,
if
other
people
are
reading
his
prohibition,
then
it
already
patched.
A
Right,
okay
and
similar
related
issue
is
again.
I
I
think
it's
the
same
same
type
of
issue
in
another
paragraph.
A
B
A
A
H
B
I
agree
that
saying,
when
retries
are
appropriate
is
is
definitely
in
scope
for
this
yeah.
D
I
I
agree
with
that,
but
but
but
I
completely
agree
with
barry's
comment:
we're
we're
really
messing
around
in
not
not
only
in
transport
layer
issues
but
in
the
issue
of
of
the
local
communication
between
the
client
and
the
transport
layer,
and
I
don't
think
we
want
to
go
there
if
we
can
possibly
avoid
it.
A
All
right,
let
me
try
to
have
a
follow
up
on
this
issue
on
the
mailing
list
if
we
can
come
up
with
some
possible
text
for
the
applicability
statement
well,
but
at
this
point
it
looks
like
no
change.
Four.
Fifty
three
twenty
one.
D
I'd
be
pretty
hesitant
about
getting
very
far
into
this
in
the
applicability
statement
as
well
again,
because
these
not
only
transport
layer
issues
but
their
their
issues
in
in
the
local
systems
model
in
the
local
systems,
client
systems
model
of
how
one
interacts
with
transport
and,
as
I
say,
go
going,
there
seems
to
be
hazardous.
A
Yeah,
I'm
I'm
looking
at
this.
I'm
just
trying
to
figure
out
whether
documenting
this
makes
a
difference
and
the
hypothetical
situation
is
if
the
server
returns
completely
different
error
code
response
code
here
like
5xx,
but
then
we
need
to
figure
out,
you
know.
Is
it
going
to
affect.
A
A
D
Understand
where
you're
coming
from
and
why
but,
but
I
also
have
memories
of
of
the
time
when
we
had
smtp
running
over
things
besides
tcp
and
and
the
possible
situation,
the
future,
where,
with
the
advent
of
of
non-tcp
transport
protocols,
we
may
have
smtp
running
over
over
non-tcp
again
and
and
getting
way
down
at
the
issues
of
of
how
tcp
implementations
behave
or
appear
to
be
in
a
in
a
given
client
environment
seems
to
be
fraught
with
risks
that
we
could
clarify
this
in
a
way
which
makes
things
more
difficult
for
for
future
implementations
in
a
way
which
we
don't
want
to.
D
So
I
again
I,
if
we're
gonna,
do
something
here.
I
think
it
needs
to
be
illustrated
with
specific
examples,
and
I
think
we
need
to
be
very
careful
that
we're
not
making
more
assumptions
about
the
the
transport
layer
than
we
need
to,
and-
and
that's
definitely
true
in
in
five
three
two
one.
This
is
probably
true,
even
in
the
as.
A
Let
me
think
how
to
approach
this
ticket
I
I
can
completely
understand
that
people
fail
to
get
excited
about
it.
So.
A
I
I
have
I
had
similar
coding
issues.
You
know
trying
to
implement
my
client.
That's
why
I'm
trying
to
do
a
fairer
presentation
trying
to
proxy.
A
All
right
we
have
this
right.
I
think
let's
get
some
coffee
in
and
talk
about.
Five.
Five,
two
walk
around
todd.
Are
you
happy
to
talk
about
this
ticket
sure.
G
The
ticket,
as
I
understand
it,
is
discussing
removing
the
bolded
sentence.
There.
Client
should
treat
a
552
code
in
this
case
is
temporary
rather
than
permanent
failure,
so
the
logic
balloon
works.
There
was
some
discussion
on
the
list.
Several
folks
posted
what
they
found
in
various
open
source
packages.
G
I
believe
that
they
all
said
that
they
treated
552
as
a
permanent
failure.
I
reached
out
to
several
large
mailbox
providers
and
a
couple
of
commercial
mta
vendors.
Not
everybody
responded,
but
google,
microsoft
and
proofpoint
all
said
they
treat
552
as
a
permanent
failure.
G
So,
while
the
recommendation
clearly
says
client
should
treat
it
as
temporary,
it
seems
that
most
clients
are
not
doing
so.
So
the
question
then
becomes:
do
we
leave
this
text
in
there
and
hope
that
people
change
their
code
or
do
we
strike
it?.
A
Clarify
as
far
as
we
know,
no
client
is
actually
following
this
recommendation.
Is
this
correct?
A
G
Want
it
right
yeah,
I
do
not
recall
seeing
any.
I
I
just
reviewed
the
the
thread
that's
called
out
in
the
ticket
a
few
minutes
ago.
I
don't
recall
seeing
any
any
mention
in
there
that
anybody
was
treating
it
as
a
temporary
failure,
and
I
have
not
heard
directly
from
anybody
saying
that
they
treat
it
as
a
temporary
feeling.
I
have
not
done
an
exhaustive
survey
of
every
possible
mta
vendor
out
there,
obviously,
but
I
have
not
yet
heard
that
anybody
is
treating
it
as
a
temporary
failure.
G
D
I
posted
a
note
to
the
list
some
hours
ago
that
that
suggested.
Not
only
is
this
statement
not
useful
because
nobody's
paying
any
attention
to
it,
but
it
may
be
wrong,
so
so
that's
a
probably
an
additional
reason
for
getting
rid
of
it.
A
A
Okay,
so
maybe
I
suggest
maybe
we
have
sort
of
like
a
mini
working
group.
Last
call
on
this
issue
asking
for
any
objections,
and
then
proposal
is
just
to
drop.
This
sentence.
G
This
is
another
one
where
I've
reached
out
to
the
same
mailbox
providers
and
commercial
mta
vendors.
I
have
not
yet
heard
any
responses
back.
They
they
get.
They
get
to
me
when
they
get
to
me
so
that
I
think
definitely
this
warrants
further
discussion.
Those
timeouts
do
seem
to
coin
a
phrase
from
a
different
time.
G
I
think
they
are
probably
far
longer
than
they
need
to
be,
but
I
think
we
need
to
get
some
actual
verification
from
current
implementations
to
see
what
they're
doing
before
we
go
forward
and
make
any
changes
here,
because
we
don't
want
to.
G
D
Flagler
is
an
opinion
we
should
should
also
reach
out,
not
just
to
things
we
consider
ordinary
email
clients,
but
the
dtn
people,
because,
if
the,
if,
if
if
either
the
client
or
server
is
on
the
moon
or
on
the
mark
and
and
the
other
one
is,
is
earthbound
change.
Numbers
may
not
be
appropriate
again,
not
not
not
opposed
to
making
changes
here.
D
But
if
we're,
if
we're
making
a
decision
on
the
basis
of
what
what
implementations
might
do,
then
then
dtn
situations
with
with
pipelining
may
be
something
or
are
something
we
need
to
make
certain.
We
don't
mess
up.
My
excerpt.
A
D
And,
and
that
would
be
the
logical
place
to
start.
H
Braun
my
question
again
in
here
is:
is
there
any
value
in
reducing
the
timeouts
generally,
if
you're
building
a
server
that
needs
to
deal
with
a
lot
of
traffic,
it
can
already
spend
very
little
research
resources
in
holding
open
a
tcp
connection,
while
it's
waiting
for
things
to
happen
down
at
what's
the
alternative?
G
Yeah,
that's
perfectly
valid,
I
I
you
know
if
the
intent
here
is
to
reflect
reality,
there
maybe
needs
to
change,
but
if
the
intent
here
is
just
to
recommend
values
that
cover
the
cases
you're
you're,
referring
to
brawn
and
maybe
leaving
it
as
is
this-
is
the
right
move.
I
think
just
further
discussion
and-
and
you
know,
reach
out
to
the
dtn
folks
and
others
to
find
out
what
they're
doing
right
now
to
to
try
to
inform
that
discussion.
G
D
I
just
when
I
think
I've
earned
the
combination
of
of
bronze
bronze
comment
and
yours,
plus
or
minus
adding
in
the
the
gtn
question
is
that
we
probably
should
not
be
looking
at
5321
about
this.
We
should
probably
be
looking
at
how
to
construct
a
nice
paragraph
or
two
in
the
as
talking
about
the
issues
and
the
trade-offs
and
what
people
are
doing
under
various
circumstances,
but
just
the.
G
Yeah
I
mean
I
don't
the
language
in
the
spec
right
now
says
the
minimum
per
command.
Timeout
value
should
be
as
follows.
So
there
are
only
recommendations,
there's
no
there's
no
structure
here
with
with
them.
Nobody
can
claim
you're
violating
an
rfc
if
you
shut
down,
you
know
after
say
three
minutes
instead
of
five
whatever.
So
perhaps
the
applicability
statement
is
a
better
place
to
discuss
this
entire
topic.
G
We
don't
we
have.
We
don't
have
any
any
on-list
discussion
of
this
topic
or
is
really
anything
in
the
ticket
to
guide
us
yet.
So,
let's,
I
think,
just
move
forward
with
further
discussion
on
this
and
see
where
what
the
consensus
emerges
as
to
where,
where
to
take
this
ron.
H
That
there
haven't
really
been
any
complaints
about
the
current
values
which
to
take
us
right
back
to
those
comments
from
ages
ago.
Maybe
we
shouldn't
be
changing
this
at
all,
because
it's
not
an
area,
that's
causing
problems
with
the
current
specs.
H
G
Fair
anyone
else
have
anything
to
say
on
this
topic.
A
Yeah
I
I
was
actually
optimistic.
I
didn't
expect
us
to
use
two
hours
but
they're
nearly
there.
A
I
think
that's
the
last
last
issue
that
I
was
really
prepared
to
talk
about.
To
be
honest,
so
let's
have
a
quick
section
for
other
other
issues,
questions
that
people
want
to
raise
and
if
not
then
we'll
finish
a
few
minutes
early.
A
Okay,
I
think
we're
done
then
thank
you
all
very
much
for
showing
up,
and
I
think
we
made
some
progress
or
at
least
pointed
out
directions
for
various
tickets
and
well,
then
I
will
hope
to
see
you
on
the
mailing
list
and
get
get
these
documents
done.