►
From YouTube: CORE WG Interim Meeting, 2021-06-09
Description
CORE WG Interim Meeting, 2021-06-09
A
So
welcome
everyone
to
this
virtual
interim
meeting
of
the
co-working
group.
My
name
is
marco
diloka.
My
co-chair
is
I'm
ahimets
and,
as
usual,
this
is
an
official
itf
meeting,
so
the
not
well
applies
and
be
sure
to
be
familiar
with
it.
If
you're
not
already,
it
is
not
just
about
ipr
and
patents.
It's
also
about
code
of
conduct,
so,
as
usual,
be
nice
with
each
other,
and
the
agenda
for
today
is
about
two
documents
on
group
communication
and
you
spend
most
of
the
time
for
the
session
actually
for
the
group.
B
I'm
I'm
I'm
working
through
the
through
the
list,
so
the
yeah
kind
of
trying
to
slot
it
in
between
between
other
other
things
that
are
that
are
also
urgent
right
now.
What
would
help
jordan,
as
you
asked,
if
you
could
have
a
look
at
the
the
point-to-point
responses
that
I'm
preparing
in
parallel
to
editing
in
things
other,
but
I
don't
see
any
kind
of
there's.
No
large
things,
it's
just
things
that
need
to
be
done.
C
B
B
Things
it's
as
we
go.
Basically,
all
the
all
the
all
the
issues
are
tracked.
It's
the
same
way,
I
did
it
with
the
resource
directory.
There's
a
file
in
the
in
the
github
repo,
where
all
the
all
the
comments
are
attract
and
they
basically,
as
I
solve
things
in
the
document,
I
also
add
the
responses
there
or
if
things
are
already
resolved
or
just
need
a
response,
then
those
are
already
in
there.
A
D
D
D
D
D
D
D
D
D
D
D
Yeah,
it's
actually
requiring,
I
think,
a
little
bit
feedback
to
make
progress-
maybe
john
or
maybe
from
others
who
want
to
chime
in.
So
what
will
be
the
relevant
attack
scenarios,
for
example,
spoofing
messages
that
are
protected
with
google
score
using
a
different
source,
ip
address
and
replay
packets.
C
D
C
I
wonder
if
we
could
use
some
source
there
and
I
don't
have
anything
at
the
top
of
my
head,
but
but
I
don't
think
we
need
to
sort
of
start
from
scratch.
We
could.
We
could
look
a
little
bit
find
some
existing
analysis
that
has
been
done
and
and
then
I
mean
in
particular
looking
at
at
multicast.
I
suppose,
and
let's
see
what
are
the,
what
can
be
what
is
applicable
and
and
where
does
group
of
score,
provide
a
solution,
and
where
does
it
not?
A
A
D
Altogether,
yeah,
that's
the
point.
So
if
you
use
the
echo
option,
then
you
just
don't
have
a
group
of
servers.
Potentially
it's
sending
something
back.
You
get
the
amplification
effect.
The
response
packet
is
getting
quite
small,
still
yeah.
You
get
multiplication
and
I
think
that
was
the
idea
to
make
that
also
explicit.
D
D
D
D
D
Number
14
was
a
point
that
question
that
came
up,
so
what
is
the
interaction
between
observe
option
and
no
response
option
so,
typically
with
doing
an
observe,
you
expect,
of
course,
to
get
responses
back
from
the
servers
and
with
no
response
option.
At
the
same
time
you
can
say
to
the
server:
please
don't
send
me
the
response
of
a
certain
class,
so
we
clarified
this
bit.
So
the
idea
was
basically
that
only
if
an
observer
is
added
at
the
server
then
that
server
yeah
should
actually
send
a
response
to
the
client
that
was
just
added.
D
It's
also
signals
to
the
client
that
okay,
this
server
request
was
successful
and
that's
why
it
should
normally
not
suppress
the
response,
but
the
user
can
still
override
this
by
including
a
specific,
no
response
option,
so
that
will
basically
override
the
default
response.
Suppression,
as
is
already
the
case,
so
this
can
be
combined
and
not
all
combinations
would
make
sense,
of
course,
but
you
can
do
it.
D
A
D
D
Ingress
devices
that
take
traffic
traffic
into
a
six
slope
on
network
because
from
yeah,
let's
say
from
things
like
earlier
simulations
that
I've
done
many
years
ago,
you
could
see
that
it's
fragmented,
multiple
traffic
is
sort
of
normally
very
bad
for
them
performance
sort
of
notes.
You
have
to
reassemble
slope
on
layer,
many
fragments
and
then
create
another
cast
ip
package
from
that
and
yeah.
We
can't
expect
very
good
performance,
so
it's
kind
of
normal
that
device
that
allows
you.
D
D
D
Yeah
so
number
17
jira
had
a
little
discussion
issue,
so
the
question
was
what
are
actually
valid
cases
of
having
a
forward
and
a
reverse
proxy,
with
either
end-to-end
security
or
what
they
call
a
two-leg
security.
So
that's
not
end-to-end
to
security,
but
just
that
two
lags
individually
protected.
Basically,.
D
And
this
is
a
topic
that
you
could
say
well,
more
or
less
belongs
to
the
new
graft
group
from
proxy,
and
I
think
so
too,
but
yeah.
My
proposal
was
still
at
a
high
level
to
include
something
about
it
in
this
draft,
just
to
mention
what
are
the
yeah?
What
are
the
valid
combinations
here,
so
you
can
sample
forward
proxy
combined
with
end-to-end
security,
or
you
could
have
a
for
proxy
case
where
there's
this
two
legs
of
security,
so
an
example
could
be
one
being
dtls
to
reach
the
box
itself.
D
D
D
Input
right
and
then
the
final
one
here
number
19:
what's
the
consideration
how
to
handle
cube
block
options
because
we
talk
about
block
options,
but
since
then
the
block
options
are
also
added
and
there
we
just
take
on
the
text.
Basically
that
was
already
defined
in
the
block,
so
it's
not
to
be
used
and
all
the
cards
requests.
So
the
servers
must
also
ignore
this
and
that
we've
added
to
the
route
editor's
copy.
D
So
this
is
a
lot
of
text
here,
so
we
have
it's
part
of
issue
number
eleven
by
the
rules
of
cashing
with
origin
clients.
Quite
some
discussion
there
so
general
problem.
There
is,
if
you
are
a
client,
you
can
basically
cache
the
results
of
this
group
request.
That's
no
problem!
But
what,
if
you
want
to
do
a
new
request,
can
you
serve
that
from
cash
partly
or
entirely
or
not?
D
So
if
you
yeah,
if
you
can
serve
their
request
entirely
from
a
cache,
then
you
miss
those
new
numbers.
So
that's
why
some
rules
islanded
here
and
now
we
need
to
edit
this
copy.
I
post
a
simple
solution,
so
yeah,
that's
in
all
cases
the
request
needs
to
be
sent
out,
so
you
can
serve
from
cache
as
defined
in
rfc
7252,
but
you
also
need
to
send
out
the
request
because
servers
could
have
joined
in
the
meantime.
D
A
D
C
A
D
D
If
the
proxy
is
the
position
that
it
puts
all
the
new
members
that
are
joining,
for
example,
if
it's
a
border
router
that
receives
all
the
group
joining
requests
joining
the
call
and
can
just
keep
track
of
all
the
members
it's
network,
but
in
that
case
that
helps
to
make
those
decisions
but
yeah.
This
is
saying
that
well,
unless
you
have
that
kind
of
knowledge,
you
can
only
basically
the
only
thing
you
can
do
is
send
out
the
request
again
just
to
catch
yeah.
Maybe
servers
that
that
have
joined
in.
D
D
Okay
and
then
the
last
slide
was
also
about
number
11,
so
the
aspect
of
placement
of
these
caching
features
functions,
so
we
have
catching
up
proxies
and
that's
all
that
so
I
moved
to
proxy
at
least
yeah
for
the
details
and
the
caching
at
origin
clients.
That's
what
we
now
discuss
in
group
from
this
yeah.
The
same
is
for
the
revalidation,
so
if
there's
a
proxy
for
all
three,
we
put
it
in.
Maybe
what
you
want.
D
D
D
D
So
the
the
design
we
have
there
is
that
in
this
we
would
like
to
have
a
final
solution
for
that.
So
client
can
do
revalidation
with
the
group
of
servers
and
once
we
have
that
solution,
we
can
also
reuse
that,
hopefully
in
the
group
proxy
draft,
so
the
proxy
can
use
the
exact
same
mechanism
to
keep
it
simple.
D
D
D
B
B
So
I
I
do
remember
what
this
is.
It
is
a
form
of
compression,
but
I
don't
think
that
we
have
a
good
use
case
for
this.
Neither
for
for
number
one
number
four
would
be
something
like
and
number
four
would
be
something
like
if
not
modified
in
the
within
the
last
so
and
so
many
seconds,
which
might
might
make
sense.
D
Yeah,
that
was,
I
think,
a
similar
reason.
We
had
there
so
there's
yeah
potential
use
cases,
but
no
no
strong
space.
We
see
at
the
moment
it's
not
that
clear
where
it
will
exactly
be
used
for
so
it
was.
I
think
the
motivation
also
people
for
option
two,
so
you
should
use
something
that's
already
there
social
backwards
compatible
and
quite
simple
to
use
to
define
anything
or
not
much
new.
For
it.
The
option
can
be
reused.
D
D
There's
basically
one
instance
per
server
in
the
group.
You
want
to
revalidate
against
so
there's
three
of
these
servers.
For
example,
you
want
to
revalidate
with
then
three
multiple
etec
options,
so
we
request
and
each
option
contains
basically
a
number
of
seaboard
encoded,
some
sequence
of
dtec
values.
D
D
D
D
D
D
C
D
C
A
A
B
Just
brief
question
to
confirm,
because
I
didn't
find
it
quickly
in
the
in
the
pointed
to
document
that
client
that
server
id
that
the
server
picks
does
not
necessarily
have
any
particular
structure
inside
the
e-text.
So
the
e-take
is
still
an
opaque
option,
but
the
server
kind
of
phrases
it's
e-tag
in
a
way
that
it's
unlikely
to
collide
with
any
other
server.
Ctec
right.
D
B
D
Same
so,
it's
not
in
that
case
nothing
better,
but
it's
still
used
to
create
it.
So
with
some
probability
it
will
be
unique
to
that
server.
Yeah.
Thank
you
and
indeed,
there's
a
choice
like
an
application
choices.
So
you
can
make
a
very
long
e-tax,
which
is
yeah,
of
course,
more
likely
to
be
unique
but
leads
to
more
bytes
over
the
wire
or
you
could
have
short
ones.
You
can
make
a
trade-off
there
just
like
for
the
normal
exam.
A
D
D
Yeah
and
that's
the
next
steps
yeah
so
you're,
seeing
the
comments
from
the
review
that
john
did
step
so
for
that
we
could
get
some
issues
with
the
tasks
to
do.
Also.
The
other
github
points
are
being
worked
on,
and
specifically
this
last
discussion
has
so
to
decide
now
on
the
validation
method,
between
client
and
original
servers,
so
that
we
already
proposed
an
attack
but
yeah.
I
think
we
should
also
give
that
a
chance
to
be
discussed
at
the
mailing
list.
People
want
to
say
something
about
that
then,
finally,
to
submit
version
4.
C
C
I
mean
we
know,
we
know
there
are.
There
are
misuse
of
co-op
and
and
the
narrow
service
attacks
has
been
executed
already,
and
I
just
wonder
why
why
we
want.
I
mean
I
understand
from
from
point
of
view
that
we
want
this
things
that
work
in
in
the
co-op
should
work
with
group
group
co-op
as
well,
but
I
just
wonder
that
if
there
would
be
a
version
two
of
co-op,
then
I
would
ask
the
same
question:
why?
Why
do
we
have
it
now
security
mode.
D
B
C
Yeah,
I
mean
that's,
I
think,
that's
reasonable,
but
why
why?
Why
wouldn't
if
you
want
to
apply
group,
combats
like
that,
surely
you
you
could
do
that,
but
why
do
we
in
the
specification
write
that
there
is
no
segment?
Why
do
we
allow
it?
I
mean
people
may
deviate
from
specifications
if
they,
if
they
know,
if
it's
an
isolated
network
or
does
it
matter
if
they
deviate
from
from
or
maybe
yeah.
C
A
C
B
There
is
no
aspect
of
amplification
unless
there
is
a
great
number
of
those
devices
deployed,
in
which
case
you
have
these
have
to
coordinate
anyway,
and
then
some
of
them
can
decide
not
to
join
the
group,
but
kind
of
negotiate
with
each
of
the
ones
is
the
one
that
kind
of
responds
first
and
the
others
are
just
fall
back.
Failure
whatsoever.
C
C
A
D
That
sorry,
okay,
there's
a
difference.
Of
course.
Now
so
john
was
mentioning
that
even
security
yeah,
we
still
have
issues
left.
Basically,
we
are
now
talking
about
no
second
mode
used
for
discovery.
That's
because
it's
discovery.
You
typically
have,
by
definition,
no
security
context
to
start
with,
find
out
example,
find
your
book
manager
and
decline
as
well
find
another
node
that
offers
certain
services,
but
that's
a
bit
of
the
problem.
Today,
you
accounted
by
a
score
solution.
D
C
D
D
B
C
A
A
A
Transferring
that
the
disco
mentioned
before
involved
involved,
especially
the
overall
response
caching
model
for
the
proxy
that
has
now
been
moved
into
this
document,
and
the
important
thing
here
is
that
proxies
other
than
a
good
configuration
on
their
side
are
also
required
to
clearly
identify
a
client
that
wants
to
send
the
request
out
to
a
group
which
implies
client
and
proxy
need
to
have
a
kind
of
security
association
that
opens
interesting
things
for
for
later,
so
quickly.
It
works
with
the
with
the
two
options.
A
The
client
also
includes
this
new
option:
multicast
signaling,
so
confirming
to
the
proxy
that
the
client
knows
what
it's
doing
and
what
he
wants,
and
the
option
also
has
a
time
indication
to
tell
the
proxy
for
how
long
to
collect
responses
to
be
forwarded
back
to
the
client
and
the
proxy
will
remove
this
option
before
forwarding
the
request
to
the
servers.
So
nothing
really
changes
for
the
for
the
servers.
A
A
So
what
we've
done?
As
mentioned
in
the
previous
presentation,
a
lot
of
content
was
moved
here.
The
general
caching
model
and
the
response
revalidation
exactly
between
the
client
and
the
proxy,
so
above
above
other
points.
These
two
points
where
before
in
group
convince
reasons
to
update
rfc
7252
and
having
moved
them
here,
they
are
making
this
document
also
eligible
to
to
update
the
cost
specification
and
like
group
compass,
was
doing
in
fact
before
this.
A
A
A
It
is
also
ready
to
be
accessed
by
a
client,
and
then
there
is
an
aggregated
cache
entry
that,
in
a
sense,
covers
the
the
whole
group
of
servers
where
the
responses
to
a
group
request
coming
from
any
server
in
the
group
are
kept,
and
it
can
possibly
be
up
to
date
by
a
response
coming
from
one
server
in
the
group,
but
as
a
reply
to
a
request
intended
only
for
that
server
too,
which
makes
it
interesting
how
you
update
the
overall
lifetime
of
the
aggregated
cache
entry.
This
is
documented
too.
A
Basically,
it's
something
we
wanted
to
do
all
along,
but
it
wasn't.
It
wasn't
clear
enough
in
the
text
and
the
proxy
is
indeed
proposed
to
forward
forward-back
responses
as
they
come
and
and
possibly
update
the
aggregated
cache
entry.
Only
when
the
indicated
time
interval
indicated
by
the
client
expires
and
all
responses
are
supposed
to
have
come
and
that's
when
the
entry
is
also
updated,
and
the
second
point
is
instead
what
you've
mentioned
now.
A
I
think
your
suggestion
is
to
start
with
caching
at
the
client
that
we're
leaving
group
this
lot
like
esther
showed,
and
then
you
mentioned
okay,
something
similar
should
happen
also
for
for
the
aggregated
cash
entry,
but
perhaps
something
more
can
be
done
and
at
least
in
the
it
was
copy
with
cash.
Something
like
that
you
can
think
of
a
proxy
that
has
a
lot
of
knowledge
in
real
time.
C
A
I
think
christian
was
opening
even
for
for
forgetting
about
it
right
now.
It's
defined
with
this
kind
of
say
rules,
because
the
only
conclusion
was
we
need
rules
on
the
best
way
to
handle
it,
and
the
impression
was
that
under
some
hypothesis,
it
can
work
well
and
if
the
hypothesis
are
not
met
just
better
to
not
have
it,
which
is
what
we
are
trying
to
describe
now.
C
B
Yeah,
I
think
I
think
this
will
need
a
bit
of
alignment
with
with
the
other,
with
the
other
document,
because
yeah
kind
of
not
now
that
we
have
the
statement
that
we
have
the
document.
This
can
kind
of
the
practical
implications
would
still
be
the
same,
because
the
proxy
might
know
that
hey
devices
only
join
say
every
at
midnight
or
every
five
minutes,
and
and
then
we're
back
to
practically
this.
But
it
can
be
phrased
in
a
more
precise
way.
A
D
Yeah
exactly
so,
it
would
be
good
in
this
draft
or
maybe
explicitly
explain
those
kind
of
typical
use
cases,
and
then
this
yeah
second
bullet.
This
was
the
five
minute
example.
So
if
probably
knows
that
group
members
can
only
join
five
minutes
or
every
day
or
if
it
knows
that
for
the
application
you
can
ignore
the
servers
that
joined
in
the
last
10
minutes.
Let's
say
something
like
that
as
well.
D
B
We
should
try
to
avoid
having
special
rules
that
apply
to
proxies
that
don't
work
just
as
well
also
for
the
client
caching
case,
and
if
we
need
something
better
than
you
can
have
out-of-band
knowledge
of
where
the
rotary
of
of
which
members
may
or
may
not
have
joined.
Then
maybe
this
should
better
be
in
in
group,
compass
and
here
just
kind
of
pointing
towards
that.
D
A
B
From
the
client
thing,
the
aggregate-
the
aggregate
entry
is
nothing
more
than
a
pointer
to
the
to
the
cached
states.
We
have
so
if
and
now
that
the
the
requirement
has
come
in
from
the
client
side
or
maybe
kind
of
maybe
we
can
reshape
it,
but
in
some
way
the
client
knows
what
the
servers
are,
which
servers
are
they're
expected
to
be,
then
the
aggregate
kind
of
state
vanishes
into
something
that
has
no
state,
because
we
know
somewhere
else.
What
members
are
there
and
we
know
in
the
cache
what
their
individual
contents
are.
C
C
D
A
For
the
matter
of
phrasing,
it's
probably
easier
to
just
not
consider
an
explicit
aggregated
cache
entry,
but
thinking
instead
of
a
group
request
from
a
client
may
hit
all
the
individual
already
existing
cache
entries
at
the
proxy,
because
a
client
friendly
to
this
would
have
already
a
knowledge
of
the
whole
set
of
servers
in
the
group.
Anyway,
if
I
got
christian
correctly
yeah,
okay,
so
the
functionality
is
interesting
to
have
under
some
hypothesis,
it
can
be
presented
in
a
more
efficient
way.
C
A
D
D
So
this
talks
about
http,
2,
co-op
proxies
and
it
defines
a
nice
way
of
encoding
a
corp
request
in
a
uri
uri,
that's
included
in
a
request
to
the
proxy,
whereas
an
example
here
in
the
second
bullet,
just
to
show
that
so
in
this
case
it's
not
a
http
proxy,
but
it's
ready
for
the
color
proxy.
So
it's
called
access
from
btls
myproxy.example.com
and
it
has
a
resource
and
slash
p.
D
D
D
D
It's
a
customizable
template,
so
that
can
all
be
done
also
for
the
co-op
to
co-op
proxy
case
and
also
for
yeah
in
this
case
co-op
two
chord
group
box
here
I
listed
also
some
alternatives
here.
So
there's
the
light
green
line
and
the
purple
line,
and
that's
for
reference,
that's
how
to
do
it
by
an
http
proxy.
It's
also
going
through
another
resource,
slash
ac.
D
So
one
question
is:
can
the
multicast
signaling
option
be
received
by
the
first
boxing
and
then
also
used,
so
it
uses
the
sample
the
timeout
there
to
time
the
group
request
we
assume
the
answer
is:
yes,
that's
not
not
necessarily
a
forward
proxy
that
in
principle
a
reverse
box.
You
can
also
do
that,
and
second
question
was:
can
the
response
forwarding
option
be
used
also
by
reverse
proxy
and
there
we
assume
a
similar
way
that
the
answer
is
yes.
D
D
It
would
be
useful
to
allow
that
at
least
that's,
because
the
option
is
an
elective.
It
means
that
a
client
that
doesn't
know
anything
about
these
signaling
options
gets
the
response.
Forwarding
option
can
safely
ignore
it
and
that's
what
it's
co-op
implementation
will
also
do
in
this
case.
There's
no
harm
done.
D
D
B
D
Yeah,
so
we
I
think
we
discussed
that
before
so.
One
assumption
is
that,
okay,
you
have
a
client
that
is
accessing
this
proxy
and
you
must
at
least
be
aware
at
some
level
that
it's
accessing
proxy
and
that's
it's
accessing
a
group
resource,
especially
if
you
look
at
the
example
above
yeah.
So
that's
very
clear
that
the
client
knows
what
he's
doing
he's
even
encoding,
specifically
right,
not
necessarily.
B
So
the
thing
is
that
your
that
reverse
proxy
uri
might
have
been
passed
to
the
client
by
some
other
by
some
other
party.
So,
for
example,
there
might
be
a
dime
link
pointing
to
that
resource,
and
the
client
has
no
idea
that
there
is
kind
of
that.
This
thing
in
there
is
a
is
a
is
a
is
a
uri
on
its
own
actually.
D
B
I
you
know,
I
think
that
the
kind
of
the
the
options
are
the
same
as
with
the
regular
proxy.
The
kind
of
the
easiest
thing
is
to
say:
yeah.
Sorry,
error.
That's
a
request
that
kind
of
request.
I
can't
process
to
that
to
the
requested
uri.
It
might
also
use
some
kind
of
application,
specific
aggregation.
D
Yeah:
okay,
that's
what
we
have
currently
yeah
so
and
depending
yeah.
You
need
to
depend
on
this
signaling
option.
Yeah.
I
was
thinking
for
the
reverse
proxy
case,
so
that
it's
something
we
don't
discuss
in
detail
yet,
but
what
we
can
actually
say
for
the
security
reasons
to
meet
the
expectations
of
the
client.
D
D
Yeah,
I
was
thinking
you
you
can,
as
a
client
also
include
the
option
without
a
specific
value.
I
think
it's
it's
a
viewing
option,
so
that
would
make
the
value
zero
yeah.
You
could
say
one
example:
a
zero,
a
meaning
as
okay,
you
figure
out
time.
I
don't
know
that
only
works
in
a
reverse
proxy
case
or
who
can
determine
a
sensible.
B
B
In
this
and
on
the
on
the
topic
of
whether
the
reverse
proxy
can't
send
a
reverse
forwarding
option
in
responses,
even
without
a
multicasting
link,
which
would
be
the
case
if
it
kind
of
fall
for
only
one
option,
I
think
in
kind
of
in
in
theory-
yes,
but
we
should
carefully
evaluate
this
against
other
ways
of
introducing
this
would
be
in
effect
introducing
lysine.
Now
this
is
okay,
because
that's
what
a
reverse
proxy
does,
but
this
might
need
coordination
with
critical.
C
B
Okay,
that's
what
you
meant
by
this,
because
I
mean
this
could
just
as
well
the
proxy
the
address
could
just
as
well.
I
I
thought
I
understood
this
third
point
to
indicate
that
if
the
request
in
there
happens
to
be
a
unicast
address
and
a
multicast
signal,
option
may
or
may
not
be
have
been
added,
then
the
the
proxy
might
still
include
that
response
forwarding
option,
and
that
would
be
basically
like
saying
yes,
but
by
the
way
my
host
name
is
actually,
and
that
would
mean
for
the
consideration.
D
A
A
A
So
the
conclusion
from
itf
110
was
that
this
is
only
one
of
a
few
more
use
cases
where
something
like
this
is
needed,
and
anyway
it's
some
work
that
requires
to
have
a
bit
more
attention
and
configuration
for
proper
analysis
and
design.
So
we
agreed
to
take
it
out
from
this
document
and
have
it
as
a
separate
draft
of
which
we
are
about
to
finalize
a
version
zero.
A
So
thinking
of
the
proxy
as
a
client,
so
most
likely
will
converge
again
to
an
adapted
version
of
the
simple
introduction
and
and
then
we
still
have
the
relatively
old
issue
that
keeps
staying
behind
because
more
urine
things
continue
coming
up
about,
enabling
this
same
mechanics
and
signaling
protocol
in
case
our
proxy
is
an
http
to
co-op
proxy
and
that
ultimately,
would
enable
an
http
client
to
talk
through
the
proxy
to
to
a
group
of
web
servers.
So
we
had
a
rough
idea
how
to
do
that.
A
A
B
So
if
you
have
strong
kind
of,
if
you,
if
things
come
up
with
with
users
that
you
talk
to
again
and
again
or
you
just
want
to
look
at
what
is
out
there,
what
are
questions
that
come
up,
especially
if
you
have
opinions
that
might
kind
of
differ
from?
What's
in
there
look,
there
start
discussion
or
just
edit
it,
because
it's
a
wiki
and
it's
not
supposed
to
be
authoritative,
but
just
contains
a
few
kind
of
common
pitfalls
and
and
things
that
and
patterns
that
emerge.
B
In
what
sort
of
specifically
pretty
general
co-op
stuff,
so
there
are
things
like
do
you
I
mean
there
are
also
controversial
questions
and
they're
like
do.
I
have
to
send
a
uri
host
option
or
not,
which
is
to
me,
was
the
most
common
question.
I've
heard
about
yeah:
do
you?
How
do
you
do
redirect?
Why
do
you
have
plain
text
responses
to
errors
when
this
is
super
wasteful
on
the
on
a
constraint
device
things
like
that?
How
how
do
I
send
incremental
updates
over
an
observation
you
don't?
B
But
this
is
why
okay
thanks,
but
trying
to
capture
what
I
think
kind
of
emerges
as
things
that
you've
come
across
when
you've
been
on
the
core
mailing
list
for
some
time,
but
newcomers
might
not
kind
of
you.
You
can't
get
it
from
the
archive.
You
have
to
be
part
of
the
discussion
or
have
someone
digest
that.