►
From YouTube: IETF113-HTTPAPI-20220324-0900
Description
HTTPAPI meeting session at IETF113
2022/03/24 0900
https://datatracker.ietf.org/meeting/113/proceedings/
B
B
B
B
B
B
C
C
F
E
C
C
C
C
C
C
G
C
C
C
G
E
C
A
A
Well,
the
goal
of
the
of
this
specification
is
to
communicate
service
limits,
so
clients
cannot
stop
before
being
throttled
out,
can
stop
before
being
traveled
out,
align
all
the
already
existing
red
limit
headers.
So
we
are
not
inventing
anything
new.
We
are
just
trying
to
standardize
something
that
is
already
existing
our
or
an
already
existing
practice,
and
we
want
to
express
multiple
rate
limiting
policies.
A
A
A
A
A
With
respect
to
this
specification,
you
always
need
to
reply
with
those
fields,
so
we
are
not
saying
that
all
http
server
must
implement
this
specification.
But
if
you
implement
this
specification,
since
the
goal
is
interoperability
between
servers
and
client,
clients
will
expect
those
fields
to
be
present
to
enable
actions.
A
The
upper
the
second
of
an
issue
is:
do
we
want
to
define
an
upper
bound
for
it
limit
reset
or
not,
since
it's
a
delta?
Second,
maybe
we
could
suggest
to
implementer
that
if
they
receive
a
incredibly
huge
number
on
this
red
limit
reset,
probably
they
shouldn't
wait
all
that
time
and
maybe
the
those
red
limit
research
should
be
either
ignored
or
interpreted
in
another
way,
and
there
was
a
last
of
an
issue
about
field
names.
A
A
This
is
the
principle
question
and
we
want
to
ask
the
the
opinion
of
work
group
on
this
splittings
part.
We
think
this
is
reasonable
because
it's
it's
apple
with
apple
and
oranges,
with
oranges,
while
in
the
previously
we
had
different
meaning
for
the
first
list
item
and
the
other
ones
and
the
rest.
If
we
want
to
discuss
the
other
policies.
A
H
H
You
know
sometimes
it's
a
good
idea
to
split
out
data
into
multiple
fields,
especially
when
it
changes
at
different
rates,
but
it
seems,
like
you
know,
like
the
remaining
and
the
reset
are
pretty
dynamic
as
far
as
I'm
aware,
whereas
the
policy
and
the
limit
are
not
so
I
I
just
I
can't
help
but
wonder
you
know
this
is
maybe
related
to
issue
65
as
well.
I
can't
help
but
wonder.
H
A
H
H
I
found
the
reasoning
for
issue
65
quite
thin
on
that
basis,
that
if
we
don't
have
it,
starting
with
the
words
right
limit,
they
won't
understand
it
seems
to
be
the
reasoning
there.
So
I
I
think
that
if,
if
we
come
up
with
a
well-reasoned
design,
we
don't
have
to
be
too
bound
by
by
precedent
there
and
I'd
encourage
you
to
to
at
least
explore
those
directions.
A
H
I
C
Some
of
it
and
probably
adding
some
kind
of
indicators
saying
this
is
related
to
the
origin,
or
this
is
related
to
the
proxy,
or
this
should
go
back
to
the
user,
whoever
they
are
saying,
you're
doing
too
many
requests
of
this
kind.
The
proxy
has
no
idea
what
the
requests
are,
but
it
can
be.
You
can
tell
the
the
the
client,
you
know,
stop
asking
for
every
single
picture
in
the
phone
book,
so
I
think
it's
mainly
just
a
heads
up
that
ojai
needs
a
similar
kind
of
thing.
C
A
Frank,
this
is
this
is
interesting,
and
probably
we
should
file
an
issue
to
understand
better
the
use
case
and
possible
exchanges
in
in
general.
I
am
well,
I
understand
the
suggestion
of
reducing
the
number
of
fields,
but
please
consider
that
the
actual
feedback
of
many
implementers
is
that
they
say
in
direct
limit
policy
that
they
don't
even
want
to
conflate
all
those
information
in
the
same
field
and
they
prefer
to
say,
for
example,
red
limit
minions
that
limit
our
different
things.
A
A
No,
I'm
I'm
I'm
not
using
I'm,
not
the
I'm
not
trying
to
avoid
using
structure-filled
parser,
but
I
need
I
I'm
building
this
specification
for
implementers
and
my
goal
is
not
forcing
them
to
do
something
they
don't
want
to
do,
but
is
avoiding
they
to
provide
different.
The
same
information
in
different
things.
H
Working
is
it
working?
Yes,
it
seems
to
be
working,
okay,
so
roberto.
I
think
it's
great
that
you're
going
out
and
engaging
with
folks
who
are
using.
You
know
similar
things
out
there
and
I
mean
implementers
potential
implementers.
I
think,
there's
maybe
a
mix
there,
I'm
not
sure,
but
generally,
when
we
do
that
it
it's
great,
but
it's
important
to
make
sure
that
we're
doing
that
to
bring
back
their
feedback
in
the
form
of
arguments,
not
just
preferences.
You
know
it's
it's
much
more
convincing.
H
If
you
came
back
and
said
implementers
want
to
do
this
and
there
there's
this
technical
or
this.
This
reason
why
that
we
can
understand
and
take
into
account
in
our
discussions,
but
it's
it's
less
useful
when
when
they
come
back
and
say
they
want
to
or
they
prefer
this
or
they
prefer
that
I'm
much
less
willing
to
be
convinced
that
that
that's
a
good
reason
to
choose
any
particular
design
in
the
discussions
for
a
standard.
H
J
B
J
Is
this
working
yep?
This
is
brian
gondwana.
I
I
wanted
to
add
something
in
favor
of
the
idea
that
something
that
people
want
to
use
has
value
in
itself,
not
just
because
of
the
technical
arguments,
but
because
they
enjoy
using
it
and
hence
they're
more
likely
to
use
it
we're
competing
against
someone
can
throw
whatever
they
like
in
the
header.
If
we're
offering
them
a
standard,
that's
a
pain
to
use
and
looks
ugly
and
they
don't
like.
Then
they
just
won't
use
it.
So
I
think
the
operators
prefer
this
is
a
significant
users
prefer.
J
E
K
K
But
I
think
in
the
api
space
really
in
the
end,
what
you
end
up
with
is
you
end
up
with
a
lot
of
developers
who
are
not
core
http
developers
who
are
using
http
as
part
of
the
work
they
need
to
get
done
and
if
you
tell
them
that
they
have
to
use
an
additional
parser
and
that
there
are
rather
complex
header
fields
to
work
with?
And
all
of
this,
I
think
it's
just
a
different
kind
of
client
base
we're
working
with
here.
K
So
I
I
just
think
we
should
take
into
account
that
from
an
http
api
perspective
for
most
people,
they
are
not
http
experts,
so
for
them,
http
is
just
something
that
they
need
of
as
part
of
the
work
they're
trying
to
get
done,
so
we
sh.
We
should
try
to
make
it
as
easy
for
them,
as
we
can
to
get
the
information
that
they
can
get
in
http
and
to
work
with
http
header
fields
without
requiring
them
to
adapt
technologies.
That
may
may
be
designed
for
a
different
user
population.
I
I
E
H
B
E
And
speaking
as
an
individual
eric,
I
will
both
agree
with
you
and
disagree
with
you.
I
I
do
agree
that
in
your
characterization
of
a
lot
of
api
developers,
but
most
api
developers
are
also
not
implementing
the
throttling
infrastructure
they're
going
to
use
some
kind
of
library.
I
think
people
we
need
to
convince
people,
writing
throttling
libraries,
and
at
that
point
it's
the
people
serving
the
headers
that
are
making
decisions.
E
The
consumers
will
use
whatever
they're
given
and
hopefully
they'll
use
library
to
go.
Do
that
parsing.
So
I
I
I
I
think
I
I
am
concerned
that
it's
the
yeah.
We
just
don't
want
to
change
our
thing.
That's
using
x,
dash
and
if
you
make
things
very,
very
different,
it'll
be
obvious
that
we're
not
using
the
standard
thing
anymore.
L
Hi,
this
is
hunter
speaking.
So,
first
of
all,
I
very
much
a
preacher
appreciates
it
works.
So
I
think
this
is
something
very
useful
once
it
is
finished
and
in
broad
use.
I
like
eric's
distinction
before
regarding,
like
there
is
two
distinct
user
groups,
like
you,
know
the
casual
user
consuming
api
and
maybe
not
wanting
to
spend
so
much
effort
and
more
advanced
users,
but
I
slightly
disagree
with
which
which
of
these
users.
We
should
focus
on
here,
because
I
think
for
the
casual
user.
L
Actually,
this
doesn't
matter
at
all
in
a
way,
because
these
users
will
just
be
heart,
throttled
by
the
apis
if
they
have
no
clue
anyway.
So
this
is
complex,
stuff,
actually
and
people
that
want
to
implement
this
kind
of
stuff.
They
really
need
to
understand
not
just
the
header
fields,
but
also
maybe
the
documentation
behind
that.
So
it's
not
just
only
the
header
fields
to
understand
here,
and
I
also
very
much
agree
what
daryl
said.
This
is
also
something
that
needs
to
go
into
libraries
in
the
end.
L
J
Brown,
since
I
put
my
name
into
this
for
the
first
thing,
a
lot
of
developers
are
going
to
probably
just
be
doing
a
regex
that
matches
digits
off
the
front
of
rate
limit
remaining
and
not
care
about.
Anything
else
would
be
my
guess,
glancing
at
this
realistically
and
that's
that's
the
use
case
that
is
going
to
be
for
a
lot
of
people
if
they
care
at
all,
if
they
just
throw
things
at
it
until
they
get
a
rate
limit
error
back,
which
is
probably
what
I
would
do.
J
So
that's
that's
the
kind
of
thing
that
that
we're
really
going
to
see
with
this.
If
you
look
at
what's
been
done
in
the
field
already,
I
think
that's
a
good
place
to
look
at
because
that's
what
has
organically
grown
and
what's
organically
grown
has
been
separate
headers
rather
than
a
structured
header.
It's
what
the
people
who
already
just
do
stuff
in
this
space
are
going
to
be
familiar
with,
and
so
I
mark.
I
totally
see
your
point.
J
E
H
There
it
is,
you
can
hear
me.
Okay,
the
lag
is
amazing.
It
sounds
like
that.
You
know
there
are
two
extreme
solutions
here
and
I
I
I
don't
want
to
paint
it
as
we
have
to
choose
a
or
b,
but
it
sounds
like
we
might
be
migrating
towards
that
at
one
extreme.
We
have
an
unlimited
number
of
fields,
depending
on
how
many
pieces
of
data
that
we
need
to
send
and
each
field
just
has
an
atomic
piece
of
data
and
it's
not
structured
field.
H
It's
just
you
know
ten
six
and
three
literally,
and
you
don't
have
any
parameters,
because
that's
too
hard
or
you
have
a
fully
structured
field,
and
it
is,
you
know,
fairly
complex,
but
we
throw
structured
fields
parsers
at
it,
and
the
data
just
appears
and
we
it's.
We
have
to
make
it
complex
enough
to
be
effectively
self
greasing,
which
I
think
there's
probably
enough
data
to
do
here.
If
we
combine
it
into
one
or
two
fields.
H
If,
if
it's
not
self
grazing,
then
I
I
think
that
braun,
you
know,
has
a
point
that
that
people
will
just
try
and
parse
it
and
then
it'll
break
when
somebody
adds
some
data
to
it
like
a
parameter
to
it
later
on.
So
so
maybe
what
we
need
to
do
is
to
write
up
those
two
extremes
and
see
what
they
look
like.
There
seems
to
be
some
noise
there.
So
right
up
those
two
extremes
see
what
they
look
like
and
and
figure
out
what
the
best
path
forward
is
from
there.
E
So
I
I
and
I
think,
we've
chewed
through
the
meat
of
the
issue.
I
don't
think
we're
going
to
solve
developer
motivation.
I
think
it
would
be
good
for
us
to
take
this
further
conversation
to
the
list,
and
maybe
we
can
move
on
to
the
next
presentation
from
roberto
on
and
his
mind
goes
blank
media
types.
Yes,
there's
gonna
be
a
lot
of
conversation
on
this
one.
I
fear.
L
A
A
So
open
api
specification
relies
on
yammer
and
json
schema
that
are
not
being
registered.
This
makes
impossible
content
negotiation
done
in
a
standard
way
and
yaml
users
do
not
have
interoperability
and
security
considerations,
so
we
want
to
register
yamalan
the
placing
ammo
media
type,
providing
interoperability
and
security
consideration
foundation
for
open
abi,
plus
yaml,
registering
up
an
api
plus
jason
and
yaml
json's
camera
plus
json
and
yaml
jason
led
placiamo
does
ingredient
a
quick
win.
A
A
A
One
engage
with
mega
types,
mailing
lists,
one
in
what
group
plus
calls
suggested
by
francesca
thanks
the
third
fragment
identifier,
considerations:
number
22:
can
we
use
normative
language
in
media
meditab
registration?
It
seems
that
it
is
possible,
but
I
don't
know
so.
I
asked
for
feedback
here
today.
A
A
A
A
A
A
A
H
There
it
goes
all
right.
I
have
no
idea
why
there's
so
much
life,
so
I'm
not
familiar
with
this
work.
The
only
thing
that
I'd
caution
is
we've
had
situations
like
this
in
the
past,
where
there's
a
draft
to
do
some
work
in
the
itf,
that's
related
to
a
larger
piece
of
work
that
lives
somewhere
else
and
and
it's
it's
super
super
easy
to
get
your
our
wires
crossed
when
doing
so.
So
I
would.
H
I
would
very
strongly
suggest
that
if,
if
you're
not
already
going
through
the
most
official
liaison
channel,
you
can
to
do
these
things,
in
other
words,
just
relying
on
people.
You
know
in
those
communities
or
chat
on
a
list
or
something
is
probably
not
adequate.
You
need
to
get
the
most
formal
possible
consensus
or
decision
or
whatever
the
mechanism.
The
community
has
that
they
are
okay
with
this
and
they
want
to
do
it
this
way
and
they
want
the
ietf
to
do
this.
Otherwise
we
can
end
up
in
a
very,
very
awkward
situation.
H
E
So
I
I
can,
I
can
speak
to
the
open
api
community
and
the
opiate
api
community
is
very
much
behind
this
effort,
and
this
we've
had
conversations
numerous
conversations
in
the
technical
steering
committee
meetings
about
this,
so
that
there's
definitely
support
there.
The
jason
schema
community,
who
are
also
actively
involved
with
the
open
api.
It
is
a
fairly
small
group
of
people,
and
I
know
that
roberto
is
talking
to
the
right
people.
H
I
I
There's
good
risk
that
those
things
are
difficult,
holding
back
the
thing,
the
other
ones,
and
it
might
be
nice
to
just
get
some
of
the
easy
things
out
of
the
way
and
and
published
and
from
a
user
perspective
being
able
to
cite
just
the
plus
yaml
spec,
when
you're,
registering
your
media
type
would
be
a
lot
easier
than
than
trying
to
fish
around
in
a
big
pocket
of
different
media
type
registrations.
When
you
have
to
do
something
like
this.
E
Meeting
this
week
there
was
a
discussion
of
multiple
suffixes
and
because
they're
talking
about
wanting
to
be
able
to
say,
plus
ld
plus
json,
on
top
of
the
application.
Slash
did
so
I'm
not
sure
where
that's
going
to
land,
but
there
was
some
pushback
in
that
conversation
specifically
around
using
suffixes
at
all.
E
So
I
in
in
reading,
through
the
issues
like
early
on
when
this
was
just
focused
on
open
api
and
json
scheme,
it
seemed
fairly
straightforward,
but
some
of
the
issues
seem
to
be
opening
up
a
bunch
of
stuff
and
sticky
stuff.
So
maybe
martin's
feedback
is
good,
that
stopping
at
one
point
and
separating
out
some
things
would
be
a
good
idea.
E
E
A
Yeah
the
goal
was
providing
a
specification
where
all
actors-
all
media-
that's
related
to
the
api-
can
be
addressed,
because
I
think
that
we
need
to
at
least
to
me.
It
has
been
beneficial
to
get
in
touch
with
all
those
community
together
to
have
a
better
overview
of
the
relations
that
there
are,
even
when
people
use
them
between
all
those
media
types.
E
E
There
is
this
project's
category
here,
and
so
you
can
simply
say
this
particular
issue
we're
working
on.
I
want
to
show
it
on
the
project
board
and
you
can
specify
a
status
and
as
soon
as
you
connect
it
here,
it
will
magically
appear
on
the
project
board
and
we've
set
it
up
so
that
it
groups
by
repo.
E
E
C
E
I
think
one
mechanism
we
could
use
here
in
processes
is
where
we
have
things
that
say
you
know,
there's
a
document
update
required.
It
would
probably
be
good
if
we
had
somebody
assigned
to
actually
do
that
document
update
and
you
can
see
here
in
the
case
of
this
one,
there
is
actually
a
pr
that
has
been
linked
to
this
one.
E
So
it's
fairly
easy
to
dig
down
into
these
items,
and
so
I
you
once
if
you
have
been
given
permission
to
this
project,
there's
another
view
that
I
set
up,
which
is
more
kind
of
like
a
kanban
board,
and
you
can
just
drag
and
drop
between
here,
but
because
this
is
changing
the
status
that
is
owned
by
the
project.
You
need
right
permissions
on
the
organizational
project.
H
Okay,
that's
it
asked
for
permissions
yet
again
that
just
made
a
question
occur
to
me
is
the
expectation
from
the
chairs
that
document
editors
will
respect
the
categorizations
that
you've
given
them
there?
So,
for
example,
I
went
through
and
did
a
couple
of
prs
for
issues
in
the
1707
bist
today
that
appear
to
have
consensus.
H
E
I
mean
that's
the
conversation
to
be
had
like
the
least
work
we
have
to
do
the
better,
but
I'm
I'm
more
than
happy
to
go
and
kind
of
reconcile.
I
think
if,
if
we
want
to
use
this
as
a
way
for
document
editors
to
communicate
with
chairs
that
this
is
the
status
of
where
we
are
up
to,
then
I'm
more
than
happy
that
that
document
editors
have
right
access
on
this
project
and
can
change
these
things
themselves.
H
E
Yeah
I
mean,
as
you
saw
from
roberto's
deck
like
he
had
a
slide
that
had
a
bunch
of
issues
that
were
open
and
to
the
base
to
talk
about
it,
and
then
we
did
that
in
the
last
ietf
meeting-
and
this
is
just
kind
of
like
hey
here's.
An
easy
way
of
keeping
that
kind
of
list
of
here
are
the
active
things
that
we're
talking
about
up
to
date.
Okay,.
E
It
was
unfortunate,
I
don't
seem
to
be
able
to
find
a
way
of
actually
getting
the
issue
number
to
appear
as
a
column.
But
if
you
hover
over,
you
see
in
the
bottom
left-hand
corner
the
issue
number,
and
I
will
note
roberto
that
you
called
out
in
your
rate,
limit
headers
and
issue
number
41,
and
I
can't
find
issue
number
41
in
the
repo
or
at
least
fish
41
had
a
very
different
title
than
the
one
that
you
call
them.
So
we
should
reconcile
there.
A
E
Yes
agreed
eric.
This
is
additional.
This
is
a
status
view
with,
hopefully
an
absolute
minimum
amount
of
additional
work,
and
we
could.
If
we,
if
we
decide,
we
could
just
completely
throw
away
the
status
column
and
just
use
labels,
and
we
could
use
labels
as
a
way
for
document
authors
to
just
put
a
label
on
an
issue
in
and
be
able
to
surface
that
up
at
the
central
place.
C
You're,
a
little
quiet,
rich
yeah,
sorry
about
that.
So
the
script
I
used
to
create
the
repos
when
we
have
a
new
document,
just
copies
standard
set
of
labels
that
came
from
you
know
marx
and
martin's.
First
thing
using
the
quick
group,
so
yeah
there's
no
way
to
say
these
are
labels
for
across
a
whole
organization.
C
E
E
E
K
K
I
don't
think
I
don't
think
we
have
a
good
plan
on
which
of
these
issues
should
be
addressed
before
we
create
a
new
version,
but
at
least
the
intention
definitely
is
to
keep
this
alive,
even
though
it
is
only
expired.
So
I
think
I
think
we
should
definitely
keep
it
in
there
and
hopefully
this
one
will
have
a
new
version
in
the
not
too
distant
future.
E
K
Like
some
of
the
things
that
you
put
there,
you
know
it's
like
okay,
somebody
should
be
assigned
to
it
so
that
we
know
who
to
go
back
to
and
yeah
good,
but
I
think,
like
your
table,
there
really
is
also
it's
just
great
for
housekeeping
right
like
making
sure
that
well
we're
discussing
many
things
but
nobody's
responsible.
Maybe
that's
not
a
good
sign.
B
K
H
E
H
Okay,
so
I'll
use
the
numbers
on
the
left,
even
though
we
know
that
they're,
not
the
real
numbers,
the
number
21
mapping
problem
details
into
a
header.
I
suggested
that
just
as
kind
of
a
thought
experiment,
because
it
has
come
up
in
the
past
before
of
of
conveying
this
information
in
a
header
when
you
don't
have
access
to
writing
to
the
response
body,
for
whatever
reason
and
or
or
if
you
want
to
expose
this
information
to
an
immediate
area
that
doesn't
want
to
crack
the
body
open.
H
H
I
think,
if
I
could
characterize
the
responses,
I've
seen
is
that
oh
yeah,
that
might
be
useful,
but
I
don't
really
have
an
immediate
use
for
it
now,
so
the
most
obvious
thing
to
do
would
be
to
drop
it
and
just
move
on.
I
think
I,
if
you
look
at
the
very
last
comment,
I
said:
if,
if
people
think
that
they
have
a
clear
use
for
this
or
or
that
it
might
be
useful
very
soon,
we
should
do
it.
H
While
we
have
the
document
open,
because
it's
just
easy
to
do
that,
otherwise
we
can
wait
on
it.
Knowing
that
you
know,
if
there
is
pressure
to
use
it
out,
there,
then
that'll
build
up
for
a
while
until
we
actually
publish
the
document
which
we've
experienced
for
a
lot
of
other
api
facilities
as
well.
H
E
H
A
L
H
Okay,
that
that's
that's,
actually
really
helpful
I'll.
I'm
happy
to
do
a
pr
and
just
see
what
it
looks
like,
and
it
may
very
well
be
that
that
that
reveals
that
it's
a
horrible
idea
or
horribly
complex
and
not
worth
the
effort
or
whatever,
but
I'm
willing
to
try
so
I'll,
give
it
a
go
next
issue.
Thank
you,
hans
that
was
helpful
and
and
roberto
down.
Thank
you
requiring
a
specification
document.
H
H
Excuse
me,
the
next
one
number
quote:
unquote
23
multiple
problems.
This
has
been
a
long
discussion
and
I
I
think
we
have
a
fairly
strong
agreement,
at
least
in
the
issue
and
in
the
discussions
we've
had
previously
in
working
group
sessions
on
a
path
forward
in
terms
of
deleting
some
text
about
status
code
207.
H
That
is
not
terribly
good
practice
and
putting
in
another
kind
of
warning
about
the
limitations
of
of
this
structure,
sanjay
was,
I
know,
a
bit
sad
about
removing
the
examples
that
he'd
put
the
work
into,
or
at
least
one
of
the
examples
that
he
put
the
work
into
adding
to
the
spec,
but
I
think
that
there's
a
fairly
strong
agreement
there.
So,
if
folks
want
to
look
at
that
pr
and
give
any
feedback,
I
again
intend
to
merge
that
pretty
soon
as
well.
H
H
I
I
would
hope
that
that
kind
of
documentation
in
the
first
instance
you'd
you'd,
put
it
into
some
of
the
you
know
whether
a
blog
or
some
sort
of
industry,
communication
or
something
or
something.
I
think
there
are
a
number
of
outlets
out
there
like
that
and
if
there
aren't
there
should
be,
you
know
you
kind
of
smashing
mag,
but
for
api
developers
or
whatever
you
know.
H
H
There
we
go
so
we
we've
had
this
latent
problem
in
a
lot
of
discussions
about
7807
and
it's
good.
I'm
actually
glad
that
this
was
opened
as
a
separate
issue,
so
we
can
just
discuss
it
separately
and
and
it's
that
the
7807
does
not
allow
new
standard
d
done.
What's
what
I'm
looking
for
properties,
members
whatever
to
be
added
to
the
structure
that
all
the
all
the
ones
that
aren't
in
7807
are
effectively
any
possible
name
is
under
control
of
the
problem
type.
H
Yeah,
I
think
that
that
we
have
a
couple
of
ways
out
of
this.
We
we
can
either.
You
know
zero,
which
I
didn't
put
into
this
message
is
the
status
quo,
which
is
don't
allow,
don't
say
anything
about
this
or
we
could
find
a
name
convention
for
new
standard
properties
that
doesn't
conflict
with
any
existing
usage.
H
So,
for
example,
add
a
prefix
to
new
standard
properties
and-
and
the
issue
with
that
is
that
we
by
nature
can't
know
all
of
the
usage
of
of
7807
around
the
world
and
that
we
won't
conflict
with
them
in
every
single
instance.
You
know
we
can
make
that
less
likely
by
choosing
a
weird
prefix
and
then,
of
course,
we
have
weird
ugly
prefixes
on
new
standard
properties
but
whatever,
but
but
that's
kind
of
like
a
just
a
you
know,
there's
a
risk
strategy
we
had
around.
If
we
take
that
path.
H
The
other
path
we
have
is
to
mint
a
new
media
type
for
problem
details
for
this
next
revision
and
the
concern
there.
You
know
that
gives
us
a
clean
slate
to
work
with,
but
of
course
that
also
risks
creating
fragmentation
that
now
api
developers
have
to
choose
which
one
they
use
and
there's
momentum
behind
the
old
one
and
oh,
would
I
have
to
use
this
new
thing,
but
I
don't
know
if
everybody
supports
it,
blah
blah
blah
blah
and
so
that
that
creates
more
confusion.
H
Potentially
there
is
a
third
option
and
that's
kind
of
the
unspoken
option
in
1707,
which
is
we
can't
define
new
standard.
This
is
recognized
in
every
problem
instance
across
the
world,
but
what
we
can
do
is
create
new
conventions
that
new
problem
types
or
any
problem
types
can
opt
into
and
say:
oh,
yes,
I
use
that
convention.
H
So,
for
example,
we
could
create
a
convention
that
there's
a
problem
pointer
and
it
means
something
when
the
type
says
it
means
something
not
quite
as
automatic
and
nice
as
you'd
like,
but
you
know
maybe
a
path
forward
without
breaking
too
much.
I
I
don't
have
any
strong
feelings
here
personally,
if
you
want
to
call
that
option
zero
one,
two
and
three,
but
I
kind
of
feel
like
I.
I
I'm
most
against
option
two,
I
think
minting
a
new
media
type.
H
There
should
be
a
fairly
high
bar
against
it
and
I
think
option
one
actually
probably
could
work.
My
only
concern
there
is
there's
a
lot
of
experiments
that
people
want
to
have.
I
think
about,
oh,
that,
that's
a
good
idea.
This
is
a
good
idea
and
we
should
have
a
chat
about
what
the
bar
is
for
new
problem
for
new
standard
attributes.
I
K
K
The
third
one.
Actually
I
have
my
problem
with
that
is
that
this
means
that
that
kind
of
each
type
would
need
to
kind
of
opt
in
individually,
and
I
think
in
many
cases
you
might
rather
have
a
situation
where
you
say
my
api
always
uses
these
fields
and
then
it
would
become
kind
of
complicated
to
say
well,
and
I
have
these
28
types
and
then
all
these
28
types
so
to
speak
would
need
to
opt
in
into
that
additional
field
that
you're
trying
to
use.
K
So
so
I
think
that
one
is
like
it
doesn't
scale
so.
Well,
I
think
so
my
I
think
my
preference
would
be
to
go
with
number
one
and
to
go
with
uri
some
kind
of
uri
as
a
prefix,
and
then
I
think
the
risk
of
conflicts
is
relatively
low
and
that's
well,
given
what
rfc
7807
already
does.
I
think
that's,
maybe
the
best
thing
that
we
can
think
of.
H
I
I
I
think
I
agree
with
on
most
things
there
I
think
the
for
me.
The
problem
with
the
third
option
is
that
tools
want
to
be
able
to
automatically.
You
know
invoke
the
semantics
without
recognizing
a
particular
problem
type
and
then
you
can
offer
richer.
You
know
handling
of
a
problem
without
having
to
know
its
particular
semantics
and-
and
if
it's
opt-in
like
that,
then
we
that
implies
that
we'd
need
some
sort
of
problem
type
description
format
to
enable
tools
to
to
process
that
which
is
kind
of
nasty.
H
And
frankly
we
know
it's
not
going
to
happen.
What
they'll
do
is
just
say:
oh
look,
it's
using
problem
pointer.
I
reckon
it
probably
means
that,
even
though
I
don't
know
for
sure
so
yeah
I
think
you're
right.
I
think
that
number
one
is
probably
the
right
way
to
go.
I
I
do
have
kind
of
this
visceral
reaction
to
using
uris
as
json
property
names.
B
H
E
We
introduced
a
vocabulary
and
then
you
declare
that
we
are
using
this
dialect,
which
is
a
set
of
vocabularies,
so
there
may
be
some
mechanics
it.
It's
a
little
interesting
to
get
your
head
around,
but
there
may
be
some
mechanics
that
we
could
reuse,
but
it
is
somewhat
dependent
on
how
well
adoption
of
dialects
and
vocabs
comes
because
it's
fairly
new
in
json
schema.
H
So
if,
if
I
can
respond,
oh
is
it
working
now
fantastic.
It's
telling
me
that
it's
success,
big
green
box,
that's
great!
I
I
have
again
a
kind
of
a
visceral
reaction
that
it's
very
similar
to
link
data
world
where
they're,
like
you
know
the
to
me
the
the
whole
idea
there
is
well.
We've
got
this
data
model
that
we
overlay
on
top
of
json,
but
it
looks
like
normal
json
and
that's
kind
of
an
attractive
nuisance.
H
You
know
because
a
developer
who
doesn't
use
linked
data
will
come
along
and
say:
oh,
look,
it's
json,
but
if
they
don't
use
that
data
model
they
might
actually
really
mess
things
up,
and-
and
so,
when
you
overlay
these
data
models
on
top
of
really
attractive
native
data
models
and
processing
models
and
so
forth
it
it
becomes
tricky
for
for
everyday
developers
to
use
it,
and
so
I'm
a
little
wary
of
those
sorts
of
things.
I
think
it
should
behave
like
it
looks.
You
know.
E
H
H
H
I
I
I
One
of
the
things
there
that
we've
discovered
is
that
there's
some
use
for
having
the
ability
to
to
mark
the
time
of
a
request,
particularly
in
that
case,
for
dealing
with
anti-replay
as
I'll
get
into
later,
but
there's
a
general
class
of
things
where
you
put
the
current
time
into
a
request,
or
something
like
that,
so
that
you
limit
the
the
time
over
which
something.
Oh,
oh,
that's
a
nice
feature.
I
Someone
spent
a
lot
of
time
on
that.
I
can
move
the
slides
down,
so
the
purpose
of
this
craft
is
to
basically
explore
the
use
of
putting
the
current
time
in
a
request
and
all
of
the
hazards
that
that
necessarily
come
with
that
moral
and
otherwise,
with
the
publicly
trying
to
make
date
time
stamps
and
requests.
I
So
the
specific
that
we
have
in
ohio
is
that
requests
are
replayable
in
that
context,
which
is
not
particularly
good
and
so
having
a
replay
strategy
is
particularly
useful
and
in
order
to
manage
the
state
commitments
on
servers
that
are
doing
anti-replay,
you
probably
want
to
have
something
like
a
date
or
sequence
number
or
some
sort
of
monotonically
increasing
thing.
A
date
is
kind
of
okay.
I
Having
a
date
means
that
if
you
receive
a
request,
that's
been
replayed,
you
can
rapidly
identify
it
as
such
and
then
just
out
of
hand
reject
it
and
then
for
those
requests
that
are
within
a
certain
window
of
the
current
time.
You
can
simply
say
well
I'll,
accept
those
and
remember
some
other
details
of
the
request
so
that
if
another
one
with
the
same
details
comes
in
again,
you
can
quickly
reject
it
as
a
duplicate
without
the
date
there's.
I
So
probably
the
biggest
part
of
the
document
talks
about
the
ad
clock
problem
so
shockingly
common
that
our
clients
and
servers
have
a
disagreement
about
what
time
it
is.
It's
quite
often
the
case
that
the
clients
are
very,
very
badly
wrong.
We've
seen
times
that
are
in
the
wrong
millennium,
and
it's
not
that
unusual
to
see
things
that
are
months
or
years
out
of
out
of
date.
I
So
having
you
having
a
means
to
break
that
is
interesting.
There's
a
scheme,
that's
suggested
in
the
document
that
simply
says,
take
the
date
from
the
response
and
try
again,
of
course,
using
an
untrusted
time
from
an
arbitrary
server.
Random
servers
on
the
internet
is
probably
unwise.
Talk
about
that
a
little
bit
as
well
talk
about
the
caching
interaction
and
some
of
the
things
that
might
happen
if
you
have
an
intermediary
in
the
path.
I
I
The
servers
that
back
them
don't
often
get
the
get
the
time
right.
So
city
ends
often
fix
it
up
for
you
the
implication.
There
is
generally
that
this
is
no
problem,
but
if
the
server
time
is
very
very
badly
wrong
and
it's
rejecting
requests
and
the
cdn
is
fixing
the
date
up
on
the
way
out,
it
could
mean
that
you
never
get
a
request
through
ever.
I
I
I
B
H
H
I
think
maybe
the
focus
the
way
to
make
this
discussion
useful
is
is
do
api
folks,
think
that
having
this
document
and
these
clarifications
in
this
problem
type
would
be
useful
for
api
consumers
and
api
designers
and-
and
if
so,
then
this
is
a
natural
home
for
it,
and
if
it's
a
little
more
scratching
your
head,
I'm
not
so
sure
we
can
probably
just
do
an
http
or
in
ohio
or
wherever
and
if
it
gets
used
elsewhere.
That's
great,
but
it's
not,
you
know
necessary
to
have
it
here.
I
A
Yeah
yeah.
Well,
thanks
martin,
I
I
think
it's
okay,
the
documents
to
be
related
to
timestamps
in
general,
but
I
I
really
don't
want
to
mess
with
dave
because-
and
I
I'm
not
even
sure
that
this
is
the
right
place
where
in
information
that
should
be
in
in
some
way,
guaranteed
should
be
used.
But
this
is
a
personal
opinion.
This
this
is
my
opinion
for
seeing
the
networks
and
for
and
in
general,
for
whatever
is
related
to
either
confidential
integrity,
or
that
is
not
just
an
operative
information.
I
G
E
I
think
this
is
daryl's.
Speaking
from
an
api
perspective,
I
haven't
seen
this
particular
issue.
Come
up
a
whole
lot,
although
I
can
imagine
four
apis
that
require
to
do
signed
requests.
This
does
get
a
lot
more
interesting
and
I
think
just
the
fact
that
we're
using-
and
it
does
include
a
problem
type
as
a
way
of
describing
it
does
kind
of
correlate
it
back
to
apis
fairly
strongly.
H
I
Yeah
I
I
haven't
spoken
to
justin
about
this
one
in
the
discussion
I
have
with
roberto
on
the
list.
I
think
we
we
kind
of
concluded
that
the
signatures
thing
was
was
less
directly
applicable
to
this
one.
It's
it's
often
the
case
that,
when
something
signs
something
they
put
the
time
at
which
they
signed
it,
but
the
purpose
of
that
is
is
usage
limitation
rather
than
to
indicate
the
the
current
time,
and
so
the
the
connection
to
signatures
is
a
little
weaker
than
than
that.
I
H
B
H
I
My
read
of
the
item,
potency
stuff,
is
that
this
is
complementary
and
entirely
complementary.
You
can
use
both
or
neither
or
one
and
and
that's
going
to
work
out
pretty
well
depending
on
what
it
is
that
you're
looking
to
do
so.
I
think
this
is
probably
okay
for
that
and
one
of
the
nice
things
about
the
item.
Potency
work
is
that
it
could
be
a
way
to
to
signal
what
what
aspects
of
the
request
can
determine
that
it
is
either
put
or
not,
which
is
sort
of
very
complimentary.
E
Section
now
daryl,
we
we
are
in
the
proposal
for
new
working
group
documents,
which
we
are
now
more
enthusiastically
open
to.
I
believe
we
had
last
time
a
conversation
about
link
template
as
a
document
to
do
a
call
for
adoption,
unlist,
which
I
believe
we
failed
to
do,
and
so
we
are
recommitted
this
time
we
really
will
do
call
for
adoption
and
we
have
more
renewed
enthusiasm
about
adopting
more
docs.
C
K
Yeah
thanks
rich.
This
is
eric
I
just
wanted
to
so
because
last
time
I
said,
I
would
get
in
touch
with
iraqi
and
see
you
know
how
he
feels
about
it
and
so
forth,
and
in
my
defense
I
did
multiple
times,
but
not
much
progress
was
being
made.
So
I
still
have
I
don't
know.
Last
thing
I
heard
from
him
was
that
he
tried
to
join
mailing
list
and
I'm
not
quite
sure
of
how
the
status
is
there.
K
I
don't
think
I've
seen
him
on
the
mating
list,
but
at
least
I'm
still
pinging
him
on
a
regular
basis.
I'll
keep
doing
that,
and
hopefully
there
will
be
some
path
forward.
I'm
not
quite
sure
whether
iraqi
has
the
the
cycles
to
actually
go
forward
with
the
draft,
but
one
way
or
the
other.
At
least
he
knows
that
that
the
group
is
interested
in
the
general
topic
and
I'll
keep
the
group
updated.
If
I
make
any
progress.
C
L
D
Hello,
I
wanted
to
ask
the
chairs
and
the
working
group
to
possibly
consider
updating
the
milestones
we
don't
need
to
have.
I
think
it's
useful
to
have
some
sort
of
record
of
you
know.
What's
the
current
status
of
the
documents,
even
though
we
have
an
awesome,
github
project
view
now,
but
this
is
a
more
high-level
general
view
and
we
can
use
the
next
and
later
and
last,
instead
of
dates.
D
I
C
Yeah,
I
I
think
yes
having
some
kind
of
priority
or
a
rough,
you
know
t-shirt
size
estimate
is,
it
will
be
worthwhile
daryl
mark
and
I
can
discuss
offline
with
francesca
and
post
them
and
then
see.
If
the
working
group
says
we
got
it
wrong.
So
we'll
do
that
between
now
and
the
next
ietf
how's.
That.
E
I
suggested
that
I
think
twitter
is
actually
quite
a
common
gathering
spot
for
api
community
folk,
and
so
if
we
want
to
get
the
attention
of
more
people,
I
think
that
probably
would
be
a
good
idea.
So
I
guess
it's
just
a
case
of
understanding
exactly
what
events
we
would
want,
so
that
we
understand
what
kind
of
frequency
that
that
might
spam
a
audience
with
notifications.
E
H
B
H
B
C
C
C
Save
the
best
for
last
save
the
best
for
last
thanks
the
authors
for
their
patience
and
good
nature.
Yes,
there
was
one
change
made
in
the
last
good
point.
One
change
made
after
the
set
of
isg
and
itf
reviews,
which
turned
two
shoulds
into
a
may
two
shirts
into
a
must
sorry
for
interrupt
I'll
post,
the
diff
to
the
list,
and
if
anybody
disagrees
by
the
end
of
you
know
next
week
speak
up,
but
it's
just
tightening
your
requirement.
C
D
So
I
don't
know
if
eric
wants
to
share
more
in
detail,
but
since
I'm
shepherding
this
through
the
ist
process,
I
can
say
that
yeah
just
for
summary,
if
someone
like,
if
people
haven't
followed
this,
but
we
had
to
do
another
ipf
last
call
because
of
process,
because
some
down
ref
were
missed
that
were
in
the
ice.
So
we
started
that
and
it's
ending
the
28th
of
march
and
I
also
requested
an
internationalization
directorate
review.
D
D
C
All
right
thanks
everyone.
I
I
want
to
say
that
you
know
this
was
sort
of
a
different
group
for
the
ietf.
We
have
I'm
very
impressed
by
all
the
authors
when
they
go
out
and
they
say.
Oh,
I
spoke
to
the
opening
api
people.
I
spoke
to
the
ammo
people.
These
are
whole
communities
that
are
certainly
new
to
me
as
an
ietf
geek,
but
I
think
we're
doing
a
very
good
job.
I
think
we're
bridging
appropriate
communities
and
getting
good
stuff
done
sometimes
when
east
meets
west
there's
little
friction
and
frustration.