►
From YouTube: IETF114 EMAILCORE 20220726 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
on
that
note,
you're
here
in
the
ml
core
and
let's
get
started,
we
haven't
now.
I
initially
thought
we'll
finish
early,
but
I
suspect
there
are
actually
several
discussions
that
might
require
a
bit
of
more
time.
So
I
thought
we'll
try
to
stay
on
top
of
it
and
kick
us.
You
know
if
we're
not
doing
it
quickly
enough
right
with
that.
A
A
A
Just
a
quick
reminder:
if
you're
in
the
room
please
use
masks
when
you
talk
to
microphone,
don't
take
them
off,
obviously
doesn't
apply
to
remote
people.
Lucky
people.
A
Quick
recap
of
the
agenda:
hopefully
there
is
no
agenda
bashing.
There
are
two
items
for
smtp
spec,
the
first
one
about
four
clauses,
kind
of
smtp,
slash
applicability
statement,
but
and
then
we
would
like
to
get
closure
on
a
registration
policy.
Yes,
john.
B
This
is
a
a
question
rather
than
just
a
certain
agenda
I
know,
but
do
you
want
to
spend
a
few
minutes
discussing
the
the
issue
which
should
not
versus
must
not
with
550
codes?
That's
been
on
the
email
list.
A
A
Okay,
can
you
remind
us
at
the
end,
if
we
don't
run
out.
A
So
we
have
a
fair
amount
of
tickets
for
applicability
statement
actually,
while
reviewing
them,
I
think
a
lot
of
them
can
get
close.
So
at
least
we
can
see
on
on
the
mailing
list
saying
look.
This
is
now
ready
to
be
closed.
Please
voice
your
opinion
and
I
don't
think
a
lot
of
them
will
take
a
lot
of
time.
A
A
This
is
very
quick.
I
don't
really
want
to
talk
much
about
this,
not
free
passed
away
in
may.
I
think
there
will
be
something
in
the
plenary
tomorrow
about
this.
A
lot
of
us
knew
ned,
and
I
think
his
council
would
have
been
very
helpful
in
in
this
room,
but.
A
All
right,
okay,
so
starting
with
the
foreclose
and
receive
header
fields,
I
looked
at
the
ticket,
I
nearly
closed
it.
I
I
sent
john,
you
know
quick
message
saying:
well,
I
think
we
need
to
do
this
tweak
and
then
he
said
no,
no.
You
know.
I
think
we
need
to
talk
about
this.
So
this
is
four
slides
from
john
and
john
you
you,
you
want
to
present
them
and
then
we'll
have
a
discussion.
A
The
only
thing
I
will
add
is
actually
I
will
for
this
discussion.
I
will
be
as
a
participant
not
as
a
chair,
because
I
might
have
a
stronger
opinion,
so
I
will
ask
thoughts
to
arbitrate
and
make
sure
that
judge
consensus
go
john.
B
Okay,
I
I,
I
posted
a
a
moderately
long
noted
list
earlier
in
the
week
and
a
an
internet
draft
which
discusses
this.
At
the
same
time,
I
I
hope
and
assume
that
everybody
has
read
both
of
them,
so
this
is
intended
more
as
a
quick
review
than
I
say,
complete
analysis.
B
The
question
when
we
start
messing
with
received
clauses
optional,
z
clause,
including
four
is
these
interests
has
been
seriously
underdefined
since
the
beginning
and
we've
been
picking
at
them
in
little
ways,
but
but
not
necessarily
getting
it
right
or
changing
them.
So
the
question
which
I
was
proud
to
ask
when
I
started
looking
at
this
in
the
current
text
of
5321
disc,
was
first
of
all
go
back
and
look
at
the
question.
What
the
four
clause
is
for,
and
50
and
821
doesn't
say
a
word
about
it.
B
It
provides
some
syntax
indicates
an
optional
field
and
the
syntax
points
to
a
path
which,
since
we
eliminated
pads,
is
now
basically
a
mailbox,
but
it
just
gives
the
mailbox
name
syntax
and
like
all
components
of
trace
fields-
and
I
hope
this
is
clear
enough
in
the
current
document.
But
if
it
is
that
we've
got
another
issue,
the
primary
intended
use
is
debugging.
The
assumption
was
never
that
users
were
going
to
look
at
these
fields
unless
they
had
questions
or
got
into
trouble.
B
So
the
value
associated
with
four
is
generally
assuming
a
mailbox
of
the
intended
recipient.
But
again
we
don't
really
say
that
very
quickly
and
if
we
did,
we
would
have
trouble
with
what
intended
recipient
means,
which
is
what
the
current
debate
is
all
about
in
a
way.
So
it's
never
been
clear.
B
What
to
do
with
multiple
receipt
commands
clause
is
only
going
to
be
used
once
per
received
field,
and
and,
as
we
have
more
recently
discussed,
it
could
easily
disclose
in
information
intended
to
be
private
and
we've
talked
about
pcp
bcc
mailboxes,
but
that's
not
actually.
The
only
choice
next
slide.
B
So
in
the
current
text,
we've
got
a
general
warning
about
accidental
information
disclosure,
especially
for
sites
and
special
circumstances,
we're
not
going
to
dividing
special
circumstances
and
we
advise
against
providing
for
when
there's
more
than
one
recipient
address,
I.e,
water,
speed
command
and
the
particular
statement.
There
is
badly
written
and
should
be
cleaned
up
to
be
retained
and
for
the
badly
written
part
you
can.
B
If
our
goal
is
prevent
disclosure
potentially
sensitive
information,
a
bunch
of
other
cases
having
to
do
with
the
fact
that
we
allow
our
mpas
to
transit
a
great
deal
of
flexibility
about
uncombining
and
recombining
messages,
as
we
suggest
them
on
combining
we're
very,
very
vague
about
when
that's
possible.
We
don't
force
it,
we
don't
prohibit
it
and
we
may
need
to
rethink
this
entirely
when
it
should
be
provided
and
at
what
stages,
rather
than
just
providing
a
quick
test.
Patch
next
slide.
B
So
obvious
solutions,
borrowing
these
things
in
the
order
which
they
appear
in
that
internet
draft
hard.
To
conclude
for
it's
just
too
dangerous,
we
need
to
get
rid
of
it.
B
Allow
it
only
a
message
submission
time,
because
the
submission
system,
including
both
any
submission
servers
in
the
mqa,
are
the
only
ones
who
really
know
what
the
intended
recipient
is.
What
should
be
kept
private
and
what
shouldn't
or
we
decide
we
don't
care
about
those
other.
These
other
cases
fix
the
bad
sentence
and
move
on
next
slide.
B
D
E
This
is
barry
lieber,
so
I
think
it's
not
sufficient
to
do
the
multi-recipients
thing,
because,
even
with
a
single
recipient
forwarding,
the
message
can
cause
all
sorts
of
exposure.
Okay,
todd:
can
you
back
up
or
whoever's
controlling
the
slides?
Can
you
back
up
a
slide.
E
Yeah,
so
I
I
primarily
support
1.1.
I
think
we
should
deprecate
it.
The
only
concern
I
have
is
whether
that
violates
our
minimal
changes
rule,
but
I
think
I
think
saying
that
you
should
not
include
it
in
new
messages,
but
it's
still
going
to
appear
in
in
older
implementations
might
be
sufficient,
but
we
should
at
least
do
one
of
those
varieties
of
one
either
1.1
or
1.2.
That's
my
opinion.
B
A
quick
comment,
the
the
minimum
changes
rule
is,
is
definitely
a
question,
but
the
the
answer
to
a
different
question
is
that
you're
explicitly
allowed
to
deprecate
things
which
had
which
experientially
haven't
worked
out
in
moving
to
both
standards.
So
it's
it's
our
rule.
It's
a
problem
and
it's
not
about
global
warming.
E
A
Okay,
so
I
do
have
a
descending
opinion
here
and
I
might
be
in
minority
we'll
see
we'll
see
about
that.
First,
I
did
quick
search
on
what
existing
mtas
do.
So
I
checked,
I
saw
their
own
implementation
and
I
checked
exam
both
on
emit
four.
If
there
is
a
single
recipient,
so
which
kind
of
confirms
my
theory
of
how
this
is
supposed
to
work.
You
know
whether
it
was
how
it
was
intended.
A
I
don't
know
because
I
wasn't
around
at
the
time,
but
this
is
my
perception
of
how
I
would
like
you
know.
I
think
it
should
work.
So
the
second
thing
is,
we
did
actually
have
a
request
at
work
where
sometimes
it's
useful
to
have
indicator
whether
you
to
occ
recipient
right,
so
email
client
shows
whether
you're
two
is
your
recipient
and
there
is
a
similar
request
for
knowing
whether
you
are
you're
receiving
it
as
a
2
occ
mailing
list.
A
In
this
case,
you
know
four
can
potentially,
if,
for
if
a
message
with
a
single
recipient
goes
to
a
mailing
list,
it
gets
expanded,
it
can
get
four
mailing
list
address
added
and
then
later
on,
you
can
figure
out
that
you
actually
got
this
because
of
the
mailing
list,
so
I
find
some
utility
in
this.
The
third
comment
is,
as
far
as
I'm
concerned:
mta's,
I've
seen
don't
make
the
mistake
of
leaking
information.
A
They
only
emit
four
if
there
is
a
single
recipient,
which
also
means,
if
I
mean
it's
up
to
ntas,
to
decide,
they
can
split
the
message
into
multiple
transactions,
at
which
point
they
are
separate
messages,
separate
transactions
with
a
single
recipient,
and
then
they
can
still
emit
it,
whether
they
do
or
don't.
I
don't
know.
B
Just
to
clarify
alexis
you've
made
a
very
strong
argument
for
inserting
the
four
at
the
descending
end
and
I
think
that's
fine,
but
it
brings
us
rapidly
direction
of
option.
Two
on
the
slide.
B
The
complicated
situations
all
arise
in
shuffling
and
reshuffling,
as
barry
pointed
out
forwarding
and
and,
as
you
pointed
out,
what
we
do
with
list
expansion
or
sending
to
a
list
that
gets
a
recipient
name
after
a
while,
and
the
only
option
I'm
opposed
to
here
is
weakening
the
rule.
The
mtas
are
are
expected
to
poke
around
in
previous
headers
in
order
to
be
able
to
do
next.
A
Can
I
just
play
it
so
yeah,
I
basically
kind
of
leaning
toward
more
of
two
or
three
options,
and
I
think
your
option
two
is
actually
not
sufficient.
I
think
mta
should
be
still
allowed
to
do
that.
Basically,.
C
C
I
should
note
that
we're
talking
about
a
trace
header
that
happens
on
entry
into
the
mail
system
so
at
each
hop
we're
recording
what
we
received
from
the
previous
smtp
talker,
and
if
that
smtp
talker
sent
us
one
recipient.
C
C
When
I
complain
about
spam,
I
often
want
to
know
which
of
my
thousands
of
email
addresses
I
received
the
spam,
for
the
spam
does
not
disclose
that
in
the
two
rcc
headers,
but
I
see
it
in
the
four
and
I
want
it
there
and
in
any
case,
whatever
the
draft
ultimately
says,
I
predict
that
postsix
will
make
no
changes
in
the
space
you
can
shout
up
and
down,
but
it
will
be
three
forever.
C
The
language
can
be
clarified
to
warn
some
hypothetical
mta
that
gets
this
wrong.
I
don't
know
of
eddie.
F
Hi
it's
pete
resnick.
I
am
strongly
strongly
encouraging
us
to
go
for
number
three.
I
think
deprecating.
It
is
a
mistake
for
many
of
the
reasons
that
that
victor
brought
up
with
a
single
address,
it's
quite
useful
information.
F
G
E
Barry
lee,
but
again
I
wanted
to
respond
to
mostly
alexei,
but
also
some
of
the
rest
that
there's
no
doubt
that
it's
that
it's
useful
for
some
people,
if
it's
there,
I
want
to
remind
people
that
it's
often
not
there,
you,
you
cannot
rely
on
it.
So,
given
what
other
people
have
said
about
three,
I'm
okay,
if
we
decide
in
three
that
that
in
53
21
bits,
we
go
with
three,
but
we
also
put
something
in
the
as
saying
that
we're
basically
basically
deprecating
it
or
advising
against
using
it.
E
H
I'm
going
to
say
that
as
someone
who
works,
reading
email
headers
a
lot,
it's
very
useful
to
me.
It
might
not
be
useful
to
you
barry,
but
for
a
lot
of
people.
It
really
is
useful
for
things
and
if
you're
scrubbing
mail
to
remove
things
being
forwarded
on,
you
have
to
scrub
lots
of
places
anyway,
it
can
also
be
a
received
four
header.
There's
lots
of
other
things.
H
F
I
Daniel
van
gilmer
I'll
be
quick,
also
speaking
in
favor
of
three.
I
believe
I
so.
I
think
that
there
are
multiple
people
in
this
room
who
have
strong
opinions
about
how
one
should
scrub
email,
and
I
think
that
was
worth
doing
as
a
separate
project
in
terms
of
removing
potentially
leaking
things,
and
that
would
be
worth
noting
that
here.
I
I
also
wanted
to
note
that
when
we
just
talk
about
deprecating
it,
I
don't
think
that's
actually
particularly
useful,
because
there's
deprecating
reliance
on
it
and
there's
deprecating
inclusion
of
it
and
those
are
two
distinct
things,
and
I
think
it's
a
mistake
to
just
randomly
say
we
deprecate
this
without
being
clear
which
side
we're
talking
about
deprecating.
I
think
the
simplest
thing
is
to
say
here:
are
the
risks
and
work
actively
on
a
scrubbing
draft
separately.
D
B
Move
on
it
raises
a
separate
question,
which
is
the
difference,
but,
as
you
tell
me,
you
go
off
and
fix
text,
which
is
the
difference
between
three
and
three
minus
minus.
Under
three.
We
tune
the
existing
language
a
little
bit
and
then
go
forward
under
three
minus
minus,
for
which
I
have
some
sympathy.
B
We
don't
address,
we
tear
the
bad
sentence
out
and
replace
it
with
nothing,
because
there's
already
language
in
the
document,
the
employers
see
the
see
that
id
that
talks
a
little
bit
about
this
and
language
about
whether
or
not
people
should
rely
on
it
and
whether
whether
they
should
and
whether
or
not
it
should
be
provided
with
their
edge
cases,
probably
belongs
to
the.
As
so.
The
three
minus
minus
option
is
even
to
tear
some
of
this.
B
Some
of
this
stuff,
which
we
put
in
back
out
and
I'm
actually
more
comfortable
with
that
option
than
I
am
with
with
with
three
by
itself
or
especially,
we
decided
not
to
do
the
others
and-
and
I
could
clarify
what
deprecated
number
one
means.
It's
probably
not
worth
the
effort.
A
Okay,
shall
we
take
it
to
the
main
list,
or
maybe
are
you
happy
with
trying
to
do
the
fix
on
the
next
slide?
I
propose
and
then
have
a
quick
discussion
about
whether
we
want
to
move
the
stacks
to
ass
or
where
they
should
stay.
B
I
I
think,
as
far
as
far
as
five
three
two
one
is
concerned,
I
and
several
people
spoke
and
very
included
are-
are-
are
closer
to
three
minus
minus
than
two
three
and
that
would
argue
against
choosing
either
of
the
options
on
that
spot.
F
This
is
pete,
I
I
think
it
would
be
a
mistake
to
completely
yank
the
sentence.
I
think
the
suggested
replacement
is
fine,
but
I,
I
think
making
believe
that
this
document
can
get
away
with
not
discussing
it.
At
all
is
probably
a
mistake.
We
should
try
just
fix
the
sentence,
I
think
that's
a
good
fix
and
move
on
and
better
notes
as
well.
So.
F
Yeah,
I
I
suppose
that's
true,
I
I
I
guess
I
don't
feel
exceedingly
strongly
about
it,
but
there
it
is
in
this
section,
it's
been
there.
I
I
I
would
my
inclination
is
to
fix
a
mistake
which
that
person,
you
know
the
the
existing
sentence.
Is
it's
just
a
mess
rather
than
just
ditch
it?
I
wouldn't
throw
myself
on
my
sword
to
keep
it,
but
I
I
think
the
fix
is
fine.
B
I'm
not
throwing
myself
on
any
swords
either,
but,
but
I
know
that
this
is
not
5221
text
that
we're
talking
about
bad
sentences
and
it's
actually
put
in
a
meteor
two
ago.
B
So
this
is
this
is
recent
text
and
it's
still
on
the
target
list.
I
don't
feel
nearly
strongly
about
this,
as
I
probably
sound,
but
I
think
we
need
to
make
a
a
careful
and
considered
decision
here
rather
than
saying,
rather
than
shutting
our
shoulders
and
moving
on
and-
and
I
think
the
text
which
isn't
documented,
most
of
which
is
from
five
three
three
two
one
is
very
much
part
of
this
picture.
B
B
A
B
D
Let's
just
do
revision
to
the
list
right
with
the
text.
That's
where
we
want
to
go.
I
I
don't.
I
don't
feel
like
we're
going
to
solve
this,
but
this
problem
in
the
35
minutes
we
have
remaining,
we've
got
other
tickets
to
get
to
so,
let's,
let's
get,
let's
move
the
discussion
on
to
the
list
and
keep
going
with
it.
I
think
some
flavor
of
option
three,
whether
it's
three
or
three
minus
minus,
is
where
we're
going
with
this.
We
have
some
proposed
text
on
the
slide
here
or
discussion
the
text
on
the
slide
here.
A
John,
I
I
I
think
there
will
be
a
slight
definition
of
compromise.
I
think
everybody
is
equally.
J
A
Hopefully
so
I
I
read
the
mailing
list
on
this
topic
and
I
thought
it
would
be
actually
more
controversial
than
I
thought
you
know.
I
expected
it
to
be
more
controversial,
but
it
looks
like
very
proposed
text.
A
A
A
My
proposal
is
to
kind
of
if
we
can
quickly
agree
that
we
cannot
live
with
this.
The
other
suggestion
is.
B
B
I
know
there's
no
general
problem
with
the
registrations
and,
as
I've
said
in
other
places,
I'm
I'm
very
very
concerned
about
those,
but
I'm
still
haunted
by
marshall's
argument
about
sparsity
and
am
wondering
whether
we
have
real
world
pieces
which
justify
worrying
about
this
or
whether
it
is
it's
just
a
theoretical
problem.
A
A
Even
though
the
person
went
into
more
details
saying
you
know
all
the
troubles
that
he
got
into
and
though
that
there
was
no
champion,
it
wasn't
the
same
issue,
so
I
think
with
the
one
or
more
experts
which
trying
to
be
helpful
and
friendly,
I
think
that's
not
going
to
be
a
problem.
At
least
that's
that's.
My
interpretation
of
of
the
proposal.
B
And
and
again
that's
the
comments
did
not
seem
to
be
about
a
real
world
problem,
which
was
a
problem.
It
seemed
much
more
about
a
more
theoretical
set
of
questions,
but
maybe
I
didn't
understand
it.
C
K
A
E
So
this
is
barry
the
the
reason
I
wanted
to
get
to
this
slide
before
I
said
anything
is
I
want
to
make
sure
that
we
agree
that
this
slide
has
the
right
the
right
guidance
for
the
designated
expert.
E
This
is
what
I
proposed
that
john
tweaked
and
dave
tweaked,
and
I
think
the
three
of
us
are
probably
good
with
this.
Is
everybody
else
good
with
this?
E
E
A
All
right
do
you
want
to,
or
they
want
me
to
talk
okay,
so
we
are
moving
on
to
the
applicability
statement
issues.
Some
of
these
there
is
too
much
text
to
really
show
in
the
room
or
to
live
edit.
I
think
this
particular
issue
is
we
had
two
rounds
of
discussions
chaired
by
todd.
Then
I
think
ken
incorporated
it
in
the
latest
revision-
and
this
is
just
a
reminder
for
people
to
have
a
look
at
this.
I
think
the
text
is
baked.
A
Okay,
this
one
is
actually
new.
I
don't
think
we
discussed
it.
A
A
I'm
so
sorry
this
is
your
ticket.
That's
why
I
can't
yeah.
There
was
basically
a
suggestion
saying
that
maybe
something
should
be
said
about
this
in
applicability
statement.
F
My
proposal
is
always
make
me,
write
less
text
and
move
it
to
the
applicability
statement.
No,
we
can
still
make
you
write.
F
I
I
think
you
know
we
may
want
to
give
examples
in
the
as
to
explain
that
there
are
going
to
be
times
with
headers
that
you're
not
going
to
have
a
nice
fold
point,
and
so
you
may
need
to
do
something.
Different
and
john
has
a
comment,
and
maybe
he
can
come
up
with
what
the
heck
we
were
talking
about.
B
My
only
question
here,
pete
before
you
sit
down,
is
the
use
of
the
word
always
in
that
first
clause,
because
that's
always
absent
sntp
extensions
and
various
other
kinds
of
weird
stuff.
B
Always
plus
or
minus
mine
stops
so
all
so
so
if
you're
gonna
do
so,
if
it
says
always,
you
may
need
to
think
a
little
bit
about
that
choice
of
words.
Right,
I
don't
think,
there's
a
problem
here,
that's
even
worth
messing
and
messing
with
in
the
as.
F
F
B
A
All
right,
three
of
you
will
discuss
some
texts
and
bring
it
to
the
mailing
list.
Thank
you.
A
Right
ticket
number
35,
erratum
3135
about
quarter
string
definition.
A
A
A
E
A
This
is
talking
about
forms,
not
accepting
book
standard
us
key
addresses,
which
would
be
otherwise
valid
right.
A
H
A
I
think
there
would
be
in
a
sense,
but
there
is
actually
you
really
have
to
be
a
bnf
expert
to
figure
it
out
from
the
base
pack.
This
is
a
common
enough
problem,
so
maybe
at
least
you
know,
if
it's
written
down,
then
you
can
point
people
to
say:
look.
It
says
there
that
you
should
do
it
cool,
that's
kind
of
the
point
of
it.
B
And
something
to
point
to
that
is
written
in
relatively
plain
english,
rather
than
a
bnf
or
or
whatever
language,
five,
three
two
one
or
five
three
people
were
written
in,
which
is
not
english.
Will
it
by
itself
anybody
if
they
know
but
have
your
clear
pointers,
useful-
and
I
say
this
as
somebody
who
has
this
problem
a
couple
times
a
week
and
and
needs
to
need
something
to
avoid
it
too,
and
that's
more
or
less.
A
K
Hi
this
is
hansard
hubble.
I
think
this
is
a
very
useful
thing,
so
I
mean
I
see
bronze
concerns
that
obviously
that
might
not
change
things
immediately
somehow,
but
I
think
this
is
really
something
in
my
personal
experience,
even
even
I
experience
on
a
weekly
basis,
that's
our
ill-defined
validation,
algorithms,
and
also
when
we
do
migration
projects.
We
see
many
different
systems
to
accept
many
different
standards,
and
many
of
that
is
basically,
I
think,
done
in
libraries.
K
So
actually,
if
we
can
point
library
developers
to
this,
that
might
be
great
and
that
might
even
have
an
impact
in
the
long
term,
I'm
not
sure
about
the
abn
f
if
it's
easily
so
easy.
What
I
think
would
be
really
helpful,
in
addition,
is
maybe
to
have
a
repository,
a
list
of
example,
data
which
is
which
can
be
tested
for
those
library
developments
or
something.
Okay,.
A
Okay,
can
so
we
can
probably
collaborate
and
we
can
find
other
people
to
help
you
with
this.
G
John,
if
I
may
throw
a
spanner
in
the
works,
the
html
living
standard
has
an
email
address,
validation
pattern
which
vast
numbers
of
libraries
and
web
applications
actually
use
and
if
we
can't
persuade
them
to
make
their
pattern
match
our
pattern,
we
are
completely
wasting
our
time
and
their
pattern
specifically
says.
We
know
this
is
only
a
subset
of
what
this
of
what
the
mail
spec
says,
but
we
think
it
matches
what
male
actual
male
systems
accept,
and
it's
not
terrible,
but
my
guess
is
we're
not
thrilled
about
it.
K
D
G
G
And
also,
I
don't
think,
they're
hostile
to
having
stuff
they're
hostile
to
updating
it.
I
think
they
just
there
have
been
a
lot
of
pranks
and
particularly
back
when
there
was
a
fork
between
the
w3c
and
what
wig
w3c
said.
Oh
we're
going
to
make
it
we're
going
to
we're
going
to
do
eai,
so
all
unicode
characters
are
valid,
which
of
course,
is
stupid,
right,
right,
yeah
and
yeah
apropos
unicode.
G
I
don't
want
to
go
there
simply
because
having
done
if
there
are
a
number
of
experiments
with
with
eai
mail
systems,
I
see
no
pattern
whatsoever
in
what
character
sets
ea
addresses
actually
allow.
So
I
wouldn't
know
what
to
say:
okay,.
A
J
A
G
A
A
Yes,
yes,
I
mean
we
shouldn't
rule
out
ability
to
actually
do
do
changes
if
they
are
well
argued
from
output.
All
right,
john.
B
I
think
we
need
to
understand
really
what
you're
designing
to
say
that
there
is
an
active
pew
going
on
between
w3c
and
wg
over
some
of
these
issues,
and
the
last
thing
we
want
to
do
is
to
point
to
one
of
the
other
of
their
documents,
one
of
the
other
of
their
incomprehensible
documents
and
say
pay
attention
to
that
incomprehensible
document,
rather
than
the
other
incomprehensible
document
or
our
incomprehensible
document.
Clear
english
language
would
be
a
good
idea.
C
A
I
think
if
people
want
to
do
regular
expression,
it's
kind
of
a
separate
topic
in
a
sense
of,
and
there
was
actually
a
sample
proposal,
a
draft
at
the
time.
I
would
like
this
written
in
plain
english
first,
okay
and
then
we
can
figure
out
whether
we
want
to
include
regular
expression,
and
we
can
do
a
call
on
the
main
list.
Okay,
all
right!
Thank
you
for
volunteering
dkg
very
quickly,.
I
Yeah,
I
definitely
think
that
we
should
exert
what
influence
we
have
on
the
other
standards
bodies
to
produce
something
that
is
regularly
usable,
and
that
does
mean
some
amount
of
functional
material,
which
is
like
a
regular
expression.
I'm
fine
if
that
goes
alongside
english
text,
but
the
I
think
the
the
test
suite
that
you're
describing
is
really
the
key
thing
to
say:
here's
a
bunch
of
things.
This
one
is
valid.
Here's
why
it's
valid!
Here's,
why
it's
not
right,
but
we
that
that
set
of
three
things
is
really
what
you
want.
B
A
A
E
E
We
will
consider
adding
mime
as
our
next
pass
and
at
that
point
we
will
probably
revise
the
applicability
statement
for
that.
But
right
now
all
we
should
say
is
that
mime
is
a
widely
implemented
and
very
important
extension
to
the
internet.
Message
format
go
there
and
look
at
it,
and
we
will
talk
more
about
this
later
and
that's
probably
all
we
should
say.
F
J
A
E
A
A
Pretty
much
you
know:
okay,
okay,
that
was
actually
quicker
than
I
expected,
sounds
good,
I'm
going
to
so
there
are
three
more
slides
on
issues
which
I
built,
I
think
should
be
closed
again,
subject
to
mailing
list,
verification,
etc,
etc.
B
A
Sounds
good
and
the
last
one
do
you
want
to
just
quickly.
D
I
know
that
the
proposal
was
to
close
this
ticket
because
that's
what
it
said
in
the
ticket
documentation
itself.
So
let
me
just
find
out
real
quick,
oh
yeah.
This
was
about
there's.
There
are
timeout
specifications
that
are
in
5321
and
probably
previous
issue
or
previous
versions,
and
there
had
been
some
discussion
about
whether
or
not
to
revisit
them,
because
they
seem
really
freaking
long
for
modern
networks
versus
when
8
21
was
first
written.
D
As
we've
discussed
it
over
the
months,
there's
been
a
whole
lot
of
might
as
well
leave
them.
There's
been
no.
D
B
We
john,
if
people
wanted
to,
I
I'm
not
necessarily
in
favor
of
it,
put
a
little
bit
of
text
in
the
ais
which
points
out
that
under
many
circumstances,
those
timeouts
in
the
modern
world.
Those
timeouts
may
be
a
little
bit
long.
But
I
don't
know
at
the
moment
how
to
write
that
text
and
and
would
prefer
we
didn't,
but
but
we
should
be
sure
we
don't
eliminate
that
possibility
without
thinking
about
it.
If
we
thought
about
it,
we
should
move
on.
A
B
Let's
talk
about
that
briefly,
very
briefly,
because
I
think
that
it's,
I
think,
we're
having
an
argument
that
borders-
let's
go
say
words
like
silly,
but
sorry,
it's
it
it's
it's
clear
to
at
least
many
of
us
that
that
we
cannot
promote
that
to
a
bus,
not
for
operational
reasons.
I
don't
understand
the
correspondence
of
the
list,
because
I
think
that
the
person
who
is
advocating
changing
into
a
must
turn
around
and
explain
why
it
should
be
assured.
So
I'm
confused.
B
E
A
A
A
Let's
do
this
first,
okay,
we
do
have
five
minutes.
A
Right
so
we
have
some
way
forward
towards
seeking
55
the
foreclose
received.
We,
I
think,
pretty
much
closed
iron
registration
policy.
There
are
two
tickets,
61
and
12
about
mailing
lists
and
improved
definition
of
mailing
lists.
So
a
few
months
ago,
ned
proposed
to
write
a
document.
This
is
not
going
to
happen
now.
I
tend
to
think
that
we
probably
don't
have
energy
for
this,
so
I
suggest
we
just
do
nothing.
A
Should
people
in
slow
time
write
a
document
on
the
topic?
We
can
revise
it
some
future
day
date
and
the
only
other
ticket
is
nullimax,
and
I
think
discussion
was
that
the
current
text
is.
B
A
A
A
Kind
of
a
ticket-
basically,
why
is
this
so
email
address-
is
so
complicated
and
it's
like.
A
A
All
right
so
and
if
we
look
at
list
of
issues
for.
A
A
We'll
have
some
text
about
the
first
one,
we're
about
to
close
the
second
number
54..
We
talked
about
51..
I
think
we're
about
to
close
number
40
recommended
smtp
extensions,
but
I'll
bring
it
to
the
main
list.
A
close
number
one
right
number.
Eight.
This
is
actually
kind
of
important.
Yes,
this
started
about
a
year
ago,
and
there
was
a
long
discussion
about
an
extra
registry
going
through
the
main
english
discussion.
I
realized
there
was
no
consensus,
so
I
I
suggest
we
just
drop
it
and
ned
was
a
big
motivator
and
part
of
the
discussion,
and
I
think
he
sort
of
initiated
it,
but
at
the
end
he
he
didn't
like
doing
it
either.
So
I
think
closing
it
with
do.
Nothing
is
probably
the
best
way
so.
A
Hopefully,
the
plan
is
john
will
update
the
document
which
will
go
to
last
call
knowing
that
next
month
is
august,
it's
probably
going
to
be
september
just
to
make
sure
that
people
are
paying
attention,
and
then
we
do
have
some
work
to
do
on
ais.
But
I
think
we
will
very
closely
very
soon
will
have
a
call
on
opening
new
issues.
So
I
think
it's
actually
getting
pretty
big
now.
A
So
if
people
think
that
there
is
a
major
thing
which
is
unclear
or
missing
now
it's
a
good
time
to
actually
bring
it
up.
Look
at
the
mic,
but
you
know
on
the
menu
list.
E
A
I
think
it
sort
of
depends.
You
know
if,
if
we
feel
that
ais
is
so
nearly
done,
you
know
like
can
be
done
within
a
month
after
that,
then
we
can.
I
just
said.
E
E
A
B
I
bought
the
deck
too
for
the
same
reasons,
but
but
if
we're
gonna
send
the
5321
best
53
22
risk
to
the
to
the
iasg
without
waiting
for
the
gas,
we
better
be
very,
very
careful
with
the
ais,
it
doesn't
say
anything
which
seems
to
contradict
the
two-way
documents,
and
the
good
news
is
that
if
we
get
53
21
finished
next
month
or
in
september,
I
will
be
able
to
pay
more
attention
to
the
ass.
F
L
L
K
A
Thank
you
all.
This
was
quite
a
productive
meeting
and
see
you
next
time.
Maybe
we
even
return
the
next
time.
You
never
know.