►
From YouTube: IETF108-LAMPS-20200728-1100
Description
LAMPS meeting session at IETF108
2020/07/28 1100
https://datatracker.ietf.org/meeting/108/proceedings/
B
B
A
A
I
only
got
what
came
last
night.
Oh.
D
C
D
Hello,
hello,
russ.
This
is
stephan,
for
whatever
reason
I
I
don't
see
your
screen,
it's
indicated
as
russ
housely
screen,
but.
A
C
A
A
We're
already
lost
a
couple
of
minutes
here,
so
this
is
the
lamps
working
group.
If
that's
not
where
you
thought
you
were
gonna,
be
you're
in
the
wrong
place.
We're
gonna.
A
Remind
her
that
this
is
an
itf
meeting,
so
the
note
well
applies
if
this
is
a
new
meeting
for
you.
Please
familiarize
yourself
with
all
of
this
and
please
don't
speak
at
the
microphone
until
you
know
about
the
your
obligations
under
the
note.
Well-
and
this
is
the
agenda-
it's
a
slightly
revised
one,
because
the
slides
I
got
for
header
protection
were
so
long.
I
swapped
it
to
the
end
so
that
I
didn't
need
to
cut
off
that
presentation
and
then
move
to
the
other
one
and
then
find
out.
A
So
the
first
thing
we
need
to
do
is
we
have
a
note
taker,
that's
going
to
happen
in
the
the
notepad,
the
code
emd
notepad,
and
I
was
going
to
ask
my
co-chair
to
watch
the
jabber,
but
he
hasn't
shown
up
here.
So
can
I
get
someone
to
do
that
for
me
because
the
way
the
screen
is,
I
can
do
the
slides
and
the
participants,
but
I
cannot
do
all
three.
A
Can
I
get
somebody
to
to
call
out
if
there's
something
going
on
in
jabra
that
needs
everyone's?
This
is
this
is
dkg.
I
can
do
that.
Thank
you
very
much.
A
All
right,
so
the
is
there
any
agenda
bash
to
other
than
the
one.
I
just
described
that
I
did
last.
F
Night,
okay,
so
quick
question:
how
much
time
do
you
want
for?
Oh
we're
at
the
end,
that's
fine,
never
mind.
A
I
just
said
that
alexi
I
put
the
long
one
at
the
end,
okay,
so
the
the
first
four
documents
are
with
the
rfc
editor
or
the
isg
I'm
going
to
give
the
chairs
a
second
to
just
I'm
sorry,
the
authors
of
each
of
the
documents,
a
second
to
say.
What's
going
on
with
that
document,
if
they're
here
sean,
are
you
here,
okay,
so
shawn's
key
update?
Our
key
usage
document
is
in
the
rc
editor
queue.
A
I
it's
a
pretty
short
document
so,
but
they
are
in
the
middle
of
processing
cluster
238.
So
I
suspect
it's
waiting
on
that.
Okay,
are
you
here.
A
Okay
on
the
lamps
ocsp
nonce
document,.
A
A
Okay,
that
one
is
in
itf
last
call
right
now.
I
believe
roman.
A
A
A
H
All
right
russ:
can
you
share
the
slides
or
should
I
do.
A
A
B
A
H
Next
slide,
please
so
the
update
of
the
cmp
updates
draft
for
since
the
last
ietf
I
did
update
some
of
the
topics
we
discussed
last
time,
so
I
kept
the
oids
for
the
cmc
ca
and
array.
As
discussed
last
time,
I
changed
the
key
management
technique
from
symmetric
key
encryption
to
password-based
key
management
technique
for
the
central
key
generation
as
discussed,
and
I
defined
the
local
key
id
to
carry
an
identifier
for
the
relocation
passphrase
in
envelope
data,
as
discussed
and
also
on
the
mailing
list.
H
H
H
H
H
So
then
I
I
would
say
this
is
near
to
be
complete
from
from
the
text
at
least
complete
and
yeah
how
how
to
proceed,
rus
or
others.
What
is
the
opinion
of
the
group
when
shall
we
go
to
working
group
review.
A
So
I
think,
once
we
have
the
asn.1
module
and
at
least
a
couple
of
us
have
compiled
it
so
we're
sure
it's
right,
it'll
be
ready
for
working
group.
Last
call.
H
A
I
Hi,
henrik,
as
we
discussed
about
the
encrypted
key
value,
actually
the
content
in
the
encrypted
key,
you
think
that's
appropriate
for
the
cnp
updates
or.
H
H
Right
so
you're
right,
so
I
there
was
a
discussion
between
thomas
and
me
on
how
to
to
code
the
private
key
for
the
central
key
generation
as
part.
So
as
content
of
the
signed
data
right
now,
it's
specified
as
id
data.
So
just
simple,
octet
string
but
thomas
said
it
would
be
good
to
have
some
structure
there
to
be
more
precise
and
for
the.
A
So
that
is
exactly
what
I
was
going
to
suggest
and
if
you
want
in
updates
to
just
put
a
parenthetical
at
this
point,
it
says
you
know
such
as.
A
Paragraph,
I
think
I
think
that
asymmetric
key
package
is
the
right
answer.
A
Okay,
I
said
I
don't
see
anybody
getting
in
the
line
to
speak,
so
I
think
we'll
move
to
the
next
document
right.
A
K
D
It,
maybe
I
can
jump
in
here,
please
so
I'm
not
quite
sure
what
happened
to
henrik.
He
probably
dropped
out
of
the
meeting
somehow,
so
we
did
some
further
issues
that
were
based.
This
is
stephen
friese.
We
we
addressed
some
further
issues
that
were
edward
is
back.
I
think.
H
Yeah
I
had
to
rejoin
so
thank
you
yeah.
I
just
started
hendrix,
so
I
give
it
back
to
you
thanks
thanks,
stefan
yeah,
so
on
on
the
updates
performed
since
last
meeting
on
the
lightweight
cmp
profile
we
did.
I
I
did
mainly
address
all
of
the
to
do's
I
collected
during
last
session,
so
we
set
the
delayed
enrollment
to
optional.
We,
I
added
the
section
or
completed
the
section
on
the
certificate
request
from
a
trusted.
A
A
E
E
A
E
The
middle
yeah
russ
do
you
have
a
way
that
you
can
reset
his
audio
stream
as
chair,
I
can
only.
D
Okay,
so
where
were
we,
we
completed
the
section
with
request
a
certificate
from
a
trusted
pki
with
signature
protection.
That
was
an
open
issue
from
last
time
because
it
hasn't
been
described
so
roughly
so,
roughly
then,
in
the
appendix
b,
there
is
a
third
template
which
has
been
added
as
an
example
that
was
also
a
change.
Then
we
changed
from
the
symmetric
key
encryption
to
password
password
based
key
management
technique
for
central
key
generation.
That
was
what
henrik
just
mentioned.
D
Also
for
the
for
the
update
there
is
a
new
oid
defined
id.
It
root,
ca,
key
update.
That
was
also
based
on
the
discussion
that
we
had
on
the
mailing
list
and
we
deleted
the
sections
regarding
get
certificate
management,
configuration
and
get
enrollment
voucher
to
not
overload
the
pro
the
lightweight
profile
here.
D
So
there
are
further
to-do's
that
have
been
addressed
in
the
meantime,
so
there
was
a
to-do
related
to
the
rsa
key
length
which
was
discussed
on
the
mailing
list.
I
have
to
admit,
I
don't
recall
exactly
what
the
what
the
issue
was
here,
but
it
has
been
addressed.
So
maybe
we
can.
We
can
get
back
to
henrik
when
he
rejoins.
H
H
We
did
some
update
on
the
offline
or
form
of
file
based
transport
section,
and
we
did.
H
Oh
okay,
sorry,
okay!
I
don't
know
how
far
you
could
hear.
A
H
H
We,
I
did
refer
to
mohit's
draft
on
cmp
over
co-op
transport
in
the
the
co-op
section,
so
thanks
to
moy
to
pick
this
up
and
and
provide
a
first
good
draft.
So
I'm
curious
to
to
hear
the
discussion
in
the
ace
working
group
on
that
I
did
complete
the
adding
additional
protection
section.
So
this
is
to
place
a
cmp
message
in
a
nested
message
structure
and
therefore
being
able
to
add
an
additional
protection
from
an
array
to
to
the
existing
message.
H
We
we
did
do
some
work
on
the
http
transport
section
and
especially
we
we
added
a
section
on
http
http,
uri
discovery
and
also
extended
little
bit
endpoints
in
the
http
transport
section
itself.
So
now
the
these
two
sections
are
quite
in
line
with
stefan's
brisky,
ae
document
and
yeah.
So
this
should
fit
nicely.
H
I
think
that's
that's
it.
So
further
minor
issues
can
be
found
in
the
in
the
change
history,
then
okay.
So
the
next
topics
on
the
to-do
list
is
this
discussion.
We
had
with
the
update
cmp
right
before
on
the
sign
data
structure,
to
specify
this
content
of
the
signed
data
as
a
metric
key
package
content
type.
H
H
H
First,
the
cmp
updates
should
be
complete
and
then
the
lightweight
profile
should
be
next,
so
I
I'm
quite
confident
that,
as
soon
as
a
cmp
updates
document
can
be,
yeah
can
start
the
working
group
review.
This
document
should
also
be
quite
complete.
I
H
H
H
H
So
yeah,
as
I
already
said,
I
I
think
with
this
update
from
my
site.
It's
it's
quite
complete
both
documents,
then
so
I'm
happy
for
any
review
comments,
any
suggestions
or
improvements,
of
course,
so
I'm
need
to
work
on
the
sn1
modules
and
I'm
happy
to
have
some
assistance
because
I'm
yeah
not
maybe
not
that
expert
in
in
these
modules
yeah.
I
will
do
the
iana
considerations
and
then
would
be
happy
to
have
a
working
group
review
then
not
last
call.
So
that's
maybe
too
quick.
A
I
Yeah
sure
so,
when
look
going
through
the
document,
there
was
a
couple
of
things
that
at
least
caught
my
eye
and
one
was
that
it's
mentioned
explicitly
like
the
chartreum
56
in
section
3.1
and
a
couple
of
other
sections,
and
maybe
in
the
name
of
crypto
agility,
specific
algorithms.
Should
I
don't
know
how
what's
the
best
way
or
customary,
let's
have
them
separate
or
how
it's
handled.
I
H
Right
so
I
could
imagine
to
put
such
important
algorithm,
so
I
try
to
have
to
keep
the
document
not
to
focus
on
specific
algorithms
defined,
as
I
think
this
is
more
up
to
the
areas
of
application
to
specify
which
or
to
define
which
algorithms
to
use
but
thomas
you're
right
here
and
there
are
algorithms
like
sha256
that
are
specifically
mentioned,
but
we
could
do
that
into
a
small
appendix
and
refer
to
that.
So
it's
easier
to
update.
A
So
if
you
believe
that
this
is
going
to
be
used
for
you
know
decades,
then
you
may
want
to
put
them
in
a
separate
document,
which
is
what
we
did
with
cms
and
the
p
kick
certificate
profile.
The
reason
for
that
is,
the
protocol
stays
the
same,
and
only
the
algorithm
document
gets
updated.
A
If
you
think
that
this
has
got
a
shorter
shelf
life
than
that,
then
the
appendix
works.
Fine,
that's
just
a
the
ability
to
update
the
algorithms
document
without
opening
the
lid
on
the
protocol
document
is
a
nice
feature.
H
A
I
H
I
H
A
So
submit
it
straight
as
draft
ietf,
lamps,
okay,
update,
alg
or
or
whatever
of
which
way
approach
you're
gonna
take
take.
A
All
right
is
there
any
other
questions
for
hendrick.
I
H
Than
why
his
go
ahead,.
I
Just
a
tiny
one
that
was
section
6.1,
which
I
think
rfc
672
about
the
http
endpoints.
It's
referenced
in
the
document
that
this
one,
I
would
say,
extends
rfc
6712
with
a
new
url
endpoints.
I
H
I
H
I
A
I
C
A
C
Well,
that
is
your
time.
Well
exactly
on
the
data
track,
there's
a
different
version
but
yeah.
Well,
then,
if
this
is
too
difficult,
we
just
go
with
this
one.
It's
only
a
couple
of
typos
in
here,
for
example,
the
slide
title
that
is
wrong,
but
anyway,
let's
start,
then
my
name
is
bernie
sand
and
a
will
jump
into
this
presentation
whenever
there
is
something
specific
and
he
will
enhance
what
I
say
next
slide.
C
We
are
discussing
about
non
like
non-mine,
conformant
user
agents
next
slide,
so
that
leads
in
the
backwards
compatibility
use
cases,
those
who
are
mime
conformant.
We
assume
those
just
work,
as
I
said
before,
and
then
we
have
like
a
non-mime
conformant
use,
user
agents
and
those
who
are
causing
serious
rendering
issues
with
robbed
but
also
forward
messages.
Next
slide.
C
Slide
so
this
is
one
of
the
things
we
are
just
discussing
after
the
in
the
next
slide.
It's
about
the
protection
levels
we
defined
like
we
have
signature
and
encryption
so
means
first
sign
then
encrypted
that
must
be
implemented
on
both
sides
and
on
the
sending
side.
This
should
be
the
default,
so
we
should
always
sign
and
encrypt
for
maximal
privacy
and
security.
C
We
also
have
the
use
case,
signature
only
which
should
be
implemented
on
the
sending
site,
and
it
must
be
implemented
on
the
receiving
side.
We
also
discuss
the
encryption
only
use
case.
We
state
that
it's
not
recommended
on
the
sending
site
and
it
may
be
implemented
on
the
receiving
side
next
slide.
Please.
C
So,
as
I
said,
specifications
targeted
on
signature
and
encryption
or
signature
only,
but
what
do
we
do
about
auto
variations
or
corner
cases
that
may
pop
up
at
the
receiving
side?
So
we
have
encryption
only.
We
have
encryption
before
signature,
we
have
signature
and
encryption,
but
the
signature
fails
to
validate
or
the
signature
validates
the
signing
certificate
has
been
remote.
C
F
Can
I
jump
in
quickly,
I
think
in
general,
it's
important.
There
are
several
error.
Handling
cases
like
signature
failed
to
validate
is
revoked.
It
needs
to
be
handled
in
the
code,
whether
it
is
wrapped
in
encryption
outside
of
it
or
not.
F
So
I
think
the
document
should
probably
talk
about
it,
but
we
can
take
them
one
at
a
time
in
their
cases
like
multiple
level
signatures.
That
might
be
interesting.
From
your
point
of
view,
what
recommendations
might
be.
E
Dkg
hi,
this
is
daniel
kahn,
gilmore,
aclu
yeah.
So
I
raised
these
issues
when
I
reviewed
this
draft
because
I
think
that
the
framing
of
protection
levels
here
it
could
use
a
clearer
description
of
what
we're
talking
about
my
experience
with
working
on
this,
and
you
can
see
this
reflected
in
the
auto
protected
headers
draft
that
I've
written.
E
Is
that
this
information
is
the
clearest
by
making
a
very
opinionated
choice
about
what
sorts
of
things
are
reasonable
and
then
about
and
saying,
like
the
things
that
do
not
fall
in
this
category,
we're
just
gonna
put
them
explicitly
out
of
bounds.
E
E
You
can
have
a
signature
wrapped
around
encryption,
wrapped
around
a
signature.
You
can
have
a
signature,
wraparound
encryption,
wrapped
around
encryption,
wrapped
around
a
signature
wrapped
around
encryption
around
a
signature,
and
you
know
when
you're
receiving
these
messages.
Someone
is
going
like
this.
You
get
these
messages,
they're
arbitrarily
bad
right.
A
So
I
think
there
should
be
three
that
we
need
to
support
and
I'd
like
to
hear
your
response
to
that,
because
way
back
rfc
2634
specifies
a
way
to
support
mail
lists
that
does
sign
encrypt
sign
where
the
third,
the
outermost
signature,
is
protecting
the
mail
list,
expansion
information.
F
I
tend
to
agree
actually
we
implemented
triple
wrap.
This
is
what
you're
talking
about
right.
So
I
would
like
this
to
be
covered,
but
I
agree
that
we
should
clearly
specify
normal
cases
and
then
yeah
signature
signed
and
encrypted
and
triple
wrap
and
declare
everything
else
out
of
scopes,
or
you
know,
maybe
have
some
guidance.
I.
A
E
Are
going
to
be
interlarted
with
messages
that
don't
have
any
cryptographic
protections
right,
fair
enough,
jonathan
hamill
says
plus
one
for
triple
rap
as
well.
I
am
not
entirely
convinced
by
triple
rap
if
you're
saying
that
that
a
triple
wrapped
message
should
contain
elements
that
the
receiving
person
should
see.
E
Then
I've
never
actually
seen
that
in
the
wild.
Now
you
and
I
have
different
email
practices
and
work
with
different
email
contexts.
So
my
experience
is
not
yours.
I
recognize
that
might
happen,
but
I
I
actually
have
never
seen
a
male
user
agent.
Do
anything
smart
with
a
triple
wrap
message
to
be
able
to
indicate
which
things
were
added
by
the
mailing
list
and
which
things
were
not.
E
So
jim,
I
don't
know
if
you
can
hear
me
for
this
use
case.
I
think
dkim
is
the
answer
at
this
point
and
I
don't
think
that
it's
worthwhile
for
us
to
try
to
shoehorn
that
into
this
particular
draft.
This
draft
is
about
end-to-end,
encrypted
message,
protection
and
I
think
putting
gateways
into
this
draft
is
going
to
make
it
unnecessarily
complex.
E
Right
and
I
think
that
if
we
make
this
draft
try
to
try
to
like
mine,
mime
structures
can
be
arbitrarily
complicated.
This
draft
is
already
struggling
with
how
to
deal
with
the
simple
mime
structure
cases.
E
I
think
if
we
turn
this
draft
into
here's,
how
to
actually
fix
your
triple
reading
triple
wrapping
ux
on
the
receiving
side,
which
I
think
I'm
hearing
that
no
one
has
functional
triple
wrapping
ux
from
the
receiving
side.
Then
I
think
I
think
this
becomes
an.
A
Entirely
different
draft
okay.
So
what
what
I
think
I've
been
convinced
is:
let's
do
signature
and
encryption
signature
only
and
signature
plus
encryption
see
where
that
takes
us
and
then
look
at
whether
the
third
case
could
be
added
right.
I
think
rationally,
but
since
these
are
the
two
by
far
more
common,
let's,
let's
proceed
on
them.
Elliot
wants
to
join
the
queue.
F
Russ,
can
I
do
a
quick
comment
on
this.
You
may
I'm
sorry,
which
I
think
I'm
happy
to
defer
triple
reptil
later
and
maybe
a
separate
document.
What
I
wouldn't
want
to
say
in
this
document
that
nothing
other
than
sign
and
sign
and
encrypted
is
valid.
E
I
was
just
gonna
say
that
signed
and
signed
and
encrypted,
isn't
that
I
mean
that
all
of
these
things
that
all
of
the
the
variations
in
corner
cases
that
bernie
lists
here
these
are
things
that
come
up
every
day
for
me
encrypted
only
messages
not
encryption
before
signature,
but
signed
and
encrypted,
but
the
signature
fails
to
validate
or
or
the
signature
validates,
but
the
scientific
is
revoked
like
these
are
things
that
happen
all
the
time
which
are
effectively
encryption,
only
messages,
and
I
do
think
that
male
user
agents
need
to
deal
with
them
just
because
signatures
will
fail
one
way
or
the
other.
A
Yeah
I
agree:
elliott
elliott
hold
on
a
second
elliot,
I'm
very
confused
about
your
request,
you're
requesting
to
share
your
screen.
J
I'm
sorry
about
that
all
right,
a
very
quick
point
of
just
a
a
point
of
clarification.
So
the
intent
here
and
forgive
me
for
johnny,
hey
everybody!
The
intent
here,
if
I
understand,
is
to
provide
a
constrained.
E
J
For
mine
in
this
reminds
for
for
doing
this
with
mine,
not
to
cover
the
the
vast
greatness
of
moneyness,
that
that
ekg
is,
it
would
otherwise,
like
probably
have
to
have
a
heart
attack
over
or
something
is
that.
Is
that
correct?
J
E
I
think
that
there
I
think
this
this
draft
ideally
needs
to
talk
about
two
things.
One
is
if
you're
trying
to
generate
a
message
that
has
end-to-end
header
protection
cryptographic,
header
protection.
What
should
you
do?
That's
one
thing,
and
that
is
an
entirely
separate
question
from
if
you
are
receiving
a
message
that
may
that
has
end
to
end
cryptographic
protection.
How
should
you
evaluate
the
the
protected
headers.
C
Well,
for
me,
it's
still
open.
We
have
the
encryption
only,
which
is
somewhat
mentioned
in
a
document.
Is
this
on
the
same
level,
what
to
do
with
sign
encryption
sign
or
how
is
this
now
going
on?
No.
C
C
One
proposal
is
that,
what's
documented
nowadays
rfc
eight
five,
five
one,
it's
smart4.0
and
there's
another
proposal
that
is
coming
from
autocrypt
so
from
daniel
and
fox
that
is
called
protect
the
titles
and
it's
a
successor
of
the
former
memory
hall
approach.
I
will
shortly
show
this
in
a
separate,
slides
like
this
formatting
issues.
C
What
is
in
common
of
both
proposal
is
that
we
have
a
auto
and
the
inner
message
which
I'm
showing
you
on
the
next
slide,
and
what
is
important
to
mention
here
is
that
the
original
message
itself
it
can
contain
any
mind
structure.
There
can
be
anything
in
it
which
we
need
to
deal
with
next
slide.
Please.
C
So
a
picture
says
more
than
thousand
words.
We
see,
on
the
left
hand,
side
a
message
that
has
a
header,
the
orange
section
and
the
content,
the
green
section
and
the
header
cannot
be
protected.
So
the
subject
and
other
information
is
cannot
be
kept
private
as
the
requirements
for
privacy
would
request.
C
C
C
So
on
the
wire
I
use
the
same
color
so
the
wires.
It
could
look
like
this.
We
have
like
the
auto
message,
the
red
section
and
then
in
between
the
dark
green
section
in
the
dark
green
section,
we
have
a
robot.
This
only
is
needed
for
the
proposal,
one
like
the
one
that
is
following
the
current
s
mime
specification.
The
autocrypt
proposal
that
doesn't
need
doesn't
use
this
wrought
bond.
C
The
wrapper
says
the
content
type
is
a
message
rfc822,
and
it
indicates
that
it
is
not
forward
message
after
that
there
comes
the
inner
message
in
orange,
the
headers
and
in
light
green,
the
content,
and
then
there
may
be
some
signature
and
other
stuff
coming,
but
in
basic.
This
is
how
it's
looking
on
the
wire
next
slide.
C
So
I
tried
to
make
a
comparison
between
the
pool
proposals.
This
is
not
exhaustive.
There
are
other
things,
but
they
are
not
so
well
elaborated
that
we
can
present
them
here.
So
we
reduce
it.
To
these
five
points,
switch
is
the
mine
conformance
the
s
mine
4.0
proposal
is
mine,
conformant
according
to
nowadays
rsc8551
and
with
protected
titles.
So,
like
the
autocrit
proposal,
it
is
unclear,
at
least
to
me.
It
is
unclear
whether
it
is
really
conformant,
because
I
found
some
stuff
in
the
mime
specification
which
is
present
on
the
next
slide.
C
A
On
a
second,
we
we
have
comment.
E
Plano
hi
there,
daniel
gilmore
again,
so
I'm
confused
by
these
slides
by
this
slide.
In
particular,
it
says
here
that
there
may
be,
I
think
it
means
rendering
issues
with
non-non-conformant
legacy
user
agents.
I
am
not
convinced
by
that
for
the
for
the
s
mine
4.0.
I
believe
that
it
is
possible
to
be
mind
conformant,
to
show
the
embedded
message
as
a
forwarded
message
as
an
embedded
message
basically,
and
that
is
a
weird
rendering
issue,
so
it
is
a
rendering
issue
with
a
mime
conformant
legacy:
male
user
agent.
C
C
That
sorry
you
jumped
in
too
early,
I
wasn't
able
to
actually
finish
what
I
wanted
to
say
and
just
two
things
with
mind:
conformance
and
the
next.
I
will
explain
what
I
mean
here.
C
E
I'm
talking
specifically
about
your
claim
about
mime
conformance
for
the
for
the
s
mime,
4.0,
wrapped
message:
I'm
not
talking
about
the
autocrypt
protected
headers
draft,
I'm
talking
about
the
question
mark
on
the
left-hand
column
there.
Possibly,
I
think
that
means
rendering
issues
with
non-mime
conformant
legacy
muas.
I
believe
that
this
this
format
has
rendering
issues
not
possibly
with
mime
conformant
legacy
muas
and
by
legacy
emuaids.
I
mean
almost
every
single
mua
out
there.
E
C
E
E
A
C
C
C
C
It
states
that
the
header
fields
that
are
inside
the
body
and
are
not
mime
header
fields,
they
can
be
ignored.
Like
header
fields,
other
than
mine,
header
fields
in
bodies
can
be
ignored.
C
They
should
not
be
ignored,
but
they
can
be
ignored
and
in
gateways
this
specifically,
they
may
be
discarded,
and
it
goes
on
that
x400
gateways
to
actually
scout
this
and
as
a
conclusion,
it
says
such
header
fields
like
it
is
two
from
subject
and
so
on
inside
body
parts
must
not
be
dependent
on
and
there
is
where
the
rsc822
message
mime
structure
comes
in,
because
this
kind
of
prevents
that
these
mime
head
fields
are
discarded
here.
The
question
is:
is
it
really
a
my
mind?
C
C
F
Yeah,
firstly,
I
I
want
to
correct
your
statement.
I
didn't
say
that
x400
gateways
have
a
problem
here.
I
don't
actually
know.
F
Basically
this
text,
I
asked
netflix
and
there
are
sort
of
a
couple
of
possible
issues
here.
One
is
my
implementation
that
parts
these
extra
header
fields
which
are
not
content,
choke
on
the
ones
it
doesn't
recognize
and
the
answer
is
it
can't?
Because
if
it
does,
it's
not
mind
compliant,
and
there
is
text
elsewhere
in
the
document.
Clearly
stating
that.
F
So
joking
is
the
most
serious
problem
that
might
be
happening,
but
basically
I'm
saying
it's
not
relevant
for
implementation,
that
don't
choke
that
bars
and
just
ignore
them.
Then
if
they
want
to
implement
something
like
autocrypt,
then
they
will
need
to
be
fixed
in
practice.
F
I
don't
think
this
is
going
to
be
an
issue.
I
know
that
you
guys
found
an
implementation
that
struggled
with
this,
but
none
of
the
other
ones.
I've
seen
have
this
issue,
so
I
think
it's
it's
slightly
subtle
and
liberal
interpretation
of
the
spec,
but
I
don't
think
it
matters
basically.
E
E
C
E
C
It's
your
endpoint
and
it
I
don't
know
if
that
exists,
but
it
may
that
the
gateway
says
I'm
the
other
endpoint
and
relays
the
message
to
the
user
unencrypted.
There
are
such
scenarios
when
the
encryption
is
finished
at
some
point
of
time,
but
I'm
not
sure
whether
this
is
relevant.
I'm
not
saying
that
I
know
that's
relevant.
It's
just
like
something.
We
need
to
look
at.
C
One
slide
back,
please
because
I
haven't
finished
it
yet
or
two
slide
back,
basically,
okay.
So
what
is
bit
related
to
this
nine
conformance?
It's
already
been
touched
in
the
discussion,
is
the
how
mind
pulse
of
proof.
Those
are,
I
would
say
in
the
s
mime
version.
This
is
my
parser
proof.
At
least
there
is
nothing
known
about
and
it
has
been
standardized
for
a
while
and
the
existing
mind.
Pulse
treatment
is
unclear
and
it's
also
something
we
need
to
look
at
closely
before
we
adapt.
C
The
auto
proposal
mentioned
that
I
know
from
my
impulse
implementation
that
is
discarding
any
non-mime
heterofields
when
it's
in
a
bodies
which
is
then
causing
an
issue
to
the
autocrit
proposal.
It's
not
the
particular
problem
with
that
mind
powers
because
they
will
fix
it.
That's
not
a
problem,
but
what
I
think
is:
are
there
any
other
mind
powers
in
the
wild,
or
can
we
rely
on
all
the
other
mind
pulses
in
the
wild?
C
E
So
I'm
not
sure
what
we
need
to
do
specifically
in
order
to
find
these
things.
Many
months
ago
I
published
a
set
of
messages
on
an
imap
server
and
I
sent
mail
to
the
lamp's
mailing
list
asking
for
people
to
send
screenshots
of
those
messages
we
got
some.
I
want
to
thank
the
folks
who
did
that.
I
didn't
see
anyone
whose
mail
user
agent
crashed
as
a
result
of
receiving
a
message
that
had
one
of
these
embedded
headers.
E
E
I
use
microsoft
exchange
on
a
daily
basis.
To
my
chagrin,
you
know
I
have
passed
messages
through
it.
I've
I
think
written
I've
been
the
only
person,
as
far
as
I
know,
who
has
written
and
publicly
documented
some
of
the
ways
that
microsoft
exchange
tampers
with
mime
structures
and
that's
in
a
draft
I
believe
I
mean
I
can.
I
can
point
folks
through
on
the
mailing
list
of
folks-
are
interested
again.
The
the
tampering
with
the
mime
structures
that
exchange
does
is
entirely
distinct
from
questions
about
whether
there
are
additional.
E
But
if
we
don't
know
what
we're
looking
for,
I
don't
know
like
we
can't
persist
indefinitely
in
a
state
of
well,
more
research
needs
to
be
done.
That's
that's
my
worry
here.
If
you're
asking
for
a
specific
piece
of
research,
how
does
x
type
of
message
pass
through
why
type
of
gateway
and
is
received
by
z,
type
of
user
agent?
E
C
D
C
Because,
if
you
don't
change,
we
don't
need
to
do
this
research,
but
if
we
want
to
change
to
reduce
these
rendering
issues,
then
we
need
to
look
at
it
closer.
That's
what
I'm
saying
here,
there's
no
further
comment.
I'm
just
going
on
next
thing
is
probably
not
really
content.
It's
of
course,
the
s
mine
conformant
that
prop
that
my
s,
my
proposes
s
mine
conformant
by.
Hence,
please
leave
the
slide
on
there.
We
are
two
slides
back.
Please.
C
C
There
are
rendering
issues
or
posterior
rendering
issues
with
no
mime
component
legacy
ways
and
dkg
enhanced
that
there
are
rendering
issues
like
ua,
rendering
issues
with
mime
conformant
uas,
and
that
is
definitely
a
plus
of
the
auto
crew
proposed
because
it
reduces
this,
and
the
last
thing
is
it's
slightly
shorter
in
the
autocrat
proposal,
so
anything
to
be
discussed
on
these
last
bullet
points.
Otherwise
we
will
go.
C
C
I
showed
here
the
whole
message
flow,
so
we
have
the
original
message
which
turns
into
an
inner
message.
It's
basically
pretty
similar
and
it
will
be
explained
more
on
the
next
slides,
which
then
from
those
and
the
original
message,
also
turns
into
another
auto
message.
We
need
to
do
something
for
the
auto
message
to
rob
actually
the
inner
message.
C
I
showed
it
on
the
two
columns,
because
on
the
sending
side
we
have
a
slightly
different
set
of
messages
and
on
the
receiving
side,
because
we
have
the
trace
header
fields
like
received
by
and
so
on,
and
it
may
also
be
different
because
some
on
the
way
somebody
changed
something
in
the
auto
header
and
at
the
receiving
user
facing
message,
we
basically
extract
the
inner
message
and
display
to
the
user.
So
that's
how
this
is
supposed
to
work
or
like
how
it
is
documented.
C
Okay,
so
the
inner
message,
it's
generally
or
often
it's
the
same
or
subset
of
the
original
message,
header
section
and
next
slide.
Please.
H
C
Okay,
so
basically
the
inner
message
is
either
the
same
as
the
original
message
or
the
original
message
without
pcc.
Bcc
has
particular
issues
which
are
discussed
on
another
issue
slide,
and
the
big
question
is
any
other
variants
we
need
to
consider,
and
that's
probably
where
daniel
is
jumping
in
now.
E
Daniel,
so
I
I
am
not
entirely
sorry
for
the
garbage
truck
noise
in
the
background
here.
I
am
not
entirely
sure
that
this
that
this
framing
inner
message,
original
message,
inner
message
is,
is
correct
and
I'm
not
sure
how
useful
it
is
again.
I
think
that
this
document
will
be
more
useful
if
we
clearly
separate
the
generating
side
from
the
receiving
side
presenting
it
all
in
one
workflow,
I
think,
makes
it
more
confusing
for
implementers,
and
so
I
think
it
would
be
more
useful
for
us
to
say.
E
Let's
talk
about
how
you
generate
this,
you
have
a
message:
you
want
to
send
your
mail
user
agent.
What
do
you
do?
What
are
the
steps
for
that
and
then
here's
how
you
might
get
receive
a
message?
Here's
what
you
might
think
about
on
the
receiving
side.
I
think
that
is
a
more
useful
structure
for
implementers.
I
know
that
as
an
implementer,
I
found
that
structure
more
useful
instead
of
trying
to
pretend
that
the
message
is
the
same,
all
the
way
across
the
loop.
E
This
isn't
particularly
because
we
in
this
description
we've
got
an
outer
message
that
actually
is
different
depending
on
who's.
Looking
at
the
message,
because
the
outer
message
might
have
been
modified
by
gateways
and
the
and
the
original
message
when
someone
is
sending
a
message,
isn't
actually
necessarily
an
email
structure
in
the
first
place
when
you're
going
to
compose
a
message
and
send
it,
the
mail
user
agent
hasn't
made
the
mind
structure
yet
right.
E
Is,
it
presumes
a
particular
type
of
workflow,
and
you
know
yes,
it's
a
reasonable
workflow,
but
not
everybody
uses
that
workflow.
So
I'm
a
little
bit
concerned
that
this
framing
is
is
pushing
in
in
a
separate
in
like
a
you
should
implement
in
the
following
way
direction.
Instead
of
saying
hey
when
you've
composed
a
message
here
are
like
the
ui
elements
that
presumably
you
got
from
the
user.
Is
this
a
reply
to
something
who's
it
to?
E
What's
the
subject,
are
you
gonna
put
a
date
on
it
like
all
of
these
things,
that
a
message
is
about
to
send,
but
it's
not
actually
necessarily
an
rfc,
a
22
message
at
that
point.
E
And,
and
with
bcc
right
bcc
is
an
example
of
it
being
the
subset.
So
there
are
some
non-subset
transformations
right
when
you
make
an
inner
message,
you're
like
wrapping
it.
If
you
use
the
s
mime,
construct
you're
wrapping
that
message
in
message:
rfc82
that
content
type
rfca
22
doesn't
exist
in
the
original
message.
So
it's
not
a
subset,
it's
actually
a
superset
right
and
then
yes,
there's
bcc
that
gets
dropped
right.
There's
a
there's,
a
set
of
things
that
happen
to
it,
that
are
that
are
distinct.
E
But
I
think
this
would
be
really
useful
is
to
say
here's
the
information
we
think
as
a
male
user
agent,
you
have
and
just
have
it
as
a
bulleted
list
of
items
and
then
say
here's
how
you
construct
the
message
with
protected
headers,
with
whatever
variant
we
go
with
right.
You
do
the
following
things,
but
I,
but
I
don't
think
that
it's
useful.
E
C
C
C
So,
but
I
think
this
is
a
minor
point.
You
had
a
more
important
point,
duration,
which,
which
is
that
we
may,
depending
on
where
we
are.
We
may
have
no
original
message
that
this
rfc
20822
message
that
we
are
just
about
to
compose
and
put
into
an
inner
message,
and
we
need
to
reflect
that
somehow.
I
agree
with
that,
and
I
suggest
that
we
are
sorting
that
out
later
and
we
are
just
taking
it
now
as
a
feedback.
C
C
So
how
it
is
defined
now
in
the
draft
is
that
we
have
the
essential
header
fields,
which
is
the
from
the
two,
the
bcc,
the
date,
the
message
id
and
the
subject.
It
depends.
This
is
kind
of
what
is
needed
and
this
depends
on
bcc
handling
and
also
whether
or
not
these
header
fields
are
present
in
the
original
message,
specifically
the
two
and
the
cc
and
the
pcc
are
not
always
present
in
the
original
message.
C
E
Hi,
this
is
dkg
again.
So
again,
I'm
not
convinced
that
outer
message
is
a
useful
term.
The
way
that
it's
defined
in
this
draft,
because
it's
defined
as
two
separate
things-
one
is
the
message
after
it
has
been
wrapped
with
the
cryptographic
protection
and
the
second
one
is
the
message
as
it
is
received
at
the
receiving
mua
and
those
are
very
different
things,
because
they,
the
message,
gets
altered
in
transit.
So
I
think
that
this
this
isn't
as
clear
as
it
could
be.
E
I
also
note
that
the
transformation
from
original
message
to
outer
message
doesn't
just
have
one
layer
right,
the
the
mime
header
section
part
it
could
have
multiple
ones,
because
multiple
cryptographic
protections
can
be
layered
on,
like
we
talked
about
in
the
protection
levels,
discussion,
and
so
the
way
that
I
framed
this
in
the
past.
Again,
sorry
for
all
the
truck
noise
y'all.
Apparently,
people
are
out
early
here.
E
The
way
that
I
framed
this
in
the
past-
and
you
can
see
this
in
the
autoclip
protected
headers
draft-
is
the
idea
of
a
cryptographic
envelope
which
consists
of
layers
of
cryptographic
protection
around
the.
What
what
I
think
is
roughly
aligned
with
what
you're
calling
the
inner
message,
which
is
the
which
is
referred
to
as
the
cryptographic
payload
right.
E
If
we're
talking
about
essential
header
fields
like
those
are
essential
header
fields
that
are
on
the
outside
of
the
cryptographic
envelope,
but
the
cryptographic
envelope
itself
is
distinct
and
there
might
be
it
says
here,
mime
header
section
part,
but
of
course
there
might
be
that's
only
one
of
the
of
the
parts
like
it
might
be,
multi-part
sign
it
might
be
multi-part
encrypted.
It
might
be
application
pkcs7.
E
So
again,
like
I'm,
not
sure
that
this
frame,
I
I
found
the
the
framing
of
cryptographic
envelope
cryptographic
payload,
to
be
more
useful
if
you
think
that
that
those
things
are
useful,
but
you
don't
want
to-
and
you
don't
want
to
import
them
into
this
draft
I'd
be
happy
to
write
it
as
a
separate
draft,
distinct
from
any
sort
of
header
protection
question
just
so.
We
have
a
document,
a
shared
document.
E
We
can
reference
that
shows
cryptographic
envelope
and
cryptographic
payload
if
that
would
be
useful,
but
I
anyway,
I
I
just
found
that
I
find
this
framing
harder
to
work
with
as
a
as
an
implementer.
C
I'm
open
to
look
at
this
terminology.
I
sometimes
invent
the
terminology,
I
know,
and
to
make
it
harmonize
to
things
that
people
know.
I
am
not
opposed,
so
we
can
introduce
that,
and
what
I
also
hear
is
that
it
should
be
a
bit
more
specific
that
there
can
be
multiple
mime
header,
section
parts
which
are
kind
of
in
the
outer
message
that
this
is
not
too
specific,
and
I
agree
with
that.
C
You
were
talking
about
these
dark
green
parts
on
the
on
the
other
slide
like
this,
what
we
call
the
rubble-
and
these
are
these
kind
of
mind,
metal,
section
parts
you
know,
but
I
agree
that
we
need
to
make
this
a
bit
more
clear
and
I'm
not
opposed
to
use
such
terms
that
are
better
understood,
but
let's
go
to
the
next
one
unless
yeah,
okay,
so
also
related
to
this
auto
message.
Shadow
field
is
that
we
need
to
obfuscate
some
stuff,
for
example
the
subject.
C
C
E
Yeah,
sorry,
no,
my
comment
is
that
I
don't
actually
believe
that
this
is.
I
don't
actually
believe
that
this
is
correct,
as
stated
because
if
it's
not
a,
if
there
is
no
encryption
in
the
cryptographic
protections,
I
don't
believe
obfuscation
is
warranted
for
any
of
these
headers
and
so
to
blanket.
Recommend.
Obfuscation
of
the
subject
line
would
be
a
mistake.
E
E
One
thing
is:
if
you're
generating
the
message,
what
should
you
do,
and
the
second
thing
is,
if
you're
receiving
the
message,
how
should
you
handle
an
obfuscated
header
field
and
those
are
those
are
distinct,
and
so
I
think
that
this
draft
should
not
recommend
any
specific
format
for
obfuscations,
with
the
exception
of
the
subject
line,
and
it
should
leave
open
that
someone
might
want
to
write
a
document
later
that
says:
hey
we've
been
thinking
now
we
like
now,
we
know
how
to
obfuscate
one
header
field,
here's
a
proposal
for
how
to
obfuscate
a
few
other
header
fields,
and
I
don't
think
we
should
get
into
the
details
for
how
to
obfuscate
date
or
message
id
or
to
or
from
on
in
this
particular
draft.
E
I
think
it
makes
more
sense
to
say
we
know
we
care
about
obfuscating
the
subject
line.
The
standard
for
subject
line,
obfuscation,
is
dot,
dot
dot
and
you
know,
obviously
you
could
propose
a
new
rfc
that
proposes
a
new
form
of
subject
line
obfuscation,
but
I
think
we
should
leave
it
at
that.
I
think
the
point
of
this
draft
is
to
get
the
mechanism
in
place
and
not
to
not
to
worry
about
the
other
fields.
A
A
The
others
we
can
have
discussions
about,
but
subject
is
the
one
that
has
caused
the
most
discussion
when
people
think.
Oh,
I
encrypted
the
message
and
then
they
find
out
the
subject
line
was
plain
text
and
they
gave
away
the
you
know
the
whole
point
of
the
message
that
that's
the
one
that
has
come
up
over
and
over.
C
May
I
reply
to
daniel's
thing,
so
we
are
still
like
on
the
generating
side
here.
You
said
that
by
mixing
up,
but
I'm
still
talking
about
the
generating
side,
not
about
receiving
side
yet
and
I'm
totally
fine.
If
we
say
that
we
are
not
going
into
the
details
of
what
we
do
with
data
fields
or
what
we
do
with
the
from
and
who
or
whatever.
C
However,
I
think
if
this
is
becoming
a
need
that
these
header
fields
need
to
be
obfuscated,
then
we
probably
need
to
define
something
to
give
guidance
to
the
spam
filtering
that
they
are
not
treating
something
as
spam,
that
or
like
that.
They
know
that
is
obfuscated
and
not
flagging.
The
spam,
based
on
this.
C
Yes,
I
just
said
I
don't.
I
don't
want
to
really
put
this
in.
I
just
want
to
put
it
to
the
discussion
and
unless
something
comes
up,
no,
no.
We
need
to
discuss
this.
I'm
happy
to
skip
this
or
like
just
make
a
note
that
this
may
happen
or
something
like
that,
but
not
just
how
is
it
called
in
a
normative
part
section
if
we
put
it
there?
C
Otherwise
we
go
on
how
much
time
do
we
still
have?
20
minutes
looks
quite
good
so
now
for
daniel,
especially
we
are
in
the
receiving
site
like
in
the
interpreting
site,
and
this
part
I
made
it
pretty
easy
and
said:
take
the
inner
message,
throw
a
without
a
message
and
display
it
to
the
user
next
slide.
C
So
this
leads
to
two
issues
again:
do
we
need
to
have
something
else
then
just
display
the
inner
message?
Do
we
need
to
actually
do
any
merging?
I
would
dis
correct
from
that,
because
it
makes
things
rather
complicated
and
prone
to
mistakes
in
the
implementation,
but,
as
a
consequence,
the
user
doesn't
have
any
more
access
to
information.
He
normally
has
like
the
information,
the
auto
headers,
for
example,
the
trace
header
fields
he
can
use
for
debugging
or
like
detecting
attacks.
A
E
C
Okay,
I
think
we
need
to
discuss
this
offline.
What
you
mean
here-
or
maybe
you
could
show
what
is
the
exact
issue?
I
mean
you
receive
a
message
and
it
has
a
defined
part,
which
is
the
inner
message
and
this
you
take
and
show
the
user.
So
what
is
here
unclear?
E
The
receiving
user
agent
has
an
obligation
to
render
the
message
to
the
end
user.
If
they
render
the
message
as
though
it
were
just
the
inner
message,
then
they
are
not
revealing
to
the
user.
The
cryptographic
protections
that
apply
to
the
message.
So
that
would
be
a
mistake.
They
have
to
render
the
cryptographic
protections
as
well
and
they
have
to
render
some
indication
to
the
user
that
the
headers
were
protected
or
not.
E
The
the
receiving
user
agent's
job
is
to
render
not
only
the
inter
inner
message
to
the
user.
It's
to
render
the
entire
state
of
the
message
to
the
user,
and
if
we
say,
if
we
say
oh
yeah
well
now
they've
got
the
inner
message.
That's
that,
then
we
haven't
actually
helped
the
receiving
mail
user
agent
think
through
what
they
need
to
be
doing.
Yeah.
C
So
basically
I
unders
yeah
ross.
Can
you
go
back
one
slide
because
he
talked
about
the
last
issue
yeah.
So
that
is
what
I
meant
that
any
other
variants
to
consider
in
this
issue
one.
So
I
understand
you
say
that
we
need
to
render
more
to
the
user
than
just
in
a
message
and
we
need
to
standardize
that
stay
correct.
E
If
I
could
live
in
a
perfect
lamps
world
is
that
every
email
that
I
received
would
be
both
signed
and
encrypted,
and
I
would
see
nothing
about
the
fact
that
they
were
signed
and
encrypted,
but
when
I
would
occasionally
receive
some
garbage
message,
that's
not
both
signed
and
encrypted.
I
would
see
warnings
that,
let
me
know
which
parts
were
not
signed
or
not
encrypted,
and
if
the
message
didn't
have
header
protection
but
was
otherwise
sound
encrypted.
E
E
We're
in
the
point
where
https
is
the
unusual
case,
so
we
can't
we
can't
go
that
route,
but
the
the
point
here
is
that
the
the
user
exp
like
the
rendering
the
rendering
job
the
job
is
to
communicate
to
the
user,
what
cryptographic
protections
they
had
and
to
make
sense
of
those
cryptographic
protections
when
applying
when,
when
ending
your
reply,
right
yeah
do.
C
A
One
additional
point:
building
on
what
dkg
has
said
and
that
is
the
itf
usually
gets
into
trouble
when
we
design
user
interface
so
saying
that
it's
a
requirement
that
something
be
communicated
to
the
user
is
fine,
saying
you
know
it
must
be
a
lock
icon
or
it
must
be
a
you
know,
a
red
border,
or
whatever
I
mean
they
all
have
trouble
in,
especially
for
color
blind
people.
But
let's
avoid
the
pitfall
that
we
know
was
there
right.
I
agree
with
russ.
C
Yeah
I
mean
we
are
in
this
as
well
and
we
take
took
into
consideration
the
colorblind
version
so
that
it's
not
only
an
icon
with
color,
but
also
with
symbol
and
so
on,
and
I
agree
that
in
the
itf
we
haven't
been
really
particularly
strong
in
designing
this
kind
of
stuff,
but
we
definitely
need
to
go
towards
this
direction.
So
in
that
sense
we
need
to
figure
this
out
so.
E
E
C
C
Wait
a
second:
can
you
go
up
on
yeah,
it's
about
the
bcc
handling,
so
the
encrypted
message
with
the
bcc
needs
to
be
split
at
the
sending
side.
Basically,
there
is
nowadays
implementation.
They
have
the
same
message
to
all
the
bcc,
a
correct
correction,
the
same
message
for
all
the
two
and
the
c
c
recipients
like
those
who
are
open,
nothing
to
hide.
This
is
sent
without
the
bcc
header
field,
and
then
there
is
the
message
that
they
sent
to
the
recipients
or
in
the
bcc,
and
these
arise
among
implementation.
C
C
Basically,
the
most
privacy
preserving
way
is
to
eat
in
the
2a,
like
one
message
for
bcc
recipient,
a
lot
of
message,
maybe
but
the
2b
and
2c
like
the
same
message
for
all
leaked
privacy,
information
via
the
encryption
keys
and
or
certificates.
C
E
I'm
also
not
sure
that
this
belongs
in
this
draft.
I
mean
I
I
agree
with
a
bunch
of
the
with
with.
I
think
what
the
consensus
of
the
room
here
is,
which
is
2a,
is
the
way
to
do
it,
but
I,
but
I
think
our
draft
this
draft
can
be
simpler
if
it
doesn't
address
this
issue,
because
this
issue
is
independent.
E
Well
again,
this
goes
back
to
the
question
of
how
of
how
this
draft
is
structured.
If
the
draft
is
here's,
what
you
do
as
a
sender,
because
you,
as
as
a
sending
mail
user
agent,
you
have
a
collection
of
information
about
what
you're
going
to
do
right,
you're,
going
to
decide
you're
going
to
the
things
you
have
are
who's
going
to
get
this
message.
E
What's
going
to
like
who's
gonna
be
listed
in
the
two
ncc
fields,
who's
the
message
gonna
be
from:
what's
the
body
of
the
message?
Will
we
step
stamp
a
date
on
it
right?
Those
are
things
that
you
start
with,
but
it's
not
necessarily
an
rca
22
message.
E
So
alexi
in
the
in
the
chat,
says:
bcc
affects
message
generation,
so
this
is
not
unrelated
alexi.
I
don't
think
bcc
affects
the
the
generation
of
the
structure
of
the
message
here.
It
affects
how
how
you
generate
like
which
steps
you
take.
I
think
this
can
I
don't.
I
think
this
is
orthogonal
to
this
particular
draft,
but
alex
if
you
have
a
suggestion
for
how
it's
how
it's
part
of
this
I'd
be
willing
to
hear.
L
A
Okay,
I'm
gonna
have
to
cut
this
discussion
now
we're
already
a
minute
over
our
time
slot
what
I.
Obviously
this
discussion
needs
to
continue
on
the
mail
list
you
have
like
10
slides.
We
didn't
even
get
to.
Let's
keep
the
momentum
going.
This
topic
went
silent
for
like
six
months.
Let's
avoid
it
going
silent
again
and
make
steady
progress
on
it
please,
but
we
are
out
of
time
and
I
don't
what
else
is
there
from
the
authors
about
next
steps.
C
Basically,
is
that
we
need
to
discuss
these
issues
further
on
the
mailing
list,
and
I
intend
to
put
those
like
one
by
one
into
some
mailing
threads
and
the
other
thing
is
that
we
implement-
or
we
discussed
the
feedback
which
we
got
today
with
like
how
to
put
it
to
the
draft,
and
there
are
some
other
open
issues
which
I
don't
mention
that
we
probably
do
a
merge
of
some
stuff
that
was
in
the
requirements
draft
and
also
some
stuff.
E
C
Yes,
that's
what
I
meant
the
part
of
the
feedback.
Yeah.
As
I
said,
I
already
sent
you
some
hints.
What
kind
of
examples
would
be
useful
to
test
and
compare
with
the
two
different
approaches
and
see
how
the
pulses
and
the
male
use
agents
react,
and
if
we
had
that
it
would
make
the
research
a
bit
easier
and
yeah.
A
Okay,
the
audio
stream
is
gonna
die
in
one
minute,
so
I
think
we
better
wrap
now
and
let's
make
sure
that
this
discussion
picks
up
on
the
list.
I
ask
you
to
manage
the
the
discussion
on
the
list
start
with
one
issue:
drive
it
to
ground,
go
to
the
next
issue,
drive
it
to
ground
and
so
on,
and
thank
you
all
for
your
participation
and
we'll
see
you
on
the
list.