►
From YouTube: IETF113-EMAILCORE-20220325-1130
Description
EMAILCORE meeting session at IETF113
2022/03/25 1130
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
A
A
A
A
A
A
A
A
A
A
A
E
So
I
read
the
the
thread
in
the
mailing
list
two
or
three
times
and
the
summary
there
is
what
I
boiled
boiled
the
issues
down
to
at
least
my
understanding
of
it
and
came
up
with
this
the
following
suggested
text.
I
don't
think
it's
worth
my
while
to
read
it.
You
can
also
I'll,
read
it
and
if
there's
any
objections
to
that,
I
am
more
than
willing
to
accept
some
some
text.
E
In
the
original
text
actually
said,
you
must
implement
the
the
spec
that
was
actually
the
original
registry
for
the
code,
so
that
was
that
was
confusing.
So
this
actually
says
you,
it's
recommended
to
implement
the
enhanced
status
code
extension
to
smtp
and
then
also
refers
to
the
list
of
codes
in
the
registry.
A
A
talking
about
possible
clarification
about
mail
transactions
and
transaction
state,
so
john's
original
note
was
that
section
33
should
be
would
be
improved
if
it
be
more
specific
about
when
mail
transaction
begins
and
ends
and
what's
part
of
the
transaction,
there
was
some
updates
to
the
document.
Since
the
original
issue
was
raised,
I
had
a
look
at
the
text
in
this
section
and
I
quoted
the
first
paragraph
of
it,
which
I
think
talks
exactly
about
what
john
was
asking
about.
A
D
I
hope
you
can
hear
me.
Yes,
I
I,
as
as
I've
looked
at
this
more,
I
I
agree
with
you.
No
no
change
is
needed.
I
think
a
small
editorial
twitch
would
probably
improve
things
slightly
and
and
propose
the
insertion
of
of
the
word
normal
in
that
first
sentence
before
smtpm
mail
transactions
as
a
slight
improvement,
but
this
is
not
worth
a
lot
of
time.
A
A
X-Extensions,
so
they
are
not
prohibited
from
being
registered
now,
and
I
think
it
will
be
a
good
idea
to
register
some
of
them
which
raise
the
question
whether
our
iron
registration
policy
is
correct.
So,
roughly
on
the
following
slide,
there
are
two
proposals:
one
is
specification
required,
which
is
as
a
quick
reminder.
This
is
expert
review,
plus
specification,
which
can
be
rfc.
It
doesn't
have
to
be
ietf
stream.
A
A
A
D
I
don't
know
how
many
of
you
have
managed
to
see
the
notes
I
sent
to
the
list
not
too
many
hours
ago,
but
I'm
a
little
a
little
concerned
about
clutter
here
and
and
vanity
activities
and
yeah.
We've
got
some
dead
ones,
but
the
dead
ones
seem
to
be
reasonable
at
the
time,
I'm
so
what
I'm
I'm
sort
of
feeling
for
and-
and
I'm
also
concerned
about,
the
possibility
of
getting
a
an
extension
proposal
in
conjunction
with
some
special
application
that
the
that
the
expert
reviewers
don't
necessarily
understand.
D
So
I've
been
feeling
around
and
the
comments
on
the
list
summarize
some
of
it
and
I've
had
some
separate
conversations
with
murray
about
the
the
possibility
of
of
creating
a
sort
of
in
between
here
where
we,
where
we
don't
quite
require
the
level
of
of
approval.
The
current
text
does,
but
we
still
do
it-
a
community
last
call
in
which
which
which
gives
people
who
may
have
expertise,
that
the
experts
don't
and
this
mailing
and
this
mailing
list
doesn't
to
to
chime
in
on
the
thing.
D
A
A
F
We
recently
had
a
document
come
through
that
looked
more
like
new
to
where
it's
first
come
first
serve,
but
there's
some
provisions
around
that
and
vcp
26
doesn't
really
support
the
I
like
it
says
that
ayanna
will
basically
accept
anything.
That's
well
formed
if
you
say
first
come
first
serve
asking
them
to
make
a
judgment
about
whether
the
reference
describes
a
particular
thing
or
looks
a
particular
way
is
outside
of
ayanna's
remit.
So
I
think
new,
too,
might
be
a
harder
sell.
G
So
I
I
wrote
this
this
thing
here:
the
I'm
okay,
with
either
of
these
options,
specification
required
or
first
come
first
served
with
a
reference.
The
reason
that
I
proposed-
maybe
we
should
do
the
second
one-
is
that
I
wanted
to
really
stress
that
that
we
would
rather
have
these
registered
than
make
the
bar
high
to
get.
The
registration
specification
required
ought
to
be
a
very
easy
level,
but
changing
to
that
requires
that
we
appoint
an
expert
for
this
and
go
through
that
process
when
really
we'd.
G
A
My
counter
argument,
as
a
participant
you
know
I
I
kind
of
I
will
be
okay
either
way
is,
as
murray
pointed
out
earlier,
that
ayan
is
not
going
to
check
names.
So
if
I
start,
if
I
request
an
extension
called
my
shiny
balloon,
it
would
be
very
hard
to
refuse
and
say
no
pick
a
better
name
or
something
so.
F
G
H
G
G
D
A
I
I
think
I'm
aligned
with
barry
here
I
mean
I
understand,
sort
of
that
in
principle.
There
is
a
writ.
You
know,
there's
a
risk
that
people
might
want
to
sneak
horrible
stuff
through
here,
but
given
that
we're,
not
the
network
police,
if
they
want
to
do
horrible
stuff,
they'll
do
it
anyway,
so
I
would
presume
I
would
presume
to
be
documented.
D
G
G
H
Pete
resnick
I'll
repeat
what
I
just
said
in
the
chat
room.
I
have
a
leaning
toward
make
this
as
close
to
first
come
first
served
as
we
can
do
it,
and
I
like
the
idea
of
some
sort
of
documentation
that
gives
people
the
ability
to
you
know,
get
some
advice
from
the
community
if
they
want
it,
but
really
that
you
know
this
is
not
a
closed
name
space
at
all.
And
you
know
if
people
like
shiny
balloon
as
their
you
know
as
what
they
want
to
register.
G
Maybe
what
we
want
to
say
here
then
is
first
come
first
served
with
the
reference
must
also
be
provided,
describes
this
and
say
it
is
highly
recommended
that
registrants
post
to
this
mailing
list
and
get
feedback
before
they
proceed
with
their
registration,
something
there
that
will
encourage
them
to
ask
for
feedback,
but
still
allow
them
to
just
do
a
fast
track
registration,
if
that's
really
what
they
want
to
do.
What
do
you
think
john
clenson.
D
I
do,
I
do
think
the
implication
I
I'm
still
hearing
marshall's
voice,
which
is
in
the
text
and
and
the
the
implication
of
needing
to
fast-track
one
of
these,
because
somebody
has
come
up
with
a
brilliant
idea.
They
want
to
get
in
the
ayanna
registry
right
away
is,
is
an
invitation
to
having
to
revise
it
later,
for
which
we
have
no
procedure
at
all,
right
and
and
generally
creating
a
mess.
G
H
Get
ready,
pete
yeah
the
speed
again.
I
I
think
I
just
want
to
address
the
fast
track.
I
don't
think
that's
the
reason
that
I
lean
toward
first
come
first
serve
it's
pain
in
the
ass
right.
It's
we
want
people
who
have
something
to
register,
to
not
think.
Oh,
my
what
a
pain
in
the
ass,
let's
just
skip
the
registration
and
start
using
it,
which
I
think
is
what
happens
now.
H
I
don't
think
people
really
want.
You
know
it
needs
to
be
registered
today.
I
don't,
I
think,
that's
a
very
rare
instance.
I
think
the
real
problem
is
that
people
view
it
as
a
hurdle,
and
so
we
want
to
say,
there's
no
hurdle.
You
just
register
them,
but
please
announce
them
here
and
you
know
get
some
feedback.
G
So
you
know,
in
other
words,
so
you're,
okay,
with
the
idea
that
somebody
posts
to
this
mailing
list
gets
feedback
saying
your
idea
is
really
really
bad
rethink
it
please,
and
they
say
and
register
it
anyway
without
paying
attention
to
feedback.
That's
that's
my
preference,
because
I'd
rather
see
it
read
if
they're
going
to
use
it.
I'd
rather
see
it
registered
than
not,
but
that
covers
john's
concern
that
they
need
a
way
to
get
feedback.
G
H
A
D
D
The
the
the
the
my
my
other
concern
here
it
goes
directly
to
the
question
dave
asked
in
the
chat
is
that
we
end
up
with
a
with
a
registration
of
something
which
seems
to
have
something
which
looks
like
a
specification,
and
then
they
discover
it
doesn't
work
and
the
specification
changes.
They
don't
bother
it
or
adopt
a
registration
document,
because
that
too
is
a
pain
in
the
ass,
and
I
don't
know
that
can
be
prevented.
E
Okay,
ken
hi
ken
richardson,
I
think
the
the
bigger
issue
that
we
want
to
try
to
solve
here
is
not
having
two
different
vendors
start
using
a
keyword
at
the
same
time
without
either
one
of
them
registering
and
then
there's
eventually
name
clash.
I
think
that's
more
important
than
somebody
registering
a
an
extension
that
ends
up
being
technical
garbage
because,
as
pete
said
before,
no
one's
going
to
use
it
there's
no
interoperability
problem.
E
A
J
J
So
I
might
suggest
my
suggestion
is
minimize.
The
changes
address
only
the
the
problem
that
is
on
the
table,
which
is
getting
people
to
register
and
don't
try
to
quality
control,
the
registration
process
or
or
because,
if
they
want
it
to
be
used,
they
will
come
and
get
advice
if
they
are
convinced
in
their
arrogance
that
they
know
truth
they're
just
going
to
work
around
this,
don't
add
more
text
that
is
basically
parental,
even
if
it's
good
parenting.
G
G
D
It
it
it
doesn't
date
because
after
a
careful
look
at
the
ayanna
procedures-
and
barry
can
comment
more
on
this-
that
I
can
because
he
wrote
them,
but
but
the
iana
procedures
require
do
not
require
that
any
of
those
standard
categories
be
used.
It
requires
only
that
the
procedure
be
clear
to
ayanna.
G
J
J
J
D
J
D
But
but
but
if
we
do
what
I
suggested
more
or
less,
the
only
complication
is
whether
ayanna
can
make
a
mark
on
their
calendar
and
count
to
60
or
some
other
period,
which
somebody
picks
and
per
the
diana
specification
document.
Again,
barry
can
say
more
about
this
than
I
can.
If
iana
doesn't
think
they
can
count
to
60
reliably,
then
they
say
no
that
doesn't
work
so.
H
Sorry,
the
the
mask
right,
pete
then
barry
this
is
pete.
I
I
want
to
actually
disagree
with
john
on
this.
The
the
simplest
way
to
deal
with
this
is
do
first,
come
first
serve
and
if
we
want
some
sort
of
iana
instructions
in
the
iana
considerations
that
they
announce
it
somewhere,
that's
fine.
Putting
a
60-day
delay
is
exactly
the
kind
of
fence
that
is
going
to
cause
people
to
not
register
these
things,
and
I
think
the
amount
of
damage
they
can
possibly
do
is
so
minimal
that
it
should
not
be
done.
H
H
G
G
G
The
next
minimal
change
is
to
say
well,
but
this
is
really
is
ietf.
Review
is
really
what
this
means.
So,
let's
change
it
to
that.
Even
making
its
specification
required
is
more
than
a
minimal
change
and
making
it
first
come
first
serve
with
this,
and
that
tweak
is
a
bigger
change.
So
it
depends
how
we
want
to
go
with
changes.
H
Works
for
me
personally,
this
is
pete.
My
only
concern
about
specification
required
is,
I
don't
think
it
significantly
changes
the
barrier
that
the
current
text
has
such
that
we're
gonna
solve
the
problem.
No,
it
does
actually,
I
understand
the
difference
between
the
two,
but
I
I
suspect
that
anybody
who
is
unwilling
to
even
do
an
experimental
rfc
just
submit
the
draft
is
not
going
to
do
specification
required.
G
G
J
You
you
were,
you
were
laying
out
a
possibility
of
some.
Let's
call
it
casual
behavior
which
might
have
some
challenges
in
utility,
so
posting
to
a
blog
might
or
might
not,
actually
be
useful,
and
so
they
register
a
name
and
they
only
post
to
a
blog
and
gee.
That's
that
doesn't
work
very
well.
Let's,
let's
just
take
that
case,
which
is
just
what
I
assume
why
you
mentioned
that
as
an
example
and
to
which
my
response
is
so
what
their
their
option
perhaps
isn't
useful.
G
J
J
J
G
K
K
Wondering
actually
I
mean
I,
I
I
totally
understand
why
this
discussion
sort
of
is
necessary.
However,
I'm
wondering
a
little
bit
like
we
are
discussing
here
something
for
quite
some
time
now,
which
actually
is
probably
not
even
as
such
a
big
deal,
because
just
not
so
many
people
will
actually
ever
register
something
here
I
mean
one
could
argue,
because
currently
these
policies
are
too
strict,
but
I'm
actually
sure
that's
not
the
point.
K
G
G
A
A
G
D
D
I
think
we're
spending
far
too
much
time
on
this
discussion
than
it
is
worth
relative,
the
rest
of
the
agenda
and-
and
we
either
take
this
the
mailing
list
or
drop
it
and
and
adopt
the
principle
of
minimal
change,
which
I
of
absolutely
minimal
change,
which
I
would
oppose
as
well.
But
but
I
think,
we're
going
around
the
circles
right
now
and
the
fact
that
I'm
having
trouble
hearing
speakers
who
are
speaking
almost
next
to
micron
into
the
mic
doesn't
help
much.
G
D
A
A
A
I
I
I
D
Yeah,
just
remember,
too,
that
we've
got
enough
loopholes
in
in
five
three
two
one,
even
for
for
not
doing
things
if
they
don't
seem
sensible
or
don't
seem
operationally
reasonable
or
seem
insecure,
that
an
implementation
or
configuration
which
doesn't
feel
like
supporting
verify,
simply
leaves
it
on
the
hello
list
and
moves
on.
So
one
can
not
implement
this
while
implementing
it
or
something
like
that.
A
D
I
believe,
after
trying
to
review
them,
say
things,
but
but
it's
very,
very
easy
to
read
them
in
ways
which
the
in
which
what
said
it's
not
consistent
or
is
he
is
even
contradictory.
So
that
may
be
a
little,
maybe
a
little
straightening
out.
But
I
don't
think
there's
a
strong
case
for
making
any
substantive
change
here
like
trying
to
deprecate
the
thing.
C
Yeah,
just
to
clarify
the
earlier
bit
about
stop
appearing
in
the
spec
or
not
the
word
stub
doesn't,
but
in
section
seven
three
it
speaks
of
if
a
site
disables.
These
commands
for
security
reasons
and
one
of
the
commands
is
verified.
The
smtp
server
must
return
a
252
response,
so
that
kind
of
speaking
toward
the
sub
to
the
stub
topic,
without
actually
using.
C
A
A
A
A
A
D
A
D
D
A
John
levine
raised
another
question
about
what
is
restricted
capability
client
section.
Three
three
restricted
capability
client
must
not
assume
that
any
smgp
server
on
internet
can
be
used
as
their
mail
processing
relaying
site.
So
I
think
it's
it's
a
valid
question.
What
what
is
meant
by
the
student
capability
client,
also
depending
on
what
it
means.
If
this
is
talking
about
open
relays,
not
not
being
a
good
thing,
then
maybe
the
text
is
misplaced
and
should
be
moved.
I
I
think
I
would
I
didn't
understand
what
restricted
capability
client
meant,
and
I
just
you
know
it
like
if
it
if
it
means
it.
Like
the
example
I
gave
is
my
printer,
which
sent
which
sends
notifications
to
one
address.
I
mean,
if
that's
what
we
mean
by
a
restricted
capability
client,
then
the
advice
is
fine
and
maybe
we
should
define
restricted
capability,
client
better.
I
thought
it
might.
H
H
A
H
H
A
D
D
D
Because
I
think
this
texas
intended
to
talk
about
smtp
clients,
not
muas,
and
that
immensely
changes
the
meaning
what's
going
on
here,
although
it
still
doesn't
make
it
clear
and
and
again
the
the
note
I
sent
to
the
we
are
the
morning
about
this
may
at
least
clarify
what
the
problem
is.
If
not
what
the
solution
is-
and
I
have
no
opinions
today
beyond
that.
J
So,
as
I
posted
there's
sort
of
two
different
lines
of
thinking
that
can
go
with
this
text,
the
first
is:
do
we
know
of
existing
operational
problems
being
caused
by
this
text?
I
think
the
answer
is
no.
I
think
that
the
concern
being
concerns
being
raised
are
by
the
static
reading
of
the
text
and
thinking
about
it
rather
than
having
reports
that
argues
against
making
any
changes,
given
the
nature
of
the
current
working
group
effort.
J
J
It
isn't
specifying
it.
It
isn't
specifying
a
meaningful
action
or
prohibiting
it
isn't
meaningfully
prohibiting
an
action
that
makes
any
sense,
and
that
argues
for
just
dropping
this
text
completely,
because
we
don't
know
we
don't
seem
to
know
of
what
problem
this
is
trying
to.
The
text
is
trying
to
solve.
J
We've
just
had
several
people
make
some
guesses
about
it,
but
we're
not
sure,
and
so
if
the
text
is
confusing,
which
it
clearly
is
dropping
it
in
the
absence
of
knowing
what
problems
it's
picking
would
would
actually
be
the
simplest
thing
to
do,
leaving
it.
Given
that
we
don't
know
of
field
problems,
it's
causing
is
the
other
choice,
so
dropping
it
or
keeping
it
make
the
most
sense
changing
it
does
not.
A
D
I
feel
really
strongly
about
this
and
I
will
drop
it
if
people
tell
me
to
drop
it,
but
but
I
am
reluctant
to
remove
text
that
the
drums
the
drums
are
yam.
I
don't
know
which
one
at
this
point
put
in
without
without
understanding
what
that
was
intended
to
say.
So
I
would
argue
for
clarification
in
preference
to
dropping
if
we
can
figure
out
what
that
clarification
means,
and
I
think
clarifications
are
clearly
in
scope.
A
C
C
It
doesn't
just
say,
restrict
capability.
Clients
must
not
assume
it
says.
You
know
that
the
prior
sentences,
these
restrictions,
may
make
the
server
useless
as
a
relay
for
clients
that
do
not
support
full
smtp
functionality.
Consequently,
restricted
capabilities
must
not
assume
in
any
server
on
the
internet
whatever,
so
I
just
want
to
throw
that
out.
There.
D
Let
me
let
me
try
to
do
that
next
week
or
so,
and
and
if
john,
if
the
other
john
wants
to
have
an
office
conversation
about
how
that
fits
should
be
written,
I
would
appreciate
it.
I
would
also
appreciate
for
your
reputation
in
mind
if
you
would
clarify
how
his
last
name
was
pronounced
before
we
get
completely
confused.
H
D
D
A
D
I
I
I
I
do
think.
However,
the
condition
for
that
is
that
it
is
that
everybody
make
a
good
faith
effort
to
to
to
read
whatever
it
is.
I
write
and
then
see
if
we
can
either
fix
it
or
agree,
rather
than
not
agreeing
in
order
to
take
it
out
in
order
to
take
this
text
out,
and
that
was
the
reason
I
was
a
little
bit
reluctant
to
answer
each
question.
Yes,.
I
I
Yeah
here
we
go
yeah,
so
the
question
is
yeah.
We
have
a
host
that
handles
mail
for
yeah,
so
here's
the
setup
mail.example.com
handlesmailforexample.com,
but
not
for
itself.
So
if
someone
sends
so,
if
someone
addresses
a
message
to
mail.example.com,
what
should
it
say
and
as
the
next
slide
suggests,
we
have?
We
have
two
competing
answers.
One
is
550,
which
is
what
it
normally
says
and
the
other
is
556,
which
says
it's
a
null
mx
and
while
I
don't
think
556
is
wrong,
I
don't
think
it's.
I
also
don't
think
it's
realistic.
I
I
think
in
my
experience,
mail
mail
servers
know
what
domains
they
handle
and
they
know
what
domains
they
don't
handle,
but
they
don't
know
any.
They
don't
know
why
they
don't
handle
other
domains.
So
this
basically
would
require
every
time
a
receipt.
Two
fails.
You
know
it's
got
to
do
an
all,
mx
lookup
and
say:
oh,
I
know
I
know
what's
going
on
there
and
it's
actually
you
know
it's
it's.
It
could
be
surprisingly
complicated
because
it
is
not
rare
for
mail
servers
to
have
100
different
names.
I
mean
like
at
microsoftoutlook.com.
I
A
A
A
A
A
A
A
Okay,
so
petraeus
thumb
up,
so
you
will
have
a
look
at
this
text.
Suggest
clarification
or
you
know
things
to
delete
things
to
add.
I
think
probably
the
best
way
is
just
you
suggest,
set
of
changes,
we'll
review
it
on
the
mailing
list,
and
then
we
decide
which
one
goes
into
base
pack,
which
one
goes
to
as
if
any.
A
A
H
A
A
A
A
A
D
The
only
advantage
of
four
over
three
is
that
if
there
was
some
weird
case
which
so
far
nobody's
been
able
to
identify
that,
that
would
would
cause
somebody
to
want
to
put
a
trace
or
other
sort
of
receipts,
other
sort
of
fields
into
the
message
that
indicated
what
was
done
here.
Three
prohibits
that
probably
and
four
does
not
accept
that
three
is
except
that
there's
already
text
there
and
says
you
can't,
cannot
change
any
header
fields,
that's
already
in
the
message,
so
they're
right,
right
click.
G
G
G
H
H
Yeah,
this
is
pete
to
answer
dave.
Yes,
I
I
think
the
reason
we
need
to
say
something
here
is
because
people
have
had
trouble
with
this.
People
think
that
changing
the
mail
from
means
that
they
have
to
change
the
from
field
in
the
message,
which
is
a
bad
thing,
and
this
clarifies
that
we
only
mean
changing
the
mail
from
doesn't
affect
the
message
header
in
any
way.
H
As
far
as
instruction
goes,
there's
an
instruction
here
that
we're
going
to
be
leaving
in
which
talks
about
changing
the
mail
from,
but
that
doesn't
affect
the
header
section.
So
I
think
this
clarifies
and
doesn't
change.
What's
currently
in
the
text,
it
just
clarifies
the
meaning
of,
what's
in
the
text
that
people
have
screwed
up
in
the
past,.
G
J
J
So
my
to
to
apply
the
point
here
that
says:
option
two
remove
the
sentence.
The
sentence
is
that
I
mean
this
is
sort
of
beyond
layer
violation,
since
it's
53
21
talking
about
53
22
topics,
but
it
it's
sort
of
beyond
that
in
that
it's
trying
to
fix
a
problem
with
something.
That's
completely
out
of
scope
for
this
spec.
The
fact
that
historically,
it
was
in
the
spec
at
the
time
was
there
weren't,
really
meaningful
choices
were
30
years
later.
G
A
A
A
C
C
I
have
incorporated
them
in
my
working
document,
but
haven't
posted
them
to
the
list
or
in
the
ticket
or
anywhere.
I
would
encourage
people
to
look
at
the
list
and
give
it
another
pass
when
they
get
a
chance.
Let
me
get
you
the
proper
or
the
the
actual
subject
name
here
as
soon
as
I
can
find
it.
In
my
threads,
the
subject
is
ticket
number,
54,
authentication
and
encryption
for
a
asrev4.
A
A
A
A
D
D
But
at
this
stage
the
document
contains
both
sets
of
terminology
in
different
places
and
the
principle
of
minimal
change
would
say
that
that
we
just
leave
it
alone.
The
principle
of
maximum
clarity
says:
we've
got
to
make
a
decision
and
I
should
clean
it
up
and
I'm
agnostic
between
those
two
principles.
D
A
H
E
H
Yeah,
this
is
pete
since
john
said
that
there
are
still
instances
of
both
of
these
floating
around
in
5321.
I
think
the
as
could
do
well
to
clarify
the
meanings
of
these
terms
and-
and
you
know,
be
explicit-
that
5321
uses
both
sets
of
these
terms
and,
and
they
both
mean
the
same.
You
know
they
both
mean
the
same
thing,
but
I
don't
think
there's
any
particular
reason
to
go
one
way
or
the
other
in
the
as
we'll
pick
one
when
we
get
to
that.
A
K
Yeah
is
this
antioch?
I
would
like
to
say,
I
probably
prefer
send
a
receiver,
because
there's
an
smt
client
for
me
could
also
be
a
mail
user
agent.
You
know
sending
the
email.
This
is
actually
a
client
for
me
and
also
like
the
sender.
Smtp
still
techn
in
a
technical
sense
might
be
an
smtp
server
component
and
in
fact,
in
many
situations
it
is
just
the
same
piece
of
fulfilling
the
role
of
a
sender
smtp
and
a
receiver
smtp
yeah.
K
A
D
It
may
not
be
entirely
consistent
that
way,
and
the
question
I'd
like
to
ask
is
whether
people
would
object
to
simply
inserting
the
sentence
that
a
sentence
equivalent
to
what
murray
suggested
into
in
the
thing
which
says
that
in
general,
these
two
things
are
just
interchangeable.
These
two
sets
of
things
just
interchange
and
would
move
on
that.
That's
a
clarification
which
really
ought
to
be
made
for
people,
reading,
5321
bis
and
not
merely
in
the
as.
D
D
A
D
D
It
is
at
least
for
me
much
more
much
easier
to
get
texts
into
documents
based
on
mail,
english
discussions
than
to
remember
what
happened
in
an
oral
discussion
and
and
transcribe
for
minutes
and
and
in
theory,
we
shouldn't
be
making
any
of
these
decisions
without
confirmation
on
the
mailing
list.
So
if
between
now
and
the
next
ietf
for
the
next
interim
or
the
next
lawn
party,
we
can
all
pay
more
attention
to
mailing
list
and
and
and
respond
to
things
there
make
suggestions
there.
A
D
D
H
Yeah,
this
is
pete
just
to
agree
with
that.
I
would
prefer
you
get
the
interim
scheduled,
because
getting
getting
time
on
the
calendar
for
a
good
block
is
sometimes
tricky
and
you
know
getting
it
on
the
calendar
and
if
we
have
to
cancel
it
is
way
better
than
waiting
to
see
if
we
need
it
and
then
trying
to
squeeze
it
in
fine,
so
todd,
and
I
will
try.
A
F
A
A
K
Yeah,
fine,
sorry
for,
but
I
mean
maybe
for
it
anyway.
So
when
I
was
looking
through
my
notes,
I
was
thinking
about
what's
going
on
here,
so
I
understand
you
basically
went
through
those
two
rfcs
mentioned
in
the
charter
sentence
by
sentence
and
try
to
figure
out
where
there
are
inconsistencies
or
clarities
right.