►
From YouTube: IETF109-EMAILCORE-20201117-0730
Description
EMAILCORE meeting session at IETF109
2020/11/17 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
Good
afternoon
good
morning,
everyone
so
we
should
get
started.
A
Yes,
right:
okay,
good,
okay,
so
notewell,
I'm
sure
you've
seen
it
before.
If
you
haven't
seen
it,
please
consult
and
read
relevant
documents.
A
Jabba
window
we
have
kodiamg
page
for
the
note
taking.
Are
there
any
volunteers
for
note.
A
A
Okay,
so
working
group
status,
we
got
charted,
we
did
a
bit
of
work
in
october,
so
I
think,
even
though
it
was
a
bit
late,
it
was
a
productive
start
to
the
discussion.
There
are
a
few
things
that
chairs
are
either
late,
taking
care
of,
or
are
still
now
to
the
list.
So
we
still
haven't
selected
editor
for
the
core
email
applicability
statement
draft.
We
had
two
volunteers.
A
Some
of
the
people
who
volunteered
we
don't
know
so
would
like
to
conduct
interviews.
Please
please,
please,
as
a
volunteer
or
suggest
somebody
else
who
can
be
a
good
person.
Somebody
new
would
be
great,
but
you
know
I
think,
we'll
take
everybody.
A
I
was
waiting
for
feedback
from
our
editors
and
done
slides
yesterday.
So
yes,
I
agree.
This
is
very
late
and
I
started
discussion
on
the
mailing
list,
but
remember
that.
A
A
Let's
have
a
productive
meeting
and
the
other
thing
is,
I
know
the
timing
of
this
meeting
is
not
great,
but,
however,
this
is
not
much.
We
can
control
so.
A
A
A
So
three
things
we
want
to
discuss
with
5322
today
the
work,
one
issue
that
came
out
of
actually
smtp
department
about
trace
header
field
definition
that
net
freed
initiated
so
we'll
discuss
this
first
and
then
we'll
discuss
possible
solutions
for
a
couple
of
rata
items.
C
C
C
Well,
that's
probably
close
enough
all
right.
Let
me
jump
right
in.
I
believe
the
issue
of
a
definition
for
trace
headers
comes
out
of
the
discussion
that
was
going
on
either
on.
I
forget
whether
it
was
going
on
on
email,
core
or
iatf
smtp
such
that
it
was
clear
what
a
trace
header
was,
and
people
thought
that
this
belonged
in
53
22.,
just
by
way
of
reminder-
and
this
will
probably
come
up
with
other
issues-
the
way
5322
was
originally
arranged
for
any
of
the
given
fields.
C
There
was
a
syntactic
syntactic
description
of
what
the
field
was
followed
by
the
abnf,
followed
by
the
sort
of
a
semantic
description.
What
it
you
know
what
it
meant,
what
it
was
used
for.
So
this
sounds
like
the
kind
of
thing
that
could
go
into
the
semantic
portion.
C
You
know
that
that
second
part
for
trace
fields
and
describe
that,
of
course,
these
can
be
extended
with
optional
fields,
and
you
know
say
something
additional
about
that,
and
I
guess
the
question
to
the
room
is
what
else
needs
to
go
in
there
and
does
anybody
have
sort
of
an
idea
of
what
they
want?
That
text
to
look
like
or
what
they
need
it
to
look
like.
A
C
Doesn't
it
have
sound
not
quite
yet
and
the
the
little
chasing
arrows
down
in
the
lower
right
corner
to
reset
your
audio
is
quite
helpful.
C
C
D
Yeah
right
when
I
started
saying
no,
I
don't
want
to
say
anything,
but
I
think
I
will
anyway.
D
And
my
apologies
for
being
missing
the
first
part
of
your
comments,
because
I
had
a
little
medical
problem
but-
and
you
may
have
covered
this
already,
but
to
respond
to
two
things
I
heard
the
one
thing
I
heard
in
the
sunslide
two
things
I
heard
is
that
there
was
an
argument
about
putting
this
stuff
into
821
5321
right,
because
these
things
are
put
in
by
and
large.
D
Although
we've
now
started
talking
about
trace
fields
which
are
post
delivery,
they
were
historically
all
put
in
by
the
transport
mechanism,
except
sometimes
for
a
where
they
started
trace
fields
which
would
have
been
put
in
by
submission
server,
which
was
until
fairly
recently
in
the
grand
scheme
of
these
things,
part
of
the
transport
mechanism
as
well
right.
D
The
the
other
observation
is,
they
have
been
called
trace,
fields
for
so
long
and
that
terminology
is
scattered
across
enough
documents
and
literature,
not
under
the
ieds
control.
The
changing
that
name
at
this
point
would
be
almost
certain
to
cause
far
more
disruption,
problems
and
confusion
and
its
worth.
Even
if
we
came
to
the
conclusion
that
that,
if
we
had
a
time
machine,
it
could
could
go
back
to
to
the
time
when
821
was
written,
that
that
we
would
have
decided
to
call
it
fizzle.
France.
C
Right
and-
and
you
know
like
I
said
earlier-
which
you
may
not
have
heard-
that
sort
of
descriptive
section
after
the
abnf,
you
know,
I
think
it
has
no
impact
to
expand
out
and
be
clear
about.
You
know
what
that
there
are
other
header
fields
that
sort
of
get
used
in
a
similar
way.
C
Either
the
transport
mechanism
is
introducing
them
or
a
delivery
mechanism
or
a
submission
mechanism,
and
so
it's
expected
that
those
things
will,
you
know,
be
added
in
the
same
place
and
that
they,
you
know
other
mechanisms
or
the
you
know
the.
What
do
you
call
it?
The.
C
My
brain's
flat,
the
the
other
document,
the
applicability
statement,
might
actually
describe
the
different
ways:
they're
used
in
different
circumstances
or
53-21
bismith
or
whatever.
So
I
don't
have
a
problem
adding
that
in
there
I'm
just
looking
for
some
advice
on
what
people
want
to
add.
Yeah.
D
And
and
and
of
course,
the
reason
why
this
ended
up
in
five
three
two
two
was
precisely
because
these
are
header
fields,
as
we
are
right,
as
we
treat
that
other
than
looking
at
how
they
were
added
or
by
whom.
C
All
right.
I
mean
it.
So
my
gut
is
I'm
happy
to
post
on
the
list.
Please
somebody
give
me
advice
and
if
I
don't
hear
back
in
a
few
weeks,
I'll
make
some
crap
up
and
then
people
can
fix
it
because
I'm
pretty
sure
I'm
not
going
to
get
it
right.
But
you
know
if
people
have
something
to
say
on
this
today,
let's
say
it:
anybody
else
want
to
jump
in.
C
Okay
I'll.
I
will
post
a
request
on
the
list,
I'm
pretty
sure
ned
says
I'm
pretty
sure
some
of
the
crap
that's
added
stretches
the
meeting
all
right
so
in
any
event,
I'll
post
a
query
on
the
list
for
someone
to
come
up
with
some
text
for
me
to
add,
and
if
I
don't
hear
it
a
little
bit
I'll
make
something
up
and
then
we
can
at
least
have
something
to
shoot
at
all
right.
C
I
I
so
I
can
just
as
simply
put
in
the
one
right
I
can
say
that
quoted
strings
must
have
something
in
them
and
alexi
did
it.
Is
that
the
following
slide,
alexi,
the
the
the
where
you
went
and
looked
go
to
the
next
slide?
If
you
would
so
yeah,
so,
oh,
it
was
ashley
who
went
through
and
and
said
you
know,
these
things
aren't
useful
and
alexi
came
up
with
the
list
below
of
empty
quoted
strings.
C
Just
are
not
semantically
interesting
any
place,
and
so
the
question
is
whether
to
disallow
them.
The
question
I
had
was:
are
they
actually
causing
implementability
problems
or
interoperability
problems?
And,
if
not,
is
there
any
harm
in
just
leaving
it
alone,
because
any
change
to
the
document
makes
life
unpleasant,
but
if
they
are
causing
people
heartburn?
C
D
The
place
where
these
have
caused
problems
is
that
is
in
addresses,
because
we've
had
historical
problems
where
various
things
pick
up,
addresses
and
quoted
strings,
put
them
through
processing
in
the
operating
system
and
which
have
their
own
interpretation
of
what
to
do
with
quotes
and
then
quote
and
unquote
and
re-quote,
and
the
fact
that
we've
got
a
double
quoting
convention
where
we've
got
quoted
strings
using
quote
marks
and
quoted
things
using
bank
slash
is
is,
is
a
problem
as
well,
and
I've
certainly
seen
in
addresses
and
in
the
transport
system
problems
with
these
with
with
quoted
strengths.
D
D
And
well
yes,
but
empty
ones
have
proven
a
specific
problem,
because
we've
run
into
operating
systems
which
look
at
an
empty,
quoted
string
and
feel
a
need
to
remove
the
quotes
right.
They
couldn't
remove
things
and
if
those
quoted
strings
have
any
semantic
value
to
anyone,
which
is
something
I
haven't
seen
yet,
then
they
cause
a
problem
and
if
they
don't
cause
a
problem,
and
somebody
starts
comparing
a
source
string
which
has
quotes
to
it.
D
Non-Source
string,
which
has
the
has
had
the
quotes
removed
and
the
comparison
fails,
because
we
don't
have
rules
about
how
to
make
these
comparisons.
Then
we
end
up
with
interoperability
problems.
So,
yes,
we
have
seen
difficulties
with
these.
They
are
of
no
earthly
use
and
and
if
we
can
get
them
out
of
there,
it's
probably
an
improvement.
F
D
A
Someone
want
to
make
a
case
for
empty
quoted
strings,
just
slightly
playing
devil's
advocate.
I
think
the
only
case
I
could
think
of
is
display
name.
A
So,
instead
of
you
know,
quote
selects
email
space
melanico
just
have
empty
quotes,
and
it
should
it's
sort
of
seem
whether
I
don't
know
whether
people
admit
it
and
if
we
stop
allowing
for
it
what
will
break,
but
in
all
other
cases.
I
think
my
very
quick
analysis
from
yesterday
suggests
that
they
are
probably
more
problematic
than
they
were
so
one
possibility
is
to
special
case
the
displayed
mk
name
case
to.
C
C
So
dave
crocker
says
quoting
or
not
quoting
is
not
supposed
to
have
semantic,
meaning
it's
only
intended
as
an
encoding
mechanism,
so
absence
clear,
concrete,
absent,
clear,
concrete,
compelling
reports
of
significant
problems,
don't
change
the
spec
just
kind
of
where
I
started,
and
if
you
take
a
look
in
5322
bis
in
the
note
about
this
errata,
I
believe
I
point
to
a
discussion
in
2002
for
whatever
that's
worth
where
this
question
came
up
and
people
said
no,
no
leave
it
alone.
That's
it's
just
fine!
C
The
way
it
is
so
yeah
I
I'm
ambivalent
about
this
one.
I
I
don't
like
changing
the
syntax,
but
if
it's
causing
damage-
and
we
know
it's
causing
damage
and
they're
not
used
in
any
particularly
useful
way.
Maybe
we
do
want
to
correct
it.
D
If,
if
this,
if
somebody
were
trying
to
use
one
of
these
things
and
explain
it,
presumably
to
explicitly
suppress
the
display
name,
why
wouldn't
they
use
it?
As
quote
space
quote,
because
again,
the
things
go
away
but
there.
D
But
there
is
an
alternative
here
if,
if
people
feel
like
this
is
too
radical
a
change
for
for
the
five
three
two
two
syntax,
which
is
to
detach
the
definition
of
quoted
string
in
in
five
three
two
one
bis
from
from
the
five
three
two
two
bis
definition
and
take
it
out
there,
because,
because
in
five
three
two
one
the
only
thing
it
affects
is
addresses
and
that's
where
I've
seen
the
part.
It's
mailbox
names
and
that's
where
I've
seen
the
problems.
C
Right
and-
and
you
know
that
that's
that's
been
the
case
consistently,
you
know
for
a
long
time
that
5321
821,
dot
dot
dot
has
always
been
the
place
that
sort
of
well
yeah-
those
are
all
nice,
and
that
was
syntactically
fine
in
the
message,
but
when
you're
actually
doing
something
and
taking
that
and
putting
it
into
an
smtp
command
stream,
you
fix
it.
So
dave's
follow-up
by
the
way
is
the
issue
is
not
that
it's
suboptimal
or
unappealing,
but
that
it's
not
known
to
cause
serious
problems.
C
I
thought
the
goal
for
this
round
of
effort
with
the
specs
was
to
make
minimum
changes
required.
This
one
isn't
required
so
yeah
equivalent
to
what
I
was
saying
earlier,
but
john
you're
saying
that
you've
actually
seen
empty
strings
float
in
empty,
quoted
strings
float
in
and
they
have
caused
problems
on
the
smtp.
D
What
what
what
I've
seen
as
as
the
most
extreme
example,
is
from
mini
writing
a
mailbox
name,
which
I
guess
we
would
describe
as
bracket
quote
quote
at
sign
domain
name
right,
hello
and
when
somebody
fixes
that
they
end
up
with
a
syntax
error,
although
the
original
is,
is
nearly
stupid
as
this
thing
from
invalid.
D
So
so
I
would
argue
that,
because
we've
seen
damage
there
that,
if,
if
someone
wants
to
pursue
this,
I
would
hope
it.
I
would
hope
I'm
not
yet,
but
I
may
have
to
be.
D
We
dropped
the
5322
discussion
just
on
the
basis
that
we
haven't
seen
enough
evidence
of
serious
damage
there
and
that
we
we
fixed
five
through
two
one,
which
is
to
explain.
D
C
And
I'll
jabber.
D
There
we
get
back
the
question
whether
prohibiting
that
in
5321
causes
damage
and-
and
that
gets
us
back
to
the
argument
that
there's
no
evidence
taking
the
child
causes
any
damage
at
all.
C
Right
and
so
ned
then
says
this
ned
says
over
in
the
jabra
room.
This
is
a
layering
violation,
since
we
don't
specify
the
process
for
canonicalizing
addresses.
We
don't
have
any
way
of
telling
what's
legal
for
a
given
admd
and
what
is
not.
It's
perfectly
permissible
for
an
admd
to
allow
an
empty
local
part,
represented
syntactically
as
a
pair
of
quotes
or.
A
Not
for
the
wonderful
coffee,
sound
in
background,
if
you
can
hear
it
yeah,
I'm
just
wondering.
Shall
we
just
test
this,
I
mean
it
should
be
fairly
simple
to
generate
message
with
empty
quotes
in
various
kind
of
places
like
receive
header
field
and
just
by
a
name,
and
I
can
even
generate
keywords
at
the.
A
D
We
don't
want
to
change
the
spec
unless
it's
clear
signs
of
damage
and-
and
there
may
be
no
clear
signs
of
damage
in
in
five
three
two,
two
and
and
my
difficulty
is
that,
because
these
things
which
mess
with
quotes
tend
to
be
operating
system
dependent,
we
could
undoubtedly
find
two
systems.
We
could
send
these
things
to
where
they
would
work
fine
and
two
systems
where
we
could
send
these
things
to
where
they
would
not.
Look
fine
and
fortunate.
G
Around
just
so,
you
know
it
took
me
about
35
seconds
to
find
examples
of
of
empty
quarter
strings
in
my
email
archive.
It's
in
use
in
this
play
name.
D
There
are
two
algorithms
I
know
of
in
was
that
about
what
to
do
with
the
display
name
when
the
user
doesn't
supply
one
and
one
of
those
algorithms
is
to
supply
an
empty
quoted,
string,
okay
and
the
other
is
to
is
the
more
common
practice
of
copying
the
email
address.
It's
copying
the
mailbox
name
into
the
display
name,
and
sometimes
quoting
it.
G
Yep
and
the
thing
is
with
we
can't,
given
that
it's
prevalent,
we
can't,
we
can't
tell
people
to
throw
away
messages
that
are
syntactically
illegal
when
they,
when
they're
when
they're
there.
So
we
can't
disallow.
C
So
so
I'm
hearing
actually
a
resolution
in
some
sense,
which
is
this
is
not
a
5322
issue
to
solve
and
if
there
is
an
issue
to
solve,
we
toss
this
over
to
53
21
to
deal
with
the
handling
at
the
smtp
layer
of
local
parts
that
are
empty
and
we
go
on
from
there.
D
Well,
there's
another
alternative
which
has
the
same
effect
as
far
as
you're
concerned
pete,
which
is
to
go
into
the
a.s
and
say
yeah
right
these
th.
These
things
are
bad
news
and
sometimes
they
get
distorted
and
stink
and
and
sometimes
they
produce
bad
results
in
muas
and-
and
you
know,
if
you're
gonna
do
this-
expect
it
isn't
gonna
work,
sometimes.
C
Right,
okay,
so
I
I
feel
for
my
purposes,
this
one
is
pretty
much
done
and
alexi
I'll
leave
it
to
you
whether
you
want
to
convert
the
issue
to
something
other
than
a
5322
issue
or
whether
you
want
to
close
the
close
this
one.
Assuming
the
list
is
okay
with
this,
and
obviously
we'll
we'll
post
that
in
in
summary,
and
if
the
list
is
cool
with
this
idea,
then
reintroduce
a
new
issue
for
5321
or
the
as
or,
however,
you
want
to
do
it.
Yeah.
C
You're
right
right
right,
right,
yes,
okay,
so
that
that
sounds
like
a
good
summary
to
bring
to
the
list
and
and
make
sure
everybody's
on
board.
Shall
we
go
on
to
the
next
slide?
Oh,
the
answer
to
harold's
question
is
yes,
the
op
syntax
is
still
in.
There
hasn't
changed.
C
This
one
is
an
interesting
errata
that
was
filed,
which
was
hey,
wait
a
minute.
The
header
field
name
does
not
have
a
length
limit
in
its
description,
and
this
one
is
yet
another
example
of
well.
It
doesn't,
but
no
one
has
really
screwed
it
up
yet
do
we
want
to
change
the
syntax
to
say
that
it
really
can't
be
more
than
77
characters,
long
to
leave
space
for
the
colon
and
the
space
after
it
and
yeah?
C
C
D
C
D
D
But
if
if
this
is
really
our
last
cut
at
this
at
least
a
warning
is
probably
in
order
that
that
there
is
this
length
limit
overall
and
if
the,
if
the
trace
fields
exceed
it,
then
if
the
field
names
exceed
it,
then
then
they
will
get
themselves
into
trouble
sooner
or
later.
Right
and
again,
we
can
again.
D
D
C
I
think
that's
the
last
of
the
issues
we
had
to
discuss
for
53.22.
Am
I
correct.
A
C
All
right,
kurt
says
making
it
explicit,
we'll
start
for
lots
of
semicircular
arguments
amongst
people
having
difficulty
counting
yeah.
C
Yeah,
like
I
said
I,
I
I'm
you
know
it's
the
it's
the
working
group's
choice,
but
I'm
personally
with
editor
hat
off
of
the
mind
that
the
less
changes,
the
better
ned
says
you
can't
break
a
header
field
name.
So
the
effect
is
that
you
should
limit
these
things
to
78
characters,
including
the
colon
right.
D
All
right
that
sounds
to
me
like
a
perfectly
good
comment
in
the
av
and
f
per
alexis
observation,
and
that's
not
really
a
change
in
the
sense
that
you're
worried
about
changes.
C
Yeah
yeah
yeah
all
right,
well
I'll
get
what
summary
we've
heard
here
posted
to
the
list
for
these
issues
and
assuming
everybody
is
happy
with
what
I
describe
them
as
we'll
go
forward
and
do
something.
So
I
will
pass
the
baton
over
to
john.
At
this
point,.
A
D
Yeah
well
yeah!
Well
as
as,
as
indicated
earlier,
I'm
not
prepared
for
this.
I'm
also
having
a
great
deal
of
difficulty.
Reading
the
screen.
D
This
opens
the
worms.
The
cat
of
worms
is
not
the
it's,
not
the
registry
of
the
absence
of
the
registry,
but
but
this
whole
issue
of
of
relay
and
delivery,
which
gets
back
to
to
dave
crocker's
comment
on
the
list.
D
D
It
gets
us
tangled
up
with
a
lot
of
semi-historical
things
about
about
gateways
which
are
not
precisely
relay
devices
relays
and
and
and
all
of
the
reasons
why
smtp
was
very
carefully
designed
back
to
to
create
craig
parcher's
little
amendment
to
to
operate
in
a
in
a
terrible
connectivity,
environment
and
there's
a
case
you
made
that
we
ought
to
be
ripping
a
whole
lot
of
that
out,
because
we
don't
have
as
many
interconnected
non-tcp
networks
as
we
used
to
and
maybe
in
all
needs
rethinking,
but
that,
of
course,
would
be
a
change
so
significantly
back
in
proposed
standard
a
second.
D
So
I'm
I'm
indifferent
to
this.
I
recorded
it.
I
don't
have
strong
preferences
one
way
or
the
other.
A
Based
on
the
mailing
list
responses
so
far,
I
think
people
question
whether
expert
review
is
a
good
policy
for
this,
because
of
how
many
proprietary
header
fields
there
are.
So
we
can
do
first
come
first
serve.
My
personal
concern
in
this
case
would
be,
if
people
don't
add
information
which
is
right.
They
say
it's
like.
It's
only
been
done
by
relay,
but
it's
done
by
other
entities
who
can
correct
the
information
so
but
we're
not.
F
D
To
go
about
this,
but
but
that's,
but
that's
also
true,
of
expert
review.
Ultimately
somebody
somebody
ends
up
having
the
referee
who
can
make
changes
if
the
if
the
person
who
originally
proposed
registration
isn't
responding
stimuli.
D
You
know
I
I've
got
a
general
bias
that
registries
are
a
good
idea
because
they
prevent
conflicting
uses
of
names,
but
but
I'm
not
certain
that
applies
in
this
case
and
and
yes,
if
people
start
squatting
on
names,
if
we
end
up
with
correction
problems,
if
we
end
up
with
incorrect
information
problems,
it's
an
issue-
and
maybe
this
is
one
of
the
ones
where
we
ought
to
leave
the
the
registry
of
wikipedia
rather
than
to
to
ayanna,
which
is
to
say
wash
our
hands
on
the
problem.
E
E
D
That's
certainly
an
answer,
and,
and
of
course
we
can
defer
the
discussion
to
the
bas
and
then
lose
it.
You
know
part
part
of
what
causes
me
concern
about.
This
is
that
we
have
never
really
tried
to
seriously
and
precisely
define
the
the
situation
in
which
something
is
running
as
a
relatively
passive
relay
at
the
administrative
boundary
of
the
delivery
environment,
but
the
real
delivery
mta
is
behind
it.
D
D
Although
there's
language
in
the
in
dave's
architecture
document,
I
I
think
we're
opening
cancer
worms
here.
A
No,
but
it's
on
our
to-do
list.
We
need
to
talk
to
the
interview
the
person
who
volunteered
and
I
asked
for
more
volunteers.
A
A
A
Sorry
I
muted
myself
and
then
I
was
saying:
let's
move
on
to
the
next
one
right,
so
this
one
is.
A
A
So
basically
the
war
ii
er
atoms
submitted
one
was
rejected.
Then
there
was
a
more
extended
one
suggesting
to
align
this
with
rfc
3986,
which
is
uri
spec
and
rfc
5952,
which
is
like
human,
readable
syntax
for
ipv6
addresses.
A
Well,
I
mean
you
know
they
were
published
at
different
times,
so
that's
not
entirely
surprising.
So
if
you
see
on
the
next
slide,
yeah
so
like
leading
zeros
as
well
as
hex
digits
are
supposed
to
be.
E
A
In
lowercase,
in
recommendation
so
before
we
actually
go
to
my
straw,
man
question
is:
is
there
let's
say
just
for
the
sake
of
argument
that
we
mandate
that
all
hex
digits
are
going
to
be
lower
case?
Is
this
going
to
be
interrupt
problem.
A
All
right
so
ned
said
he
posted
a
message
to
the
mailing
list,
which,
unfortunately,
I
haven't
seen.
He
suggests
we
take
it
to
the
mailing
list.
D
I'm
I'm
in
favor
of
that
one
observation,
which
is
that
if
people
are
going
to
point
to
this
mess,
then
there
needs
to
be
a
dividend
in
my
strong
recommendation
to
the
isu,
which
I
hope
I
don't
have
to
make
in
the
form
of
an
appeal
is
that
we
need
to
straighten
out
this
ipd6
syntax
and
make
it
definitive
and
and
that's
probably
something
which
given
where
this
started
needs
to
come
out
of
the
presumably
the
the
internet
area
and
the
ip
area
and
and
updates
all
of
these
stray
documents
which
have
their
own
strange
ideas
about
syntax
and
when
that's
done,
then
it
becomes
appropriate
to
change
5321
to
match
whatever
it
is.
D
That
says.
But
what
has
happened
here
is
that
we
put
syntax
into
2821
which
matched
the
then
theories
to
what
idv6
addresses
looked
like.
We
put
syntax
into
5321,
which
matched
the
dense
syntax.
As
to
what
ipv6
addresses
looked
like,
and
and
now
we're
talking
about
changing
five
three
two
one
bish
to
match,
whatever
we
think
ip
addresses
look
like,
which
has
changed
each
time
and
and
I'm
in
principle,
opposed
to
changing
it
again.
D
Unless
there's
a
clear
statement
of
itf
wide
applicability
as
to
what
ipd6
address
is
supposed
to
look
like,
ideally
either
there
or
then
we
do
something
in
five,
three,
two
one
or
an
as
which
says
different
historical
reasons.
You
want
to
permit
the
following
kinds
of
flexibility,
but
and
again
we
can
take
that
to
the
list,
but
I'm
I'm
at
least
mildly
opposed
to
changing
this,
a
third
time
as
the
tides
go
in
and
out
in
various
documents,
defining
network.
D
A
E
A
Right
and
I'll
just
quickly
show.
The
next
slide,
which
shows
complicated
at
5952,
is
actually
inconsistent
with
itself.
So
there
are
issues
there.
D
Okay,
yeah
in
in
general,
I
am
opposed
to
changing
and-
and
this
is
reminiscent
of
pete's
comment
with
the
observation
that
we
changed
it
we
made,
we
were
making
more
mistakes,
I'm
opposed
to
making
changes
in
5321
because
of
things
that
the
5952
and
especially
3986,
decide
to
do
deciding
creatively
to
do
or
not
to.
A
So
this
one
might
be
a
very
little
issue
or
it
might
be
big
grenade.
I
have
no
idea,
so,
let's
just
have
a
go
with
it.
A
So
john,
you
pointed
out
that
there
is
a
definition
of
domain
names
and
well
domain
names
as
used
in
smtp,
and
it
says
only
dissolvable
fully
qualified
and
the
main
names
are
permitted.
A
You
suggested
clarifying
resolvable
in
the
public
dns.
I
am
sort
of
personally
suggesting
to
go
the
other
way
by
saying,
if
I
just
removing
resolvable,
because
I
think
whenever
you
talk
about
resolvability
of
domain
names,
it's
quite
clear
in
the
context
in
the
rest
of
the
document.
D
D
We've
avoided
in
5321
and
its
relatives
creating
the
sort
of
you
can
send
this,
but
you
you
you
can
receive
this,
but
you
shouldn't
send
it
stuff
and
much
as
it
might
be
appropriate
in
some
places.
That
would
be
a
fairly
major
change
in
the
text.
D
The
reason
for
resolvable
is
that
without
resolvable,
fully
qualified
domain
name
begins
to
look
a
whole
lot
like
something
with
with,
with
with
some
ascii
characters
and
some
thoughts
in
it.
As
long
as
you
don't
have
two
consecutive
dots,
and
indeed
without
those
church
and
ascii
characters,
not
because
of
of
the
smtp
utf-8
work,
but
because
modulo
syntax
restrictions
in
821,
which
made
their
way
into
11,
34
and
11
35
is
the
preferred
syntax
there's
you
know,
no
domain
name
need
for
this
restriction.
D
D
Again,
I'm
a
little
lucky
to
start
fooling
with
this,
unless
we
introduce
unexpected
problems,
but
but
when
readers
come
to
the
conclusion
that
if
it
says
this,
you
want
to
start
testing
and
rejecting
in
various
places,
we're
we're
pushing
historical
boundary
and-
and
maybe
the
right
thing
to
do-
is
to
have
the
ais
explain
that
historical
boundary
of
people,
but
but
I'm
I'm
reluctant
to
take
resolvable
out
and
again.
D
However,
this
thing
is
came
to
me
and
I
don't
feel
nearly
as
strongly
as
as
as
this
slide
might
indicate
about
how
we
might
handle
this
public.
Dns
is
an
issue
I
don't
know
if
it's
helpful
or
not,
especially,
we
get
that
trace
fields
to
to
restrict
people
from
putting
nonsense
there.
D
Localhost
israel
is
not
a
for
a
publicly
resolvable
domain
name
or
a
domain
name
in
the
public
dns,
depending
on
who
you
ask
for
the
context
you're
talking
about
and
again
the
variation
of
the
robustness
principle,
which
is
a
little
good
sense,
goes.
A
long
way
would
be
helpfully
applied
here.
E
Yeah,
there's
nothing,
you
know
we're
trying
to
accomplish.
There's
nothing
in
here
that
says
public
so
use
within
a
particular
administrative
domain
where
something
might
be
resolvable
that
isn't
resolvable
outside
is
an
issue.
There
are
a
whole
lot
of
issues
here.
There
are
a
whole
lot
of
dragons
involved
with
changing
this.
I
think
I
feel
fairly
strongly
that
for
the
stability
of
the
document
and
the
other
documents
that
reference
it,
we
should
not
change
it
and
we
can
discuss
the
issue
in
the
ais,
but
not
change
what
we
say
here.
D
Yeah,
I
I
I
think,
that's
right
and
and
I'd
add
that
if
we
start
trying
to
parse
this
and
and
put
qualifiers
and
details
here,
we're
rapidly
going
to
have
to
separate
domain
names
and
addresses
from
domain
names
and
various
other
places,
and
that
introduces
complexity
and
the
and
the
potential
for
errors
that
we
really
don't
need.
A
Right
so
comments
from
that
was,
he
was
agreeing
with
me.
There
are
many
private
use
cases,
so
I
don't
know
whether
I
think
nat
is
probably
not.
Are
you
happy
with
no
change
or
are
you
happy
was
deleting
resolvable
still
dave
said
that
he
wants
no
change.
He
thinks
some
ambiguity
is
actually
a
good
thing
here
and
that's
still
things
that
he
wants
to
drop
reservable.
E
A
D
Again,
my
my
concern
is
about
unintended
consequences
of
making
that
move.
I
think
I
think
you're
right,
incidentally,
but
my
concern
is
about
unintended
consequences
of
making
that
move
and
and
the
next
top
problem
interacts
with
the
gateway
problem.
A
D
Yeah
the
reason
if
I
remember
the
original
discussion
for
the
ad
for
the
request
to
add
the
public
dns
was,
was
simply
that
if
the
domain
name
appears
someplace,
that
a
recipient
has
to
get
hold
has
to
do
something
with
it,
then,
if
it's
put
in
by
somewhere
near
the
center,
and
if
it's
put
in
some
place
where
the
recipient
has
to
deal
with
this,
then
the
recipient
has
no
hope
of
res
of
interpreting
anything
else
and
and
that's
the
argument,
I
don't
find
it
particularly
compelling.
A
All
right,
so
this
actually
made
me
wonder
whether
I
should
split
the
ticket
two
to
two
one
is
about
whether
it
should
me
say
resolvable
here
and
the
other
about
private
domain
names.
A
D
My
personal
preference
partially
because
I
I'm
afraid
of
side
effects
of
touching
stuff
like
this
rather
than
because
I'm
opposed,
but
my
personal
preference
is,
would
be
to
put
a
discussion
into
the
ais
about
what
resolvable
means
and
how
one
might
interpret
it
in
particular,
strongly
discouraging
the
the
attempt
to
resolve
anything.
You
see
when,
when
it
recedes.
D
Keeping
in
mind
that
one
of
the
reasons
why
resolvable
is
here
is
that
if
a
domain
name
appears
in
a
mail
from
a
mail
command
and
the
message
reaches
the
other
end,
and
somebody
tries
to
do
a
reply
or
even
bounce
a
message
that
if
that
is
not
a
public
resolvable
type
domain
name,
it's
hopeless.
F
A
Okay,
so
I
hope
seth
is
taking
good
notes
for
this
section.
I
I,
I
think,
yeah.
B
D
D
Of
things
which
make
one
address
into
more
addresses
and
send
them
out
to
avoid
using
any
of
any
other
vocabularies
gets
complicated.
D
And
may
not
work
anymore
because
of
other
things
we've
done
to
the
internet,
but
that's
not
an
smtp
problem
and
those
things
should
not
be
messing
with
anything
but
trace
fields,
because
they
shouldn't
need
to.
D
The
other
kind,
as
dave
explained
on
the
mailing
list
better
than
I
can
do
with
at
this
hour
in
the
morning,
are
things
where
the
mail
is
delivered
to
something
which
then
simulates
an
exploding,
mua
type
of
thing
and
sends
it
back
out,
and
in
that
situation,
all
kinds
of
interesting
things
get
changed,
because
it's
actually
a
new
message
which
the
message
coming
into
that
pseudo
mua
past
the
delivery
server
basically
constituted
an
a
request
to
turn
in
some
other
message
and
redistribute
it,
and
in
that
second
model.
D
Adding
list
fields
is
entirely
reasonably
appropriate,
but
it
has
nothing
to
do
with
first
model.
So
in
some
sense
the
question
here
is
not
whether
to
diddle
around
with
list
star
fields
in
5321.
A
So
I
think
what
you're
saying
is:
this
restriction
is
valid
for
mta
level
explorer,
but
not
for
the
mailing
list.
So.
A
All
right
dave,
you
go
ahead
and
you
probably
have
the
closing
words.
H
H
The
alias
mechanism
happens
to
be
a
very
streamlined
capability,
but
it
is
architecturally
after
delivery,
just
like
mailing
lists
the
fact
that
they're
super
streamlined
and
they
and
they
don't
mess
around
with
a
lot
of
the
data
and
they
preserve
a
lot
of
the
data
makes
it
really
easy
to
think
that
it's
part
of
the
relaying
process,
but
aliases
are
not
part
of
relaying.
They
come
after
delivery.
They
are
a
reposting
mechanism
that
just
preserves
the
heck
out
of
the
message
that
it
got,
whereas
mailing
lists
don't
do
that
much
preservation.
H
The
reality
today
is
that
that
this
world
of
additional
handling
has
gotten
so
much
more
elaborate
and
better
documented
that
there's
just
no
way
5321
is
going
to
do
justice
to
these
topics.
D
Takes
us
back
to
the
gateway
and
psi
gateway
and
pseudo
gateway
problem,
which
is
itself
a
can
of
worms
and
the
possible
need
to
apply
aliases
there
in
order
to
make
addresses
work
in
the
environment,
that
the
other
side
of
the
thing,
which
is
fussy
and
we
don't
have
a
clear
boundary
between
relays
and
things
which
move
mail
into
slightly
different
kinds
of
systems,
gateways
and
almost
gateways
and
other
things,
and
I'm
reluctant.
For
that
reason,
and
some
others
to
eliminate
the
mta
level,
alias
if
you
like,
expansion
capability
or
renaming
capability.
D
Although
I
completely
agree
with
dave's
observation
that
that
in
the
modern
world
for
for
both
the
reasons
he's
identified
and
another
and
other
sets
of
reasons
that
we
may
not
see
this
very
often,
but
but
when
we've
got
something
which
is
at
a
boundary
into
a
different
kind
of
environment.
Even
if
it's
using
smtp
on
both
sides
for
that
to.
D
Expand
things
really
may
be
a
nmta
function,
a
handy
example
or
his
peculiar
handling
postman
of
postmaster
in
some
environments,
which
has
always
been
an
odd
special
case
and
will
continue
to
be
one
until
we
eliminate
that
requirement,
which
de
facto
is
gone
in
many
places.
A
Right
quickly,
I
think
we
might
be
shut
down
anytime
now,
because
we
have
passed
five
minutes
past
the
the
end
of
it.
So
ned
was
saying,
except
that
it
isn't.
I
think,
in
response
to
dave
that
just
isn't
how
things
work
he
posted
on
the
mailing
list.
So
let's
take
this
to
the
main,
invest.
A
Thank
you,
everyone
for
coming
and
staying
so
late
or
so
early.
I
know
the
time
is
not
ideal
this
time,
but
thank
you
for
participating.