►
From YouTube: IETF111-HTTPAPI-20210727-2130
Description
HTTPAPI meeting session at IETF111
2021/07/27 2130
https://datatracker.ietf.org/meeting/111/proceedings/
B
A
A
A
A
A
Well,
I
guess
let's
get
started,
we
only
have
an
hour.
We
have
a
couple
of
good
documents
to
talk
about.
There's
been
some
discussion
on
the
list,
so
welcome
to
the
http
api
at
ietf,
111.
A
Some
administrative
overhead
proceedings
at
the
itf
are
governed
by
the
notewell.
By
the
end
of
the
week
we
were
originally
scheduled
for
friday.
This
got
moved
to
today,
tuesday,
so
it
might
be
newer
to
some
of
you,
as
opposed
to
by
the
end
of
the
week,
everyone's
burned
out
from
seeing
all
of
these
bullets.
A
There
are
particular
policies
contributions
if
you
speak
up
at
a
meeting.
You
are
agreeing
to
be
governed
by
these
no
well
processes,
we're
not
going
to
go
over
the
details
of
them,
but
basically
treat
people
with
respect,
acknowledge
that
the
meetings
may
be
made
public.
In
fact,
we
record
most
of
these
videos.
You
can
see
in
the
lower
right
corner,
it
says
recording
and
they
are
often
put
out
on
our
youtube
channel.
A
A
Administrative
stuff
notewell
we
did,
we
need
a
minute
taker.
Does
anyone
want
to
speak
up
in
the
chat
and
say
they're
willing
to
take
minutes.
A
A
fairly
easy
thing,
you
just
you,
don't
have
to
record
conversations
and
what
people
say
mainly.
You
know
the
minimum
is
record
this
document.
Here's
the
action
item:
here's
the
proc,
the
progress.
If
you
want
it's
a
live
editing
via
codemd
markdown
stuff,
the
split
screen,
I'm
sorry
the
slide
says:
111
acme,
that's.
A
A
A
Okay,
you
really
don't
want
me
to
pick
somebody
at
random.
A
Great,
thank
you
mike
mike
is
a
co-worker
of
mine,
so
I
owe
him
now
all
right.
We
have
a
minute
taker.
This
is
the
agenda
called
from
the
mail
that
daryl
sent
to
the
mailing
list.
A
few
days
ago,
we
have
a
couple
presentations
set
and
some
other
documents
that
we
can
talk
about.
A
A
If
you
want
to
just
get
okay
well,
the
other
deal
is
you
can
ask
to
join
the
queue
which
is
in
the
far
left
of
the
upper
left-hand
corner
of
the
screen,
and,
let
me
go,
click
on
mark.
Go
ahead.
A
C
F
First,
up
was
just
a
discussion
around
link
set,
oh
okay,
sure.
F
Yeah
no
bro,
so
the
the
we
are
at
the
point
where
we
were
approaching
very
close
near
to
last
call.
There
appears
to
be
a
one
open
thread
on
the
the
mailing
list,
and
I
was
just
wondering
whether
we
can
have
some
opinions
and
maybe
make
some
progress
on
that
particular
issue
or
at
least
get
a
status
on
where
we
think
we'll
end
up.
F
So
the
the
item
that
is
open
is
whether
or
not
the
json
representation
of
the
links
that
should
include
support
for
multilingual
titles
seems
to
be
fairly
agreed
upon
that.
It
is
not
a
large
use
case,
but
there's
the
question
of
well
is
the
consistency
between
the
formats
more
important
than
the
additional
complexity
that
has
been
added,
and
I
pasted
the
link
in
the
chat
to
the
discussion.
F
I
see
that
the
primary
conversation,
julian,
isn't
with
us
probably
time
zone
wise
and
looks
like
eric,
isn't
there
either?
So
it
might
be
a
rather
stilted
conversation
that
we
probably
should
take
back
to
the
list.
Then.
E
Phil,
you
have
well
just
to
say
I
was
one
of
the
people
taking
part
in
the
conversation
with
everybody.
E
Gs1
and
yeah,
I
think
it
was
my
phrase:
vanishingly
small
number
of
websites
use
content
negotiation
by
language.
I
wish
it
were
more,
but
it
just
isn't
and
serious
people
don't
like
content
negotiation
at
all,
let
alone
content
negotiation
by
language.
So
it
does
add
complexity.
E
I
just
dread
the
thought
of
going
back
to
people
we've
been
telling
everybody
we've
implemented.
Lig
set
it's
not
going
to
change
now
we're
not
going
to
change
it.
This
is
now
stable
and
now
we're
talking
about
changing
it
and
it's
going
to
look
slightly
red-faced
if
we
have
to
go
and
change
it,
but
that
is
a
very,
very,
very
poor
reason
to
want
it
to
stay
as
it
is.
E
I
understand
that
so
if
it
changes
okay,
but
we've
kind
of
implemented
it
the
way
it
is
with
multilingual
labels
and
it
wasn't
a
big
problem.
F
Out
of
curiosity,
the
folks
involved
with
link
relation
types:
is
there
any
opinion
as
to
whether
or
not
the
json
serialization
should
maintain
consistency
there
any
concern
about
it
if
it
were
to,
if
pro
we
were
to
go
forward
with
removing
that.
C
C
F
Okay,
well,
we
I'm
sure
eric
and
julian
can
listen
to
recording
and
we
can
take
the
conversation
back
to
the
list.
Hopefully
we
can
close
off
that
issue
and
then
we
will
make
the
recommendation
to
go
to
last
call.
I
F
C
Yeah,
so
this
is
rfc
7807
bis,
revision
of
the
problem,
details
for
http
api's
document
next.
C
Slide
so
there's
the
issues
list,
the
the
sub
bullets
are
the
ones
that
have
been
closed
recently,
so
we've
done
a
lot
of
editorial
and
procedural
kind
of
updates,
and,
oh
that's,
okay.
Now
it's
back.
We
kind
of
had
a
just
a
question
of
whether
or
not
to
keep
the
external
serialization.
We
decided
that
it
was
doing
no
harm.
C
C
So
we
kept
it,
we
added
a
preliminary
and
non-normative
json
schema
independence,
a
it
pretty.
Much
has
to
be
non-normative
because
jason's
schema
is
not
adopted
by
the
itf,
yet
it
doesn't
have
any
status
and
we
can't
really
reference
it
normatively
without
a
lot
of
headaches,
and
we
also
did
some
some
kind
of
clarification
around
the
use
of
uris
and
types
of
instances
in
number,
11
and
14,
but
there's
still
some
work
to
do
there.
I
think
which
we'll
get
to
in
a
second
next
slide.
C
So
I
wanted
to
go
through
some
of
the
open
issues.
This
is
not
all
of
them,
but
these
are
kind
of
the
high
points
to
get
some
any
any
feedback
that
people
wanted
to
give.
The
first
is
number
six
on
multiple
problems.
You
know
this
is
where
you
have
multiple
instances
of
the
same
problem.
Sorry,
there
are
two
major
cases
here
that
we
can
identify.
C
One
is
when
a
service
has,
you
know
multiple
instances
of
the
same
problem.
So,
for
example,
you
know
there
were
15
validation
errors
in
the
input,
and
this
seems
like
it's
relatively
easy
to
address.
We
it's
a
best
practice
and
and
problem
design
issue.
We
need
to
give
people
some
examples
and
give
some
guidance
about
how
to
create
problem
types
that
can
convey
multiple
instances
of
the
same
problem
and
what
that
might
mean.
So
that's,
relatively
straightforward.
C
The
more
interesting
part
of
this
is
when
you
have
multiple
problems
of
different
types
at
the
same
time,
so
there's
a
validation
error
and
I
don't
know,
there's
an
authentication
error
at
the
same
time,
for
example,
and
and
so
you
know
when
we
put
together
7807
one
of
the
design
goals
was
that
you
know
there
can
only
be
one
http
status
code.
C
The
problem
is
just
explaining
that
status
code
with
more
detail,
and
so,
if
you,
you
know
in
http,
there's
this
natural
process
sorting
where
processing
order,
where
you
do
things
like
check
for
authentication
or
check
to
make
sure
the
method
is
supported,
and
all
these
other
different
things
and
then
eventually,
you
process
the
content,
and
so
you
know
the
natural
way
to
do
this
in
http
is
to
choose
the
first
or
the
most
important
problem
and
give
the
details
about
that.
C
The
other
way
of
going
about
this
would
be
to
create
a
multiple
problem,
type
or
a
whole.
New
media
type
to
you
know,
encapsulate
multiple
problems,
but
that
kind
of
doesn't
really
fit
well
with
the
way
that
http
works
and
it
kind
of
shoves
people
towards
a
situation
where
they,
you
know,
have
to
have
a
really
bland
generic
status
code.
Often
the
multi
status
stats
code,
two.
What
is
it
217?
C
I
forget
207,
it's
been
a
while
it
was
defined
by
web
dab
for
this
kind
of
situation,
and
it
it's
it's
quite
obscure,
and-
and
so
my
inclination
after
the
discussion
and
going
back
and
forth,
is
that
we
should
recommend
in
this
case
that
you
choose
one
and
surface
that
problem
type
and
then
give
some
people
some
guidance
along
those
lines,
and
I
wanted
to
talk
through
that
see
what
other
people
had
feedback
on.
C
J
So
actually
I
wanted
to
know
from.
There
are
people
on
the
list
here
who
have
used
707
and
how
they
dealt
with
this,
because
I
also
know
that
when
we
looked
at
it
a
while
back
in
paypal
we
had
to,
then
you
know
define
our
own
response
type
for
errors,
where
you
can
have
multiple
instances
and
that
kind
of
was
not
a
good
thing.
You
know
if
you
could
have
adopted
rfc
707.
J
That
would
have
really
helped,
but
I
think
this
was
one
issue
where
you
know
we
thought
that
it
doesn't
solve
our
purpose,
and
you
know
paypal
defined
its
own
type
and
I
believe
that
microsoft
also
has
done
something
similar
to
my
probably
daryl
can
give
some
more
information
on
that.
But
people
do
then
you
know
developers
define
their
own
type
and
that
reduces
the
acceptance
of
7807.
J
So
I
want
to
know
from
others
and
what
they
think
about
this,
because
we
can
always
add
examples
provide
more
guidance,
but
if
they
are
still
going
to
go
and
define
their
own
type,
then
it
defeats
the
purpose.
B
F
Just
as
another
example,
the
the
microsoft
api
follows
from
oh
data
specification,
and
it
does
support
the
idea
of
having
multiple
I
have
to.
I
don't
see
very
much
use
of
it
and
the
few
cases
we
do
see
it
it's
because
the
request
that
is
made
is
more
of
a
batch
type
of
operation.
It's
do
this
thing
on
add
these
five
different
things
and
some
of
them
will
succeed
and
some
of
them
will
fail.
D
I
mike
wanted
to
say
that
I've
basically
been
returning
the
case
where
this
comes
up
for
me
is
usually
in
400
class
errors,
input
problems
or
something's
missing
and
using
the
examples
in
the
7807
seems
pretty
fine
to
me.
I
just
returned
like
the
invalid
params
array,
or
something
like
that.
If
and
if
it
comes
up
to
actually
being
different
status
codes,
I
like
mark
had
talked
about
just
pick.
The
first
one
that's
encountered
and
stopped
there.
D
I
I
don't
think
we
should
kind
of
invent
something
that
leads
someone
into
kind
of
mucking
about
with
the
status
coding
anyway.
I
I
think
the
example.
The
resolution
that's
on
here,
which
is
guidance
on
how
to
you
know,
return.
Multiple
instances
of
the
same
problem
is
just
guidance
on
some
arrays
and
I
would
say
they
should
choose
one
from
the
top
of
the
stack.
So
that's
just
my.
D
C
C
Granularity
of
problem
types
is
probably
useful
as
well,
and-
and
maybe
this
gets
to
another
issue
which
we'll
discuss,
which
is
the
possibility
of
a
you,
know,
registry
of
problem,
types
that
are
well
defined
and
suitable
for
use.
C
So
what
I
might
do
is
start
to
work
on
a
pr
to
show
people
and
then
see
if
that
convinces
folks,
that
this
is
the
right
way
to
go.
If
that
makes.
F
H
The
reason
that
sanjay
described
as
multiple
problem
types
were
needed
for
400
cases,
so
we
had
like
very
standardized
and
generalized
like
problem
types
like
malform
request
invalid.
You
know
minimum.
H
Max
item
invalid
integer
value
like
so,
we
had
bunch
of
enumeration
for
400
so
and
given
a
request,
we
could
emit
multiple
problem
types
and,
and
the
reason
why
we
could
not
use
7807
as
is
for
400,
was
one
of
the
reasons.
So
if
we
can
standardize
have
some
general
enumeration
for
400s,
where
we
can
emit
multiple
problem
types
instead
of
just
saying
invalid
pattern,
I
think
that
would
help
towards.
F
J
So
the
first
one,
I
think
the
multiple
instances
of
the
same
problem
is
the
most
common
thing,
which
I
would
think
the
second
one
happens
in
in
limited
use
cases.
So
if
everyone
thinks
that
examples
and
guidance
would
help
that's
great,
I
had
also
suggested
you
know.
Should
we
have
those
problem,
common
problem
types
defined
somewhere?
J
I
think
the
the
I'm
trying
to
remember
the
answer
on
that,
but,
as
jaideva
was
saying
that
you
know
some
of
the
problem
types
might
be
common
across
apis
and
where
those
could
be
defined,
so
probably
mark
is
going
to
cover
that
with
the
registry
issue.
I.
C
Guess:
okay,
so
I'll
I'll
write
up
the
r
and
put
it
to
the
left,
and
we
can
talk
through
that-
and
I
think
maybe
seeing
it
in
in
text-
might
help
us
make
a
decision
here.
C
So
issue
number
seven
is
indeed
that
very
issue.
We
talked
about
this,
I
think
in
our
last
meeting
and
we
kind
of
came
to
the
place
where
we
said.
An
iana
registry
was
probably
a
good
idea,
and
so
I
put
together
a
pr
for
that
which
seems
to
have
some
support.
C
I
think
the
only
question
here
is
whether
or
not
we
use
an
ht.
We
recommend
an
http
prefix
for
those
problem
types
or
whether
we
recommend
the
urn
form
of
uri
for
those
problem
types.
Does
anybody
have
any
preferences.
G
We
we
we
implemented
problem
types
in
a
library
and
one
of
the
things
we
did
is
we
we,
if
we
encounter
an
error,
is
we
we
link
to
a
wiki
page?
Would
something
like
that
stop
being
possible
with
this.
C
And
what
form
would
those
uris
take?
I
think
you
know
using
the
https
uri
is
effectively
an
advertisement
for
the
registry,
so
people
can
go
and
find
the
registry
easily
and
get
perhaps
a
little
bit
more
information
about
the
type,
whereas
the
urn.
Obviously
you
can't
dereference
it
it's
a
little
more
compact.
C
We
don't
have
to
worry
about
load
issues
on
the
eye
in
a
cerner,
so
although
people
are
doing
the
right
thing,
they
won't
be
dereferencing
those
automatically
anyway.
So
I
I
don't
have
strong
feelings
about
this.
One.
B
H
Should
this
be
prefixed
with
http
at
all,
or
we
can
avoid,
because
we
can
think
of
using
this
problem
by
definition
for
non-http
protocols
as
well
like
messaging
or
elsewhere,
so
maybe
make
prefixing
it.
Stp
may
may
make
it
very
specific
and
this
year
to
use
in
other
protocols
if
we
want
to
use
just
just
an
opinion.
C
But
but
it's
really
just
being
used
as
an
identifier
here,
it's
not
being
used
to
to
dereference
the
uri,
so
at
least
this
particular
operation,
and
furthermore,
that
you
know
the
whole
scope
of
the
document
is,
is
very
explicitly
http
problems.
It's
not
trying
to
be
a
universal.
You
know,
protocol
problems
listing.
E
E
J
Reading
that
trade
on
the
multiple
problems
and
you
you
said
that
the
status
quo
code,
error,
ref
error-
has
to
semantically,
you
know,
refer
proper
status
score,
and
that
made
me
think
that
you
know.
J
Ideally,
what
I
was
expecting
was
that
the
response
that
comes
in
http
may
be
formed
at
some
other
layer
which
is
not
at
the
let's
say:
http
server
may
not
be
doing
it
and
it
may
be
coming
from
somewhere
else,
some
business
service
down
or
domain
service
downstream,
which
might
be
forming
that
error
response
and
then,
when
it
bubbles
on
the
top
there,
it
is
associated
with
the
status
quo
and
sent
it
over
the
wire
in
response.
J
So
that
helps
you
know.
If
it
is
now,
I
you
know,
a
problem
type
has
a
status
quo
defined
in
it
and
we
cannot
change
it.
I
I
saw
your
response
on
that,
but
I
was
just
thinking
that
what
jayadeva
was
mentioning
right
in
the
messaging
system.
You
could
still
use
this
response,
problem,
type
and
and
and
problem
details
associated
with
it
and
either
it
can
stream
over
a
non-http
protocol.
And
then,
then
you
can
associate
it
with
http
status
when
it
comes
on
the
top.
C
C
C
C
D
I
prefer
the
urn
just
to
throw
that
in
the
mix.
It's
a
little
less
likely
to
be
dereferenced
and
more
likely,
I
think,
to
be
easily
managed.
But
that's
just
me.
C
Okay,
next
slide.
C
So,
as
I
understand
it,
some
folks
who,
who
want
to
build
tooling
for
for
handling
problems
or
debugging,
want
to
be
able
to
to
tell
deterministically
whether
or
not
document
the
the
type
uri
is
dereferencable,
so
they
can
condition
their
behavior
on
that
to
say
to
present
to
the
user.
C
You
know
for
more
information,
follow
this
like
or
whatever,
and
so
that
could
be
a
boolean
flag.
You
know
yes,
the
type
uri
is
resolvable,
feel
free
to
go
and
try
and
show
it
to
the
user
or
it
could
be.
Excuse
me
a
a
separate
field.
You
know
in
case
the
documentation
has
to
move,
but
you
don't
want
the
type
uri
to
change.
C
I
think
there's
maybe
a
whole
discussion
to
be
added
around
which
of
those
two
forms
is
preferable,
but
but
the
function
is
is
still
the
same
is
to
give
those
tools
a
more
solid
hint,
but
I
think
it
can
only
be
a
hint
because
you
know
at
run
time
when
the
debugging
tool
is
actually
running.
It
could
try
and
de-reference
that
url
and
discover
that
there's
a
network
problem
or
it's
a
404
or
whatever-
and
so
it's
it's
not
you
know
a
guarantee,
it's
it's
still
just
a
hint.
C
Furthermore,
to
complicate
this
even
more,
I
think
adding
a
new
standard
member.
So
a
new
member
to
the
problem.
Dictionary
7807
doesn't
allow
that
because
it
can
conflict
with
the
extension
attributes,
the
extension
you
know
the
type
specific
metadata,
and
so
it's
a
closed
set
there.
That
may
or
may
not
be
a
great
design.
E
C
I
think
the
options
on
the
table
are
if
we
think
that
adding
a
new
member
is
going
to
break
existing
problem
types
about
fun
problem
types
we
can
create
a
new
media
type,
which
we've
discussed
in
the
past
and
shied
away
from
the
problem
is
that
by
doing
so
we're
going
to
perhaps
bifurcate
support.
You
know
the
more
different
formats
for
this.
You
have
out
there
the
harder
it
is
to
get
momentum
behind
any
one
format,
and
so
that's
not
great.
C
We
could
convince
ourselves
that
adding
a
new
standard
member
is
not
going
to
break
anyone,
and
if
we
can
convincingly
do
that,
we
can
just
go
ahead
and
do
it.
I
think
the
problem
there
is
that
knowing
all
the
different
problem,
types
that
are
existing
out
in
the
world
is
difficult,
it's
it's
not
like.
The
specification
has
seen
hugely
wide
adoption,
but
I
don't
really
have
confidence
that
we
have
everybody
who's
using
it
in
the
room
here
today
or
on
the
mailing
list.
C
We
cannot
do
this,
we
can
just
say
if
you
want
to
surface
this
information
to
users,
you
have
to
you
know,
do
a
predictive
look
up
in
the
back
in
the
in
the
background,
and
if
it
succeeds,
then
you
can
change
your
ux,
maybe
cache
the
results
to
make
that
a
little
less
painful
and
so
forth,
and
and
maybe
write
some
some
text
about
how
you
would
do
that.
So
what
do
folks
think.
I
K
If
you,
if
we
want
to
encourage
people
to
write
docs,
wouldn't
it
be
wise
that
whatever
we
choose
the
default
is
the
docs
would
be
resolvable
and
the
real,
like.
The
other
option
is
that
you
indicate
that
it's
not
resolvable.
C
I
believe
there
is
a
requirement
that
the
docs
should
be
resolvable.
It's
a
sugar
double
requirement,
so
we
already
encourage
people
to
do
that
if
they
really
don't
want
to
do
that,
you
know
for
personally.
I
think
that
if
you
really
don't
ever
want
your
docs
to
be
resolvable,
you
should
make
an
ern
or
some
obviously
non-resolvable
uri
scheme.
But
having
said
that,
I
think
there's
a
lot
of
merit
to
have
it
accidentally
be
resolvable.
So.
K
Yeah,
I
agree
so
we
we
actually
do
resolve
docs.
The
same
smacks
as
usually
a
wiki
page,
but,
as
you
say,
we
might
be
down,
you
might
have
a
network
error,
so
I
I
don't
think
we
can
ever
guarantee
it
unless
it's
loading
from
local.
K
The
options
that
I
saw
that
that
seemed
reasonable
to
me
is
providing
it
via
the
link
header
that
could
come
on
on
the
same
problem
result.
So
you
don't
actually
need
to
specify
this
in.
You
can
expect
it
on
top
of
seven
seven,
eight
or
seven
or
use
a
standard
member,
that's
actually
two
characters
or
less,
because
that
seems
to
be
possible
with
your
previous.
J
I
think
so
from
api
developers
perspective,
there
is
real
cost
if
the
developer
experience
is
hurt
by
not
providing
enough
information
about
the
error,
and
it
also
increases
support,
cost
and
all
that
stuff.
J
So
if
it
is
a
separate
link
header,
it
may
not
help
because
how
the
error
is
processed
on
the
client
side.
You
know
it
should
rather
be
with
the
actual
problem
details
object
rather
than
somewhere
else.
That's
my
opinion,
but
I
think
for
this.
We
really
need
to
consider
that
aspect
where
any
api
developer,
who
is
sending
the
error
response
with
a
problem
details,
object.
J
J
F
K
Yeah
sorry
yeah,
I
I
agree
with
sanjay.
I
think
I
wasn't
extremely
clear
in
my
suggestion.
My
suggestion
was:
if
you
want
to
indicate
that
the
documentation
live
somewhere
else,
I
would
suggest
a
link
header
or
if
you
want
to
indicate
you
can't
resolve
it.
I
would
indeed
suggest
a
urn
or
a
link
that
has
the
rail
document.
That
is
a
that
is
a
urn
or
an
about
blank
or
something
that
doesn't
or
that's
meant
to
not
resolve.
K
F
D
Yeah
ex,
actually
I
pretty
much
agree
with
what
dirk
just
said.
I
use
urns
when
I
don't
think
they're
going
to
be
resolvable.
I
don't
want
them
to
be
resolvable
and
I
use
urls
when
I
want
them
to
be
resolvable,
and
I
just
realize
that
they're
hints
and
that
they
may
not
work.
That's
basically
it
and
I
usually
write
that
up
in
the
docs
and
that's
that's
the
end
of
it.
So
no
change
in
the
spec.
For
me.
C
C
I
hear
people
saying
if
we
do
this,
it
should
be
a
flag
saying
it's
not
resolvable,
but
I'm
not
hearing
strong
urgency
behind
that.
I
guess
from
my
standpoint:
it's
it's
it's
kind
of
a.
I
really
mean
it
flag.
You
know.
We've
tried
this
in
protocols
before
where
you
say
something
you
know,
but
it's
not
always
true
and
so
you're,
just
adding
more
noise
to
the
mix.
C
You
know
like
we
said
it's
just
a
hint.
So
again
I
don't
have
incredibly
strong
feelings
about
this.
Would
anyone
be
sad
if
we
resolve
this
by
well?
What
would
we
do?
I
think,
resolve
it
with
no
real
changes,
except
maybe
some
some
explanation
and
refinement
of
the
of
the
text
to
make
the
the
design
principles
clear
here.
F
C
I'll
review
the
text
and
see,
if
anything,
needs
to
change
to
to
better
explain
any
of
this,
and
if
so,
do
a
pr,
but
otherwise
I'll
just
put
a
proposal
to
close
out
there.
F
C
We'll
make
progress
on
these
issues
and
once
them
and
a
few
others
are
wrapped
up,
I
don't
think
we
should
be
terribly
far
away
from
working
group
last
call.
J
Sanjay,
take
it
away
all
right,
so
I'll
just
cover
a
few
slides
and
then
my
co-host
would
walk
us
through
the
issues
and
status.
So
next
slide,
please
right.
J
So
just
a
brief
history,
it's
very
new
header,
probably
seven,
eight
months
back
jaideva
and
I
were
talking
and
he
reminded
that
we
had
something
in
done
in
paypal.
We
had
used
a
hidden
name,
paypal
request
id
for
item
potency,
so
we
started
researching
and
we
found
lots
of
different
types
of
headers
used
and
a
couple
of
approaches
reached
out
to
mark
mark
had
done
what
you
call
post
ones
post
once
exactly
earlier.
J
J
J
So
I
think
a
lot
of
people
know
here
about
this
particular
use
case.
But
post
and
patch
in
http
are
not
idemportant
and
post
is
used
a
lot
in
http
apis
and
there
are
many
use
cases
where
duplicate
processing
of
the
post
request
could
be
really.
J
Expensive
and
hurt
the
business,
especially
in
a
money,
transfer
use
cases,
so
you
can
find
a
lot
of
different
ways
in
which
people
have
tried
to
address
this.
I'm
using
different
headers
so
request
id
is
one
example
then,
for
example,
in
paypal,
as
I
mentioned,
paypal
request
id
was
used.
Open
banking
and
psd2
uses
x,
item
potency
key,
and
then
there
are
cases
where
the
potency
keys
is
added
inside
the
request
body.
J
J
So
the
idea
was
that
if
we
have
a
header
defined
by
the
http
api
working
group,
that
could
help
and
good
we
found
few
instances
already
after
we
released
the
draft
next
slide.
Please.
J
Stripe,
adian
voila.
All
those
people
were
already
using
item
potency
key
as
a
header
and
then
once
we
released
the
draft
we
found
http
for
scala,
finastra
and
data
trans.
At
least
these
are.
These
are
the
three
we
know
of
who
have
used.
The
header
which
is
released
under
issued
api
working
group
people,
django,
twilio,
razer,
pay,
open
banking
all
are
using
different
header
names
and
google
and
square
are
using
item
potency
key
in
the
request
body
next
slide.
J
Please
so
I
want
to
give
it
to
jay
deva
now
to
walk
us
through
the
different
issues
later.
H
Weather
around
the
status
quo
right,
whether
the
iron
potency
implementation
should
return
the
previously
processing
status,
or
should
it
return
the
latest
status
by
because
it
may
happen
that
by
the
time
the
client
retries
a
request,
someone
some
other
client
might
have
modified,
that
resource
and
and
the
resource
rate
might
change.
So
so
I
think
the
argument
there
is
yes,
so
we
we
can
return
the
previous.
H
You
know,
processing
state
when
the
client
is
retrying,
because
it
relates
to
the
the
request
it
has
sent
and
if
the
client
wants
the
latest
representation
of
the
resource,
it
can
always
do
a
get
the
conditional
get
all
right.
So
so
that
was.
That
was
one
thing.
The
other
thing
is
around
you.
H
Usage
of
words
should,
instead
of
must
for
for,
for
the
for
the
the
condition,
so
some
implementation
saying
whether
we
need
to
consider
a
fingerprint
part
of
the
part
of
the
contract,
and
so
should
we
use,
can
that
language
be
softened
to
should
so
that
was
the
easy
one
and
issue
two
is
again
around
using
the
status
code,
so
the
the
status
code
of
returning
204
when
the
idempotent
request
is
already
processed
to
a
differentiator
code
to
the
client
saying
this
is
already
processed.
H
E
H
It
wants
to
know
the
resource
details,
whether
full
or
the
pop
or
the
resource
link,
and
that
can
be
emitted
through
200
or
through
201.
H
So
204
is
not
really
required
again
on
the
second
suggestion
around
the
softening
of
language
for
for
from
march
to
may
and
should
for
the
item,
potency
conditions,
saying
the
implementer
must
return
the
previous
status
code
version
versus
the
and
previous
status
versus
the
current
set
of
research.
So
we
will
make
that
soften
the
language.
So
so
this
issue
will
resolve
by
softening
language
next
one.
H
So
this
is
the
issue
raised
by
google
multiple
issues.
So
again,
one
is
in
the
contract.
There
is
bit
of
confusion
around
wording
so
everywhere
it
says
the
item
potency
contract
is
the
key
plus
fingerprint.
H
So
so
the
submitter
was
asking,
but
the
wording
when
you
describe
that
condition
it
says,
or
instead
of,
and
so
the
submitter
are
asking
it
should
be,
and
so
that
it's
not
confusing
that
both
key
and
fingerprint
are
part
of
the
contract.
So
that's
one
thing:
one
issue:
the
other
issue
as
part
of
this
sub
dc
as
part
of
the
issue,
is
for
a
failure,
condition
that
can
be
retried
like
429,
500
404.
H
Should
that
importance,
implementation,
server,
side,
implementation
return,
the
previous
status
code,
which,
which
can
be
four
or
four
or
nine
sorry,
yeah,
500
or
or
any
kind
of
recoverable
error,
or
should
it
just
reprocess
the
request
and
the
item
putting
server
not
purchase
these
recoverable
error
statuses
at
all.
I
think
that's
a
fair
ask
all
right.
So
so
the
ask
here
is:
either
we
soften
language
from
mass
to
suit.
H
So
it
is
up
to
the
implementer
to
decide
whether
for
errors,
whether
it
needs
to
still
return
the
previous
error,
which
means
the
client
may
need
to
regenerate
a
key
in
order
to
retry
a
request.
H
If
the
previous
status
was
recoverable
error
which
which
in
which
means
there
would
be
more
traffic
to
the
server,
so
I
think
the
submitter
wants
the
language
to
be
clarified
that
way
and
yeah.
So
those
are
mainly
you
know
two
issues
and,
and
the
third
thing
is
yeah
sorry
I
thought
thing
is
the
submitter
wants.
H
H
So
the
argument
here
is
that
server
will
create
a
composite
key
and
if,
if
server,
regardless
of
what
client
sends
and
as
long
as
that
key,
the
client
set
is
unique
based
on
the
whatever
the
server
generated
composite
key.
It
should
be
fine,
but
the
submitter
wants
again
those
conditions
and
all
the
details
to
be
put
in
the
document
which
which
will
put
and
clarify
next
one.
H
So
issue
four
is
really
about
the
oasis
standard,
which
has
a
similar
header.
In
fact,
three
three
headers,
the
repeatable
repeatability
request
id
similar
to
add
importancy,
key
and
repeatability
client
id,
which
is
an
optional
parameter.
That
client
sends
and
and
then
repeatability
first
send,
which
is
the
timestamp
that
that
client
sends
so
there
is
a
there,
is
an
osc
standard
and
which
is
in
place.
So
we
we
just
you
know,
came
to
know
about
this
yesterday,
so
we'll
work
with
the
authors
there
and
reconcile
the
standards
and
resolve
the
issues.
H
So
we
have
some
concerns
around
the
dossier
standard,
even
states
that
you
can
use
that
key,
even
for
put
and
delete
requests
which
are
natural,
light,
important
and
I'll
define
an
stp
right,
and
it
also
that
is
laid
a
lot
of
constraint
that
you
feel
in
on
the
server
side
to
implement
that
standard.
So
we'll
work
on
on
this
and
with
those
authors
and
reconcile
the
standard
and
resolve
the
issue,
so
more
updates
in
the
in
the
working
group.
This
also
so
this
was
our
oasis.
You
see,
okay,
I
I
missed
it.
F
Conditional
request
using
conditional
requests
instead.
H
So
this
was
raised
by
eric
and
so
is
like
the
item.
Potency
can
also
be
implemented
by
using,
if
ma,
if
not
match,
all
those
you
know
conditional
headers,
so
that
seems
kind
of
an
alternative
implementation
to
implementing
item
potency
using
posts.
So
I
think
this
is
not
in
the
scope
of
this
draft
right.
H
This
is
not
in
the
scope
of
the
draft
to
say
what
are
the
alternative
ways
to
implement
an
iron
important
post
request
if
you
are
not
doing
using
post
but
we'll
see
if
we
can
make
some
reference
to
references
to
saying
that
this
is
not
the
only
way
to
implement
right,
but
there
are
several
other
ways
to
implement
item
potency,
and
this
draft
is
all
about
if
you
want
to
implement
importance
using
post.
So.
H
J
The
there
are
a
couple
of
things:
one
is
about
working
with
the
os's
odata
group.
J
We
came
to
know
about
the
header
that
they
have
proposed
yesterday,
as
jai
deva
was
saying,
if
you,
if
the
working
group
has
any
suggestion,
how
we
proceed
further
with
them
and
we
will
talk
to
them
and
we'll
figure
it
out,
but
I
guess
it
will
be
best
to
invite
them
to
have
the
discussion
on
our
working
group.
J
But
please
we're
looking
for
some
suggestion
on
the
from
the
group
on
how
to
resolve
that,
and-
and
the
second
thing
is,
I
guess,
the
issue
number
four
eric-
probably
he
has
referred
mike
amundsen's
article
there
and
he's
participant
here
would
like
to
know
from
him.
J
What
is
the
suggestion
on
the
issue?
Number
four.
D
I
didn't
know
eric
was
going
to
post
that
it's
actually
a
serendipity
that
that
article
was
released
close
to
this
discussion.
The
point
I
was
making
was
that's
an
item.
Potency
pattern
I
used
put:
you
could
use
it
with
post
it's
in
the
spec.
D
I
think
the
challenge
you're
looking
at
is
the
ad
importancy
key
examples.
I'm
seeing
so
far
rely
on
some
state
on
the
server
which
can
is
going
to
have
some
challenges.
I
think
in
terms
of
whether
or
not
it's
been
used
before
and
keeping
track
of
a
list,
possibly
even
being
enlisted
in
a
ddos
attack
where
somebody
just
asks
for
a
lot
of
keys
or
something
so
I'm
a
little
concerned
about
that.
D
The
use
of
the
conditional
request,
I
think,
is
pretty
handy
and
I'm
wondering
if
we're
not
just
looking
at
the
idea
of
using,
if
not
match.
If,
if
none
match
star
as
really
an
item
potency
key,
you
don't
have
to
generate
a
key,
you
don't
have
to
keep
track
of
it.
So
it's
definitely
an
alternative,
but
it's
an
alternative.
A
F
C
Yeah,
okay-
that
was
weird
so,
regarding
that
introducing
a
new
conditional
request
mechanism
into
http
is
not
trivial.
We
had
a
discussion
about
this
recently
in
the
hp
working
group.
You
have
to
consider
how
it
interacts
with
other
conditional
request
methods
very
carefully.
You
have
to
consider
other
http
features
and.
E
C
Just
would
I
I
would
advise
some
caution
before
going
down
that
road
to
do
it
right,
and
I
think
we
probably
need
to
pull
the
hp
working
group
in
to
make
sure
that
we
did
it
right
if
we
wanted
to
do
that.
Regarding
the
next
issue
about
oasis,
I
think
history
has
shown
that
the
joint
working
groups
or
joint
work
between
the
itf
and
other
standards
organizations,
especially
with
ones
with
different
rules
for
participation
of
membership
in
ipr,
can
really
be
problematic.
C
I
think
we
could
invite
the
oasis
folks
to
come
and
participate
as
it,
but
this
but
says
anyone
in
the
world
can,
of
course,
or
if
interested
folks
here,
are
or
want
to
go
over
there
and
help
them
with
their
effort,
and
they
have
the
ability
to
do
that.
That's
great,
I
would
be
concerned
if
we
started
to
have
some
sort
of
joint
effort,
because
it's
just
it's
gone
off
the
rails
so
many
times
in
the
past
xml
digital
signatures,
so
that
that's
just
kind
of
my
take
on
that.
A
Yeah
then
we'd
have
to
get.
This
is
rich.
Yes,
I
think
that
should
really
be
considered
a
non-starter,
because
then
we
have
to
get
liaison
statements
done
and,
as
you
say,
the
the
ways,
the
two
sdos
work
is
very
different.
E
A
D
D
D
Oh
yeah,
that's
put
is
explicit
in
the
text,
but
it's
it's
as
guidance,
not
as
yeah.
C
G
G
J
Yeah,
I
think
mike
you
know,
probably
we
can.
J
Figure
out,
you
know
how
the
alternate
could
be
used
with
that.
I
think
I
was
looking
at
your
article
also
who
worked
with
many
apis
internally
and
external
paypal
and
other
places
using
put
to
create
something
when
where
id
of
the
resource
is
provided
by
the
client
is
probably
not
the
norm
that
I
have
seen,
but
I
might
be
wrong,
but
regardless
I
think
we
can
discuss
that
as
part
of
evolving.
This
draft,
and
thanks
mark
for
that
os,
is
enrich.
That
os
is
how
we
deal
with
the
os
thing.
J
J
A
A
But
now
virtually
you'll
have
to
do
it
on
your
own.
Dad,
you
want
to
say
any
closing
words.
F
No
just
thanks
to
everybody
who
brought
that
content
and
mark
sorry,
we,
I
didn't
notice
those
items
that
are
in
the
discussions.
I
would
call
everybody
to
take
a
look
at
the
discussions
tab
in
the
git
repo
there's.
Definitely
some
interesting
content
in
there
that
we
should
have
a
conversation
on
list
about.
A
Yeah
definitely
thanks
people.
This
is
a
really
interesting
discussion
and
thank
you
very
much
mike
for
taking
notes
we'll
send
around
the
link.
People
can
make
corrections
and
have
a
great
rest
of
the
week
people.
Thank
you
thanks.
Folks,.