►
From YouTube: IETF115-HTTPAPI-20221108-0930
Description
HTTPAPI meeting session at IETF115
2022/11/08 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
C
B
D
E
D
F
B
G
B
Oh
okay,
all
right
all
right
is
this:
better:
okay,
good!
Welcome
to
the
HTTP
API
working
group,
contrary
to
other
ITF
acronyms,
that
is
not
easily
pronounceable.
It's
Say
it'll!
You
know
like
Bronx,
cheers
as
they
say.
Okay,.
B
B
I
have
a
cold
only
a
cold,
so
oh
and
people
are
screaming
it.
So
all
right
this
is
Tuesday
Morning.
You
should
have
seen
the
QR
codes
they
are
outside.
Also
up
there
have
your
phone,
please
Point
your
phone
to
it.
That
will
get
you,
the
lightweight
client.
If
you
want
to
talk,
you
will
have
to
press
a
button
on
that
client
to
or
Tap
a
button
on
that
client
to
get
entered
into
the
queue
we
will
manage
the
queue
through
mid
Echo.
B
E
Oh
I'm
sure
I
can
do
this.
One
I'm
sure
we'll
use
a
scene
by
now
the
net.
Well
here
it
is
once
again
please
follow
these
rules.
Yeah
I
think
Richard
said
most
of
these
things.
The
only
other
thing
did
you
mention
the
mask
burn
in
the
room
unless
you're
at
the
mic.
Please
keep
hurting
us.
E
C
B
E
So
I
shall
let
Rich
get
to
the
place
in
the
notes
and
then
Ben.
Are
you
ready
to
do
your
presentation.
H
H
Thank
you
to
the
chairs
for
letting
me
put
this
presentation
at
the
top
of
the
session.
Of
course,
it's
4
30
in
the
morning
here
so
I,
don't
know
how
great
that
really
is,
but
I
had
a
conflict
with
another
working
group.
So
this
is
not
a
top
priority
item
for
HTTP
API.
It's
just
scheduled
here
due
to
a
time
and
conflict.
E
H
So
this
is
the
same
slide
deck
for
consistency
sake.
This
is
the
same
presentation
that
I
I
gave
to
oauth.
Yesterday,
I
will
be
saying
some
slightly
different
things,
but
the
these
are
the
same,
slides
that
you
saw
in
oauth
so
feel
free
to
you
know
to
to
eat
your
croissant
if
you're,
if
you
were
already
in
oauth
yesterday,
so
interactive
authentication
of
non-interactive
HTTP
requests,
that's
a
mouthful
I
call
this
pop-up
Authentication.
H
And
the
the
key
idea
is
this:
the
the
web
today
has
a
rich
login
experience,
there's
a
whole
panopoly
of
different
ways
that
you
can
log
into
a
website.
You
can
use
complicated
single
sign-on
things
to
use
one
account
from
one
web
service
with
a
different
web
service
and
then,
when
you're
actually
logging
in,
maybe
you
can
use
a
Yuba
key
or
a
pass
key
or
any
number
of
other
tricky.
Second
Factor
things
that
give
you
a
lot
of
extra
security.
H
There
are
password
recovery
flows
if
you've
forgotten
your
password
and
all
sorts
of
great
stuff,
and
this
is
what
login
looks
like
if
you're
trying
to
use
HTTP
and
you're
not
actually
on
the
web.
H
H
And
oauth
doesn't
really
today
get
us
what
we
want,
because
oauth
is
designed
for
a
client
that's
registered
with
a
specific
service.
That
already
knows
some
proprietary
details
about
how
to
communicate
with
a
specific
service
in
advance,
and
what
we
are
really
trying
to
get
to
here
is
a
way
for
clients
like
that.
Caldav
client.
That
I
mentioned
that
I
showed,
on
the
previous
slide,
to
be
able
to
speak
a
standardized
protocol
to
to
any
compatible
origin.
H
H
This
is
the
kind
of
user
experience
that
I'm
imagining
we
could
achieve.
Imagine
that
you
have
some
service
configured
on
your
system.
H
You've
configured
it
basically
by
dropping
a
URL
into
some
settings
field,
probably,
and
then
this
service
says
actually
I
need
authentication.
So
your
system,
pops
up
a
little
notice
that
you're
going
to
need
to
authenticate
and
then
takes
you
to
a
browser
like
authentication
experience
that
shows
you
whatever.
That
service
wants
to
do.
Maybe
it's
a
captcha,
maybe
it's
single
sign-on.
H
So
this
is
the
the
draft
protocol
that's
listed
in
the
document,
but
I
should
say
that
Aaron
perecki
of
of
oauth
helped
me
out
yesterday
to
understand
a
bunch
of
oauthings
and
actually
added
a
bunch
of
slides
here
to
describe
how
this
would
work
in
oauth.
H
So
I'll
try
to
keep
this
very
brief,
but
the
idea
here
is
the
client
tries
to
do
something.
Protocol
specific,
like
this
is
a
an
initial
caldav
request.
It
gets
back
in
HTTP
401
and
it
gets
back
some
kind
of
nude
www
authenticate
response.
That
indicates
no
open
away.
I
know
you're
not
allowed
to
do
this
and
you
can
authenticate
by
opening
this
web
page
and
then
so.
H
This
web
page
is
open
now
in
a
different,
essentially
by
a
different
user
agent
in
a
browser,
and
then
the
user
again
gets
a
401
unauthorized
in
this.
In
this
version
they
get
a
401
unauthorized
and
then
they
do
some
other
stuff,
maybe
get
a
cookie
for
that
get
a
200
response
that
that
is
interpreted
as
meaning
you
can
close.
The
browser
you've
successfully
retrieved
that
authentication
resource
and
then
in
again,
in
this
version
of
the
protocol,
the
the
sort
of
non-interactive
client
you
can
think
of
it
as
like.
H
A
command
line
utility,
maybe
steals
the
cookie
reaches
into
the
browser.
Browser
State
steals
that
cookie
out
and
and
then
uses
it
to
successfully
reach
the
cow
Dev
server.
H
So
I
don't
want
to
focus
too
much
on
this
specified
procedure,
except
to
say
that
it
has
this.
It's
based
on
this
idea
that
the
client
in
question
can
sort
of
spin
up
a
browser
context
into
which
it
has
privileged
access.
H
Has
been
somewhat
unstable,
can
you
reapprove
thank
you.
H
So
that's
this
version
and
I'm
going
to
skip
the
details
of
that
spec.
So
the
bottom
line
is
that
I
want
to
solve
this
use
case,
and
let
me
Skip
One
More
slide
ahead
and
I'll
come
back.
So
this
slide
is
from
Aaron
who
proposes
a
an
alternative
approach
here,
which
essentially
takes
oauth
2.0
and
a
couple
more
extensions
beyond
what
exists
today
in
oauth
2.0.
So
we
would
have
to
write
at
least
one
or
two
oauth
extensions
to
Define.
H
Specifically,
the
new
thing
here
is
this
location
parameter
which
just
like
before
tells
the
recipient
I
need
you
to
authenticate
and
here's
the
web
page
that
you
can
open
to
be
able
to
authenticate
so
so
I
think
really,
and
we
can
I
can
just
briefly
show
you
that
this
is
a
now
looks
more
or
less
like
an
ordinary
oauth
flow
and
and
again
this
opens
an
oauth
context
that
eventually,
that
will
result
in
a
the
in
the
original
request.
The
in
this
case
the
caldav
request
carrying
a
bearer
authorization
token.
H
Do
you
do
you
essentially
view
this
as
being
something
that's
best
thought
of,
as
essentially
a
very
strange
oauth
variant
where
we
solve
this
using
oauth
and
a
bunch
of
oauth
extensions
to
to
get
to
a
very
special
oauth
behavior,
or
is
this
actually
kind
of
a
core
HTTP
function,
and
we
should
basically
Define
a
very
simple
HTTP
extension
that
that
gets
us
to
to
this
ability
and
so
I'm
seeking
adoption,
but
I
think
which
working
group
this
goes
in
definitely
depends
on
on
the
technical
aspects
of
the
the
solution.
D
A
So
Martin
Thompson
I
think
you
probably
skipped
a
step
there.
I
I'd
like
to
talk
a
little
bit
about
the
use
case
before
we
start
talking
about
how
we
might
sort
of
address
that
sort
of
thing
when
I
first
did
this
draft,
it
was
pretty
horrifying.
I
have
to
say
to
have
the
the
notion
that
you
might
have
arbitrary
pieces
of
code
that
that
might
pop
up
browsers
in
in
various
contexts
is
a
little
bit
scary.
A
We
spent
a
lot
of
time
trying
very
very
carefully
not
to
have
pop-ups
appear
in
in
various
contexts,
and
this
seems
like
a
pretty
smooth
path
to
that.
For
someone
who
wants
that
that
capability.
That
said,
there
may
be
some
ways
in
which
you
can
frame
this.
That
might
make
that
a
little
bit
more
acceptable
for
for
people,
I,
I,
don't
know,
I
I
didn't
see
any
sort
of
discussion
of
sort
of
abuse
or
any
of
those
sorts
of
other
things.
Have
you.
H
Yeah
well
so
my
here's,
my
here,
here's
my
sort
of
Nod
to
the
abuse
problem
that
anytime
this
happens
in
my
proposed
ux.
Here
you
are
directed
to
you're
presented
with
a
pop-up
that
gives
you
the
option
to
actually
accept
this
pop-up
or
to
basically
go
to
the
settings
that
is
triggering
this
and
get
rid
of
this
thing
that
is
sending
you
pop-ups
yeah,.
A
So
you're
gonna
pop
up
to
manage
the
pop-ups
status
yeah.
This
is
exactly
the
sort
of
thing
that
I
think
is
is
really
important
to
discuss,
because
these
sorts
of
interaction
models
are
difficult
to
understand.
I
think
there's,
there's
a
number
of
use
cases
in
which
this
sort
of
behavior
would
be
very,
very
useful.
A
I
I,
just
published
a
rust
crate
this
morning
and
I
haven't
used
this
machine
to
publish
them
before
and
and
there's
a
command
line
process
that
ultimately
asked
me
to
go
off
to
a
web
page
and
copy
and
paste
a
token
from
the
web
page,
and
that
sort
of
error
prone
and
fraught
and
and
and
concentrating
on
that
use
case
would
be
I
think
reasonable.
A
In
that
context,
you
would
probably
just
fire
up
the
browser
and
everything
would
be
fine,
but
I'm,
not
sure
that
that's
the
end
of
the
story
here
I
think
we
need
to
talk
about
what
it
means
to
fire
up
a
browser
context
in
this
in
this,
whether
or
not
you
really
do
want
to
have
the
application
in
control
of
the
browser
context,
to
the
extent
necessary
to
do
the
sorts
of
things
that
you're
talking
about
here
or
whether
there
is
something
else
that
is
more
appropriate
for
signaling
back
to
the
application.
A
I
think,
there's
probably
more
to
be
said,
also
about
the
nature
of
the
the
signal
that
you
use
to
determine
that
the
authentication
process
is
complete
as
well.
So
those
those
are
the
sorts
of
things
that
I
think
we.
We
should
probably
concentrate
on
before
we
sort
of
talk
about
whether
there's
whether
this
is
oauth
or
not,
I
think
perhaps
I'm
leaning
toward
an
HTTP
thing,
but
that's
because
I'm
an
HTTP
familiar
person
and
not
no
off
person.
It
seems
more
General.
H
Interesting,
so
thanks,
thank
you.
Martin
I'll,
just
say
that
I'm
I
was
just
slightly
surprised
by
your
your
last
note,
because
your
other
comments
sound
actually
a
lot
like
what
I,
what
I
think
of
as
sort
of
the
oauth
perspective,
where
oauth
has
spent
a
lot
of
time.
Thinking
about
the
the
ux
of
transitioning
between
these
different
contexts
about
the
different
signals
that
indicate
termination.
I
J
Mike
Bishop
I'm
sympathetic
to
the
abuse
concern,
although
presumably
this
is
a
context
in
which
you
would
have
gotten
a
pop-up
anyway,
asking
for
username
and
password,
so
we're
swapping
one
pop-up
for
another.
J
So
as
long
as
an
app
is
already
able
to
do
that,
pop-up
I'm
not
particularly
concerned
about
them
being
able
to
do
this
pop-up
instead
I'm
a
little
less
happy
about
the
whole
reach
into
the
browser
and
extract
the
cookie
part
I
correctly,
if
I'm
wrong,
but
I
think
the
current
way
to
do
this.
If
you
need
a
rich
sign-in,
is
to
launch
the
browser
to
it
oauth
and
give
it
the
completion
URL
or
something
on
the
local
machine.
Is
that
correct.
H
A
J
H
In
in
oauth
today,
your
client
has
to
know
out
of
band
what
the
authentication
flow
is
for
the
service
that
it's
using
oauth
does
not
standardize
that
okay
so
like,
for
example,
in
it
imagined
in
like
a
I,
don't
know
if
you've
run
across
J
map.
It's
like
you.
H
Of
HTTP
API
for
foreign,
you
have
a
general
purpose,
jmap
client.
How
do
you
configure
it?
You
know,
ideally
you
would
just
put
in
a
URL
for
a
jmap
endpoint,
but
now
you
need
a
way
to
log
into
that
service.
H
H
H
And
and
we
can,
if
we
sort
of
go
all
in
on
an
oauth
model,
then
then
we
can
just
use
the
oauth
redirect
URI
stuff
and-
and
maybe
that's
all
we
need
so.
J
F
From
the
oauth
group,
yeah
I
just
wanted
to
say:
can
you
actually
go
to
that
slide?
The
first
slide
that
I
sent
you
so
after
after
Ben
presented
this
to
the
oauth
group.
Yesterday,
I
was
looking
at
it
and
I
said
I
feel
like
we
have
almost
all
the
pieces
already
put
together
in
oauth
itself,
except
for
this
one
piece
which
is
driving
the
location
of
where
to
go
log
in
given
the
location
of
the
server
you're
trying
to
access.
F
So
in
this
example,
it's
dropping
a
calendar
URL
to
the
client,
and
that's
the
only
thing
that
you
plug
into
the
client
and
then
you
need
to
sort
of
Drive
the
login
from
that.
So
this
is
essentially
the
only
thing
you
need
in
order
to
then
just
use
the
rest
of
oauth
to
do
the
flow
and
I
totally
agree
that
there
are
security
concerns
and
issues
around
pop-ups
and
phishing
and
all
sorts
of
things
that
need
to
get
sorted
out.
F
So
that's
why
I
put
this
sequence
together,
showing
what
it
would
look
like
to
just
to
leverage
the
rest
of
oauth
to
do
this
and
oauth
has
the
answers
for
things
like
what,
if
you're
you
don't
want
to
spin
up
a
local
host
server
for
your
redirect
URL
it
answers
things
like
how
do
you
know
that
the
flow
is
done?
What's
the
signal
for
that,
like
all
that
stuff
is
already
done
there?
So
it's
not
it's
not.
These
aren't
particularly
new
problems
really.
F
So
that
is
why
I
wanted
to
put
a
sort
of
alternate
proposal
together
that
gets
to
the
same
end
result
here
and
I
guess
I
should
mention.
There
is
one
other
piece
of
this
that
does
that
would
need
to
get
solved,
which
is
the
fact
that
these
clients
would
be
previously
unknown
to
the
authorization
server,
as
in
you
download
a
random
calendar.
F
App
talking
to
a
random
caldav
server
and
they
don't
know
about
each
other
ahead
of
time,
which
is
like
been
mentioned,
not
normal
in
the
oauth
world
in
the
oauth
world,
things
kind
of
get
deployed
all
as
a
cohesive
system.
F
That's
why
I
put
this
note
on
here
about
the
client
ID,
where
in
some
scenarios,
actually
the
client
ID
could
be
pre-registered
and
there'll
be
plenty
of
scenarios
where
that
would
work
just
fine
and
in
other
situations
you
may
need
to
do
something
more
dynamic
or
more
on
the
fly
or
just
straight
up
Anonymous,
and
there
are
also
starting
to
be
some
proposals
for
that
kind
of
thing
in
the
oauth
group
coming
as
well.
So
again,
it
feels
very
suited
for
for
that
that
world
foreign.
K
One
of
the
areas
that
I
really
focus
on
is
the
human
factor
side.
We
see
that
as
a
very
big
Vector
for
attacks
and
exploits
and
I
think
the
moment.
This
gets
this
proposal
if
it
gets
connected
to
the
oauth
universe,
there's
sort
of
all
sorts
of
other
interesting
opportunities
now
for
lateral
moves
and
attacks
right.
K
You
know
you're
not
only
and
I'm,
also
sympathetic
with
the
fact
that
there's
already
a
big
you
know
there
are
some
there's
already
pop-ups
coming
up,
but
just
thinking
about
thinking
through
that
and
see,
if
there's
an
opportunity
to
actually
make
it
better
in
general.
My
Guidance
with
this
would
be
one
if
you
can
avoid
having
the
customer
make
a
decision
or
avoid
having
the
end
User
make
a
decision.
K
Please
do
so
if
they're
making
a
decision
give
them
the
best
possible
information
to
make
that
in
decision
with,
and
then
they
will
make
bad
decisions.
Please
do
you
know
in
your
design,
make
sure
that
there
is
stop
gaps
and
mitigations
for
when
the
end
user
makes
a
poor
decision,
because
they
will
I
think
what
we're
seeing
is
incredible.
Cleverness
on
the
side
of
attackers
into
using
these
pop-up
type
experiences
to
really
confuse
the
user
to
engage
in
social
engineering,
and
it's
actually
become
a
major
entry
point.
K
G
Eric
Kinnear
Apple,
so
I
would
I'm
a
little
bit
curious
as
to
what
mechanism
we're
trying
to
Define
here.
We
actually
do
something
almost
identical
to
the
flow
that
you
had
on
the
slide
earlier.
If
you
go
in
the
mail
app
on
your
Mac
and
you
ask
to
add
a
Gmail
account,
it
will
pop
up
a
thing
that
uses
oauth
uses
a
custom
URL
scheme
as
the
redirect
URI.
That
causes
it
to
deliver
everything
back
into
the
app
without
having
to
go
through
weird
localhost,
localhost
bounces.
G
So
I
don't
know
that,
like
having
the
user
put
in
a
particular
URL
or
identifying
it.
That
way
is
as
interesting
as
having
the
user
be
able
to
just
use
their
normal
flow,
which
is
what
it
already
does.
H
The
the
distinction
here
is
that,
instead
of
having
the
client
know
that
it's
it
can
talk
to
Gmail
and
having
a
button
that
says:
Gmail
I'm
imagining
a
world
where,
in
in
the
mail
example,
we
have
a
j
map,
rest
API
for
communication
between
mail,
apps
and
and
male
backends,
and
and
so
the
user
paste
in
just
once,
an
identifier
of
their
mail
server
instead
of
Gmail,
whoever
is
providing
mail
for
them
and
now
I
want
exactly
the
same
kind
of
magical
authentication
flow,
potentially
still
with
single
sign-on
through
Google,
but
now
using
that
to
cross
authenticate
into
whoever
their
actual
mail
provider
is
and
then
using
a
standard
protocol.
G
Excellent
yeah
so
being
able
to
have
anybody
put
that
in
I.
Think
one
of
the
things
that
would
make
this
super
compelling
is,
if
there's
a
way
to
reduce
that
kind
of
bouncing
around,
and
maybe
that's
hard
because
by
definition,
we've
kind
of
defined
this
as
a
pop-up,
but
to
the
comments
around
social
engineering,
even
just
from
a
user
confusion
like
suddenly
I'm
in
settings,
suddenly
I'm
in
a
browser
suddenly
I'm
somewhere
else.
A
All
right
so
Peter
reminded
me
that
this
is
far
more
challenging
than
than
even
I
had
first
thought
when,
when
I
have
an
application,
that's
asking
for
this
permission
that
goes
off
to
the
website.
A
What
is
the
website
know
about?
Who
is
asking
in
this
context
we're
talking
about
a
random
application,
that's
sitting
on
localhost
or
a
random
application
that
is
essentially
an
arbitrary
binary,
that's
running
on
your
machine
and
and
to
Peter's
Point
earlier
I.
Think
that's
really
scary
and
I.
A
Think
there's
probably
a
case
here
to
be
made
for
simply
saying
that
that
this
requires
some
sort
of
server
infrastructure
so
that
the
server
knows
who
it's
talking
to
and
then,
for
example,
in
the
cargo
publish
example
that
I
was
talking
about
before
the
the
cargo
published.
Binary
knows
me
and
can
talk
to
crates.io,
which
is
their
server
infrastructure
and
can
authenticate
to
that
and
it's
crates.io
that's
receiving
the
authorization
token
in
this
case,
and
then
it
passes
it
back
down
to
the
command
line.
Client
in
that
case,
otherwise,.
H
I
wanted
to
note
here
is
that
the
in
this
version
of
The
Proposal,
the
the
location
of
the
of
the
authorization
page
is
only
given
as
a
path.
So
it's
meant
to
be
on
the
same
origin
as
the
as
the
actual
service
you're
trying
to
reach
and
from
there
maybe
you'll
go
through
some
series
of
redirections
to
get
you
through
a
single
sign-on
type
flow,
but
but.
A
So
that
that
doesn't
necessarily
help,
because
the
application
that
the
server
thinks
that
it's,
that
that
it
might
be
providing
this
information
to
and
the
application
that
the
information
ultimately
ends
up
in
may
be
two
different
things,
because
let's
just
say
that
I
managed
to
get
some
some
bad
software
on
your
machine
and
then
the
service
handing
out
for
that.
Instead,
yes,.
H
Well,
so,
if
you
believe
in
open
source,
you
know,
then,
unless
you're
going
to
invoke
some
kind
of
like
client-side
attestation
trusted
platform
stuff,
you
know
the
the
server
no
server
ever
actually
knows
what
what
software
is
running
on
the
client
client
to
server
oauth
always
has
some
version
of
this
problem,
and
this
is
also
how
the
web
works
right.
Like
servers,
don't
get
an
attestation
proving
what
browser
is
being
used
to
access
gmail.com,
we
just
that's
just
the
world
as.
A
That's
that's
not
really
the
the
sort
of
problem
that
I'm
looking
to
to
address
here.
You've
got.
You
have
clients
authenticating
to
servers
all
the
time.
This
is.
This
is
not
a
particular
particular
challenge,
but
what
you're,
if
this
was
the
only
way
in
which
you're
authenticating
to
to
the
server
and
then
because
you're,
using
the
the
interactive
session
in
order
to
authenticate
the
user
to
the
server
the
service
storm,
doesn't
know
anything
about
the
application
that
it's
providing
this
token
to
and
to
the
phishing
point
earlier
that
that
becomes
fraught.
A
Whereas
if
you
had
a
scenario
where
you
have
an
application,
where
a
user
is
authenticated
to
a
server
and
they're
looking
to
access
secondary
resources
on
others
other
services,
then
this
becomes
a
little
bit
more
interesting.
Because
then
you
can
use
that
first
authentication
session
as
the
basis
for
knowing
that
the
this
is
a
particular
user,
that's
receiving
information
and
then
then
you're
talking
about
interactions
between
the
two
different
servers
and
then
it
becomes
a
little
bit
easier
for
the
the
server.
A
E
So
maybe,
to
close
this
conversation,
I
think
there's
two
questions
here
to
this
group
is
HQ
API.
Is
there
a
concernses
that
this
would
be
useful
to
http
API
world?
E
E
And
so
Aaron
Ben
probably
you're
the
best
folks
to
talk
more
about
how
to
move
this
forward,
but
but
there's
an
interest
I
think
in
the
HP
API
space.
It's
just
I
think
the
a
lot
of
folks
have
the
tools
to
make
this
happen.
H
Okay,
well
so
yeah
I
think
the
most
likely
outcome
here
is
that
Aaron
and
I
will
hopefully
try
to
put
together
a
now
a
more
oauth
flavored
version
of
the
protocol
and
and
we
will
probably
try
to
to
run
that
by
oauth
again.
I'm
sure
that
oauth,
as
always,
will
will
be
looking
very
closely
at
questions
about
user
confusion
and
and
leakage
of
tokens
and
that
sort
of
thing.
E
F
F
If
you
look
at
what
Google's
done,
they've
locked
down,
they've,
really
locked
down,
who
can
get
access
to
be
able
to
do
an
oauth
flow
at
all
and
depending
on
the
scope
you're
requesting
so
they've
gone
like
super
hard
on
that
in
the
Enterprise
world,
it's
extremely
locked
down.
Only
the
Enterprise
admin
can
create
a
client
ID
in
the
system.
Both
of
those
scenarios
would
work
with
the
oauth
version
of
The
Proposal,
both
those
are
enabled
by
it.
So
if
you
want
those
policies,
you
can
still
have
those
policies.
F
If
you
want
to
open
it
up
and
allow
your
random
calendar
app
developer
to
publish
an
open
source
piece
of
software,
that's
you
know,
lives
on
GitHub,
that
someone
downloads
and
there's
no
binary
signing
anywhere,
that's
great,
and
if
the
server
wants
to
enable
that
to
happen,
that's
also
cool
and
think
think
of
also
the
WordPress
model.
Anybody
can
set
up
a
WordPress
server.
Anybody
can
write
an
app
to
use
the
WordPress
API.
F
Obviously,
there's
no
prior
link
between
the
two
Developers
there's,
no
registration
that
can
happen
out
of
band
there's
no
signing
that
can
happen,
but
that
is
a
useful
use
case.
If
you're,
okay,
with
the
assumptions
that
or
the
the
consideration
is
there
so
I
just
think
writing
that
all
down
and
capturing
that
as
like
here's
the
assumptions,
here's
how
you
can
deploy
this
in
ways
that
make
sense
for
you.
That's
also
stuff
that
can
be
worked
out
in
this
draft.
I
Just
a
quick
comments:
group
chair
I
agree
with
the
with
the
with
that
with
Aaron
others
that
this
is
probably
fits
nicely
into
the
earthquake
group.
They
and
and
then
got
great
feedback
from
their
group
work
group
interested
in
this
one.
So
this
is
the
right
place
for
it.
Excellent.
E
I
E
L
L
L
Just
one
thing:
actually,
we
specified
that
that
yaml
is
the
preferred
extension
while
yml
is
the
Legacy
one,
and
we
acknowledge
that
the
relation
with
median
and
suffixes
does
not
require
any
changes
for
the
rest
API,
we
need
more
feedback,
so
we
are
not
addressing
in
this.
In
this
meeting
we
just
have
one
open
issue
that
is
related
from
a
clipboard
identifier
for
Windows
and
Macross.
L
E
This
is
Greg
I'm
glad
to
see
we're
making
progress
on
this
one,
and
it
was
probably
a
good
idea
to
do
that.
Split
that
we
did
from
the
other
media
types
because
they
seem
like
they
have
a
few
more
things
to
sort
out.
Does
anybody
have
any
questions
or
feedback
on
the
ammo
media
type,
see
somebody
walking
to
the
mic.
D
M
Hi
Alex
yeah
I
had
to
look
at
this
need
to
double
check
the
the
template
itself.
It
looks
fine
in
regards
to
things
like
clipboard
names
and-
and
you
know,
this
sort
of
information
is
useful
if
you
know
it
but
I
understand
there.
Aren't
that
many
experts
for
this.
So
if
you
can
find
out
what
should
go
there
included,
if
not
I,
don't
think
it's
going
to
be
a
big
deal.
E
E
There
doesn't
appear
to
be
any
action
right
with
Microsoft
at
all
with
regards
to
clipboard
identifiers,
okay,.
L
After
we
match
these
two
reverse,
eventually,
we
can
just
start
the
publication
procedure.
E
Okay,
so
the
next
part
of
this
we
are
going
to
just
go
through
the
other
working
group
documents
and
have
some
discussion
around
the
open
issues.
Of
course,
because
I
shared
a
window
I
can't
just
change
it.
I
have
to
re-share
the
other
in
the
tab.
Give
me
a
second
not
used
to
working
with
only
one
window.
H
E
E
E
Go
up
there,
okay,
so
we
keep
track
of
in
the
HP
API
working
group.
We
keep
track
of
the
issues
via
the
GitHub
repos
and
there
is
this
common
project
that
lists
all
of
the
different
documents
that
we
are
working
on,
that
surfaces
all
the
various
issues,
and
we
have
status
here
to
give
us
an
indication
of
where
these
issues
are
within
our
shepherded
pipeline.
E
E
So
they'll
stay
there.
The
one
open
issue
that
comes
still
really
remaining
from
ietf
114
is:
we
ran
into
challenges
with
regards
to
the
formatting
of
the
date
field
in
the
deprecation
header
which,
amongst
the
suggestions
to
move
to
structured
headers,
also
ran
into
a
challenge
with
well,
we
want
the
deprecation
field
to
also
be
consistent
with
the
sunset
header
as
the
two
work
in
parallel,
the
outcome
of
that
was
well.
E
Should
we,
instead
of
having
two
separate
Fields,
just
have
one
life
cycle,
header
and
I
believe
the
some
of
the
last
words
from
itf14
is
oh,
that
would
be
a
really
easy
PR
to
write.
It
shouldn't
require
a
whole
lot
of
changes.
Do
you
remember
that
comment
mark.
B
E
Let's
have
that
discussion
now:
cool
awesome,
one
head
or
two
headers
do
folks
have
an
opinion
in
so
far
as
whether
or
not
it
would
be
valuable
for
us
to
be
able
to
have
a
let's
say,
a
dictionary
style
header
for
life
cycle
to
be
able
to
maintain
the
states
of
an
API
over
its
life
cycle.
Or
do
we
stick
with
Sunset
and
have
a
new
deprecation
header?
Does
anybody
have
any
opinions
that
they
would
like
to
share.
C
I
I
think
it's
worth
trying
I
think
the
worst
case.
We
come
up
with
a
life
cycle.
Header
and
people
still
use
the
sunset
header,
but
my
impression
is
that
the
sunset
header
isn't
terribly
widely
deployed
yet,
and
so,
if
we're
going
to
do
it,
don't
get
sooner
rather
than
later
would
be
good
so
that
we
can
capture
some
of
that.
Adoption
got.
E
E
C
Yes,
so
the
as
I
understand
it.
The
consensus
in
the
HTTP
working
group
is
that
we
will
be
creating
a
structured
date
type.
It
will
be
inserted
into
a
revision
of
the
structured
Fields
specification,
so
we're
going
to
revise
the
entire
RFC
to
add
it
and
it
will
its
representation
in
HTTP.
1.1
text
will
be
a
an
at
symbol,
followed
by
an
integer,
and
that
integer
is
a
Delta
from
the
common
Epoch
January
1st
1970..
C
There
were
personally
I
I
think
that
a
more
human
readable
one
would
be
a
little
friendlier,
but
that's
because
I'm,
very
bullish
on
binary
structured
headers,
where
that
in
the
efficiency
loss
isn't
so
so
great,
and
it's
not
at
all
clear
that
binary
structure
headers
are
actually
going
to
happen.
Sorry
Fields,
sorry,
Julian
Fields,
so
the
the
Feeling
by
far
was
that
by
by
using
an
integer,
it
would
improve
not
only
efficiency
but
also
remove
a
lot
of
chances
for
errors.
Date.
C
Parsing
is,
is
nasty
and
adds
a
lot
of
questions
that
people
thought
weren't
needed.
So
it
was
a
fairly
strong
feeling
that
it
should
be
an
integer,
and
so
that's
I
think
what
it's
going
to
be
now.
I,
shopped
that
around
with
the
folks
discussing
I,
think
both
the
deprecation
I
think
that
yeah
the
deprecation
header
and
was
a
little
surprised
to
hear
that
that
that
seemed
like
it
was
okay.
C
If
I
interpreted
the
responses
correctly,
that
having
one
way
to
do
it
and
having
that
integer
representation
would
be
adequate,
could.
C
First
of
all
that
it's
not
readable
as
an
integer
I
think
that
in
some
contexts
it
is
I
think
that
tooling
will
eventually
present
that,
as
a
more
readable
in
a
more
readable
form,
I
think
that
tooling
will
emerge,
especially
as
we
get
more
headers
using
it
and
if,
if
you
do
want
to
have
a
textual
header
that
on
the
wire
or
the
bits
on
HTTP
1.1,
mind
to
HP
one
point:
I'm,
sorry
2.0
and
three.
C
If
you
look
at
the
bits
in
the
water
you're
going
to
see
gibberish,
no
matter
what
you
do
in
in
age
to
be
1.1,
if
you
want
to
see
an
actual,
you
know
human
friendly,
Sunday,
comma
December
5th.
You
know
you
could
put
that
in
a
string.
If
you
wanted
to
it,
just
wouldn't
have
a
date.
Type,
yes
and
you'd
have
to
specify
in
detail
the
parsing
and
serialization
of
that
date,
as
well
as
error,
handling.
E
Okay,
so
that's
where
we
are
with
the
application:
header,
I
Heard
it:
let's
try
it.
We
shall
talk
with
the
editors
and
and
get
this
easy
PR
done
so
that
we
have
a
life
cycle
header
and
get
feedback
on
it.
If.
L
L
Yeah
I
I
think
that
for
life
cycle,
the
point
for
me
internally
is
that
it
should
be
human
readable.
So
if
it
will
be,
if
we
decide
not
to
use
to
move
to
structure
fields,
I
think
the
value
should
anyway
not
should
not
use
a
non-humor,
readable,
serialization.
C
So
we
had
a
discussion
about
this
and
I
thought
that
that
I
didn't
see
any
other
feedback
to
that
effect.
That
people
felt
that
an
integer
would
be
adequate.
But
we'll
we'll
have
to
have
that
discussion
when
we
look
at
the
pr
I
I
think
their
arguments
to
be
had,
but
we
need
to
come
to
some
sort
of
consensus
on
it,
keeping
in
mind
if,
if
we
do
choose
not
to
use
a
structured
field
type
that
is
tailor-made
for
this
use
case.
We'd
better
have
a
good
explanation.
C
When
we
go
to
the
isg
in
last
call
about
it,
because
whilst
we
might
get
consensus
in
this
room
for
one
way
or
another,
the
larger
consensus
of
the
ITF
may
be
different
and
we
need
to
be
able
to
defend
that.
I
got
up
originally
just
to
say.
Could
you
please
assign
that
issue
to
me
so
that
I
can
remember
to
do
the
pr?
C
E
And,
and
just
to
remember
to
just
to
you
know
reiterate
what
Mark
said:
I
think
that
the
important
thing
there
is
we
are
moving
into
a
world
where
you
don't
look
at
HP
headers
without
using
some
kind
of
tooling
that
does
presentation,
and
it
is
it
with
the
value
of
structured
headers
and
the
at
symbol
indicating
this
is
a
date.
It
can
definitely
present
those
headers
in
a
human,
readable
format.
So
we,
our
our
world,
is
Shifting
underneath
us
in
this
space.
E
Okay,
moving
on
to
item
potency,
we
have
one
minor
issue
that
is
left
here.
There's
been
a
number
of
issues
that
have
been
closed
just
recently,
and
this
particular
request
I
believe
was
just
resolved
yesterday,
and
so
this
should
be
closed
up,
which
will
close
all
of
our
issues
on
the
item.
Potency
header.
E
E
Just
as
a
sense
of
the
room
is
there
other
folks
in
the
room
who
feel
that
they
would
be
interested
in
using
this
ad
impotency
header
or
see
it
as
a
valuable
thing.
L
D
Mouse
collider
with
the
HTTP
working
group,
we're
working
on
resumable,
uploads
and
we're
thinking
about.
Maybe
using
the
item
potency
key
here
there
in
there
it's
still
like
only
a
proposal,
and
there
hasn't
been
a
lot
of
discussion
if
we
actually
end
up
using
it,
but
it
looked
really
interesting
for
the
problem
we're
trying
to
solve
so
yeah.
We're,
definitely
like
to
see
where
this
is
going
excellent.
It's
great
to
hear.
E
Which
brings
us
to
the
link,
template
header.
I
have
not
seen
a
whole
lot
of
feedback
on
this
draft
from
Mark,
which
means
either
it
is
wonderful
or
nobody
cares.
E
There
is
one
I
see
it
has
been
moved
to
structured,
Fields,
that's
great!
There's
a
PR
I
added
a
tiny
little
comment
on
there
Mark
and
so
then
the
only
open
issue
is
this
anchor
parameter
in
URI
templates,
which
is
an
interesting
problem
that
we
have
run
into
a
number
of
times
in
the
past.
You
have
thoughts.
C
I
I
think
I'm
probably
gonna
do
this,
and
unless
it
doesn't,
you
know,
there's
some
unforeseen
problem.
I
just
I
frankly
haven't
gotten
to
it.
I've
been
a
little
busy
with
other
stuff,
but
yeah
I
think
once
these
two
things
are
done,
we
can
go
ahead
and
do
a
working
group
last
call
I
still
from
time
to
time.
Hear
people
saying
yes,
I'd
really
like
to
use
that
so
we'll
see.
E
We're
just
ripping
along
here
so
we've
already
talked
about
media
types
from
the
media
type
yaml,
both
the
yaml
RFC
and
the
restful
media
types
for
Jason
scheme.
An
open
API
are
two
different
documents
in
the
same
repo,
so
they're
kind
of
mixed.
E
We
are
still
waiting
on
a
whole
bunch
of
feedback
from
the
Jason
schema
folks,
fragment
identifiers
get
a
little
funky
and
the
Jason
schema
world
so
they're
working
to
resolve
those
and
there's
a
need
for
security
considerations
for
the
open,
API
spec,
which
we
have
had
conversations
in
the
open,
API
initiative
about
this,
and
we
will
be
writing
those
up
and
they'll
largely
be
what
the
Jason
schema
says.
Plus
so
expect
to
see.
E
Hopefully,
we'll
get
these
resolved
in
a
few
months,
but
we're
kind
of
locked
on
the
Jason
schema
Folks
at
this
point
in
time.
E
Right,
which
brings
us
to
actually
before
we
do
rate
limit
headers,
because
I'm
feeling
that
will
have
us
a
bit
of
a
conversation,
7807
is
going
through
area
review.
Is
that
the
right
term
and
I
see
there
was
a
whole
load
of
issues
that
were
opened
up
yesterday.
E
Hence
why
I?
Don't
have
any
status
on
these
things
Mark,
you
have
more
things
that
have
been
added
to
your
plate,
so
but
many
of
these
issues,
I,
think
that
have
been
brought
up
have
previously
been
discussed,
so
hopefully
we'll
be
able
to
resolve
these
I
didn't
see
any
in
here
that
were
tremendously
controversial
more
than
they
have
been
in
the
past
and
we've
solved
them
in
the
past.
E
Okay,
which
brings
us
to
rate
limit
headers,
and
if
that
this
is
possibly
one
of
the
larger
GitHub
issues
that
I've
seen
in
a
while,
and
it
boils
down
to
structured
headers
at
the
moment
the
rate
limit
headers
are
defined
as
separate
fields
with
a
separate
field
for
rate
limit,
remaining
rate
limit,
reset
and
rate
limit
limit,
and
there
is
a
proposal
or
there
is
a
conversation,
that's
happening
about.
E
Can
we
move
this
into
a
single
header,
but
there
is
a
disagreement
and
there
has
been
feedback
from
the
community
that
they
like
really
simple
headers,
that
are
just
scalar
values,
but
there
is
also
the
future
where
of
structured
headers,
and
there
is
a
there's,
also
the
value
of
them
being
in
a
single
header.
As
they
are
related
values,
and
so
there
is
not
consensus,
I
don't
know
I'm
trying
to
find
a
particular
issue
that
summarizes
that
best.
E
Here
was
an
so.
This
is
how
it
is
currently
used
in
the
wild,
with
rate
limit
limit
rate
limit,
remaining
rate
limit
reset
and
there's
a
desire
from
some
folks
to
merge
it
into
a
single
header,
we're
using
structured,
Fields
Roberta.
You
have
opinions,
I
know:
do
you
want
to
Make
Your
Case.
L
Yes,
the
problem
here
is
that
the
industry
works
with
three
fields.
In
a
previous
release.
With
of
this
draft,
we
tried
to
conflate
to
to
combine
some
of
the
provided
information
in
one
field
and
folks
ask
to
roll
back
this
kind
of
change
and
provide
different
information
in
different
fields.
L
The
current
tooling
makes
very
difficult
to
work
with
information
that
is
combined
in
in
a
single
field.
L
L
This
is
the
the
the
main
the
main
issue
we
want
to
standardize.
We
don't
want
to
make
the
the
14
standards
out
of
the
13
that
exist
before
so,
and
this
is
the
reason
we
created
this
specification.
E
Thank
you,
Roberto
Chris,.
N
So
you
say
that
intermediaries
don't
have
the
ability
to
parse
structured
content,
but
that's
what
headers
are
I
mean:
headers
are
structured
content,
they're
keys
and
their
values,
and
you
split
them
up
and
you
parse
them,
and
so
an
intermediary
that
has
tooling
that
can
parse
structured
content,
we're
dispelling
the
structured
content
in
a
different
way,
and
so
I
think
I
I'm
sympathetic
to
the
point
that
intermediaries
may
not
currently
have
exactly
the
parsers
that
we
want
them
to
have.
N
But
I
don't
know
that
I'm
persuaded
entirely
that
they
won't
and
that,
if
we
spell
it,
this
way,
they're
just
going
to
throw
up
their
hands
and
say
well
that
uses
semicolon
instead
of
equals
and
I
I.
Just
don't
know
what
to
do
with
that.
E
C
Yeah
Mark
Nottingham,
with
all
respect,
I
think
Roberto
is
focusing
far
too
much
on
the
very
short-term
deployment
of
the
specification
and
and
the
path
to
that.
Rfcs
are
supposed
to
be
relatively
long-lived
documents
we're
supposed
to
be
creating
infrastructure
that
lasts
a
long
time
and
and
and
if
we
focus
too
much
on
on
the
the
exact
current
deployment
patterns
down
to
syntax.
We're
going
to
be
so
constrained
that
we're
not
going
to
be
able
to
function.
C
I,
I,
I,
just
I
I
think
it's
just
a
different
Viewpoint
I
think
for
for
internet
standards.
We
need
to
be
focused
on.
What's
the
right
long-term
pattern
to
have
here
and
then
you
know,
I,
look
at
this
I
look
at
the
what's
on
the
screen
and
I
think
well.
If
we'd
taken
the
approach
that
Roberto
was
talking
about
for
the
cache
control
header,
we
would
have
cache
control
max
age,
colon
30.
C
cash
control,
private
cash
control,
you
know,
and
and
it
would
lead
to
an
absurd
design.
Just
just
putting
aside
the
issue
of
deployment
ease
of
deployment.
Putting
aside
the
issue
of
structured
fields
and
whether
you
know
we
should
use
them
in
in
what
fashion
we
should
use
them
as
as
just
as
header
Design
This
just
is
really,
you
know,
you're
spreading
the
smearingness
information
across
multiple
headers
you're
having
the
chance
for
it
to
be
desynchronized.
C
It
doesn't
make
any
sense
to
me
now
if,
if
there
are
legitimate
use
cases
where
you
have
multiple
parties,
touching
these
fields
and
they're,
and
and
so
that
there
are
slightly
different
semantics
to
them
by
all
means
split
them
into
separate
headers.
But
let's
have
a
discussion
about
semantically.
What
makes
sense
to
put
in
the
same
header
versus
different
headers,
rather
than
just
saying,
let's
put
every
discrete
value
in
a
separate
header,
because
that's
it's
not
good
design.
E
Could
you
just
talk
more
about
this
scenario
where
there's
an
origin
server
that
defines
some
kind
of
right,
limit,
header
and
then
a
gateway
then
wants
to
modify
that
rate
limit
header
before
returning
to
the
client?
What
is
what
is
the
use
case
for
that.
L
For
example,
if
you
haven't,
if
you
have
an
application
that
is
served
through
together
as
one
external
and
one
internal,
maybe
those
two
getaways
want
to
adjust
the
published
direct
limit
depending
on
the
client
and
assign
different
scales,
different
proportion
of
the
complete
quota
of
a
single
application,
one
for
external
traffic
and
one
from
kernel.
L
But
again,
the
point
is
that
this
kind
of
field
is
are
actually
used
in
in
industry
and
infrastructures
in
many
possible
ways
that
we
don't
even
know-
and
my
concern
is
that
if
we
make
some
distance
from,
if
we
diverge
from
how
something
that
is
actually
used
in
different
ways
that
we
may
know-
or
we
may
not
know-
and
that
is
already
present
in
the
industry,
we
take
the
risk
of
creating
a
specification
that
is
not
adopted
because
currently
people
already
use
custom
weight
limit
fields,
and
we
should
provide
some
selling
points
for
them
to
adopt
this
specification,
which
is
the
selling
point.
L
If
they
don't
change,
if
they
don't
need
to
change
anything,
they
are
sold
and
actually
they
have
been
already
sold
to
different
gateways
because
they
just
had
to
change
the
field
name.
But
if
we
need
to
change,
if
we
ask
them
to
change
the
structure,
we
don't
know
if
they
buy
them,
so
we
can
take
the
risk
of
providing
a
specification
that
is
not
adopt
not
adopted
easily,
but
I
really
would
like
to
have
some
feedback
from
implementer.
L
L
My
feedback
was
generally
that
they
are
not
interested
to
change
significantly.
They're
actually
deployed
code,
but
if
you
have
some
feedback
from
implementers
that
say,
okay
I
will
follow
you
in
structure
fields,
and
they
do
it.
For
me
it
will
be
okay,
but
we
need
I.
I
would
really
see
this
feedback.
Okay,.
B
I
so
hi
Rich
Saul's,
no
hats.
Right
now.
The
industry
is
apparently
using
x,
dash
rate
limit
they're
going
to
have
to
make
a
change
anyway.
You're
argument
is,
or
your
concern
is
two
characters-
is
a
lot
easier
than
supporting
structured
fields,
but
structured
fields
are
coming
anyway,
there's
nothing
that
prevents
existing
applications
from
using
x,
dash
rate
limit
a
b
c
d
e.
B
The
future
direction
of
HTTP
is
clearly
structured,
Fields,
I'm,
hoping
more
than
hoping,
not
with
my
head
on
I
think
the
working
group
should
adopt
something
that
is
headed
toward
the
future
direction
of
the
HTTP
specification,
we'll
have
to
take
a
working
group,
consensus,
call
and,
of
course,
Roberto
thanks
for
emphasizing
that
you
will
do
what
the
working
group
suggests,
because
that's
your
job
and
our
job
is
to
figure
out
what
the
working
group
suggests
and
wants.
But
clearly
the
advice
we've
gotten
from
HTTP
is
structured
fields
are
the
future.
B
So
with
that.
N
Chris
Chris
I
think
I
may
be
reiterating
points
everyone
else
is
making,
but
we
need
to
decide
whether
what
we're
doing
is
documenting
current
practice
or
designing
something
for
the
future,
and
we
should
be
really
specific
about
what
we're
doing
and
why
we're
doing
that.
E
B
B
D
B
Okay,
we're
gonna
home
in
the
room
and
we
will
take
it
to
the
mailing
list
just
because
I
miss
not
humming
after
two
and
a
half
years.
So
the
questions
are
the
question:
is
there
are
three
parts?
Do
you
prefer
simple?
Do
you
prefer
three
Fields
with
a
numeric
value
or
structured
fields
in
a
com
compound
header
field
whatever
or
do
not
know
yet?
B
E
Thank
you
very
much.
Everybody,
okay,.
B
I
E
Okay,
I
I
think
that
is
the
that
was
really
the
main
issue
that
was
holding
up
the
the
rate
limit
header
work.
If
we
can
get
an
answer
to
that,
we
can
definitely
move
forward
with
it,
and
that
brings
us
to
the
end
of
the
working
group
documents
that.
J
E
L
No
problem
I.
It
would
be
great
to
have
some
help
with
the
by
the
other
folks
to
reach
out
implementers
in
ensuring
that
the
structure
fields
is
a
sensible
Choice
even
for
them,
since
I
think
there
is
people
from
cloudflare
and
other.
B
B
Correct
this
is
the
working
group
is
open
to
all.
This
is
the
working
group
decision.
If
somebody
wishes
to
propose
something
else
they
should.
This
is
the
venue
to
participate
so
I
understand
your
concern
and
I.
We,
the
ITF,
wants
to
make
standards
that
are
used,
but
we're
not
going
to
reach
out
to
Industry.
It
will
be
vague.
You
know
if
you
have
people
in
Industry
who
will
feel
strongly
about
this,
they
should
read
the
pr
and
comment.
E
Okay,
and
with
that,
let
me
just
I
believe
we
have
a
any
other
business
agenda
item.
Does
anybody
have
any
other
business.
E
I
can
do
that
just
as
a
informational
thing.
If
you
now
go
to
the,
let
me
figure
out
where
I'm
going.
If
you
go
to
the
website
that
corresponds
to.
E
The
HPA
working
group
HP
API
working
group.
We
now
have
a
little
kind
of
flow
diagrams.
That
attempt
to
indicate
where,
in
the
process,
the
each
of
the
working
group
documents
are.
We
have
a
lot
of
people
in
the
HP
API
Community,
who
are
not
necessarily
familiar
with
how
the
ietf
works.
E
These
diagrams
and
I
will
try
and
find
a
way
of
changing
the
color.
The
circle
currently
indicates
where
this
document
is
in
the
flow,
but
it's
a
little
too
subtle.
So
once
I
figure
out
how
to
apply
styling
to
these
mermaid
diagrams,
we'll
be
able
to
make
that
a
little
bit
clearer.
But
you
can
see
here.
E
The
yaml
media
type
is
in
working
group
last
call
and
the
status
of
the
other
media
types,
and
so
this
is
a
way
for
us
to
help
communicate
to
the
broader
community,
see
the
process
and
make
it
clear
to
them.
Also
that,
even
when
we
say
working
glue,
glass
call
there's
a
whole
bunch
of
things
Downstream,
because
there
is
an
expectation
that
yep
we're
done
and
then
there's
lots
of
other
review.
That
happens,
that
is
as
I'm
learning
extremely
valuable
from
from
Upstream
folks,
and
so
yes,
you
can.
E
You
can
see
this
on
our
GitHub.
I
o
website.