►
From YouTube: IETF112-HTTPAPI-20211112-1200
Description
HTTPAPI meeting session at IETF112
2021/11/12 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
B
B
Okay,
we'll
start
I'll.
Do
the
overhead
daryl
will
steer
the
content
welcome
to
the
first
session
of
the
last
day
of
yet
another
virtual
ietf?
Thank
you
all
for
coming.
B
B
C
C
B
B
B
Pardon
me:
it's
a
reminder
of
the
policies
and
practices
for
intellectual
property,
contributing
at
the
ietf.
A
contribution
is
speaking
up,
saying
something
writing
on
the
mail
list,
personal
information.
We
have
a
policy
privacy
policy
that
we
take
very
strongly
and
try
to
you
know
follow
second
page
of
the
note.
Well,
pardon
my
throat
is
links
to
the
documents,
as
francesca
pointed
in
the
slides
that
you
can
find.
B
One
thing
to
know
is
the
bcp
things:
if
you
haven't
seen
them,
they
are
indirect
references
to
rfcs,
bcp
9
in
particular
means
oh,
these
following
eight
rfcs,
maybe
that'll
get
updated
at
some
point,
but
anyhow
the
current
note.
Well,
the
note
really
well
pardon
me
this
session,
the
iesg,
the
technical
leadership
of
the
ietf,
has
really
asked
working
chairs
to
emphasize.
B
B
If
you
have
a
dis
disagreement
about
ideas,
use
judgment,
don't
just
say:
oh,
that
idea
is
stupid
and
how
could
you
have
thought
of
it?
The
goal
is
to
use
your
best
engineering
judgment
and
find
a
solution
that
works.
Pardon
me
for
the
whole
internet,
certainly
having
things
deployed,
shows
proof
of
concept
at
least,
but
it
may
not
be
applicable
to
everyone,
and
the
goal
here
is
really
to
get
everyone
to
contribute
to
the
ongoing
work
of
this
working
group
of
all
the
working
groups
and
the
ietf
and
whole
over
as
a
whole.
B
B
B
B
Please
mute
your
mic
unless
you're
speaking
and
the
controls
for
all
of
the
controls
for
all
of
that
sure,
most
of
you
aware
by
now
are
in
the
upper
left
hand
corner
just
above
the
chat
dialogue
on
the
left
hand,
side,
you're,
encouraged
to
use
headset,
earbuds
and
so
on.
It
tends
to
be
a
better
sound
quality,
the
blue
sheets
or
the
blue
she's,
whatever
they
are,
are
automatically
generated
by
meat
echo.
B
B
Should
we
ever
be
able
to
go
back
to
that?
Hopefully
they
are
also
have
been
used
periodically
when
people
sue
the
iatf
about
patents.
Oh
so-and-so
was
here.
He
never
said
anything
well,
here's
the
list
that
shows
they
were
there,
but
think
of
it
mainly
as
capacity
planning
for
the
future
chat
rooms
in
meet
echo.
The
bar
on
the
left
are
connected
to
the
jabber
chat
rooms
that
are
listed
in
the
data
tracker
agenda.
B
So
if
you
go
to
dt.iatf.org
wg
for
working
group,
slash
http
api,
you
can
see
the
chat
room.
There
is
a
meet
echo
guide,
it's
from
the
previous
ietf
session.
B
Agenda
first
part
is
administrative:
oh
yeah
acme.
The
note.
Well,
that's
the
few
pages
that
we
just
covered
minute
taker
braun
has
gwanda,
has
asked
as
offered
to
take
minutes
he'll
be
doing
it
at
notes.ihf.org
notes:
ietf112
http
api,
not
acme.
B
D
Can
you
hear
me
yes
excellent?
So
this
is
just
a
heads
up
about
a
draft
that
is
in
the
http
working
group.
It's
it's
for
a
new
http
method.
D
Originally
this
was
we
were
reusing,
the
search
method,
which
was
an
old
web
dev
method,
but
the
most
recent
version
of
the
draft
changes
that
for
queer,
where
we
thought
that
had
a
little
bit
better
ergonomics
and
it
was
more
clear
that
it
wasn't
just
for
web
dav
and
so
we're
trying
that
out
to
see
how
that
goes
and
see
if
people
like
it
and-
and
so
this
is
a
new
http
method
that
is
has
similar
semantics
to
get
in
that
it's
safe
and
item
potential,
but
it
allows
you
to
put
a
a
request
body
on
the
get
which
http
either
doesn't
allow
or
extremely
strongly
discourages,
and
we
know
that
some
people
out
there
are
using
gets
with
bodies
because
they
want
certain
attributes.
D
They
don't
want
to
put
some
data
in
the
url
or
you
know
it.
It
might
be
that
the
url,
the
data
they
want
to
send
is
really
long
and
they're,
not
sure
that
it's
going
to
be
url.
Is
that
longer
to
be
handled?
And,
of
course,
if
you
want
to
put
some
kinds
of
data
in
a
url,
it
has
to
be
encoded,
and
so
for
various
reasons.
People
want
to
to
do
this,
but
they
still
want
it
to
be,
for
example,
cacheable
they
want
to.
D
They
want
those
get
semantics,
and
so
this
method
is
designed
to
kind
of
fit
that
niche
to
allow
a
safe
and
unpotent
and
cashable
request,
potentially
cashable
request
to
be
expressed
with
a
body
and
and
so
the
most
recent
version.
We
introduced
caching
semantics
for
it
to
some
guidelines
of
how
caches
should
treat
it.
We
change
from
search
to
query,
as
I
mentioned,
and,
and
I'm
talking
about
it
here,
because
the
the
probably
the
biggest
use
case
for
this
method
is
folks
using
http
apis.
D
I
know
that
I
think
elasticsearch
uses
get
with
bodies
in
this
fashion
and
a
few
other
folks
do
too.
So
if
you
know
of
apis-
or
you
have
apis
that
need
these
semantics,
we'd
really
be
keen
to
have
your
feedback
over
in
the
http
working
group,
because
we'd
like
to
make
sure
that
we're
on
the
right
track
with
it.
D
D
E
Hey
mark
yes,
sorry,
I've,
just
you
know
seen
this
so
just
you
know
to
say
absorbing
what
you
just
said.
There's
nothing
here.
I
I
hope
and
knowing
you
I'm
sure,
it's
true
there's
nothing
here
that
defines
the
format
of
that
query.
It's
just
I'm
sending
you
a
query.
Here's
some
stuff
that
I'm
hoping
you
understand.
D
Right-
and
this
actually
falls
into
a
similar
pattern
that
we
had
with
patch,
we
defined
the
patch
method,
but
we
didn't
find
it
to
find
any
patch
formats
and
so
it
you
know
that
was
unfortunate,
especially
for
patch
people
needed.
You
know,
application
specific
patch
formats.
We
eventually
came
up
with
jason
patch
and
a
few
others
came
down
the
pike,
jason
margepachen,
and
maybe
one
or
two
others.
But
the
question
is
whether
we
need
a
common
query
format
for
this
method.
D
You
know
there
are
different
kinds
of
constraints
you
might
want
to
make
we're
just
giving
you
a
method
to
do
that
in
so,
but
it's
a
good
question,
and
certainly
if
somebody
comes
up
with
a
draft
for
a
standard
and
really
interesting,
query
format,
that's
something
I
hope
the
ietf
would
consider
taking
on.
E
Yeah
it
was,
it
was
really
the
fact
that,
in
the
query
string,
you
have,
you
know,
name
value
pairs
here,
you've
written
a
sql
query,
so
that
sort
of
indicates
that
well,
you're
thinking.
This
is
how
you
put.
This
is
how
you
send
a
sql
query,
which
may
or
may
not
be
what
you
intended,
but
that's
the
impression
I
get
by
seeing
something
that
has
a
recognizable
format
of
your
query
makes
me
think
uh-huh.
This
is
what
you
want
to
do.
D
D
Yeah,
the
query
could
be
anything
it
could.
It
could
just
be
a
you
know,
name
value
pairs.
You
know
in
the
in
the
common
query
format
that
we
we
see.
I
guess
the
interesting
thing
here
is
is
that
it
is
kind
of
mirroring
that
lack
of
definition
in
the
uri
query
string,
because
although
everybody
in
the
world
seems
to
think
that
you
know
the
query
format
in
uris
and
httpr's
is
fixed
to
you
know
key
equals
value
and
key
equals
value
and
key
value.
That's
not
true!
D
That's
standardized
by
html
and
specific
to
html,
it's
just
that
it
became
really
popular
and
and
so
it
could
be,
the
same
thing
happens
here.
Maybe
somebody
will
come
up
with
a
great
query
format.
We
don't
know.
B
D
This
is,
is
you
know
if
we
had
a
better
name
that
was
more
generic?
I
think
we'd
take
it.
We
were
concerned
that
search
was
too
specific.
The
the
nice
thing
about
query
is
is
that
it
mirrors
the
query
string
in
a
uri
and
that's
how
often
people
are
using
this.
They
they
just
don't
want
to
put
it
in
the
query
string
they
want
to
put
in
the
body,
and
so
that's
kind
of
a
hint
that
hey,
if
you
could
put
the
query
string
and
you
want
to
put
the
body.
D
This
is
the
method
you
should
use.
You
know
we
could
also
call
this
method
get
underscore
with
underscore
body
if
we
really
wanted
to.
But
you
know,
that's
not
the
direction
we
took
in
the
current
draft.
Okay.
I
I'm
not
familiar
enough
with
that
me
to
answer
the
question
specifically,
but
it
sounds
like
they
could
use
it.
B
All
right
yeah,
I
mean
you
know
if
you
were
fat
cat.
I
like
that
fact.
Yeah,
if
get
with,
if
get
with
body
makes
you
know,
is
not
out
of
line.
Then
I'll
mention
this
to
the
acme
folks
sure.
F
D
D
Daryl,
oh,
okay,
sorry
daryl,
daryl's
great
too.
So
this
is
a
draft
that
I
put
together
a
very
long
time
ago,
and
it
was
just
you
know,
almost
a
thought
experiment
to
say.
Well,
you
know
the
link
header.
I
think
it
was
around
the
time
that
we
did
the
link
header
the
first
time
in
rfc
598,
and
you
know
it's
like
well.
D
We
have
links
in
in
headers
and
we
have
this
framework
to
put
links
and
headers
what
you
know
why
and
then
we
had
ui
template
come
along,
which
was
me
and
a
few
other
folks,
roy
and
dave
and
someone
else.
We
put
together
the
ui
template
format,
and
so
this
was
just
a
thought
experiment
to
say:
well,
you
should
probably
be
able
to
put
uri
templates
into
links
as
well
into
into
headers,
so
that
you
can
do
interesting
things
and
especially
since
the
web
is
supposed
to
be
generative.
D
You
know
this
is
that
that's
a
really
nice
property
here
that
you
can
convey
the
template
for
something
and
then
the
client
can
generate
new
uris
based
upon
the
information
you
give
it,
and
so
this
was
a
an
attempt
to
do
that
and
I
very
purposefully
didn't
push
it
very
hard.
I
wanted
to
see
if
people
were
interested
before
I
you
know
did
anything
with
it.
D
I
got
a
few
sniffs
of
interest
over
the
years,
but
but
recently
it
seems
like
I've
seen
a
lot
of
people
come
across
and
say:
oh,
that's
something
I
need
or
say.
Can
we
have
this
without
realizing
that
this
draft
is
already
there,
and
so
I
guess
the
question
is:
is
there
enough
interest
to
maybe
pushed
across
the
line?
Now?
D
I
think
there
are
a
couple
of
open
issues
in
my
repo
about
this.
One
of
them
being.
D
You
know
people
have
asked
what
vera
base
is
for,
and
some
people
are
confused
by
another
say
that
could
be
useful,
so
we
probably
need
to
at
least
clarify
something
there
and,
and
there
I
think
the
other
big
issue,
if
I
remember
correctly,
is
that
it's
a
good
question
as
to
whether
we
should
use
structured
headers
for
this
or
structured
fields,
rather
rather
than
duplicating
the
somewhat
wonky
link,
syntax
and
and
increasing
the
amount
of
monkey
headers
in
the
world.
D
But
I
guess
the
question
right
now
is
not
you
know
how
to
address
those
issues.
The
question
is:
is
there
interest
in
adopting
this
in
the
working
group.
E
Thanks
my
point
of
view:
yes,
I
think
this
fits
very
well
with
what
we're
doing
with
gs1
digital
link.
I'm
worrying
you
know,
especially
in
this,
in
this
environment
god.
This
is.
This
is
like
being
in
lots
of
standards
bodies.
We
talk
about
the
huge
cultural
differences
and
the
fear
that
a
lot
of
people
have
of
looking
idiot
in
front
of
their
peers,
so
with
great
trepidation.
E
Right,
my
in
front
of
you,
I'm
going
to
make
yourself
look
an
idiot
one
of
the
link
relation
types
we
use
in
our
work
says:
don't
ask
me,
ask
him,
in
other
words
a
general
redirect
that
says.
I
know
what
you
want.
I
understand
what
you
want,
but
I'm
not
the
person
to
ask,
go
and
ask
them
and
the
link
relation
type
we
have
for
that
is
called
handled
by
the
query.
You're
asking
me
is
handled
by
them
over
there.
E
D
I
I
don't
know
enough
about
the
specifics,
but
conceivably
yeah,
you
could,
you
know,
generate
a
uri
over
there
to
you,
know
and
kind
of
pass
some
information
along
with
it,
yeah,
so
that
you
know
that
you,
you
can
possibly
avoid
a
round
trip,
which
is
always
nice.
A
I
think
the
example
that
always
comes
to
mind
for
me,
for
this
is
you're,
making
a
request
for
something
that
returns
a
long
list
of
things,
and
you
won't
be
able
to
have
links,
construct,
links
for
off
each
of
those
things
so,
rather
than
embedding
link
the
like,
basically
duplicate
links
in
every
single
item
in
the
list.
This
template
would
give
you
a
way
of
being
able
to
generate
links
for
any
of
the
items
in
the
list.
H
I
don't
have
a
whole
lot
to
add,
but
I
think
this
work
is
useful.
I
think
the
problem
is
well
scoped
and
worth
doing.
I
support
this
particular
approach.
D
B
D
Could
do
a
call
for
adoption
if
you
wanted
to?
I
think
I
could
I'm
happy
to
noodle
away
on
it,
but
I'd
rather
get
people's.
You
know
feedback
and
make
it
part
of
an
open
conversation
rather
than
me
just
continuing
to
noodle
at
it.
B
F
F
Oh,
I
sent
one
too
rich
but
anyway,
so
in
that
case,
I'll
do
screen
sharing.
Okay,
I
missed
it.
I
apologize
it
doesn't
matter
it's
just
because
the
last
time
it
was
not
perfect.
F
B
You
have
to
go
on
the
pre
share
screen
on
the
upper
left.
After
you
got
permission.
B
F
F
F
F
The
idea,
pretty
simply
said,
is
to
say
the
links
that
can
be
represented
in
a
link.
Header
field
and
http
also
should
be
able
to
be
represented
as
as
a
resource
as
a
standalone
resource,
and
we've
been
working
on
that
for
a
while.
We
define
two
media
types.
One
of
them
uses
the
syntax
of
rfc8288,
which
is
the
normal
syntax.
F
Everybody
is
used
to
for
links
in
the
http
context
and
the
other
one
which
took
a
little
bit
more
creativity
so
to
speak,
is
a
json
based
representation
which
is
intended
to
represent
the
model
of
rfc
8288,
but
does
so
in
json,
so
that
people
use
two
processing,
json
and
easier
time
processing.
Those
link
sets-
and
I
again
I
won't
go
through
all
of
this.
I
think
we've
seen
that
in
previous
meetings.
F
Very
broadly
speaking,
it
looks
like
this.
This
is
a
json
example,
so
this
is
one
of
these
link
sets.
In
that
case,
it
has
two
links
in
it.
Two
anchors
link
relationships
of
next
and
it's
http,
example.com
relations
buzz
and
then
two
link
targets
and
since
we've
working
on
that
for
a
while,
already
there
actually
are
implementations
out
there.
Already,
probably
the
biggest
one
is
gs1.
F
Since
the
last
meeting,
we
have
produced
a
number
of
new
versions,
so
we're
currently
kind
of
working
on
our
six,
but
o5
is
the
one
that's
currently
being
published
or
it's
currently
published.
We
have
addressed
26
issues
we
have,
I
think
we
have
discussed
all
of
them
appropriately.
At
least
we
haven't
had
any
complaints
that
people
said.
You
didn't
address
that
and
we
are
at
zero,
open
issues.
So,
in
our
mind,
we're
actually
looking
pretty
good.
We
had
some
discussions
already
on
the
list.
G
F
Very
good
input
from
mark
had
a
lot
of
input
for
us
and
we
had
some
other
reviews.
I
think
daryl
also
gave
us
a
couple
of
inputs,
so
we
did
get.
I
think,
a
good
set
of
inputs
from
the
community.
G
F
And
we
think
we've
addressed
them
and
then
currently
we
have
no
open
issues.
We
have
added
a
couple
of
things,
so
we
added
support
for
profiles.
We
also
added
the
ability
to
have
newline
characters
in
the
in
the
syntax
that
use
the
http
header
field,
syntax,
because
that
makes
things
a
little
bit
more
readable,
better
formatted,
and
if
you
have
those
as
text
files,
we
also
worked
a
little
bit
on
the
extensibility
model.
F
That
also
were
some
issues
around
that
how
that
is-
and
we
also
had
to
work
a
little
bit
on
the
json
ld
mapping,
editorial
updates
and
where
we
are
now
is.
As
I
said,
we
have
published
version
number
five
of
this
draft,
so
we
we
have
had
many
more
versions,
because
we
also
have
kind
of
a
history
of
transitioning
between
different
versions.
So,
overall
we
had
17
versions
of
that
draft
in
the
meantime,
so
it
has
been
around
for
quite
a
while
and
that's
about
it.
F
So
so
the
one
thing
that
is
still
open,
but
that
is
not
really,
I
would
say
something
that
is
specific
to
our
specification,
but
with
the
json
ld
mapping.
The
problem
is
that,
if
you
map
what
else
json
lc
does
for
those
of
you
who
don't
know
it
so
well,
jason
ld
defines
a
way
how
you
take
json
representation
and
basically
turn
it
into
rdf,
and-
and
we
can
do
that.
F
So
the
extension
link
relation
types
are
these
uris,
which
is
something
that
rdf
can
work
with,
but
the
registered
link
relation
types
are
just
strings,
and
that
means
that
it
is
a
problem
to
turn
that
into
a
proper
rdf
model,
because
rdf
is
realistically
constrained
and
what
it
can
deal
with
as
identifiers,
because
identifiers
always
have
to
be
your
eyes,
and
in
that
case
the
identifier
is
not
a
uri,
it's
just
a
string.
So
that
is
the
one
kind
of
open
issue.
F
But,
as
I
said,
there
is
nothing
in
my
mind
that
you
can
easily
do
about
that,
because
that's
just
kind
of
an
incompatibility
of
how
the
mechanism
works
for
links
with
with
these
strings
as
registered
values
and
with
what
json
ld
needs
as
identifiers,
which
are
your
eyes,
and
these
two
things
just
fit
together.
But
apart
from
that,
apart
from
that,
we're
done
I'll,
stop
sharing
my
screen
here
so
yeah,
that's
the
status
on
link
set.
F
A
A
B
Right
so
I
see
phil's
commented
that
it's
currently
implemented
by
the
sacrifice
of
goat
no
mark.
We
don't
do
that
anymore.
The
ietf's
new
rules
are
vegans,
so
okay,
so
the
process
is
first
of
all,
thanks
eric
and
others.
For
your
patience,
often
the
way
things
work
right,
like
probably
most
of
life
ietf,
is
deadline.
Driven,
so
someone
says
here's
my
new
draft
and
I
think
it's
all
done,
and
then
people
come
out
of
the
woodwork
and
they
make
a
whole
bunch
of
corrections
or
suggestions,
issues
that
have
to
be
dealt
with.
B
B
We
will
issue
on
the
list.
A
working
group
last
call
we'll
decide.
You
know
it's
typically
one
or
two
weeks
and
then
what
happened.
That's
sort
of
a
last-minute
chance
for
people
to
say.
Oh
this,
this
issue,
I
just
thought
of
this
issue
now:
okay,
sean
we'll
do
two
weeks
so
we'll
do
a
two-week
last
call
yeah,
especially
because
it's
getting
into
the
us
thanksgiving
holidays.
B
So
we
do
a
working
group
last
call.
This
is
the
last
chance
for
the
working
group
quote
unquote
last
chance
for
the
working
group
to
make
substantive
changes
and.
B
B
Who
is
in
the
chat,
francesca
halumba,
saying
her
last
name
wrong.
The
shepherd
writes
up
in
essence
a
history
of
how
it's
been
the
discussion.
That's
thank
you.
Francesca,
palombini.
Okay,
sorry
writes
up
history.
There
is
a
format
to
follow.
You
know
what
is
the
intended
use
of
this?
It's
a
proposed
standard.
B
B
B
Then
the
most
important
thing
is
you
get
to
what's
called
auth
48,
which
is
48
hours
48
days,
48
weeks,
depending
where
the
rfc
editor
looks
at
it
and
they
make
editorial
nitpicky
suggestions,
hey
you
said
was,
and
you
should
say
where
or
things
like
that,
it's
it's
really
english
language
wordsmithing
and
then
it
gets
published.
But
the
point
is
once
it
leaves
once
the
iesg
approves
it
and
the
less
ietf
less
call
has
happened.
B
Then
the
boss,
the
document
is
basically
done,
and
you
can
say
this
is
now
in
the
queue
to
be
published
as
an
rfc.
That
last
process
takes.
You
know,
given
the
holiday
year
end
season,
the
isg
might
be
a
little
slower
than
we
than
usual,
and
the
publication
system
is
they're
back
up
to
their
normal
speed.
Now
having
gotten
over
the
xml
v3
conversion
pump,
so
it
should
be
fairly
straightforward.
B
B
B
F
Just
a
very
brief
question
so
so
we
did
start
version
six,
which
has,
I
think,
super
minor
editorial
changes,
but
should
I
then
publish
that
one
so
that
we
have
kind
of
the
latest
and
greatest
version
out
before
you
do
the
writer.
B
You
all
right
great,
that's
well,
first
with
the
slides
and
first
and
to
last
call.
B
A
Thanks
for
the
explanation,
rich,
okay,
so
if
we
want
to
slide
to
the
next
slide,
what
I
did
is
I
took
each
of
the
the
documents
that
are
currently
going
through
the
working
group
and
went
to
the
github
issues
and
found
what
appeared
to
be
the
most
contentious
issues
so
that
we
could
just
surface
them
here
and
get
any
other
conversation
and
encourage
folks
to
go
to
those
get
up
issues
if
they
have
strong
opinions.
A
Looking
at
rfc,
7807
biz,
the
two
main
issues
that
seem
to
be
attracting
the
most
attention
was
this
conversation
around
how
to
integrate
warnings
and
there
seems
to
be
two
distinct
threads
of
conversation,
one
which
is
around
well.
How
do
I
describe
a
use,
the
hp
problem
to
describe
what
is
actually
a
warning
and
the
other
being
well
yeah.
I
want
to
do
a
regular
request
that
comes
back
with
a
response,
but
also
attach
a
warning,
and
I
believe
the
the
latter
suggestion
or
the
latter
issue.
A
We
are
punting
to
either
a
future
spec
or
a
separate
spec,
but
I
will
let
mark
speak
to
that
as
he
jumped
into
the
queue.
D
Yeah,
I
I
just
closed
this
one,
because
the
the
conversation
seemed
to
conclude
that
that
would
be
okay.
If,
if
we
need
to
reopen
it,
that's
fine
it
just
that
seems
like
the
date
we
were
in
so.
A
The
the
second
issue
is
the
multiple
problems
and
I
believe
sanjay
has
created
a
pr
based
on
a
suggestion
that
was
made
in
the
thread
that
says
it's
a
certain
type
of
error
that
has
the
potential
for
multiple
reasons
why
it
occurred
within
single
request
and
that
describes
that
uses
the
extension
capabilities
of
hp
problem
to
list
out
a
set
of
causes.
A
This
wouldn't,
if
I
understand
correctly,
this
isn't
actually
won't
need
to
actually
be
part
of
the
spec
itself.
It's
just
using
the
natural
extension
mechanisms
of
the
spec.
Is
that
correct.
F
D
So
I
think
the
place
we
ended
up
here
was
that
we
decided
to
to
document
some
more
examples
in
the
spec
at
least
one,
if
not
more
than
one
to
kind
to
illustrate
how
this
could
be
done
and
and
what
the
parameters
are
around
it.
So
I
think
you
know
it
in
some
ways:
it's
very
similar
to
the
stuff
we
did
for
the
most
recent
draft.
We,
you
know
clarified
and
kind
of
explained
and
gave
examples
of
stuff
that
was
already
there.
D
It
just
wasn't
adequately
communicated
in
7807,
and
so
I
think
that's
the
direction
we're
going
to
go
in.
I
know
that
that
sanjay
has
a
pull
request
that
he's
been
working
on,
that
I
think
he's
getting
closer
to
to
being
ready
to
merge.
So
I
think
we
just
need
to
continue
discussing
that
it's
a
little
delicate,
because
if
you
make
the
the
examples
too
realistic,
then
people
might
just
use
those
as
templates
almost
you
know,
and
cut
and
paste
from
the
spec,
which
may
or
may
not
be
a
good
thing.
D
G
F
A
I
And
I
can
based
on
the
comments
I
can
put
some
more
words
cautioning,
that
it
is
an
example
for
an
extension.
It
doesn't
look
like
the
swag
is
saying
that,
but,
as
mark
was
saying,
we
had
to
give
an
example.
That's
what
we
agreed
on.
So
I
think
we
can
do
a
couple
of
things.
One
is
the
example
for
the
multiple
problems,
and
I
think,
where
more
comments
are,
is
a
second
example
which
is
using
json
pointer
to
point
to
a
a
problem
in
the
request
itself.
D
Here
I
think
one
of
the
things
that
came
up
in
the
discussion
was
the
difference.
You
know
they're
different
kinds
of
classes,
of
multiple
problems
and,
and
one
is
that
you
might
have
you
know
multiple
instances
of
the
same
problem
type.
Excuse
me,
and
in
that
case
you
know
it's.
It's
probably
the
you
know
the
type
that's
here
in
this
example,
the
multiple
errors
is
is
not
ideal.
What
you
would
really
want
to
do
is
is
that
have
you
know
the
the
valid
validation
error
type?
D
Allow
multiple
instances
to
be,
you
know
communicated
of
where
it
is
in
the
document.
So
so
it's
you
know
not
so
generic
at
the
top
level
type.
Another
example
would
be
what
you
see
here,
which
is
there,
are
multiple
different
problem
types
in
the
document
and
you
need
to
convey
them
all.
At
the
same
time,
you
don't
want
to
just
convey
the
first
one.
They
have
the
person,
make
the
request
and
convey
the
second
one
and
so
forth,
and
in
that
case
you
do
need
this.
D
This
multiple
errors
type,
but
but
there's
there's
two
different
kinds
of
of
two
different
ways.
This
can
happen.
One
is
where
all
the
different
problem
types,
although
they
are
different
problem
types-
they
have
the
same-
recommended
http
status
code.
For
example.
Maybe
it's
a
you
know
400,
which
is
quite
common
it
you
know
it
things
with
something's
wrong
with
the
request
and
hear
the
details
of
that,
and
in
that
case
you
should
use
that
status
code.
The
only
time
that
you
should
use
207
multi-status
is
when
there
are
multiple
problem
types.
D
True,
you
know
you
have
this
multiple
errors
case
that
we're
coming
up
with
and
they
have
incompatible
recommended
http
status
codes,
and
so
you
need
some
way
to
you
know
convey
that
one
example
would
be
to
use
207
multi
status,
but
I
would
say
that
even
if
they're
all
400
4xx
status
codes,
for
example,
you'd-
probably
send
it
as
400,
because
that's
the
most
generic
for
xxx
status
code,
and
so
I
think
we
need
to
have
some
more
nuanced
guidance
here
about
these
multiple
status
cases,
and
I'm
I'm
really
happy
to
write
text
about
that.
D
I
I
This
was
on
the
top
in
the
earlier
draft,
so
I
thought
maybe
introduce
these
things
right
there,
but
we
can
introduce
them
in
proper
sequence,
like
you.
Just
have
one
type
of
error.
Give
example
of
that
and
if
you
have
cases
like
different
kinds
of
errors,
then
and
207
could
be
used,
and
that
would
be
a
separate
example,
so
mark
yeah
feel
free
to
have
an
update
on
that.
D
No,
no,
that
that
sounds
good
and
I'm
totally
with
you.
I
I'm
not
a
fan
at
all
of
specs
that
are
just
big
walls
of
examples
that
you
have
to
fight
your
way
through.
So
if
we
can
find
a
way
to
balance
that
to
convey
the
nuance
here
without
you
know,
having
too
many
examples,
I
think
that
would
be
a
good
goal
to
have
here.
A
A
D
I
think
the
the
multiple
you
know
since
before
we
started
this,
the
multiple
problems
was
clearly
the
the
most
impactful
potential
change,
the
ld
jason
ld
context.
I
think
we,
we
probably
need
a
a
proposal
for
that.
I
think
ashborne
volunteered
to
do
that.
If
I
remember
correctly
the
32,
the
extension
to
show
source
of
problem
and
request
for
exact
class
of
errors,
I
think
that's
just
kind
of
a
part
of
the
example
you
know,
processing
and
getting
that
right,
so
we'll
get
there.
D
I
think
the
other
question
that's
kind
of
been
the
back
of
our
heads
is:
do
we
want
to
standardize
any
register
with
the
so
the
last
revision
we
introduced,
the
idea
of
a
registered
problem
type
still
a
uri,
but
it's
it's
in
a
registry
to
kind
of
promote,
good
practice
and
so
forth,
and
I
guess
the
question
is:
do
we
want
to
go
to
the
effort
to
define
any
of
those
like
you
know
the
multiple
errors
or
a
validation,
error
problem,
and
I
think
that's
something
we
could
do
I.
D
I
do
think
that
that's
you
know
not
a
trivial
design
task.
It
would
take
some
time,
but
it's
you
know
we
so
there's.
I
guess
the
decision.
Do
we
want
to
try
and
put
any
in
this
document
or
do
we
want
to
punt
that
to
to
maybe
a
follow-up
document,
and
I
I
don't
have
strong
feelings,
that's
something
we
should
do
with
purpose
either
way.
A
Which
I
may
have
to
wave
my
hands
a
little
because
roberto,
I
don't
believe,
is
in
the
call
the
rate
limit
headers.
They,
the
roberto,
did
publish
a
new
update
to
this
document
just
a
few
days
ago.
A
The
items
that
are
seem
to
be
the
most
popular
of
this
conversation
around
naming
of
the
headers.
At
the
moment
there
is
rate
limit
dash
limit
rate
limit
dash
remaining
a
rate
limit
dash
reset,
I
know
mark,
has
suggested
that
maybe
shortening
those
to
rl
dash.
There
is
a
interesting
conversation
about
compatibility
with
existing
deployments,
because
this
spec
is
as
much
as
anything
is
a
an
attempt
to
standardize
what
is
current
practice,
but
the
current
practice
starts
with
x
dash.
A
A
Throttling
scope
is
an
interesting
conversation
that
there
was
a
discussion,
I
believe
in
the
hp
working
group
around
whether
retry
after
should
have
any
scope
qualifications,
and
it
was
that
it
that
did
not
lead
to
anything
other
than
clarification
around
retry
after
I
believe
here,
because
there
is
a
lot
of
flexibility
around
determining
quota
policies,
there
is
an
opportunity
to
define
scope,
and,
what's
meant
by
that
is
is
is?
Are
you
being
throttled
for
just
this
particular
resource?
Are
you
being
throttled
for
all
of
these
resources
for
your
company?
A
Are
you
being
throttled
for
just
this
particular
mailbox
or
this
particular
website,
so
there
there?
I
believe
the
extensibility
mechanism
is,
is
going
to
be
able
to
address
this
with
quota
policies,
but
there's
definitely
a
conversation
worth
having
there
mark.
D
Just
on
that,
in
my
experience,
scoping
the
applicability
of
a
header
is
one
of
the
worst
things
to
to
leave
out.
Well,
no,
no
that
that's
not
true.
Sometimes
it
makes
sense
to
leave
it
out,
but
if
it's
left
out
and
and
it's
ambiguous,
it
can
be
really
pernicious
to
figure
out
down
the
road
and
we
you
know
for
retry
after
we
didn't
define
it
because
it's
already
in
deployment
and
it's
undefined.
So
we
can't
just
define
it
by
fiat
and
break
some
people,
you
know
and
their
idea
of
how
it
applies.
D
So,
if
you
know
to
me,
the
the
intuitive
thing
to
do
here
would
be
to
not
define
a
static
scope,
but
to
say
that
the
scope
is
undefined,
but
also
to
define
maybe
a
vocabulary
of
scopes
that
people
can
apply
and
say
well.
This
is
scoped
just
to
this
resource
or
this
a
scope
to
this
entire
site,
or
you
know,
carve
out
the
right
kinds
of
of
primitives
that
people
can
use
to
declare
this
if
they
want
to
declare
it.
A
The
define
header
dependencies
is
an
issue
that
talks
about.
Do
you
need
to
provide
all
three
rate
limit
rate
remaining
rate
reset?
Are
there
interdependencies?
Can
you
define
one
but
not
another,
and
that
conversation
is
ongoing?.
A
The
last
item
is
related
in
two
ways:
it's.
It
is
an
extension
to
the
standardized
behavior
and
refers
to
the
use
of
a
structured
field-
header
list,
as
opposed
to
it's
currently
using
a
list,
because
you
can
apply
multiple
quotas.
You
can
say
in
the
next
10
minutes.
You
can
make
100
requests
in
the
next
hour.
You
can
make
10
000
requests,
so
you
can
define
multiple,
but
that
is
again
not
compatible
with
the
existing
implementations
and
so
there's
questions
around
capability
compatibility
with
the
past.
A
A
Oh
wait:
are
you
back
in
the
key
mark
or
still
in
the
queue
from
previously.
A
Oh
he's
gone,
defecation
header.
F
Sure
yeah,
I
can
thanks
daryl
yeah,
so
this
one
we
actually,
we
have
not
produced
a
new
version.
Since
the
last
meeting
we
had,
we
had
a
couple
of
open
issues
still
so
we
have
not
been,
I
would
say,
super
good
at
closing.
All
of
these,
as
I
said,
there
is
no
new
version
of
the
draft.
F
Mostly.
I
think
I
would
like
to
encourage
everybody
to
look
at
the
draft
if
you're
not
aware
of
it,
it's
very
simple
one.
It's
very
similar
to
the
sunset
mechanism.
That
already
is
an
rfc
or
deprecation
is
a
header
field,
but
you
can
say
this
resource
still
works,
but
it's
deprecated,
so
you
should
think
about
alternatives.
It
may
get
shut
down
all
these
kind
of
things.
It's
a
very
simple
mechanism
and
it
can
either
say
this
is
deprecated
or
this
is
going
to
be
deprecated
with
a
date
in
the
future.
F
One
of
the
I
think
most
contentious
issues
we
had
around
this
was
this
question
of
scope.
So
is
deprecation
always
just
for
the
resource
where
you
say
this
whole
resource
will
become
deprecated,
or
is
there
some
kind
of
more
fine-grained
model?
I
think
we
still
might
have
some
some
issues
around
that
I'm
not
quite
sure.
To
be
honest,
I
know
that
daryl
has
his
own
opinions
about
that.
Taking
off
my
chair.
A
I
I
think
you've
made
a
good
case
for
there's
value
to
just
keeping
it
focused
at
the
resource
level.
I'll
have
to
go
back
to
our
team
and
say
hey
that
header
that
I
suggested
you
using
you're
not
using
it
for
the
right
way
and
find
some
other
way
of
doing
it.
But
I
am
I
I
I
think
we're
getting
close
to
being
able
to
close
that
one
with
no
action.
F
F
You
kind
of
need
to
have
a
model
how
to
do
that
or
it
doesn't
make
a
lot
of
sense
to
do
it
and
and
then
that
that
goes
pretty
quickly
very
deep
into
the
realm
of
the
representation
that
you're
sending,
because
you
somehow
need
to
talk
about
that,
and
since
this
is
an
http
header
field,
we're
not
really
kind
of
intending
to
go
to
that
level.
F
A
So
martin
has
a
question
in
the
chat
to
answer
your
question:
why
says
retry
after
has
an
ambiguous
scope?
Why
this
not
also
this
scope
is
not
scope,
as
in
how
many
resources
did
this
apply
to
it?
The
the
the
desire
was
to
be
able
to
have
the
deprecation
header
say
there
is
something
inside
this
response,
this
representation
that
has
been
deprecated,
the
entire
resource
isn't
going
away,
but
one
of
the
data
elements
within
it
is
is
being
deprecated.
F
Okay,
it
seems
like
the
comments
are
mostly
about
retry.
After
so
you
don't
have
to
worry
about
that
yeah
so
that
one,
then
the
question
was
yeah.
Can
you
redirect
to
a
new
location
there.
A
F
Yeah
and
then
I
so
that
number
12
that
you're,
I
think
that
one
was
raised
by
mark
if
I
recall
correctly
saying
that
it's
just
not
not
such
a
great
design
to
do
it
like
that,
and
I
to
be
honest,
I
don't
I
haven't
thought
so
I
think
my
main
point
was
that
I
agree
that
maybe
is
not
a
great
design,
but
that's
how
sunset
works.
G
G
A
D
A
Yeah
I
mentioned
in
the
chat
that
because
sanjay
called
out
well,
this
is
this
is
open.
Api
uses
deprecated
as
a
boolean,
and
I
think
mark
was
suggesting
why
not
just
use
just
a
date
and
if
the
date
is
in
the
past,
then
consider
it
true,
and
I
wish
we'd
done,
that
in
open
api.
So
please
don't
use
open
api
as
a
model
to
start
to
follow.
F
You
know
right
now
we're
using
sunset
right,
which
does
that
so-
and
I
haven't
heard
any
specific
complaints
about
that.
But
I
agree
that
it's
probably
not
the
best
design
and
we
have
a
chance
to
make
it
easier
to
work
with
so
yeah.
So
I
think
it's
a
good
suggestion,
but
we
still
have
to
address
that.
I
I
Thinking
that
you
know
the
api
developers
were,
writing
the
contracts
not
to
confuse
them
too
much.
If
there
is
some.
I
A
Cool
if
there
are
no
other
comments
about
deprecation
header,
you
know
where
to
find
the
issues.
F
Yes,
so
if
anybody
has
any
additional
input
or
comments
or
whatever,
please
of
course,
you're
free
to
raise
an
issue
ideally
or
comment
on
the
existing
ones,
we
still
have
to
go
through
the
ones
that
are
open.
I
think
there's
a
total
of
six
open
issues
in
there
right
now.
So
it's
not
it's
not
huge.
It's
also
not
a
huge
spec,
but
we
definitely
still
have
to
do
some.
Some
work.
A
I
am
potency
key,
so
I
I
think,
mark
just
went
through
all
of
the
drafts
and
just
added
an
issue.
He
restricted
fields,
and
I
think
it's
a
great
suggestion
and,
as
I
mentioned,
the
chat
before
we
should
just
that
should
be
the
de
facto
suggestion
with
specs
moving
forward
use,
restrictory
keys
unless
there's
a
really
good
reason,
not
to
structured
fields,
structured
headers,.
A
A
However,
from
my
reading
of
it,
the
beatles
request
is,
is
somewhat
more
ambitious
and
puts
signific
an
additional
burden
on
the
server
side.
So
it
is
an
interesting
question
as
to
whether
or
not
it
makes
sense
to
have
these
two
things.
Two
different
specs
live
side
by
side,
depending
what
requirements
are
sanjay.
You
want
to
speak
to
that.
I
I
But
we
definitely
would
produce
one
before
the
next
one.
I
am
looking
at
the
issues
and
there
was
one
I
think
eric
you.
You
have
sent
an
email
to
order
or
data
comments
list.
Did
you
receive
anything?
I
F
Yes,
if
I
may
jump
in
here
so
yeah,
I
did
receive
some
so
the
problem
or
problem.
The
issue
with
the
oasis
repeal
request
aspect
is
that
it
kind
of
has
a
bigger
scope,
but
it's
not
just
the
item
policy
key.
They
also
have
these
correlation
keys
so
that
you
can
correlate
requests
more
easily
and
some
specs
do
or
some
of
the
practices
out
there
do
both
some
of
them
do
only
item
policy
keys.
F
So
in
terms
of
the
practice,
I
think
that's
out
there,
the
oasis,
repeatable
requests
method,
has
more
applicability
or
is
something
that
uncover
more
possible
scenarios
what
people
are
doing,
but
that
would
also
mean
that
if,
if
we
did
wanted
to
align
those
or
say
there,
there
is
a
mechanism
for
doing
that,
then
that
would
also
mean
that
we
need
some
kind
of
correlation
identifier
correlation
key
and
we
we
don't
have
that
right
now.
A
If
the
repeatable
request
does
some
more
advanced
things,
what
is
the
better
place
in
the
world
to
end
up
with
a
repeatable
request?
Spec
that
says
hey.
If
you
want
to
do
something
more
sophisticated
go,
do
it
that
way
or
do
an
ietf
spec?
That
would
like
the
item
potency
key,
which
allows
you
to
do
it
in
a
simple
way,
but
also
adds
in
additional
semantics
to
allow
you
to
also
do
the
things
that
repeatable
requests
effectively
keep
creating
a
competing
spec
for
those
for
the
with
the
repeatable
requests.
I
So
before
writing
this
up,
I
did
a
bit
of
digging
and
I
found
so
many
instances
where
what
we
have
so
the
draft
comes
after
a
lot
of
implementation.
It
seems
right,
it's
not
like.
I
think
the
application
is
bit
different,
where
we
don't
have
as
many
when
we
started
writing
it.
We
didn't
have
as
many
implementations
out
there
now
they
have
increased
a
lot,
but
in
this
case
it
was
already
used
by
so
many
api
developers.
I
So
it
was
more
about
standardizing
and
honestly,
I
didn't
come
across
oasis's
draft
then
or
or
usage.
So
I
don't
know
eric
has
been
looking
at
a
lot
of
apis
also,
he
might
have
seen
it,
but
I
had
not
seen
it
so.
I
was
just
wondering
we
can
refer
this,
but
this
deserves
its
own
place,
since
there
are
lots
of
implementations
already
using
it
without
it
being
a
draft.
A
I,
I
suspect
the
reason
why
the
oasis
repeatable
requests
it
can't
have
more
independence
in
implementation.
Dependencies
is
because
it's
largely
targeted
at
people
who
are
building
our
data
apis
with
our
data
machinery
for
implementation.
Hence
they
can
make
some
implementation
assumptions
so
probably
a
safer
bet
to
keep
it
closely.
Scoped
to
the
current
implementation
requirements
of
people
who
are
using
item
policy
key.
A
A
Awesome
cool,
so
that
brings
us
to
the
end
of
the
notes
on
the
documents
and
the
only
thing
that
I
want
to
just
call
folks.
Attention
to
is
mark
created
a
repo
to
have
github
discussions
and
has
filled
it
with.
We
could
do
this.
We
could
do
that
his.
He
has
no
shortage
of
suggestions
for
work
that
could
be
done
and
one
of
the
the
specs
that
was
raised,
and
that
might
be
interesting
for
this
working
group.
A
Is
this
health
check
api,
and
so,
if
you
have
scenarios
in
your
working
environment,
where
having
a
standardized
response
to
health
check
would
be
useful.
A
I
encourage
you
to
take
a
look
at
that
spec
and
go
take
a
look
at
the
discussions,
and
I,
with
my
very
newbie,
chair
hat
on
a
little
reluctant
to
suggest
hey,
let's
just
take
on
another
one
and
I'm
very
happy
to
see,
link
set,
go
into
heading
to
last
call
so
that
we
can
shepherd
some
documents
out
and
make
room
for
new
ones,
but
I
would
definitely
love
feedback
or
whether
you
think
that
this
health
check
api
is
worth
adoption.
A
D
So,
to
be
clear,
I
I
created
that
repo,
so
hopefully
other
people
will
put
their
ideas
in
there
too,
but
yeah.
I
do
have
a
few
and,
from
my
perspective,
I'm
looking
you
know
when,
if,
if
things
get
upvoted
a
lot
or
if
you
know
there's
a
lot
of
discussion
about
something
that
to
me
is
an
indication
that
I'll
put
more
energy
into
it,
you
know
there
are
a
lot
of
different
things
I
could
write,
but
if
people
aren't
interested,
I'm
not
going
to
put
the
energy
into
them.
D
I
Sanjay
yeah,
so
this
one
I
came
across
this
while
looking
at
spring
boots
inbuilt
implementation
on
health
check,
and
I
think
I
have
asked
this
question
to
the
author,
because
he
has
referred
that
he
has
looked
at
different.
I
think
assure
health
and
spring
boot
and
all
and
try
to
accommodate
those
things.
But
what
I
couldn't
find
was
spring
boot
is
used
a
lot
in
enterprises
right
and
have
they
adopted
it
or
not,
and
if
they
have
adopted
this,
then
it's
a
very
strong
case.
I
But
this
is
a
very
general
problem
and
to
have
that
defined
in
a
standard
form
would
help
a
lot.
So
I
think
it's
very
relevant,
but
I
had
some
questions
about.
You
know
where
it
is
adopted,
because
there
are
lots
of
implementations
and
if
this
is
different
than
those
popular
implementations,
then
adoption
may
take
some.
I
You
know
it
may
not
be
as
good
so
so
I
thought
that
maybe
we
can
ask
the
question:
invite
the
author
and
find
that
out
and
yeah.
I
really
like
that
discussion
group
thanks
mark.
E
F
Yeah
and
so
in
terms
of
adoption
right,
I
think
like
with
some
of
the
things
that
that
we're
doing
in
this
group,
it's
it's
always
the
same.
We
look
out
there
and
we
see
that
there
are
20
different
ways
how
people
do
stuff,
and
then
we
come
up
like
the
good
old
xkcd
right.
F
We
come
up
with
the
21st
way
and
we
hope
that
it
is
more
convincing
than
the
20
ways,
but
it
always
is
going
to
be
something
where
it
takes
some
time
until
some
specific
approach
of
doing
that
gains
momentum,
but
I
think
for
the
health
check
part
we
we
do
see.
That
is
a
pattern
that
you
see
in
a
lot
of
apis.
So
the
pattern
is
definitely
something
that
is
pretty
popular.
F
So
I
think
it
definitely
is
something
that
could
have
quite
a
bit
of
impact
and
just
having
one
other
building
block
that
you
don't
have
to
come
up
with
by
yourself,
but
you
can
just
say:
okay,
health
check
apis.
If
we
have
an
and
health
check
endpoint
in
our
api,
this
is
how
we're
gonna
do
it.
A
I
I
think
one
thing
that's
appealing
to
me
is
it's
another
example
of
a
media
type
like
http
problem
that
addresses
a
horizontal
need
across
http
apis
and
demonstrates
the
value
of
putting
a
chunk
of
semantics
to
solve
a
particular
problem
in
a
media
type,
which
is
not
a
concept
that
many
ap
api
designers
are
familiar
with.
They
largely
see
media
types
as
well.
That's
applications
like
json
right
and
we
just
put
all
of
our
semantics
inside
application,
slash
jason.
A
Okay,
move
on
okay
operator,
perfect.
I
A
That's
good
call
eric.
F
Yeah,
so
I
I've
spoken
with
iraqi
and
he's
he's
kind
of
interested,
but
is
also
something
that
that
I
think
he
hasn't
looked
at
for
a
little
while.
So
if
we're
interested
to
maybe
add
this
to
our
list,
I'm
sure
we
can
we
can
get
him
to
join
as
a
guest
or
something
like
that.
So
yeah
he's
definitely
he's
not
focusing
on
that
anymore,
so
it's
kind
of
just
sitting
there,
but
I
think
it
is
something
that
is
useful
and
could
be
a
very
useful
thing
for
the
group
to
produce.
A
And
to
answer
your
question
sanjay,
I
think
I
need
to
talk
to
folks,
because
I
have
I
have
rich
nodding
when
I
say
we
shouldn't
take
any
more
things
on
and
I
have
mark
in
the
chat
saying.
Oh,
you
can
take
on
lots
of
more
things,
so
we
we
will.
We
will
get
consensus
on
our
capacity
and
then
we'll
go
chase
iraqi.
B
Agreed
we
need
to,
I
mean
it's
not
totally
our
decision,
you
know
if
the
working
group
buckles
down
and
finishes
off
the
existing
drafts
quickly,
and
certainly
eric
and
other
and
sanji
and
others
have
been
trying-
that's
great,
but
we
don't
want
to
overload
people
and
have
a
bunch
of
things
in
draft
that
don't
progress,
but
it's
up
to
the
group
martin.
So
you
can
finish
something
before
you
take
more
work
on
and
that's
that
will.
A
Certainly,
and
because
when
we
charted
the
group,
one
of
our
statements
was,
you
know,
let's,
we
didn't
quite
know
how
to
run
this
working
group
and
because
it
had
such
a
broad
scope
and
we
were
like
well,
let's
try
it
for
six
months
and
see
how
it
goes
and
we
are
somewhat
further
along
than
six
months
and
we
need
to
as
martin
says,
show.
We
can
finish
something.
A
So
if
there
is
no
any
other
business
for
many
folks,
it
looks
like
we
can
end
early.
J
So
I
have
a
question
about
the
query
method.
If
it
would
also,
I
can't
find
the
draft
anywhere
but
or
maybe
I
misunderstood,
but
I
wonder
if
there
will
also
be
a
corresponding
head
method
so
where
you
have
a
query
on
the
payload,
but
you
get
only
the
headers
back
and
no
payload.
A
D
Microphone
working,
yay,
yeah,
it's
so
to
be
clear.
This
is
a
draft
in
the
http
working
group
and
we've
pasted
the
link
into
the
chat
a
few
times.
Now.
It's
not
called
draft
anything
query
because
we're
we're
not
we
haven't
locked
down
the
the
method
name,
so
it's
the
safe
method
with
body
and
it's
in
the
http
working
group.
I
like
daryl,
I
think
daryl's,
on
the
right
path
there.
I
think,
if,
if,
if
it
well,
you'd
send
the
whole
query,
but
you
don't
get
the
response
back.
J
D
J
D
I
see
your
point
I
I
do
wonder
if
maybe
that
could
be
triggered
with
a
header
on
the
request.
For
example,
I
just
know
that
you
know
head
adds
a
lot
of
weird
corner
cases
to
http
and
and
I'm
not
100
sure
that
if
we
were
designing
http
from
scratch
today,
we
would
still
do
head
acknowledging
that
it's
useful.
But
you
know
it's
it's
having
two
methods
that
are
supposed
to
have
the
same
semantics
and
supposed
to
operate
in
the
same
way,
except
that
one
doesn't
return.
D
A
body
create
some
weird
corner
cases,
so
yeah
sure.
If
you.
D
For
that,
please
open
an
issue
on
the
repo.
It's
certainly
an
interesting
discussion
to
have
okay
I'll.
Do
it
thanks
thanks.
B
So
I'll
mention
the
charter.
There's
some
discussion
going
on
in
the
chat.
The
charter
for
this
working
group
is
different
from
how
most
working
groups
are
chartered
they're,
given
specific
tasks
and-
and
you
know,
advisory
deadlines
milestones
as
to
when
we
would
meet
them.
B
This
group,
thanks
to
mark,
was
deliberately
left
open
and
so
there's
very
few
specifics
in
it
and
it's
like
well,
let's
see
what
the
group
needs
to
do.
It's
supposed
to
have
been
revised
a
while
ago
francesca
says
yeah
that's
hard
to
do,
but
we
are
unusual
from
other
groups
in
that
we
don't
have
specific
things
to
do
and
mark
you
can
speak
next,
since
I
assume
you
want
to
talk
to
that.
D
Kind
of
put
a
poison
pill
in
this
charter
because
at
least
for
me
personally,
my
goal
for
this
was
to
make
sure
that
we
created
a
group
that
was
connected
to
the
http
api
community
and
and
connected
to
real
world
implementation
and
deployment,
and
if
it
was
just
a
bunch
of
itf
folks
sitting
around
a
campfire
chatting
about
what
they
thought
about
http
apis.
I
was
not
interested
in
perpetuating
any
such
thing.
D
D
But
what
I
would
plead
with
our
area
director
who
I
see
is
up
next,
is
that
if
I
strongly
suspect
that
if
we
get
a
couple
of
as
they
say,
runs
on
the
board,
if
we
get
a
couple
of
specs
shipped
that
actually
add
value
to
the
hba
api
community,
I
think
that
will
feed
more
energy
into
the
group
and
get
us
some.
Some
new
people
who
are
more
connected
to
the
hp
api
world
involved.
D
Not
that
we
don't
have
people
now,
it's
just
I
I
want
more
of
them,
and-
and
so
I
I
think
it
would
be
great
to
see
us
ship
a
few
specs
and
see
what
happens
next,
but
I
do
feel
like
we
have
a
fairly
successful
and
and
I've
been
happy
with
the
nature
of
the
meetings.
I've
been
wondering
a
little
bit.
If
maybe
we
should
hold
in
from
meetings
once
in
a
while.
G
Hi
yeah,
I
just
wanted
to
repeat
what
I
was
saying
in
the
chat
which
is
there
is
this
requirement
in
the
chat
which
is
to
assess
whether
the
group
is
functioning
well
and
it
it
explicitly
mentions
not
only
me
but
the
asg.
G
So
I
think
that
there
is
an
ip
for
me
to
bring
this
in
front
of
the
isg
and
have
some
sort
of
discussion.
I
don't
know
if
it
needs
to
be
like
a
telechat
or
an
informal
telechat,
but
I
will
make
sure
that
this
happens
just
so
that
we
are
complying
with
the
charter
text.
I
personally
think
that
the
working
group
is
functioning
well,
even
though
that's
very
subjective,
so
it's
kind
of
hard
to
say
is
it
functioning?
G
Well,
if
we
don't
have
a
like
very
precise
details
of
what
that
means
or
yeah,
but
yeah
this
doesn't
mean
the
working
group
is
on
probation.
This
is
just
I,
I
guess
another
another
moment
to
be
able
to
discuss
how
to
how
things
are
working
for
everybody.
I
guess
for
the
community
as
well,
and
it
is
working
well
if
we
ship
good
stuff.
Yes,
I
guess
that's
the
the
main
thing,
but
but
it
also
takes
a
little
bit
of
time
to
do
that.
G
So
no
documents
yet
doesn't
mean
necessarily
that
it's
not
working
well-
and
I
agree
with
mark
about
possibly
possibly
having
interims.
That
would
be
nice
and
coordinating
with
http,
which
I
know
you're
already
doing,
but
yeah
they
have
interims
to
replace
itf
meetings
like
week
meetings.
So,
okay-
and
I
don't
know
if
we
want
to
like
start
a
discussion
in
the
main
list
about.
G
Well,
so
that
I
can
bring
that
to
the
asg
if
that
would
be
useful
at
all
or
or
it's
just,
maybe
not
that
useful
cheers.
Do
you
have
an
opinion
and
mark
and
everybody
else.
G
Okay-
I
I
don't
know
which
part,
but
the
last
thing
I
was
saying
is
that
I
don't
know
if
it
would
be
interesting
to
have
start.
The
mailing
mailing
list
thread
just
to
get
feedback
from
the
community
that
I
can
then
bring
to
the
isg
to
have
that
discussion
about
easy
functioning.
Well
or
maybe
that's
not
useful,
and
I
just
have
that
informal
discussion
with
the
asg.
B
My
view,
is,
you
know
if
the
if
the
icg
in
the
discussion
has
concerns,
then
we
can
probably
have
some
discussion,
but
I
don't
know
that
we
need
to.
I
think,
the
idea
of
having
interims
in
particular
co-located
virtually
where
other
api
working
groups
are
involved.
You
know
w3c
and
or
you
know
what
working
group
or
whoever
it
is.
You
know
open
graph.
That
would
be
a
really
useful
thing,
interesting
thing
to
try
doing
so.
B
G
B
Thank
you.
Everyone
for
the
participation
and
the
continued
good
work
stay
safe,
stay
healthy,
see
you
soon.