►
From YouTube: IETF115-MIMI-20221109-0930
Description
MIMI meeting session at IETF115
2022/11/09 0930
https://datatracker.ietf.org/meeting/115/proceedings/
B
C
A
A
So
this
is
the
ietf
note,
well
that
outlines
the
policies
governing
this
meeting
if
you're
not
familiar
with
these
policies.
Please
take
a
look
in
particular
about
contributions
of
IPR
and
code
of
conduct.
We
are
definitely
expecting
to
have
a
very
pleasant
and
respectful
meeting
today.
So
please
keep
the
policies
in
mind.
A
Next,
it's
Wednesday,
so
those
who
have
been
here
are
already
familiar
with
this
in
terms
of
the
tips
for
using
medecco
in
in
the
room
for
those
who
are
here
in
the
room,
please
sign
in
to
the
Mimi
session,
either
using
full
meet
Echo
with
audio
and
video
off
or
the
medeco
light
icon
in
the
data
tracker.
That's
how
we're
taking
attendance
today.
If
you
want
to
speak
at
any
point,
please
join
the
Mike
queue.
A
Unless
you
want
to
so
here's
our
agenda
for
today,
fairly
kind
of
standard
boff
agenda,
we'll
bash
this
agenda
and
then
we'll
have
Rowan
who's
going
to
present
the
problem
statement
for
Mimi
for
about
20
minutes,
we'll
have
time
for
clarifying
questions
only
at
the
beginning
and
then
we'll
move
into
discussion
of
the
charter
and
and
the
boss
questions
at
the
end.
And
if
we
get
done
in
time,
we
can
start
a
little
bit
of
solution.
A
A
We
have
a
long
history
of
sort
of
an
interaction
between
things
that
we
develop
and
the
broader
regulatory
environment,
especially
in
the
in
the
in
the
Telco
space
and
Telecommunications
space,
with
things
like
stir
and
ecrit
and
so
on.
So
this
is
not
new
for
us.
It's.
You
know
something
that
we've
done
before
and
we
can.
We
can
think
about
what
the
regulatory
requirements
are,
but
really
what
we're
mostly
focused
on
is
developing
the
best
solutions
for
the
internet
and
its
users.
A
Next,
there
were
a
bunch
of
drafts
that
were
submitted
in
advance
of
the
boff.
We're
not
going
to
be
doing.
You
know
individual
draft
presentations
today,
but
if
you
want
to
familiarize
yourself
with
what
was
submitted,
there's
a
list
in
the
slide
and
also
in
the
data
tracker.
If
you
want
to
take
a
look
at
how
people
are
starting
to
approach
the
different
topics.
E
E
E
This
lack
of
interoperability
causes
a
very
poor
user
experience
and
so
what's
different
from
last
time.
Well,
last
time
instant
messaging
was
still
pretty
basic,
so
the
feature
experience
now
what's
the
the
sort
of
common
set
of
features
among
instant
Messengers
is
is
quite
robust
and
we
didn't
have
widespread
indent
encryption
before
and
now
there's
a
lot
of
external
pressure,
for
example
from
the
EU
digital
markets
act.
E
In
order
for
us
to
have
interoperability,
so
we
could
achieve
slowly
bit
by
bit
interoperability
by
just
letting
individual
vendors
publish
their
apis
without
standardization.
But
this
would
this
would
perpetuate
the
status
quo.
We
would
end
up
with
probably
some
pretty
poor
user
experiences
and
lots
of
bugs.
E
E
So
if
you
are
and
then
encrypting
you
don't
get
to
use
a
gateway
to
change
the
contents
that
are
end
and
encrypted
it's
encrypt
once
and
send
and
forget
you
have
to
send
it,
and
so
we
have
a.
We
have
a
number
of
different
things
that
we
need
to
be
able
to
convey
in
the
message
format
that
are
quite
common
across
instant
messaging
systems.
E
E
E
So
what's
important
here
is
that
everyone
in
the
group
gets
the
same
content
from
whoever
sends
content,
so
we
need
at
least
one
kind
of
common
minimal
set
of
formats,
but
they're
likely
to
be
many
formats
out
there.
So
if
there
are
proprietary
formats,
you
need
to
be
able
to
probably
still
send
those
and
also
send
the
common
format,
depending
on
their
circumstances.
So
you
need
to
communicate
which
formats
are
supported
which
are
required
and
what
is
actually
said.
E
So
MLS
describes
two
abstract
Services,
an
authentication
Service
and
a
distribution
service,
and
these
in
concept
of
in
the
context
of
interoperability.
A
distribution
service
is
very
likely
to
span
multiple
administrative
domains.
So
the
service
isn't
running
on
one
server
over
here
and
then
you
have.
You
know
a
separate
service
to
talk
to
the
other
thing,
the
the
service
spans
all
of
the
domains
that
are
involved,
and
it
also
does
not
specify
whether
a
particular
function
needs
to
be
accomplished
in
a
client
or
in
a
server.
E
So
the
architecture
is
quite
flexible
and
if
you're
curious
about
this
for
more
detail,
I
encourage
you
to
look
at
the
MLS
architecture
document
linked
below
it
describes.
What
are
the
decisions
that
an
implementation
needs
to
make
about
how
to
how?
How
to
deliver
a
compliant
authentication,
Service
and
in
a
compliant
distribution
service,
authentication,
Services,
need
to
issue
credentials
and
they
need
to
enable
a
client
to
verify
that
credentials
that
they
receive
are
as
they're
presented
by
another
client.
E
B
E
Great
okay,
one
more
layer
down,
so
we
need
a
way
to
convey
the
encrypted
messages.
The
MLS
messages
to
a
server
which
is
sort
of
the
between
between
servers
among
servers
and
between
clients
and
servers,
and
so
the
we
at
minimum
need
to
be
able
to
send
these
MLS
messages.
There
may
be
some
other
features
that
we
also
want
to
to
communicate
using
the
same
protocol.
E
E
E
E
An
identifier
that
is
used
internally
is
not
always
what
the
end
user
sees
in
a
user
interface.
So,
in
a
user
interface
you
may
you
may
see
something
like
that
looks
like
a
phone
number
and
in
fact,
when
you
search
for
a
user,
you
may
use
a
phone
number
or
an
email
address,
or
a
full
name
or
you
may
have
a
service
handle.
The
internal
identifier
may
be
different
as
part
of
the
problem
space.
E
We
just
need
to
make
sure
that
internal
identifiers
are
compatible
with
the
protocols
we
use,
and
we
should
make
sure
as
well
that,
because
our
goal
is
interoperability,
that
we're
not
we're
not
putting
a
high
barrier
on
an
existing
service
that
they
have
to
completely
change
their
service.
In
order
to
use
to
incorporate
some
identifier
that
they
already
use.
E
E
E
This
is
how
do
you
get
the
internal
identifier
and
how
do
you
obtain
permission
to
start
sending
messages
to
someone
or
inviting
them
to
groups
now?
The
first
part
of
this
assumes
that
you
know
what
the
target
service
is.
So
this
would
be.
You
know,
I
I
come
to
Jonathan
and
I
say
I
Jonathan.
Do
you
have?
Do
you
have
wire?
No,
do
you
have?
Do
you
have
WhatsApp?
Yes,
do
you
have
signal?
E
E
E
E
E
A
B
F
Wow
I
did
not
expect
to
be
the
first
person
in
line
here.
So
thanks
for
the
presentation,
one
question
that
came
up
is
we're
talking
about
sort
of
like
client
to
server
interoperability
as
well
as
server
to
server
interoperability.
Do
we
have
like
a
preferred
or
understood
preferred
model
for
which
one
we
want
to
support?
First
right
like
so,
you
know.
I,
am
you
know,
member
of
service
X,
there's
service
X
to
service
y
interoper
between
those
servers
versus
I,
have
client
X
and
can
connect
to
server
for
service
y.
F
E
E
Once
we
get
a
working
group,
we
talk
about
what
are
the
requirements,
but
technically,
if
we're
using
MLS,
we
need
the
MLS
clients
on
whatever
service
we're
interoperating
with
to
have
sort
of
a
cohesive
over,
and
we
need
to
have
an
intersecting
set
of
policies
and
so
the
the
clients,
for
example.
If
to
give
you
a
simple
example,
when
I
remove
myself
from
a
group,
I
send
a
I
send
a
proposal
to
remove
myself.
Someone
needs
to
commit
that
proposal
whose
responsibility
is
to
do
that.
We
need
to.
F
Okay
so
I
think
what
I'm
hearing
is
we
don't
know
yet,
but
there
is
a
a
strong
preference
to
use
the
MLS
architecture
as
a
basis,
and
that
will
drive
some
of
the
decisions
is
supposed
to
with
respect
to
what
gets
done.
First,
yeah
cool
I
don't
want
to
do
the
whole
present
I.
Don't
want
to
do
the
whole
discussion.
That
was
that
that
was
the
thing
that
I
was
I
needed
to
clarify.
So
I'll
sit
down.
Okay,.
A
I
Hey
Rowan,
thanks
for
giving
this
presentation,
definitely
kind
of
clears
up
a
lot
of
the
the
space
that
we're
looking
at
I
was
hoping
to
clarify
the
introduction
identifying
individuals
inside
of
these
different
groups
by
different
protocols,
because
I
think
the
the
initial
urge
is
to
go
for
something
that
we've
seen
in
like
an
email
client
where
there's
some
sort
of
identifier.
Like
you
know,
this
is
some
user
and
we've
got
some
contact
system
that
finds
these
other
internal
identifiers
at
system
or
service
of
their
choice.
I
guess
the
difficulty.
I
What
is
the
thought
behind?
There's
we're
not
talking
to
the
service
to
Route
us
to
this
user.
We
just
need
to
identify
their
device
individually
and
that
message
gets
delivered
straight
to
them.
That
you
know
devices
identity
by
IP,
address
or
where
it
sits
in
the
network
is
going
to
be
tough,
to
tease
out
with
some
sort
of
Authority
in
the
middle
that
directs
us
to
them
and
trying
to
solve
that
end
to
end
versus
centralizing.
It
is
going
to
be
difficult.
E
E
I
E
A
J
When
we're
in
the
group
chat,
and
then
somebody
wants
to
bring
somebody
on
WhatsApp
into
that
group,
and
everybody
says
how
the
whole
reason
we're
on
Signal
is
to
stop
Facebook
getting
us
our
data
or
whatever.
You
need
to
have
some
kind
of
semantics,
both
at
the
API
and,
frankly,
the
uxler
to
make
sure
that
people
can
control
the
metadata
privacy
within
a
given
conversation.
J
K
L
E
A
If
you
could,
between
now
and
when
we
start
talking
about
the
charter,
look
there's
a
line
in
the
charter
about
respect,
respecting
expressed
user
preferences
about
reachability
and
discoverability
and
see,
if
you
think
it
captures
this
bit
as
well
about
kind
of
where
the
metadata
is
located.
Okay,.
L
In
this
case,
since
people
are,
did
you
decide
who
has
to
join
a
group?
You
could
be
like
I,
don't
like
people
who
have
you
know
at
whatsapp.com
in
the
back.
So
I
want
to
tell
you
the
instruction
problem
just
a
minute
and
try
to
sharpen
up
I
think
what
what
the
requirements
are.
So
there's
either
three
layers
of
requirements,
things
you
might
imagine
doing
right
at
the
very
top
I
started.
L
The
very
most
most
powerful
would
be
to
say
that
you
know
you
could
have
I
think
what
Jonathan's
draft
calls
calls
a
a
service,
specific
identifiers.
You
know
things
like
you
know
unqualified
names
like
at
Ecker
and
be
able
to
figure
out
like
which
service
they
were
on
yeah
or
e164
numbers.
You
know
which
what
spin
residue
the
sort
of
next
level
down,
which
I
think
you're
trying
to
roll
out
of
scope.
L
The
next
level
down
is
to
be
able
to
have
you
know
whether
they're,
hidden
or
unhidden
qualified
identifiers.
In
the
same,
you
know
like
RFC
22
names,
and
the
idea
would
be
so.
You
know
it
might
be
the
case,
you
know
so
now
the
interfaces
might
be
presented,
as
you
know,
as
ekr
at
you
know
at
wire,
but
like
theoretically,
but
the
point
would
be
that
that,
given
those
things
is
an
unambiguous
way
to
figure
out
what
exactly?
What
services
that
that
requires
connecting
to
right
for.
L
Yeah,
so
so,
if
I'm
giving
an
internal
Journal
identifier,
the
scoping
parameter,
this
is
what
services
on
that
on
what
so
I
mean
I
guess
so
so
an
email
like
in
in
an
email
system
right
on
you
know
you
can
email
names
are
one
giant
string,
but
you
can
imagine
them
being
on
this
way.
You
imagine
saying
you
know
you
know
here
and
then
you
know
example.com
as
like
as
they
identifier.
My
point
is:
there's
a
single
algorithm.
L
You
follow
to
figure
out
where
that
server
lives
right
and
then
there's
like,
and
then
it's
like
a
an
even
worse
thing,
which
is
you
have
to
maintain
a
table
that
is
not
like
generically
lookable,
it
tells
you
what's
up
is
over
here
and
it
goes
over
here
and
and
in
fact,
like
you
know,
there's
different
things
you
have
to
do
to
connect
you
to
them.
I
assume
that
we
want
the
middle
one,
not
the
last
one
right
that
is,
there's
there's
a
single
hour
set
of
algorithm
and
community
and
communication
protocols.
E
So
I
think
that,
in
terms
of
the
problem
statement,
I
don't
think
we
need
to
decide
that
I
think
that's
a
requirements
question,
but
you
know
I
I
think
it
I
think
that
that,
as
if,
when
present,
when
presented
specifically
explicitly
I,
think
that
the
The
Logical
conclusion
will
be
fairly
obvious
for
that
question.
I.
L
L
M
Jim
Fenton
I've
got
a
slew
of
questions
about
identifiers
and
I'm,
not
going
to
ask
now
because
I
think
we're
covering
that
pretty
well
the
thing
that
confused
me
was
toward
the
end.
You
were
talking
about
the
need
to
understand
what
service
a
particular
user
uses.
Are
they
on
wire?
Are
they
on
Signal
or
are
they
on
WhatsApp
or
what
Etc?
N
E
I
need
you
know,
I
need
to
somehow
I
can't.
Just
you
know,
I
I
need
to
be
able
to
from
and
I'm
not
using,
if
I'm,
not
using
that
system.
I
need
to
be
able
to
provide
some
information
so
that
I
can
I
can
start
the
process
and
start
routing
messages.
Send
my
user
introduction
to
the
correct
service
to
start
the
ball.
The
ball
rolling.
M
E
So
the
second
problem
is
that
if
you
have,
let's
say
that
some
something
to
search
on
like
an
email
address
or
a
phone
number
or
a
full
name,
and
some
other
information
say
that
you
could
that
you
could
optionally,
with
the
user,
with
the
target
user's
consent
that
you
could
use
that
to
figure
out.
Here
are
some
services
that
I'm
on
and
sort
of
the
preferred
order
of
them
like
and
I'm.
That's
I'm
not
trying
to
be
specific
about
how
you
would
do
that.
There
are
a
lot
of
privacy
issues,
blah
blah
blah
blah.
E
M
E
O
A
I
think,
for
the
purposes
of
the
problem
statement,
the
problem
is
being
stated
as
functionally.
You
have
a
you
have
a
Target
identifier
and
what
you
need
to
be
able
to
do
is
bootstrap
a
communication
with
that
identifier
on
their
service
and
the
area
that
needs
to
be
explored
in
the
design
space
is
around.
How
do
you
do
that?
Is
it
at
the
user
level
or
the
system
level?
Does
it
leverage?
You
know
some
side
service
on
the
side
to
help
you
do
that?
Those
are
like
questions
about
the
solution,
as
opposed
to
the
problem.
G
G
G
C
C
For
instance,
you
had
these
invites
or
receipts
you
sent
on
an
invite
to
a
certain
user
when
you
invite
to
an
invent
event,
which
is
fine
for
live
indoor
probability.
But
if
you
later
on,
like
10
years
later
or
so,
move
people
away
to
another
provider,
you
wanna
put
the
data,
but
you
don't
want
to
resend
those
invites.
E
A
P
Hello,
this
Jim
I
had
an
elephant
just
wondered
in
through
the
room
in
my
head
presence
and
this
proposal
never
talks
about
the
presence
and
every
single,
a
messaging
system
I've
dealt
with.
Has
a
support
for
presence
and
every
single
messaging
system.
I've
been
involved
with
on
the
server
side,
has
had
major
scaling
problems
because
of
presence.
P
E
Q
And
so
that's
one
point.
The
other
point
is
that,
looking
through
all
these
presentations,
it
appears
that
there
is
an
assumption
here
that
what
you're
going
to
build
is
a
series
of
gateways
because
of
course,
you've
all
got
these
large
infrastructures,
and
you
think
that
the
easiest
way
of
going
from
where
you
are
to,
where
you
want
to
be,
is
going
to
gate
each
of
the
10
messaging
infrastructures
to
each
other.
Q
And
we
actually
have
a
data
point
that
tells
us
that's
not
stable,
because
I
remember
the
days
when
smt,
before
SMTP
dominated
where
I
used
to
have
to
send
my
mail
through
different
gateways
and
the
reason
we
went
from
that
model
to
us
common
protocol
was,
it
was
just
too
much
to
maintain
and
so
I
I
understand
that
we're
going
to
go
and
Charter
with
the
assumption
that
we're
going
to
do
a
gateway.
But
by
the
time
we
actually
read
out
I
assure
you.
Q
O
All
right,
Jonathan,
Rosenberg,
five,
nine,
so
I
I
mostly
wanted
to
offer
clarifying
response
to
some
of
the
folks
at
the
mic.
I
think
there's
a
little
confusion
on
this.
Perhaps
the
the
charter.
The
focus
of
this
group
I
believe,
is
not
to
build
a
whole
Suite
of
things
that
someone
could
go
Implement
a
new
client
and
build
a
new
service
around
and
we're
going
to
design
the
new
protocol
for
how
one
would
build
a
chat
system
from
scratch.
O
O
That's
what
I
wanted
to
be
clear,
we're
doing
so.
If
things,
for
example,
like
Harold,
like
let's
worry
about
the
scale
of
presence
systems,
scale
presence
system
is
a
big
deal
for
the
people
who
are
implementing
them.
We're
not
trying
to
build
a
specified
protocol
for
them
on
how
to
build
it.
They
already
have
something
we
have
to
decide
only
whether
or
not
we
want
presence
messages
to
be
exchanged
between
these
providers
and
that's
work.
O
I
believe
we'll
do
in
the
working
group
where
we
Define
that
minimal,
viable,
oh
message,
format
and
whether
there's
a
presence
message
or
not
so
I
think
it's
in
that
sense.
It's
quite
a
simpler
problem
on
the
wire
see
what
I
did
there
for
you
know
getting
these
things
implemented.
So
that's
that's
my
clarifying,
hopefully,
commentary.
D
I
I,
just
since
there's
been
confusion,
I
just
wanted
to
clarify
that
my
understanding
of
this
with
as
phone
numbers,
definitely
in
scope
and
the
desirable
user
experiences.
If
I
had
somebody
else's
phone
number
I'd
have
a
chance
of
being
able
to
connect
and
have
communication
with
them
if
they
wanted
to
and
the
sort
of
requirements.
Point
of
view
that
that
was
you
know
that
that's
what
we
were
trying
to
get.
D
We
weren't
the
the
I
thought
we
got
way
too
deep
in
the
weeds
of
possible
implementations
of
ways
that
you
could
achieve
that
user
experience
about
whether
it
required
servers
in
the
cloud
or
whether
you
had
to
know
which
service
the
person's
on
I
mean
a
fundamental
characteristics
for
me
is
I,
do
not
want
to
know
which
service
I
don't
want
to
have
to
know
what
service
somebody
is
on
to
be
able
to
connect
to
them.
If
all
I
know
is
their
phone
number
I
want
to
be
able
to
connect
to
them.
A
G
R
Kind
of
more
maybe
like
that
that
some
something
that's
often
overlooked
with
this
aspect
is
that
there
are
some
use
cases
where
impersonation
is
actually
desirable.
For
example,
the
business
use
case
where
you
have
like
an
admin,
and
you
want
to
impart,
be
like
impersonate,
a
certain
user
and
I
just
wanted
to
raise
awareness
that
there
might
be
use
cases
out
there
where
this
is
actually
an
important
feature,
but
as
far
as
I
understand,
usually
that's
more
concerning
long-term
storage
and
not
what
you're
talking
about
it.
Just
wants
to
double
check.
Basically,
yeah.
S
Antoine
hello
I
wanted
to
have
a
clarification
on
The
View.
You
have
an
interoperability.
Is
it?
Do
you
mean
that
you
want
to
specify
a
minimal
list
command
denominator
among
the
different
systems
that
Implement
instant
messaging?
Or
do
you
want
to
provide
a
way
for
external
systems
that
don't
support
a
specific
additional
feature
that
you
have
on
a
given
system?
So
users
from
the
outside
world
of
your
network
can
provide
a
way
to
an
information
that
mimics
this
feature.
So
the
experience
in
your
network
is
consistent.
E
I'm
not
sure
I
understood
the
your
second
option,
so
I'll
I'll
sort
of
give
give
an
answer,
and
then
you
can
tell
me
whether
that
answers
your
question
at
I
want
to
be
able
to
send
an
instant
message
to
people
on
multiple
that
currently
are
on
multiple
different
services
and
I'd.
Like
them
to
be
able
to
reply
and
be
able
to
send
me,
you
know
cat
pictures
and
so
on.
S
R
S
C
E
So,
if
you
want
to,
if,
if
like
having
Rings
or
knocks
or
or
window
vibrations,
is
a
feature
on
some
systems-
and
that
happens
to
not
to
not
make
the
cut
in
terms
of
the
common,
the
common
interoperable
feature
set
that
people
who
use
whatever
proprietary
format
they
they
currently
use
can
still
do
that
and,
if
I'm
in
a
group
that
doesn't
do
that,
I
would
not
be
able
to
do
that,
but
I
would
still
be
able
to
do
all
of
the
things
that
are
in
the
common
feature
set.
Okay,
that's
personally
my
goal.
B
So
there
was
some
discussion
just
now.
Let
me
get
the
slides
a
bit.
There
was
some
discussion
about
whether
particular
requirements
are
present
here.
Think
in
terms
of
whether
you
want
this
group
to
decide
requirements
or
you
want
it
to
be
locked
into
the
charter
and
that
distinction
for
those
of
you
who
are
not
used
to
this
process
is,
do
you
want
the
entire
ietf
on
board
with
this
before
we
start,
or
do
you
want
this
group
deciding
it?
The
former
is
the
chartering
process.
B
The
latter
is
this
group
coming
to
requirements
so
make
sure
that
the
charter
is
clear
enough
for
you
that
you
think
the
requirements
will
be
addressed
by
the
group.
Don't
try
and
convince
the
ietf
that
they
have
to
be
on
board
with
exactly
what
requirement
you're
talking
about
that
of
reasonable
distinction.
K
B
B
K
A
U
U
A
A
Yeah,
okay,
so
so
this
one
related
to
the
language
about
how
this
working
group
will
not
be
specifying
new
signaling
protocols.
I
think
there
was
some
confusion
about
that.
This
term
signaling
protocols,
I
think
when
the
charter
was
written,
it
was
meant
to
imply
audio
and
video
signaling
specifically,
but
it
was
not
clear
in
in
the
context
of
the
paragraph
that
that
that
was
the
limitation
on
it.
A
A
V
J
Yep,
it's
clear
on
the
discussion
on
the
list,
but
it
should
be
back
put
that
into
the
wording
on
the
pr,
because
the
pr
is
currently
saying.
Oh,
was
there
a
minute
ago
here
we
are
the
pr
was
saying
that
it
specifically
requires
ordering
of
handshake
messages
within
groups.
You
are
explaining
that
can
be
done
in
a
decentralized
fashion
or
at
least
shared
between
the
participants,
whereas
that
isn't
clear
here,
or
at
least
it
wasn't
too.
V
B
E
So,
at
the
beginning
of
this
discussion,
Pete
said:
do
you
want
the
ITF
to
discuss
this,
or
do
you
want
us
to
discuss
this
I
think
this
is
a
clear
case
where
the
intention
we've
discussed
in
this
room
we've
discussed
among
the
like
the
main
parties
we
agree,
but
adding
more
text.
This
is
going
to
be
a
red
flag
for
the
ITF.
It's
going
to
cause
confusion.
It
I
think
that
this
will
hold
up
triggering
so
I
think.
The
original
wording
that
Raphael
proposed
is
fine
and
then
incorporates
what
we
need.
L
Yeah
I
want
to
speak
to
that
same
point.
I
agree
with
Rowan
like
this
is.
This
is
quite
classic
over
specification
in
the
charter,
and
we
should
like
the
Rafael's
text,
looks
like
reasonable
to
me.
I
made
words
with
the
disappoint
later
but,
like
the
German,
looks
fine,
but
I.
Think
that,
like
writing,
this
text
here
is
going
to
like
cause
all
kinds
of
problems
and
I,
don't
even
know
what
it
means
so
like,
let's
just
start
there,
so
it's
like
yeah
I
think
we
shot
it.
K
L
I
I,
don't
think
this
applies
Central
position.
If
you
think
that
if
you
have
texts
that
would
like
my
problem
is,
that
is
the
is
the
is
I
mean
I
I
generally
agree
with
this,
like
I.
Think
the
intent
of
this
is
but
but
I
don't
know,
but
I
don't
know
quite
what
it
actually
means,
and
so
I
think
if
you
want
to
just
avoid,
if
you
have
suggestions
that
make
this
not
prescribing
centralized,
did
you
make
those
suggestions
but
I
think
trying
to
prescribe
non-centralized
is
the
problem
here:
okay,
yeah
totally.
B
N
A
A
U
Totally
optimism
Enthusiast,
so
I
I
really
appreciate
the
optimism
by
which
the
proponents
are
brought
forward.
The
work
in
general,
especially
given
our
past
history
here,
that
that's
really
cool
and
important
but
I,
think
the
introduction
problem
text
as
it
stands
now
and
even
with
the
just
disappeared,
PR
yeah
sorry
Pete
I
was.
U
Refer
to
that,
so
even
without
it,
the
way
it's
currently
written
needs
a
complete
rewrite,
not
a
small
change,
because
the
way
it's
currently
written,
it's
a
completely
separable
problem
right.
You
could
you
could
gen
up
a
working
group
that
had
as
its
goal
solving
the
introduction
problem
across
these
services
without
a
goal
of
creating
interoperability
among
them
and
I.
Think
that's
not
what
you
actually
want.
I
think
what
you're
trying
to
say
is
for
the
systems
which
have
signed
up
to
interoperate
by
implementing
whatever
Mimi
comes
up
with.
U
U
Mimi
will
consider
developing
a
protocol
to
allow
conformant
services
to
provide
a
mechanism
to
introduce
their
subscribers
across
other
conformant
services.
So
I
think
that
what
we're
trying
to
do
here
is
actually
much
less
ocean
boiling
than
this
sounds
like
and
I
think
for
a
charter
to
get
through
the
rest
of
the
process.
We
have
to
make
it
clear
that
we're
only
boiling
the
parts
of
the
ocean
that
have
deliberately
dug
the
canals
we
specify.
U
U
A
Because
sorry
people
stand
around
at
microphones,
sorry
Ted
I
thought
you
were
also.
You
were
because
what
Rowan
just
spoke
about
is
more
to
this
additional
sentence
that
he
was
adding,
but
I
thought
you
were.
You
were
concerned
about
this,
the
prior
sentence
as
well,
where
we
say
we're
going
to
specify
a
solution
to
the
introduction
problem
that
needs
to
be
narrowed.
According
to
you,
correct,
yes,.
U
Okay,
yeah,
okay,
then
I
think
I
have
an
action
item
to
raise
an
issue
and
a
propose.
A
PR,
yes,
but
I
I
hope
that
the
general
question
of
how
we
ensure
that
this
does
not
become
the
ocean
boiling
question
of
solving
the
introduction
problem
for
people
who
haven't
signed
up
for
Mimi
is
leaves
the
charter
one
way
or
the
other.
Whether
you
take
my
PR
or
somebody
else,.
L
So
I
don't
want
to
worry
too
much
of
Charter
checks
at
this
exact
moment
and
try
to
scope
out
the
problem.
Space
is
that
for
a
second,
as
Pete
says
it
seems
to
me
there
are
two
problems.
One
problem
is
give
an
identifier
and
the
service
it
is
on
arranging
to
connect
a
to
B
and
we
can
go
in
induction.
If
we
want,
we
can
call
it.
L
D
D
They
may
find
it's
an
impossible,
Problem
Solver
they
may
they
may
solve
it,
but
I
do
not
want
to
continue
to
insert
these
words
in
there
that
it's
a
new
protocol
that
we'd
have
to
do
to
do
this
because
I
think
the
best
Solutions
don't
involve
a
protocol
at
all,
and
so
I
I
would
rather
not
keep
embedding
Rowan's
solution
into
the
charter
text
on
this
right.
So
because
I'm
not
I,
don't
like
that.
D
Q
A
general
question
a
point
throughout
the
chart.
At
some
points,
the
term
identity
is
used
and
the
other
other
points
we
have
user
identifier.
They
both
appear
to
be
meaning.
The
same
thing
I'd
like
to
propose
that
we
use
user
identifier
throughout
and
Nick's
identity,
which
is
you're
looking
in
in
the
terms
that
it
is
being
used.
It
is
certainly
being
used
to
me
as
a
user
identifier-
and
you
know
my
Twitter
handle
is
not
my
identity.
Q
Q
A
A
But
so
on
the
identity,
Point
I
think
people
should
should
respond,
because
my
understanding
was
that
actually
we
do
mean
two
different
things
when
we
say
identifier
and
identity
and
the
identity
is
the
cryptographic
identity
and
the
identifier
is,
is
you
know
whatever
we're
using
on
a
particular
service?
So
if
people
have
opinions
about
that,
please
respond
Matthew.
J
F
A
X
Am
but
I
was
doing
this
intentionally
trying
to
beat
the
end
of
the
number
four
discussion.
It
is
kind
of
a
broader
point
about
this
passage,
but
not
about
the
specific
PR,
so
I
mean
when
I
read.
This
I
still
think
there's
a
bit
of
tension
in
the
way
the
charter
is
structured,
which
I'm
sure
we'll
resolve
this
is
I
think
this
is
a
simple
one
between
that
that
last
sentence
that
Express
user
preferences
about
discoverability
and
reachability
must
be
respected
insofar
as
I
suspect.
X
So,
in
other
words
this
is
this
is
I'm
talking
entirely
about
you,
know
social
media
style
messaging
systems
where
you
curate
very
carefully
the
set
of
people
that
you're
supposed
to
be
in
contact
with
this
interacts
a
lot
with
both
the
introduction
problem
and
with
the
question
of
the
degree
to
which,
like
spam
mitigation,
is
actually
in
scope
of
this
or
not
so,
I
guess
my
the
only
question.
I
had
about
this
and
I
wanted
to
do
this
because
we
have
this
BR
open.
X
I,
read
Express
user
preferences
to
mean
I
had
to
say
intentionally,
I
don't
want
to
be
discovered,
and
we
have
to
respect
that
and
of
course
we
should
respect
that,
but
I
I
guess
I
am
hypothesizing.
There
are
actually
a
lot
of
properties
of
common
systems
that
have
an
introduction
problem
that
users
don't
have
to
press
a
button
to
say
that.
But
the
reason
why
they're
on
the
service
is
because
it
has
that
property.
So
it's
not
like
I
expressed
it.
It's
not
an
Express
user
preference.
It
is
an
innate
preference.
B
X
Anything
later
the
charter
says,
like
everything,
that's
concerned
with
Spam
and
abuse,
we're
kicking
down
the
can
we
may
do
it,
but
a
lot
of
it
is
out
of
scope.
It's
metadata
analysis
now
in
fact
think
the
main
way
those
systems
mitigate
spam
is
through
things,
users
don't
express
his
preferences.
So
that's
why
I
was
asking
if
that
we
could
maybe
tweak
that,
but
this
I
don't
want
to
take
the
entire
working
group's
time
on
this.
If
this
is
a
complicated
one,
no.
A
X
R
K
W
L
B
Y
I
just
have
a
bit
of
a
clarifying
question
here,
so
I'm
kind
of
following
and
getting
up
to
speed.
There
was
a
question
from
Eric
to
say:
is
Discovery
in
or
out
and
I'm
listening
to
the
discussion
about
identifiers
and
identity
and
I
kind
of
think
they're.
The
same
question:
if
we
say
identity
is
me,
but
I
have
identifiers
in
different
systems.
Y
Does
that
open
the
question
of
how
does
Eric
speak
to
me
and
discover
which
identifier
to
use
which
will
get
to
me
out
of
the
many
identifiers
I?
Have
that
identify
my
identity
too
many
idents
in
that
sentence?
I
apologize
and
should
it
therefore
be
pushed
out
of
scope
of
discoveries
out
of
scope
or
absolutely
addressed
within
the
charter
if
we
are
doing
discovery,
that's
my
open
question.
A
B
I
I
think
the
the
answer
to
what's
in
the
charter
is
it
should
what
I'm
hearing
is?
It
should
allow
this
group
to
take
on
the
discoverability
question,
but
not
require
it.
The
that
the
group
will
decide
once
up
and
running
whether
they're
taking
on
discoverability
and
examine
that
problem,
see
if
they
can
address
it.
B
A
Z
A
L
I
I
think
just
briefly
the
am
but
we're
gonna.
We
will
in
fact
need
to
like
clarify,
because
internology
is
great
about,
like
King
material
versus
versus
versus,
like
names
versus
like
real
names.
Jonathan
rosenberg's
draft
was
a
quite
a
nice
job
actually
of
trying
to
technical
taxonomy
of
the
various
things
so
I
think
like
that's
something
we
can
do
offline.
We
can
make
a
pass
through
and
like
use
either
terminology
from
there
somewhere
else.
L
That
tries
to
try
to
cut
those
apart
right
and
I
certainly
agree
with
php's
point,
but
like
the
public,
keys
and
and
and
names
identifiers
are
all
different
things,
but
I
think
I
think
that's
something
we
can
actually
do
offline
because
I,
don't
there's
actually
disagreement
about
it.
I
think
it's
like
the
writing
needs
some.
F
Q
Q
Now
that
is
a
discovery
problem,
but
it
is
a
much
more
narrowly
constrained,
Discovery
problem
than
the
broad
one
that
we've
been
expanding
it
out
to
and
in
ITF
terms.
That
is
something
that,
for
me
comes
back
to
Uris,
because
the
whole
idea
of
Uris
is
a
uniform
identifier
space
that
you
can
map
any
form
of
identifier
onto
so.
You
can
cut
and
paste
them
between
people.
B
Q
AA
This
is,
should
really
really
narrowly
be
scoped,
both
Charter
and
requirements,
to
make
sure
that
identity
is
in
service
of
the
messaging
and
now
I
understand,
because
I
was
a
real
proponent
of
keeping
discoverability
in
this
on
the
list
previously
and
now
I
understand
why
people
didn't
want
it,
because
I
think
it
gets
us
to
this
point
where
we
are
building
interoperability
or
interoperable
identity,
which
would
be
a
total
disaster
and
I.
Don't
think
we
want
that.
A
J
G
P
P
E
U
M
A
Yeah,
it's
a
little
hard
to
multitask,
so
I
think
I
think
we're
in
a
good
place.
With
with
this
item,
we
can
kind
of
resolve
the
final
differences
immediately
after
the
buff
and
take
it
that
way.
I,
don't
think
we
need
to
decide
on
specific
words
at
the
moment,
give
people
a
little
time
to
look
at
the
PRS,
so
I'm
going
to
unlock
the
queue
and
I
think
we
should
come
to
PR
number
seven
here
and
then
we'll
come
back
around
to
spam
and
anything
else.
People
want
to
talk
about.
L
So
I
I
commented
this
I
think
this
is
over
specification
in
the
charter.
Like
I,
understand
the
motivation
but
like
this
is
like
this.
This
is
like
one
in
many
requirements,
so
I
might
think
what
might
be
desirable,
but
it's
not
like
actually
that
core
to
what's
actually
happening
here
and
I
think
that
it
should
not
be
the
Turner
I
mean
like
if.
F
A
V
Yeah
I
think
I
agree
with
that
in
the
sense
that
metadata
has
not
been
introduced
as
a
term
so
far,
and
this
is
oddly
specific,
while
also
introducing
metadata
so
yeah
I
agree
with,
like
I
said.
If
you
want
to
talk
about
metadata,
we
would
have
to
do
something
more
comprehensive,
but
there
is
no
PR
for
that.
O
Jonathan
Rosenberg
I
think
the
express
and
implied
preferences
language
that
we
already
have
in
the
charter
gives
the
working
group
the
room
to
sort
out
the
details
on
these
things
and
is
sufficient,
so
I
agree
I
I,
don't
think
this
is
needed
in
the
charter.
I
think
it's
a
fabulous
discussion
for
the
working
group.
K
AA
Mallory
noodle
CDT
I
wanted
to
put
on
Mike
something
that
Nick
Doty
said
in
the
chat,
which
is
really
smart
to
just
remove
the
word,
express
and
just
say,
user
preferences
rather
than
adding
implied.
But
this
is
not
exactly
about
this
I
tend
to
agree
with
others
that
we
don't
need
to
introduce
the
metadata
if
it's
not
mentioned
anywhere
else
in
the
charter,
but
because
Ecker
and
others
brought
up
just
that
word
again.
I.
AA
No
actually
I
think
that
user
preferences,
so
so,
if
we
so
back
to
the
conversation
before
I
didn't
come
on,
Mike
then
because
I
felt
others
were
handling
rather
well,
but
my
reaction
to
it
was
you
actually
need
to
ask
now
so
that
the
implied
piece
I
think
means
that
we're
not
okay
with
it
being
implied
anymore.
We
actually
do
need
to
confront
and
make
visible
these
implied
preferences
somehow
now,
and
so
what
are
the?
What
are
the
implied?
AA
What
are
user
preferences
that
are
now
implied
that
must
be
expressed
and
shift
this
so
that
interoperability
works
and
user
I?
Don't
think
it's
okay
to
work
based
on
implied
user
preferences,
because
we
don't
know
what
they
are
and
there's
no
way
for
users
to
feed
back
then.
So
that's
a
problem
that
has
to
be
solved
in
the
context
of
this
working
group.
It
doesn't
have
to
be
in
the
charter.
So
if
you
remove
Express,
you
just
talk
about
user
preferences,
it's
something
we
have
to
address
in
the
working
group.
AA
AC
Yeah,
getting
back
to
the
data
residency
working
I
think
that
maybe
data
metallurgism
is
a
bit
too
specific,
but
I've
been
in
favor
of
keeping
a
reference
to
something
a
little
more
generic
like
data
processing,
meaning
that
when
you
introduce
the
the
join
the
Federation,
then
you
you
I
mean
you
must
keep
the
principle
that
it's
the
user.
That
decides
where
the
data
can
or
cannot
go,
which
is
the
basic
principle
of
the
European
privacy
laws
anyway.
X
X
Anyone
if
you
have
a
telephone
number
can
like
hit
you
with
a
telephone
number,
there's
nothing
you
can
do
about
it.
Social
media
has
has
fundamentally
altered
this
Dynamic
and
to
put
this
as
a
way
that
well,
you
know
we
need
to
like
confront
users
to
get
them
to
like
Express,
that
that
is
what
they
actually
want.
X
B
X
This
I
I
fear
it
is
getting
the
list
to
discuss
more
about
to
put
in
Charter
about
this,
because
I
think
there
is
an
unfortunate
interaction
between
solving
the
introduction
problem,
putting
spam
out
of
scope
and
having
the
statement
about.
Nonetheless,
we
want,
to
you
know,
respect
user
preferences
right
and
I
believe
those
user
preferences
are
cassette
in
every
way.
That
makes
the
introduction
problem
a
problem
at
all
like
there
is
no
introduction
problem
for
telephone
numbers.
You
got
a
telephone
number.
Anybody
can
call
it
right.
A
So
yeah
I'm,
gonna,
I'm
gonna,
contradict
myself
from
20
minutes
ago.
Maybe
do
you
not
envision,
given
the
fact
that
all
of
the
closed
systems
offer
controls
that
that's
where
this
came
from
in
the
first
place
right,
if
you're,
all
of
a
sudden,
going
to
open
up
a
closed
system
to
people
from
other
non-closed
systems?
Who
can
reach
you
that,
if
you,
if
you
are
already
in
a
position
where
you're
controlling
who
can
reach
you,
that
better
extend
to
this
much
larger
interoperable
system
right?
A
So
do
you
not
Envision
that
the
the
services
that
already
offer
such
controls
will
not
augment
those
controls
with
hey
now,
people
from
signal
can
reach.
You
are
you
okay
with
that,
like
that,
and
that's
why
I
think
I
mean
Mallory's
point
is
perhaps
that
whatever's
implicit
today
will
have
to
become
explicit,
because
the
users
who
signed
up
for
these
services
that
that's,
why
they're
there
in
the
first
place
is
because
they
have
those
controls.
So
why
would
these
like?
A
X
Is
the
former
point
that
we
can't
force
these
systems
to
to
make
users
make
this
choice
right
and
to
put
it
explicitly
to
them
as
a
choice
like
if
I,
if
I
thought
Facebook
was,
it
was
going
to
give
me
a
button?
I
could
push
that
said.
I'm
an
open
front
door
like
anybody
can
say
I,
don't
require
anything
for
anybody
to
see
anything
right,
I
mean.
X
Maybe
public
posting
is
like
that
or
you
know,
maybe
there
are
systems
for
like
DMS
and
Twitter
or
where
you
can
like
set
that
and
receive
DMS
from
from
anyone.
Those
are
examples
of
ways
that
that
could
be
made
explicit.
My
point
is:
if
the
default
of
these
things
and
the
way
that
the
the
the
reason
they
have
been
successful
is
communication
systems
is
because
they
do
not
their
default
out
of
the
box.
Behavior
is
to
prevent
users
from
having
these.
X
T
Just
a
quick
question
from
a
complete
messaging
newbie,
just
the
language
must
be
respected.
There
just
strikes
me
as
a
bit
odd.
You
know.
Are
we
really
saying
that
we're
going
to
put
a
must
in
the
specification
that
you
must
behave
in
this
way
when
it's
effectively
untestable
I
mean
that
seems
like
it's
something
that
would
be
regulated
by
by
legal
forces,
but
I'm
not
sure
it's
really
about
technical
interoperably.
Do
we
really
mean
must
be
respected,
or
is
it
must
be
able
to
be
expressed?
A
T
Q
Okay,
this
might
be
unpopular,
but
basically
we've
got
the
completely
wrong
language
here.
This
is
not
the
introduction
problem.
This
is
the
access
control
problem
that
front
door.
That
John
was
talking
about.
Yes,
he's
got
that
completely
right,
yeah.
Every
message
that
I
receive
over
an
instant
message
channel
is
access
controlled,
because
you
can't
talk
to
me
on
Signal,
unless
I've
already
decided
to
accept
Communications
from
me.
Q
So
really
what
we've
got
here
is
an
authorization
problem
and
you
have
to
have
a
mechanism
that
allows
somebody
to
set
up
an
authorization
in
the
first
place
and
you
have
to
have
an
access
control
system
so
that
people
can
say
I
do
not
want
J
random
fascist.
Sending
information
into
my
messaging
box
is
an
access,
control
problem
and
so
I,
you
know,
I,
don't
think
we
can
really
word
Smith.
Q
This
I
think
we've
got
to
go
back
and
cast
it
in
those
terms,
because
once
you
do
that
the
whole
bit
about
Express
user
preferences,
no,
no
they're,
not
preferences,
they're,
Access,
Control
policy
and
the
user
has
to
be
in
control
of
that.
And
that
goes
to
the
heart
of
what
AOL
and
signal
and
so
on
are
saying
when
they
want
anti-spam
built
in.
They
want
to
protect
those
existing
access
controls.
Q
B
Thanks
so
what
I'm
hearing
right
now
and
just
in
case
people,
don't
need
to
get
to
the
mic?
What
I'm
hearing
right
now
is
this
PR
doesn't
address
the
problem,
that's
being
expressed
here,
and
this
really
does
need
to
go
back
to
the
list,
and
this
paragraph
needs
to
be
reviewed
and
and
figure
out
what
text
we
want
to
express
what
people
are
talking
about
here.
A
O
Yeah
Jonathan,
Rosenberg,
I
I
think
almost
all
of
this
is
stuff
that
should
happen
in
the
working
group
and
not
in
the
charter.
I
I'm,
not
a
fan
of
protocol
engineering
via
indirection
in
the
charter.
Everyone
who
has
all
these
strong
opinions
on
identity
and
preferences
and
implied
versus
explicit.
Can
we
just
do
this
in
the
working
group
because,
instead
of
like
asking
for
delaying
of
another,
you
know
three
months
to
make
a
working
group.
O
Just
let's
get
a
working
group
and
have
this
debate
and
I
say
that,
because
I
think
a
lot
of
this
discussion
is
losing
sight
of
what
the
objective
of
this
is.
We
are
not
here
to
design
the
messaging
system
in
world
of
messaging.
We
wish
we
had.
That
is
not
the
charter
of
this
group.
There
are
existing
providers
and
they
sell
the
products
and
they
have
the
policies
and
they
make
the
decisions
they've
already
made,
and
it's
not
our
job
to
tell
them
to
do
something
else.
O
Our
job
is
to
provide
a
way
for
them
to
interoperate,
and
we
need
to
solve
the
just
the
protocol
mechanisms
necessary
to
facilitate
that
interoperability.
That's
what
we're
here
to
do
so
I
would
love
to
sort
of
conclude
on
the
charter
text
and
I'm
pretty
much
happy
with
whatever,
because
we're
going
to
have
it
all
over
again
in
the
working
group
and
we
do
no
benefit
to
ourselves
by
delaying
it
and
the
dma
has
a
deadline
in
case
people
didn't
know
this.
A
U
Think
part
of
the
thing
that
the
working
group
has
to
Define
is
how,
when
you're
building
one
of
these
overlaid
conversations
or
channels
Etc
you
get
that
inheritance,
and
there
are
a
variety
of
ways
of
doing
it,
that
the
working
group
has
to
design
and
the
charter
isn't
required
to
design.
But
I
think
it's
really
important
that
we
keep
in
our
brains
that
we
are
not
trying
to
solve
the
problem
of
service
interoperability.
U
Broadly,
it's
per
overlay.
We
have
to
solve
it
and
that's
a
much
more
constrained
problem
and
that's
good
because
trying
to
solve
it
and
the
full
interoperability
of
all
the
different
aspects
of
these
different
Services
is
not
going
to
meet
the
dma
deadlines
and
it's
not
going
to
be
a
solvable
problem
with
the
enthusiasm.
But
if
we
conceptualize
this
that
way,
I
think
we
can
understand
these
buff
questions
in
a
much
more
useful.
D
A
J
A
So
we
have
time
to
do
that,
but
we
are
going
to
move
on
to
the
boff
questions
we're
going
to
be
asking
to
help.
So
the
point
of
these
questions,
for
those
who
are
new
to
this
process
is
to
help
inform
our
responsible
area
director,
who
is
helpfully
standing
now
at
the
front
of
the
room,
Marie
and
the
rest
of
the
iesg,
as
they
think
about
whether
this
working
group
should
be
chartered
and
put
the
charter
out
for
Community
review.
A
Z
Yes,
I'm
David
I
think
there's
one
issue
around
scoping
and
this
is
slightly
related
to
the
Charter.
Apologies
for
that,
but
I
think
it
is
somewhat
problematic
that
the
problem
statement
explicitly
places
a
lot
of
this
permanent
abuse
questions.
Semi
out
of
scope,
I'm
I'm,
worried
about
the
impact
that's
gonna
have
on
the
Solutions.
A
Thanks
yeah,
we
left
it
out
of
the
charter
because
it's
an
unconventional
thing
to
do
in
ITF
Charters,
that
is
in
the
it's
like
in
the
buff
request,
description
but
I,
think,
and
there
are
some
backup
slides
in
this
deck
that
you
can
peruse
at
your
own
Leisure.
That
explains
some
of
the
dma
requirements,
but
I
think
in
general.
We
try
not
to
be
have
that
as
the
basis.
It
is.
A
It's
obviously
a
motivator,
but
if
you,
if
you
look
at
that-
and
you
think
that
it
has
an
impact
on
the
problem
statement-
scope
that
would
be
useful,
I
think
it's
actually
stated
at
a
very
high
level
what
the
requirements
are
on.
The
Gatekeepers
under
the
dma,
so
I
think
everything
we've
talked
about
today
is
potentially
within.
Within
that
scope,
Victoria.
AC
A
AC
AC
AC
I
think
that
there's
a
real
risk
that
we
I
mean
if
we
don't
address
the
problem
at
least
start
discussing
how
it
could
impact
we
end
up
with
something
which
will
fail,
because
people
will
try
to
deploy
it
and
then
it
will
be
immediately
used
to
spam,
everyone
else
and
and
the
main
players
in
the
field.
We
say
we
don't
interoperate,
because
this
is
just
opening
up
too
much
spam
and
abuse
and
abuse,
not.
L
So
I
don't
think
we
should
say
anything
about
dma
in
the
charter.
I
understand
it's
motivating
for
why
this
work
was
more
successful
but
I,
don't
think
we
I
think
trying
to
be
like
we're,
not
like
the
consultancy
for
like
the
for
the
EU,
so
our
jobs
recently
that's
good
and
that
does
does
will
serve
those
requirements,
but
I've
read
I've,
read
the
requirements
and
they're
really
quite
vague,
so
so
I.
Don't
really
think.
L
There's
much
fear
that,
like
that,
like
that
that
will
fail
to
hit
those
if
we
do
a
proper
job,
otherwise
I'm
also
sensitive
to
this
point.
John
Peterson
is
another
people
raised
about
spam
and
abuse,
I,
I'm
really
torn
I,
don't
think
as
much
I
think.
Maybe
maybe
like
there's
a
question
between
you
know.
We
are
not
going
to
solve
spament
abuse
ever,
but
even
here,
especially
because
those
are
like
very
platform,
specific
ways
of
handling
it.
L
What
we
need
to
do
you
know
and
if
you
think,
of
the
email
situation,
you
know
we
didn't
try
to
solve
family
abuse
and
email
either
we
tried
to
get
the
plot.
The
applications
of
platform
is
the
ability
to
handle
themselves,
and
so
I
think
you
know
if
we
were
able
to
like
come
up
with
a
a
consistent.
You
know
set
of
functionality
which
would
enable
platforms
to
handle
sound
abuse.
We
should
do
that.
L
I
I
not
feel
comfortable.
I
understand
the
situation
well
enough
to
be
able
to
do
that
at
the
moment.
I
wonder
if
there's
a
way
to
sort
of
finesse
this
a
little
bit
the
charter
interest
like
I,
mean
having
room
for
like
in
the
same
ways
we
made
room
for
a
discovery
thing
make
room
for
make
room
for
protocol
support
for
that.
If
we
then
need
it
like
I,
say:
I
I
feel
like
that's
like
not
entirely
adequate,
but
it's
the
best.
I
know
how
to
do
so.
There
we
are.
B
W
Matthew
Wilde,
so
I
I
completely
sympathize
with
the
the
point
about
not
wanting
to
make
the
whole
working
group
about
the
dma
I.
Think
that's
very
sensible,
but
I
also
worry
that
if
we
don't
recognize
that
as
a
goal
at
all
and
I
think
it
is
implied
as
a
goal,
because
we
keep
talking
about
it,
we
run
the
risk
of
possibly
defining
solutions
that
are
not
acceptable
to
The
Gatekeepers,
for
example,
and
go
too
far
in
one
direction.
E
Rowan,
so
from
my
perspective,
spam
is
specifically
mentioned
in
the
problem
statement
and
in
the
charter.
It's
listed
as
that
that
there's
some
text
about
you
know
basically,
let's
get
the
ball
rolling
and
then
what
we
can
go
and
do
this
we
can
go
and
do
this
a
little
bit
later.
So
that's
my
understanding
is
that
the
problem
statement
does
include
doing
spam
metadata
and
that
there
is
a
mention
of
it
specifically
in
the
charter.
E
O
Yeah
Jonathan
Rosenberg,
so
I
think
the
probability
that
spam
is
not
considered
in
the
discussion
is
exactly
zero,
it's
sort
of
like.
Should
we
worry
about
security?
How
about
like
backwards?
Compatibility
extensibility
like,
of
course
we're
all
going
to
do
those
things
too.
Do
they
need
to
be
in
the
charter,
every
single
one
of
them
I,
don't
think
so.
O
I
think
everyone
who's
working
on
this
understands
the
risks
and
the
challenges
without
a
doubt
to
me.
I
think
it's
fine
as
it
is
we're
going
to
work
on
those
things.
I
think
the
main
point
is
this:
group's
Charter
is
not
to
specifically
design
protocols
whose
primary
functions
are
spam
abuse.
Where-
and
this
is
why
I
think
what
ecker's
saying
is
right-
we're
building
a
messaging
interop
system
which
has
many
design
considerations,
all
of
which
do
not
need
to
be
enumerated
in
the
charter,
which
is
obviously
inclusive
of
Trying
to
minimize
spam.
X
Yeah
and
I
I
do
think
the
problem
statement
is
I.
Think
it's
pretty
clear
to
most
folks
here
and
I
think
the
way
it's
been
articulated
is
fine.
I
mean
on
on
the
spam
thing
again.
I
raise
this
just
to
make
sure
that
the
way
that
the
charter
text
is
going
to
capture
that
aspect
of
the
problem
statement
actually
encompassed
the
way
that
some
of
these
messaging
systems
behave
right
and
I
think
we
all
here
know
how
those
missing
systems
behave.
We've
events
that
we
can
work
this
out
in
the
working
group.
X
A
A
Going
once
going
twice
good:
okay,
does
anyone
object
to
forming
a
working
group
with
the
proposed
Charter
module
of
changes
discussed
today?
Obviously
we
have.
We
have
more
refinements
that
we
need
to
discuss
on
introduction
and
Discovery
Express
user
preferences,
potentially
spam
data
residency
and
metadata,
but
we've
had
robust
discussion.
I
have
confidence
that
we
will.
You
know,
reach
some
some
agreements
on
those
bits
of
text
so
modulo.
All
of
that
happening.
L
A
B
B
B
B
B
B
Oh
yeah,
red
lanyard
people
yeah!
So
here's
the
third
one
are
there
folks
who
are
willing
to
share
or
co-chair
this,
and
so
we've
got
experienced
people
we've
got
inexperienced
people
and
we
certainly
would
be
happy
to
take
both.
So
if
you
are
even
if
you
feel
like
I,
don't
know
about
sharing,
if
you
think
with
an
experienced
person,
you'd
be
willing
to
do
that
as
a
co-chair.