►
From YouTube: IETF110-HTTPAPI-20210312-1600
Description
HTTPAPI meeting session at IETF110
2021/03/12 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
C
It's
looking
good.
Okay,
all
right!
Welcome
everyone
we'll
give
it
well
we're
already
one
minute
passed:
okay,
I'm
rich
sitting
next
to
me
is
coach.
Hare
daryl
I'll
be
running
the
slides,
which
means
for
those
of
you
haven't
done
it.
I
don't
have
access
to
the
midako
ui.
C
Otherwise
you
get
that
funky
little
picture-in-picture
and
picture-in-picture
thing
you
saw
a
second
ago.
I
am
also
on
the
jabra
client
and
I'll,
have
my
audio
on
so
I'll
run
through
the
first
set
of
slides
and
then
I'll
be
presenting
the
others.
So
if
you're
speaking
just
say
next
slide
and
I'll,
you
know
hit
the
down
arrow,
welcome
to
the
ietf
1
110.
C
C
C
Welcome
to
http
api,
our
second,
our
second
meeting,
if
you've
been
to
the
itf
before
you've.
Seen
this
the
note.
Well,
if
this
is
your
first
ietf
and
you've
been
around
for
the
week,
you've
seen
it
and
you're
already
sick
and
tired
of
it.
Basically,
it
says
we
have
processes,
we
have
procedures.
C
Your
name
was
written
down,
behave,
politely,
maturely
act,
you
know,
don't
do
anything
you'd
be
embarrassed
if
it
showed
up
in
your
local
paper,
administrative
tasks,
so
the
blue
sheets
will
happen
automatically.
C
C
We
use
the
kodi
md
we
can
get
by
with
one.
If
we
need
to,
but
ideally
we
have
two
people
that
play
catching,
you
know
help
catch
each
other
up.
It's
a
pretty
easy
job.
You
don't
have
to
record
everything
that
was
said.
This
recording
will
end
up
on
youtube
in
the
ietf
channel,
but
is
there
a
volunteer
to
take
notes
in
the
on.
C
C
C
All
right
I'll
have
to
do
it,
but
not
that
big
a
deal
all
right
in
other
administrative
things
here
is
our
agenda.
We've
already
done.
Two-Thirds
of
the
administrivia.
We
have
a
two-hour
meeting
time
slot
agenda
bashing,
ietf
term,
for
does
anybody
want
to
make
suggest
changes
to
the
agenda
or
add
things
that
aren't
otherwise
here.
D
C
D
Yes,
this
is
eric
speaking
eric
wild.
So
what.
D
F
All
right
daryl,
I
I
added
that,
because
it
was
an
open
item
from
last
time
that
we
ran
out
of
time.
So
if
we
wanted
to
have
that
as
a
conversation
at
the
end,
we
can
do
that.
D
C
C
So
if
everyone's
fine
with
the
agenda,
we'll
move
to
the
rate
limiting
headers
discussion,
which
I
guess
daryl
you
were
doing.
F
Yes
and
I'm
not
gonna,
go
into
any
details
here,
but
just
as
an
update
on
this
specification,
there
has
been
a
number
of
pull
requests
based
on
feedback.
That's
been
received
on
the
spec.
There
has
been
work
around
improving
the
goals
of
the
overall
specs
and
that
link
will
take
you
there
to
the
details.
There
there's
also
some
areas
around
performance
insofar
as
just
providing
guidance
around
telling
implementers
hey
this
big
set
of
headers.
You
don't
have
to
return
these
headers
on
every
single
request
that
is
made.
F
You
can
maybe
only
return
it
once
a
quota
is
up
to
a
particular
level
and
you
can
dig
into
the
details
there
and
there's
some
conversations
around
specific
throughput.
I
tried
to
put
more
details
here
initially,
but
then
I
realized
there
would
be
just
way
too
much
stuff
and
without
the
draft
editors
I
didn't
think
it
would
be
worth
going
into
too
much
detail.
But
all
that
said
there
is
active
work
going
on
in
that
spec
and
we
are
closing
a
bunch
of
issues.
C
F
C
D
D
I
think
it
was
pretty
clear
that
it
was
simple
that
it
was
useful
and
what
we
did
in
the
meantime
is
we
moved
the
draft
to
be
an
official
working
group
header.
It's
for
those
who
don't
know
it.
It's
very
simple:
it
works
in
the
same
way
as
the
sunset
header
field.
So,
basically,
what
you
can
do
is
you
can
just
say
this
resource
is
going
to
be
deprecated
or
this
recall
resource
is
deprecated.
So
it's
a
simple
time
step.
Basically,
next
slides,
please,
you
can
just
cursor
keys
further
right,
yep,
yes,
thank
you.
D
So
the
model
is
really
simple.
It's
just
basically
saying
deprecation
is
something
that
is
happening
or
has
happened
for
resource
the
one
limitation
that
is
in
there,
and
that
is
still
in
there
is
that
deprecation
is
only
on
the
resource
level.
So
there
is
no
mechanism
in
there
to
say
certain
fields
or
certain
methods
are
deprecated,
so
it's
either
the
whole
resource
is
deprecated
or
it's
not.
This
makes
the
model
much
simpler,
but
it
also
means,
of
course,
that
for
some
needs
that
people
might
have
where
they
want
to
deprecate
individual
things.
D
This
might
not
be
the
thing
to
use,
but
so
far
it
seems
that
most
people
are
okay.
We
have
a
list
of
implementations
in
the
draft
and
there
is.
There
is
a
a
good
list
already
if
you
have
already
implemented
that
header
field,
or
you
have
seen
it
implemented
somewhere
and
that's
not
in
the
list,
please
let
us
know
we
are
happy
to
add
it
next
slide.
Please.
D
Thank
you,
so
the
history
now
is:
we've
seen
six
versions
of
the
draft
being
published.
There
were
four
that
were
published
as
individual
drafts,
and
then
we
had
a
little
publication
blip,
which
meant
we
had
to
publish
two
versions
very
briefly,
one
after
the
other,
but
now
there
is
a
stable
version.
I
I
don't
really
see,
there's
no
open
issues
in
the
repo
it.
I
think
it
was
okay
when
we
presented
it
last
time
and
there
were
no
issues
that
were
raised
in
the
meantime.
D
We
did,
I
think,
a
very
few,
mostly
editorial
changes
and
other
than
that.
I
think
it's
kind
of
ready
to
go.
I
don't
really
know
what
the
process
is
but,
like
I
said,
if,
if
anybody
thinks
there
are
things
that
need
to
be
improved,
then
I
would
appreciate
to
see
a
comment
or
to
see
an
issue
on
the
repo.
If
not,
then
I
think
it's
kind
of
ready
to
for
last
call.
C
Okay
I'll
say
a
couple
words
about
the
way
the
process
works,
we'll
yeah,
okay,
so
we
would
normally
ask
you
know
how
many
people
have
read
the
document
we'll,
I
think,
do
all
of
that
on
the
mailing
list,
unless
daryl
feels
comfortable
doing
a
show
of
hands
paul,
but
then
we
say:
okay,
we're
going
to
issue
a
working
group
last
call
that
usually
lasts
a
week.
Maybe
two
where
we
say
is
anyone
object
and
we
make
sure
that
their
objections
have
been
addressed.
C
C
Who
is
our
now
responsible
id
after
she
reviews
it?
It
then
goes
on
to
the
iesg,
which
will
post
it
to
the
ietf
wide
and
they'll
also
do
reviews
the
iesg
has
to
approve
it.
They
can
do
a
discuss
vote
which
has
detailed
things
that
they
find
wrong
or
that
need
to
be
addressed.
It
will
come
back
to
the
working
group
depending
on
the
changes
made
we'll
either
redo
the
last
call
or
send
it
back
up
to
the
isg
fdisg
and
the
ietf
last
call
is
done.
C
It
then
gets
okay,
we're
going
to
publish
it,
and
at
that
point
it
goes
to
the
rfc
publication
group,
and
that
takes
you
know
a
few
weeks
and
then
it's
formally
published.
C
So
I
think
what
makes
sense
eric
is,
if
you
post
a
note
to
the
mailing
list,
saying
you
think
it's
done.
You'd
like
to
issue
a
work.
Last
you'd
like
us
to
issue
a
working
group
last
call
which
daryl
and
or
I
will
do
but
first
see
if
there's
any
other
comments,
give
people
a
chance
to
comment
so
that
we
can
just
do
the
call
once
and
be
done.
C
F
I
I
just
want
to
add
to
speaking
as
an
individual.
I
didn't
realize
that
there
had
been
changes
made
to
make
it
target
just
the
the
resource,
because
I
know
I
I
believe.
Originally
there
was
text
that
was
inferring,
that
it
could
be
more
precise.
F
I
know
that
I'm
familiar
with
implementations
that
do
currently
use
it
to
show
deprecations
within
the
content,
so
I'll
I'll
grab
some
people
who
are
dependent
on
that
behavior
and
get
them
to
come
comment
there,
because
I
think
there
there
is
interest
in
being
able
to
have
finer
grained
capabilities
and
alexander
is
in
the
queue
so
go
ahead.
Alexander.
B
Hello,
alexander
mayor,
I
have
process
question:
do
you
guys
want
reviews
of
documents
as
text
to
the
mailing
list,
or
do
you
want
to
get
full
requests
in
the
in
the
repo
itself
or
both.
C
So
if
you
have
a
pull,
if
you
want
to
just
make
a
suggestion,
if
you
want
to
just
make
a
pull
request,
it's
probably
worth
making
the
pull
request
and
then
posting
a
note
to
the
list.
Saying
I've
done
this
and
you
know
give
a
link
to
the
pr
number
or
something.
D
Eric
go
ahead
just
responding
to
your
comment.
Darryl
there
was
language
in
there
that
said
that
it
did
support
deprecations
of
individual
features,
but
it
never
said
how
which
is
kind
of
the
tricky
part,
and
and
because
of
that,
and
because
we
did
see
some
some
people
using
it
for
that
just
resource
level
deprecation,
and
we
our
assumption,
was
that
if
we
want
to
add
that
mechanism
later
on,
that
could
be
done.
It
just
could
be
something
that
later
on
is
being
done,
maybe
in
in
a
different
spec.
D
A
Let
me
go
ahead
and
voice.
The
comment
that
I
made
in
jabra
chat,
but
the
question
I
have
around
this
particular
id
is
what
we
want
clients
to
do
with
this
information.
A
So
this
the
spec
tells
me
a
lot
about
how
servers
can
express
intent
and
how
they
should
format
it
and
what
they
can
tell
me,
but
it's
unclear
as
a
client.
What
I'm
supposed
to
ever
actually
do
with
that
information,
especially
if
I
don't
have
any
scoping
information
to
go
along
with
it.
D
Yeah,
okay,
so
that
that
is
then
maybe
something
that
we
should
add
to
the
draft
to
put
in
there
and
to
be
honest,
I
mean
there's
not
much
that
clients
can
do
on
a
programmatic
level,
mostly
what
clients
can
do
is
they
can
write
into
log
files
alert?
Whoever
is
is
responsible
for
the
client,
whoever
is
responsible
for
maintaining
that
code,
that
one
of
the
consumed
apis
or
one
of
the
constrained
resources
is
going
to
be
out
of
service
or
is
getting
deprecated,
but
maybe
the
developers
want
to
see
what
replacement
they
can
find.
A
That
sort
of
advice
might
be
useful
somewhere
taking
logging
actions
or
notifying
users
via
some
sort
of
an
interface
are
automatic
automatic
behaviors
that
clients
could
actually
act
on.
D
G
I
think
eric
answered
it.
That
was
what
I
was
thinking
that
you
know
in
the
client
side:
you're,
not
taking
any
programmatic
action.
But
if
you
are
doing
log
scraping-
and
you
find
out
that
there
is
something
a
sort
of
a
warning
there,
then
you
would
go
and
try
to
migrate
to
the
new
version
or
start
preparation
for
the
migration.
G
F
I
will
I
will
also
add
that
a
lot
of
api
developers
work
with
tools
like
postman
or
other
kind
of
developer.
F
D
F
Do
you
one
of
chris?
Do
you
want
to
further
elaborate
on
your
comment
in
the
chat
about
people
doing
bad
things.
A
Yeah,
so
you
know
one
thing
that
I
definitely
wouldn't
want
someone
to
do
is
I
wouldn't
want
someone
to
see
a
deprecation,
followed
by
a
successor
version
link
and
then
have
their
client
automatically
start
making
requests
against
the
successor
version
as
though
it
were
the
previous
one,
because
that
would
be
bad
for
a
whole
host
of
reasons,
and
hopefully
people
wouldn't
do
that,
but
I
certainly
wouldn't
want
them
to
think
that
they
ought
to.
D
B
Hello,
I
think
that
that
if
we
look
at
the
specs,
we
should
be
very
precise
on
the
semantics
and
and
in
other
working
groups.
We,
we
have
had
great
success
with
leaving
the
decision.
What
actually
happened
mostly
to
the
client,
because
I
mean
people
can
get
all
kind
of
weird
ideas
and
upgrading
automatically
to
another
version
of
the
api
would
be
one.
But,
but
I
think
we
should
make
very
clear
in
the
draft.
Having
said
that,
I
haven't
read
it
yet.
B
A
Specifically,
on
the
semantics,
the
alternate
and
successor
version
and
latest
version
don't
have
a
lot
of
detail
on
what
the
semantics
of
those
are.
So,
for
example,
the
alternate
designates
a
substitute
is
a
it
would
be
nice
to
know
if
a
client
is
entitled
to
assume
that
they
can,
they
can
use
that
substitute
in
the
exact
same
way
as
the
current
one,
and
if
they
do
what
parts
would
need
to
be
substituted.
A
So
so
it's
not
clear
to
me
exactly
what
that
means,
and
so
specifying
exactly
what
alternate
and
successor
and
latest
actually
mean
semantically
would
allow
a
client
to
make
decision,
make
informed
decisions.
D
G
Yeah
we'll
try
to
clarify,
I
think
you
know
the
aspect
about
you
know
what
you
interpret
from
it,
and
someone
starts
using
a
newer
version.
Typically,
you
know
when
there
is
serious
application
involved.
There
is
a
process
to
migrate
to
a
new
version
of
the
api.
It
doesn't
happen
just
because
of
you
know.
G
Looking
at
the
response
right,
it
starts
the
process,
so
we
can
up
to
certain
point
we
can
clarify,
but
I
think
a
lot
depends
on
the
documentation
that
the
link
refers
to,
and
that
is
that
is,
you
know,
provided
by
the
api
developer,
and
we
leave
that
responsibility
over
there
in
clarifying
those
things
right.
So
we'll
try
to
put
client-specific
context
examples,
but
I
think
we
shouldn't
expect
a
lot
of
accuracy
from
the
spec
on
that
aspect,
and
I
agree
with
alexander
on
on
that.
C
C
D
D
D
But
for
what
we're
doing
it's
a
little
bit
more
tricky,
because
if
those
now
are
standalone
resources
that
you
can
store
that
you
can
pass
around
that
are
basically
context-free,
then
it
becomes
a
little
bit
more
tricky
to
establish
the
context
of
those
links,
because
there
is
not
this
implicit
context
of
an
http
conversation,
and
that
is
one
of
the
issues
that
we
have
in
open
that
we
still
have
as
an
open
issue
about
the
draft.
But
we
can
look
at
that
in
a
bit
if
we
can
move
forward.
D
One
slide,
please
you
so
just
just
if
you're
wondering
what
this
is.
Looking
like.
This
is
a
simple
example
of
such
a
link
set.
This
is
a
json
syntax.
So
what
you
see
here
is
basically
two
links
that
would
be
represented
in
json
in
that
case
that
originally
or
no
might
also
have
been
used
in
an
http
link.
Header
field.
In
this
case
it's
a
json-based
resource
and
those
two
links
both
have
actually
an
explicit
anchor
that
explicitly
says
where
the
link
is
originating
and
then
one
of
them
uses
the
next
link
relation
type.
D
The
other
one
uses
a
uri
based
link
relation
type
and
then
both
of
them
state
the
target
of
the
link
in
those
href
properties
and
again
we
we
just
reused
what
h,
what
the
http
link
header
defines
and
therefore
we
didn't
really
have
that
much
freedom,
but
the
exact
structure
of
that
json
once
again
is
something
that
we
try
to
make
as
as
nicely
working
with
json
ld
as
possible.
E
D
Okay,
so
we
have
implementations
already,
one
is
particularly
relevant,
so
that
is
a
gs1
digital
link.
So
gs1
is
the
organization
that
is
in
charge
of
basically
defining
all
these
nice
barcodes
that
you
find
on
your
average
supermarket
items
and
they
just
released
a
new
standard
for
how
this
barcode
now
becomes
a
uri.
D
Let's
say
you
ask
information
about
a
medication
you
get
from
a
pharmacy,
then
you
could
get
information
that
says
and
here's
the
information
that's
available
for
consumers
and
here's
the
information
that's
available
for
doctors
and
maybe
here's
the
information
that's
available
for
people
who
have
allergies
or
these
kind
of
things,
and
this
information
then
gets
actually
returned
in
such
a
link
set.
So
it's
a
pretty
major
standard.
D
I'm
sure
there
will
be
literally
billions
of
those
things
getting
used
pretty
soon
and
they
took
what
we
had
in
december,
basically
because
well,
that's
when
they
were
finishing
their
standard
and
that's
where
it's
being
used
already,
so
we're
hoping
that
whatever
we
end
up
with,
we
will
not
break
compatibility
with
what
they
have
now
put
into
their
standard
and
then
there's
another
there's
another
implementation.
Where
I
to
be
honest,
I
can't
say
much
about
it.
This
is
one
where
my
colleague
my
co-author,
howard
from
example.
D
D
D
D
D
So
so
that's
one
of
the
things
we're
still
discussing
and
I
think
the
rest
actually
to
be
honest-
is
more
like
little
details
of
the
draft.
So
it's
not
it's
kind
of
still
stuff
that
we
need
to
resolve,
but
it's
it's
not
really
changing
a
whole
lot
of
functionality
in
the
draft.
So,
from
my
point
of
view,
I
think
we
mostly
have
addressed
all
the
big
questions.
There
are
still
some
small
ones
that
we
need
to
resolve
any
input
on.
Those,
of
course,
would
be
very,
very
welcome.
D
C
E
Yeah,
I
just
thought
I'd
I'd
share
with
the
group
why
gs1
is
finds
us
so
useful.
There's
a
link
in
the
chat
you
could
you
could
follow
if
you
like
and
you'll
see
an
html
rendering
of
a
link
set,
look
at
the
source
to
see
the
actual
json
link
set
object,
if
you,
if
you
so
choose
and
as
eric
has
explained
fully,
I
don't
need
to
repeat
it.
It's
about
providing
links
to
other
sources
of
data
related
to
the
product
that
you
that
you
have
so
we're
not
expecting.
E
They
are
on
a
link
registry
to
include
any
of
our
links
to
things
like
here's,
a
product,
information
page
or
here's
where
you
can
buy
this
thing,
so
we
we
expect
those
to
be
defined
in
our
own
namespace
and
we're
using
that
that
full
power
of
representing
the
the
languages
that
something's
in
or
whatever
it
may
be.
One
thing,
I'm
never
quite
sure
of
in
this
kind
of
thing
is
we're
using
the
standard
in
a
way
that
makes
sense
to
us.
E
I
don't
expect
other
people
to
use
it
in
the
same
way
and
therefore
I'm
not,
for
example,
raising
issues
on
the
issue
tracker,
where
I
think
you
know
what
it'd
be
great.
If
it
did
it
like
this,
because
well,
that's
just
how
I'm
using
it
so,
for
example,
I
I
know
that
the
idea
is
that
you
make
an
http
request
with
the
accept
header
sent
to
lickset
and
you
get
back
the
link
set.
So
that's
not
how
we
do
it.
E
What
we,
what
we,
what
we
do
is
we
say
if
you
want
the
link
set,
you
have
to
actually
ask
for
it
by
putting
a
thing
in
the
query
string
and
then
you
get
back
the
link
set
and
then
the
we
use
the
accept
header
to
determine
whether
or
not
you
get
that
link
set
in
the
native
link,
header
format
or
the
json
format.
We've
only
implemented
one
of
them
so
far
we
will
implement
the
other
one.
E
So
we
are
using
those
features,
we're
using
those
media
types
we're
using
the
link
set,
but
we
may
not
be
using
it
exactly
as
herrick
as
eric
and
herbert
have
planned.
I
hope
that's
not
a
problem
because,
as
far
as
I'm
concerned,
we're
implementing
the
standard
and
we're
very
grateful
that
it's
there
and
we're
planning
to
continue
using
it
there's
another
issue.
I
have
if
there's
one
that
it's
it
says
that
the
ling
set
has
to
be
its
own
json
object.
E
It
has
to
be
an
asian
adjacent
object
with
exactly
one
thing:
that
is
a
link
set.
That's
a
bit
of
a
limitation.
We
want
to
put
other
stuff
in
there.
We
want
to
be
able
to
add
a
link
set
to
another
json
object,
but
again
that's
just
our
implementation.
Does
it
matter
that
we're
doing
that?
So
I'm
kind
of
you
know
wondering
where
it
how
much
this
group
wants
those
kind
of
issues
that
we
have
to
be
issues
for
the
standard.
E
F
F
H
Yes,
okay,
I
I'm
not
up
to
speed
of
this
draft,
but
listening
to
phil's
questions,
I
would
hope
that
we're
not
going
to
try
and
promote
you
know
what
are
perceived
as
best
practices
for
things
other
than
this
format
in
this
draft,
and
I
would
hope
that
phil
would
be
able
to
use
the
structure
here
and
then
any
requirements
about
what
you
know
the
overall
structure
is
would
be
about
the
media
type,
so
you
can
still
use
the
the
json
object
in
another
place.
Just
you
wouldn't
use
the
same
media
type.
For
example.
E
D
Yeah
I
just
I
just
wanted
to
say
that
I
I
think,
there's
nothing
wrong
with
what
what
you're
doing
phil
we
don't.
We
don't
really
say
anything
about
how
to
request
those
things
right.
We
just
define
the
media
types,
so
you
can
use
them
in
any
way.
You
like
the
only
thing
is,
of
course,
if
you
start
putting
a
link
set
object
so
to
speak
into
your
own
json
structure
somewhere
else,
then
it's
not
that
media
type
anymore,
but
I
think
that's
that's
clear
other
than
that.
E
It
might
sound
emotive
for
us.
Yes,
that
is
the
key
thing
for
us
eric
exactly,
as
you
say,
having
that
structure
defined
in
a
way
that
we
can
refer
to
normatively
in
our
standards
because
we're
a
standards
body
as
well.
I
want
to
be
able
to
refer
to
this
normatively
in
the
gs1
digital
link,
standard
and
say
do
that,
and
until
this
is
an
rfc
icon.
F
Excellent,
I
don't
see
any
additional
questions
in
jabber,
so
unless
anybody
has
any
other
thoughts,
we
can
move
on.
C
G
Yeah,
so
thanks,
this
is
just
an
update
on
this
bis
spec
and
I'm
looking.
You
know
at
mark
and
eric.
You
know
if
I'm
wrong
somewhere,
please
chime
in
so
just
can
you
go
to
the
next
slide.
G
This
is
just
information
for
people
who
haven't
looked
at
this
slide,
I
think
mark
and
eric
are
co-authors
of
this
rfc.
They
started
in
2012.
I
think
there
are
12
drafts
and
rfc
in
2016..
G
So
the
motivation
for
the
bis
draft
is
one
of
the
common
use.
Cases
that
we
find
when
we
try
to
use
7807
is
that
it
treats
sending
multiple
problems
in
in
the
error
in
the
response
of
http
request
as
an
extension,
and
so
this
is
the
most
common
case
when
a
new
consumer
of
the
api
starts
using
an
api,
especially.
G
I
have
noticed
this
in
the
fintech
world,
where
the
request
payload
is
a
bit
complex
for
most
of
the
apis,
so
they
come
across
this
problem,
most
often
where
they
have
to
the
api
developers
have
to
send
multiple
errors
in
the
response
and
the
problem
details
rfc
suggested
that
you
know
you
should
provide
an
extension
for
that.
So
because
of
that,
what
happens?
Is
we
find
proprietary
ways
of
sending
the
error
responses?
G
Second
use
case
I
have
come
across
also
a
and
this
is
while
I
think
I
was
at
paypal
at
that
time,
which
is
a
payout
kind
of
use
case
where
you
have
to
pay
to
multiple
parties
in
in
this
gig
economy,
and
at
that
time
you
are
sending
multiple
things
there
and
you
know
the
errors
may
be
coming
from
multiple
payment
transactions,
the
validation
error.
So
that
was
the
second
use
case.
G
G
A
bunch
of
issues
I
was
not
sure
that
we
are
going
to
go
through
these
issues
in
this
meeting,
and
this
is
the
first
time
I'm
attending
itf
meeting
and
presenting
also,
but
just
to
give
you
an
overview.
There
are
probably
15
issues
we
have
resolved
to
for
our
editorial
issues
and
the
rest
are
listed
here.
As
you
see
issues
related
to
clarifying
what
is
what
goes
in
the
type
member
of
the
problem.
Details
json
is
coming
up
in
four
issues.
G
Discussion
is
about,
should
it
be
a
relative
uri,
you
know
or
not,
or
should
it
be
a
urn
how
it
should
be
interpreted,
so
that
requires
some
clarification
and
I'll.
Let
I
think
mark
has
been
involved
with
all
those.
So
maybe
you
know
he
can
provide
better
explanation
if
I'm
missing
something
number
12
problem
details
subject
for
warning,
so
we
have
this
another
id
to
that.
G
There
are
a
bunch
of
responses,
so
these
all
these
issues
are
still
open.
So
if
you
have
any
comments
on
that,
please
feel
free
to
put
your
comments
there.
G
There
are
a
couple
of
issues
which
number
10
and
number
eight
where
the
agreement
is.
Once
we
define
the
change
the
schema
we
should
provide
in
appendix
the
json
schema
for
the
change
with
the
change
problem,
details,
object
and
also
json
and
the
context
and
the
last
one
is
basically
the
issue
which
started
this.
This
effort,
so
link
is
at
the
bottom.
I'm
not
sure
we
are.
We
have
time
to
discuss
all
those
issues,
but
there
are.
These
are
the
issues
in
general
over
there
next
slide.
Please.
G
There
was
one
issue,
and
this
is
the
question
here
is
it
was
about.
Should
we
have
a
repository
for
common
problem
types
graham
raised
that
common
types,
I've
given
some
examples.
He
also
provided
some
examples,
but
there
could
be
more
if
we
have
more
than
you
know.
G
The
question
is
where
it
should
be
listed.
Mark
has
given
couple
of
suggestions,
so
that's
an
open
issue
how
to
treat
it,
but
I'm
not
sure
you
know
it's
part
of
the
work
of
this
rfc
or
is
it
a
separate
ids
required
for
that?
So
that's
a
question
for
the
group
next
slide.
D
F
H
So,
just
just
about
the
one
on
the
screen,
the
repository
of
common
problem
types,
I
think
it
would
be
interesting
to
try
to
have
a
coordinated
community.
You
know
effort
to
define
common
problem
types
and
excuse
me
the
difference
between
these
two
proposals
is,
you
know,
an
iona
registry.
You
know
you
would
need
some
sort
of
process
and
probably
some
sort
of
quality
bar
for
for
getting
into
the
registry,
whereas
if
it
was
something
like
wiki,
then
anybody
could
just
kind
of
lump
in
what
they
like.
I
think
both
are
viable.
H
F
F
I
want
to
say
my
thing
is
not
found
and
then
another
team
says
well,
no
my
thing
is
not
found
and
the
types
those
further
precisions
are
not
really
anything
that's
actionable
by
the
consumer.
They
are
just
more
descriptive
because
this
is
the
way
people
are
used
to
building
apis
where
they
come
up
with
an
error
code
for
everything,
and
it
has
caused
a
lot
of
challenges
for
us
to
manage
those
things
that
don't
really
add
any
ex
real
extra
value.
F
H
And
that
aligns
with
my
experience
too,
I
mean,
I
think,
the
the
probably
the
one
of
the
most
relevant
counter
examples
is
the
the
what
working
group
uses
wiki
to
manage
their
link
relations
registry
still,
and
they
did
that
because
working
with
iono
industry
in
the
past
was
really
difficult.
H
A
Yes,
I
do
think
that
this
would
certainly
be
the
most
most
useful
if
we
have
a
repository
of
common
problem
types
to
encourage
reuse.
I
think
that
will
allow
clients
who
receive
these
to
to
potentially
take
take
common
actions
on
them
to
make
decisions
about.
What's
going
on,
I
think
I
could
see
a
lot
of
value
in
that
as
long
as
the
problem
types
are
well
specified,
meet
reasonable
bars
and
and
iana
has
processes
for
all
these.
F
A
Right
so
we
have
status
codes
for
certain
categories
of
thing
right,
but
the
problem
details
are
going
to
be
more
granular
than
that
right,
so
you
might
have
404
not
found,
and
you
might
have.
The
problem
was
that
oh
now,
I'm
trying
to
make
up
api
things
on
the
fly.
That's
not
going
to
go
well,
but
the
your
problem
may
be
more
more
specific
than
that,
but
still
more
general
than
there
was
a
there
was
a
problem.
Locating
it
in
you
know
my
particular
application
directory.
C
This
is
rich.
Let
me
for
the
benefit
of
some
members.
Let
me
just
mention
how
the
registries
work.
There
are
a
couple
of
there's
an
rfc.
The
number
escapes
me
that
describes
them,
but
they're
iana,
the
assigned
numbers
authority,
maintains
a
text
file
or
a
series
of
text
files
that
lists
different
things,
such
as
the
mime
type
such
as
dns
and
dns
entry
types
and
so
on.
C
C
First,
come
first
serve
meaning
the
first
person
to
get
the
to
claim
the
not
found
error
problem
gets
to
use
it.
There
are
increasing
levels
of
specificity
and
correctness
required.
A
common
one
is
the
most
strict
being.
The
only
thing
you
can
put
in
a
registry
is
something
that
is
documented
in
a
standards
track
rfc,
so
that
takes
a
long
time.
C
A
step
down
from
that
is,
it
must
be
documented.
Typically,
that
means
written
as
an
internet
draft
since
those
always
last
forever
and
midway
between
those
two
is,
it
must
be
documented
and
it
must
be
reviewed
by
a
couple
of
designated
experts
and
they
can
push
back
and
say
no.
This
is
too
loose.
C
This
doesn't
seem
like
something
you
know
you
can't
get
the
not
found
error
for
the
case
where
one
parameter
of
the
method
of
the
api
is
not
found
so
those
kinds
of
things.
So
you
get
a
review.
It's
certainly
possible
to
create
a
registry,
as
I
said,
meets
any
of
anything
along
that
scale.
C
The
experts
would
be
appointed
recommended
by
francesca
and
appointed
by
the
iesg,
the
thing
okay,
so
that's
background
as
a
with
no
hats,
speaking,
not
as
a
chair,
I
prefer
a
registry
because
wikis
and
their
mutability
and
lack
of
permanence
bother
me
in
particular.
If
I'm
going
to
start
to
encode
common
semantics
in
something,
I
really
don't
want
it
to
change
without
some
process,
for
it
to
change,
as
opposed
to
someone
just
added
something
in
the
snip.
H
I
know
julian
made
the
julian
made
the
comment
that
being
the
designated
expert
for
99
registry
is
really
popular,
and
that
is
indeed
the
source
of
most
of
his
fame
and
fortune.
So.
C
H
G
On
this
one,
oh,
can
I
ask
a
question
on
this,
so
for
the
registry
it
seems,
like
you
know,
the
updates
to
it.
If
you
want
to
add
something
or
you
want
to
change
something,
there
is
a
process
involved.
G
H
Yeah
the
reason
that
the
current
rfc
7807
cautions
so
strongly
against
automatically
retrieving
a
problem.
Type
uri
is
because
of
an
experience
that
the
w3c
has
had
with
the
dtds
for
xml.
H
H
So
I'd
be
really
wary
of
setting
up
something
where
the
ietf
were
running
a
critical
piece
of
infrastructure
that
people
were
using
to
to
get
information
at
runtime
if
we
can
design
it
so
that
it's
something
that
they
get
offline,
that
that
might
work,
but
that
to
me
seems
more
like
it's
a
static
repository,
much
like
the
registries
work
now,
rather
than
you
know
something
with
an
api
around
it.
That's
just
my
initial
reaction,
yeah.
C
Although
mark
and
I
work
for
companies
that
can
ameliorate
that
problem,
but
the
the
the
bigger
concern
is
that
a
region
any
published,
rfc
or
you
know
appropriate,
published
rc
can
change
the
schema
of
the
registry,
which
means
that
fetching
it
and
looking
through
it
and
its
description,
most
of
which
are
intended
to
be
human,
understandable.
C
B
H
H
I
don't
think
do
nothing
is,
is
an
option
just
because
this
has
come
up
so
often
we
can
certainly
introduce
some
examples
describing
how
you
know
you
would
handle
multiple
problems
in
an
extension
or
in
your
type
definition,
and
that
might
just
do
it
by
example,
might
help
or
by
defining
a
few,
and
if
we
can,
we
can
maybe
toy
with
trying
to
come
up
with
a
way
to
convey
multiple
problems
as
long
as
they
share
the
same
status
code
semantics.
H
What
I
think
someone
referred
to
as
facets,
so
I
guess
you
know,
let's
we
can
work
on
some
proposals
and
bring
those
to
the
group,
see
how
that
goes
and
the
other
ones
here.
H
If,
if
we
want
to
you
know,
do
something
like
say
that
it's
never
a
relative
uri,
it
could
be
a
short
token
string.
That
is
a
registered
string
or
something
like
link
relations.
Does
we
could
do
that,
but
that
would
be
a
backwards
and
compatible
change,
and
so
we
should
probably
introduce
a
new
media
type
for
the
for
the
format.
H
And
then
the
question
is:
is
that
really
improving
things
when
we
now
have
two
different
problem,
media
types
and
that's
kind
of
the
nature
of
the
discussion?
My
my
reading
of
of
the
current
discussion
is
that
people
are
very
of
introducing
a
new
media
type
and
that
so
we
probably
need
to
work
within
the
constraints
of
refining.
What's
there
and
making
it
more
approachable
for
developers,
but
if
folks
have
feedback
on
that,
that
would
be
really
helpful.
A
G
G
Sanjay
so
want
to
know
what
the
group
thinks
about
inclusion
of
the
warning
into
problem
details.
I
think
we
have
a
brief
discussion
on
the
issue,
but
if
I
just
want
to
raise
it
here,
what
are
the?
What
is
the
thinking
about
that,
including
the
problem
details?
D
Just
briefly
putting
it
so
the
the
warning
draft,
which
still
is
the
individual
submission
right
so
that
one
kind
of
has
solved
a
little
bit.
I
think
if
we
are
revising
the
problem
details,
it
definitely
would
be
a
good
idea
to
think
about
whether
both
of
these
could
go
in
there,
and
I
think
we
did
realize
for
the
warning
draft
that
we
published
a
little
while.
D
D
But
I
think
if,
if
that
is
something
that
we
want
to
add
to
the
problem
details,
then
I
think
we
would
need
to
think
about
how
to
best
do
that,
because
at
that
point
right,
the
the
response
is
not
necessarily
an
error
response
anymore.
It
we
use
the
same
structure
to
serve
in
a
success
response
with
embedded
warning
information
which
would
be
pretty
different
from
the
model
that
the
problem
detail
had
so
far.
B
A
Yeah,
it's
not
clear
to
me
why
warnings
are
just
not
slightly
less
severe
problems.
All
the
same
logic
that
we
have
around
problems
seem
to
apply
well
for
warnings,
and
I
see
no
compelling
reason
that
a
problem
couldn't
be
returned
as
the
result
of
a
successful
operation.
F
Speaking
as
an
individual,
my
understanding
was
there
are
some
scenarios
where
there
is
a
desired
response.
Payload
that
has
it's
basically
a
partial
success
that
here's
a
bunch
of
results
that
we
got,
but
there
were
some
issues,
so
you
might
not
have
the
complete
set
of
results
that
you
were
expecting,
and
that
was
what
I
understood
pretty
much
andre's.
D
So
gary
yeah
yeah,
so
I
mean
what
andre
started
right
with
pretty
much
just
what
you
said.
So
it
was
the
proposal
to
say
that
the
general
structure
of
that
problem
detail
object
is
useful,
but
I
also
want
to
be
able
to
embed
it
in
a
response
that
so
to
speak,
mostly
is
success
but
does
have
some
stuff
in
there.
D
That
might
be
interesting
to
look
at
and-
and
in
that
case
you
could
just
embed
that
the
same
object,
but
it
would
be
a
successful
response
and
not
an
error
code,
but
that
that
was
also
because
when
the
warning
draft
was
started
right,
we
didn't
have
the
revision
of
the
problem
detail
graph
already
on
the
table.
E
H
G
G
Would
you
be
looking
for
warning
with
a
400
or
4x6
or
5xx
class
of
data
score?
My
observation
is
that
you
probably
would
not,
and
what
I
looked
in
the
warning
graph
was
specifically
as
eric
was
saying
that
you
know
it's
a
success,
but
there
is.
There
are
some
warnings,
so
that's
where
it
is
conflicting,
in
my
opinion
that
in
problem
details
we
specifically
say
I
guess
that
4x
is
in
5x6
class
of
problems.
G
We
don't
talk
about
200,
2xs
kind
of
status
quo
there
right
unless
I'm
reading
something
wrong.
I
thought
that
that
was
the
conflicting
part.
How
do
you
include
warning
in
problem
details
and
still
convey
that
warning
with
400
or
500
class
of
error
status,
quo
thoughts.
D
That
said
yes,
but
what
is
that
header
field
then
good?
For
what
can
intermediaries
do
with
it?
And
I
think
that's
a
valid
question.
You
could
still
say:
well,
it's
maybe
some
something
that
you
along
the
way
you
wanna
you
want
to
log.
You
want
to
analyze,
you
want
to
say:
oh
there's,
a
lot
of
warnings
happening.
Let's
look
into
that,
but
that's
I
don't
know
whether
that's
a
good
enough
response,
but
that's
kind
of
a
place.
I
think
where
we
are
right
now.
F
D
Eric
so
mark
already
said
that
right
in
the
chat,
so
the
warning
header
itself
is
deprecated.
So
initially
I
think
we
we
thought
of
piggybacking
on
that,
and
then
we
were
told
no.
This
is
going
away.
So
the
warning
draft
introduced
the
new
header
field,
which
is
kind
of
similar,
so
to
speak
right,
but
it's
not
called
warning.
I'm
blanking
right
now
what
it's
called.
I
don't
know
something
wanting
something:
it
was
content.
F
D
I
think,
and
there
you
go
yeah,
okay,
thanks,
daryl
and
and
that
warning
header
then
basically
surfaces,
the
information
that
that
response
is
success.
But
there
is
something
in
there
that
is
not
so
to
speak
of
full
success.
So
anybody
interested
might
want
to
look
into
this
and
then
that's
kind
of
the
general
mechanics
of
the
warning
draft.
F
F
H
I
am
still
at
the
place
where
I
don't
understand
why
the
header
adds
any
value,
because
you
know
usually,
when
you
add
a
header,
it's
for
somebody
who's
not
going
to
process
the
body.
You
know
it's
it's
for
generic
http
software
or
an
intermediary,
or
something
and
or
it's
because
something
doesn't
fit
into
the
body.
But
if
we're
going
to
put
the
data
in
the
body,
I
think
what
the
header
really
is
in
this
case
is
a.
I
really
mean
it.
H
You
need
to
examine
this
body
and
I
really
mean
it
headers
and
I
really
needed
protocol
elements.
I'm
not
a
big
believer
in
those.
I
I
think
that
you
know
the
recipient.
They
need
to
parse
the
body
and
understand
the
body,
even
if
it
is
successful
and
you
can
write
in
your
format.
You
know
that
the
successful
response
contains
this
thing.
There
might
be
warnings
in
it,
so
be
aware
of
that,
and
developers
should
read
the
documentation.
F
About
and
so
just
as
a
question
chris
smart
sorry
if
the
proposal
was
to
add
actual
content
in
the
header
that
described
what
the
problem
was,
so
that,
for
example,
you
could
return
a
warning
related
to
something
that
wasn't
easy
to
embed
like
I'm
returning
an
image,
but
I
want
to
return
signal
some
kind
of
additional
warning
metadata
about
that
content.
Would
that
be
a
more
valuable
scenario
in
your
mind,.
H
Sure
I
could
see
it.
I
think
there
will
be
some
complications
in
that,
but.
A
Yeah,
I
I
think
I
would
understand
it
a
little
bit
better.
Quite
a
bit
better.
I
can
see
I
can
picture
situations
where
the
the
the
object
you
return
doesn't
easily
contain
some
sort
of
warnings,
and
I
think
it
if
it
does.
You
know
if
you're
returning
a
json
object
from
an
api.
That's
delightful,
just
put
your
stuff
in
there
and,
like
mark
said,
read
the
documentation,
but
if
you're
returning
an
image
you
know
returning
a
link
set.
A
Maybe
you
have
a
warning
that
says
this
link
set
is
truncated.
I
was
only
able
to
give
you
some
of
the
things
again.
I'm
thinking
up
things
on
the
fly
here,
so
maybe
they're
not
good
examples,
but
the
having
the
actual
problem
in
the
header
itself
does
feel
like.
It
probably
addresses
some
use
cases.
F
Cool
were
there
any
other
issues
that
people
wanted
to
bring
up
on
this
https
problem.
This
mark.
H
Working
yet
just
to
con,
to
conclude,
that
is
this:
something
we'd
be
interested
in
doing
this
draft,
because,
if
we're
going
to
have
a
header
that
says
how
to
express
these
things-
and
probably
we
need
some
pretty
tight
coupling
between
the
the
format
and
the
header.
So
is
this
something
we
should
try
and
do.
I
guess.
H
F
Okay,
so
I
think
that
closes
this
issue
and
I
think
we
basically
have
already
had
the
conversation
on
the
next
item
on
the
agenda
so
rich.
Do
you
want
to
pull
up
the
final
topic
here
and
I
shall
take
off
my
chair
hat
and
put
on
my
fireproof
outfit,
as
I
suspect
this
will
be
fairly
controversial.
F
The
th:
this
is
a
proposal
to
see
how
much
support
interest
there
is
in
this
idea.
I
see
some
signs
of
there
being
value
here
and
we
shall.
I
shall
take
you
through
the
story.
So
if
you
want
to
go
to
the
next
slide,
so
api
is
generally
for
the
large
amount
of
cases.
Use
json
as
their
format
and
json
very
wisely
chose
a
very
limited
set
of
primitive
data
formats.
F
Apis
are
describing
all
kinds
of
much
more
richer
semantics
and
people
regularly
want
to
introduce
those
semantics,
but
currently
they're,
just
kind
of
conveyed
out
of
band
and
the
client
figures
out.
Oh
well,
when
you
put
those
series
of
characters
in
that
property,
this
is
how
I
go
interpret
it.
Should
you
go
to
the
next
slide.
F
F
In
our
open
api
specification
to
describe
http
apis
initially
that
we
took
the
type
and
the
format
property
in
json
schema
and
extended
that
even
further,
so
now
we
can
differentiate
between
integer
and
longs
and
floats
and
doubles.
Because
what
tends
to
happen
is
these?
Apis
are
sending
payloads
that
then
get
zoomed
by
people
using
programming
languages
and
we
are
mapping
to
those
types
of
those
programming
languages
and
we
start
to
get
a
little
bit
further
into
programming
languages
types
with
things
like
date
and
date,
time
and
then
odd
cases
like
password
next
slide.
F
F
Please
graphql
is
very
popular
in
the
api
world
and
they
kind
of
went
the
other
way.
They
said,
yeah
we're
going
to
be
really
simple
and
we'll
just
stick
with
okay,
we'll
define
differentiate
between
ins
and
floats
and
we'll
have
strings
and
blue,
and
then
we'll
have
this
special
thing
id,
because
that
has
some
special
semantics,
but
when
it
comes
to
a
date,
the
serialization
of
that
is
kind
of
left
to
the
reader.
F
So
there's
just
a
lot
of
ambiguity
here:
okay,
keep
going
next
slide,
please
you
can
go
further
and
people
have
started
to
try
and
define
further
repositories,
catalogs
of
types,
because
everybody's
api
has
an
address,
and
so
therefore,
why
not
define
standards
for
country
codes
and
well
country
codes?
There's
two
letter
abbreviations
and
there's
three
character
abbreviations,
so
people
are
trying
to
standardize
those
next
slide.
Please.
F
When
it
comes
to
the
serialization
of
their
duration
type,
it
has
two
what
they
call
fields
which
in
json,
get
serialized
as
properties,
one
which
is
seconds
and
then
nanoseconds
and
in
the
specs
that
we're
looking
at
we've
sort
of
seen
the
same
thing.
If
you
go
to
the
next
slide,.
F
F
In
that
case
it
used
the
rel
as
a
property
in
the
json
object,
as
opposed
to
a
map
key,
and
so
it's
not
so
simple
as
saying
well,
we
should
just
have
one
standardized
way
of
formatting
these
things,
because
there
isn't
just
one,
and
sometimes
the
serialization
format
on
the
right
makes
more
sense.
Sometimes
the
serialization
on
the
left
makes
more
sense,
and
so
next.
F
Slide
this
is
really
the
question
that
I'm
asking
is:
is
there
a
place?
Is
there
value
in
creating
a
serialization
registry
for
json
types,
both
primitives
and
complex
types,
where
we
can
give
a
globally
unique
identifier
and
then
reference
a
specification
that
defines
what
the
shape
of
that
json
fragment
is,
and
there
are
questions
like?
Is
this
just
defining
syntax?
Can
we
define
additional
semantics?
F
Should
this
registry
enforce
some
standardized
schema
format?
Do
we
pick
a
winner
in
json
schema
formats,
or
do
we
let
people
just
choose
whatever
they
want
within
the
spec
and
just
go
to
the
next
slide
and
I'll
make
my
pitch
I.
I
think
this
would
be
valuable,
because
we
have
lots
of
people
who
just
keep
reinventing
the
same
thing,
and
then
we
have
efforts
to
try
and
pick
a
winner
as
to
which
is
the
right
one,
so
that
people
will
adopt
it
apis
on
you
know.
Unfortunately,
in
many
cases
they
are
not
self-descriptive.
F
H
F
Okay,
I'm
seeing
suggestions
of
this
is
the
wrong
working
group.
Julian,
do
you
do
you
want
without
elaborate?
What
is
the
right
working
group.
F
F
A
A
F
There
are
a
there
are
some
drafts.
Yes,
there's
conversations
has
been
conversations
about
what
the
white
right
working
group
is.
Some
people
asked
about
whether
it
should
be
in
our
working
group,
and
I
believe
the
suggestion
was
no.
It
would
make
more
sense
in
the
json
working
group,
there
are
a
number
of
people
actively
working
on
those
specifications.
C
Yeah,
so
the
the
context
I
have
is
there
was
acme
is
a
json
based
protocol
for
doing
certificate,
management
and
creation,
and
an
extension
came
up
to
do
it
for
third
parties,
where
you
get
the
certificate
and
the
key.
But
it
goes
to
the
cdn
that
acts
on
your
behalf,
that
kind
of
thing
and
they
defined
a
whole
bunch
of
json,
request
stuff
and
they
had
to
redefine
it
in
c
c,
more
cddl,
because
there
was
no
json
schema
yet
which
just
mind
blowing.
So
I
wonder
I
saw
the
in
the
jabber
thread.
F
The
thing
is
that
jason's
schema
isn't
defining
really
any
semantics.
Json
schema
is
a
validation
language.
It
just
says
when
you
come
across
a
toke
that
property
name
that
is
called
this,
then
here
are
the
rules
that
you
apply
to
that
it.
It
isn't
th.
This
is
this.
I
see
that
it
is
a
distinct
set
of
problems
and
you'll
see
asked
what
is
an
example
beyond
link
set
and
like
it.
It
comes
down
to
if
somebody
defined
a
json,
payload
and
decided
to
use
like
the
iso
format.
F
For
date,
there's
no
standardized
way,
that
is
machine,
readable
to
say
I
picked
the
iso
standard
for
date
in
order
to
communicate
what
that
those
set
of
characters
are
going
to
look
like
there's.
No,
when
I
specify
duration
there's,
you
know,
did
I
spit?
How
did
I
specify
the
set
of
characters
that
define
what
the
value
is
for
that
duration?
There
is
no
one
way
that
anybody
who's
building
a
media
type
or
some
kind
of
protocol
on
top
of
http
can
in
a
globally
unique
way.
F
Okay,
I
I'm
I'm
not
seeing
a
lot
of
enthusiasm,
I'm
seeing
a
lot
of
fear
and
mark
suggested.
We
take
this
to
the
list
so.
A
So
the
the
questions
I
ask
when
I'm
when
I'm
trying
to
determine
whether
something
should
be
worked
on
as
a
standard
is,
is
it
useful
and
do
different
parties
need
to
agree
on
it,
and
I
think
I
think
you've
clearly
hit
both
hurdles
here
and
especially
demonstrated
that
we
have,
you
know
a
half
a
dozen
competing
standards,
and
so
clearly
we
should
have
another
one,
and
so
I
I
do
think
there's
definitely
work
here.
A
The
question
is,
then:
do
we
have
enough
agreement
to
do
it
and
is
the
problem
well
enough
specified?
It
is
now
at
the
appropriate
time-
and
I
don't
know
that
I
have
the
answers
to
all
of
those
questions.
F
This
is
a
proposal
to
allow
all
of
those
existing
standards
to
have
a
standardized
way
of
identifying
json
structures
that
are
defined
within
their
standard,
like
json
schema,
for
example,
has
this
property
called
format,
which
is
very
specifically
an
identifier
that
provides
additional
semantics
over
and
above
the
json
type,
and
it
is
intended
to
address
this
particular
problem.
The
fact
that
jason
itself
doesn't
provide
any
additional
semantics
other
than
those
basic
primitives.
The
thing
is
that
format
value
the
range
there.
There
is
no
range
of
values
that
you
can
use
in
that
format.
F
It's
just
a
string
that
anybody
can
make
up,
and
hopefully
people
will
adopt
a
common
set
of
strings
and
I'm
like,
if
you
look
at
some
of
the
other
examples
that
I
gave
it's
like.
Every
spec
comes
along
and
wants
to
give
some
kind
of
identifier
to
this
kind
of
type
and
I'm
or
this
kind
of
shape
of
data,
and
I'm
suggesting
that
we
create
a
repository
of
those
identifiers
which
would
could
be
used
by
any
of
the
existing
standards
or
future
standards.
A
Right
yeah,
I
think
I
understand
that
that
does
make
sense,
and
I
can
see
a
lot
of
places
where
it
would
be
useful.
You
could
have
common
library,
implementations,
there's,
definitely
a
lot
of
utility
to
it.
There's
still
questions
about
whether
there's
a
lot
of
agreement
about
it.
F
Yeah,
actually,
the
biggest.
What
comment
that
came
up
that
I
was
sort
of
surprised
at
is
the
fact
that
folks
don't
feel
that
this
is
the
right
working
group
to
do
this,
which
is
really
interesting
because
I
see
this
is
one
thing
that
http
apis
are
very
dependent
on,
but
it's
good
feedback.
F
C
The
only
one
I'll
really
mark
nottingham's
going
to
bed,
but
he
thinks
this
is
interesting
and
looks
forward
to
seeing
discussion
on
the
list
and
I
think
that's
probably
the
best
place
for
it.
For
now.
F
C
All
right,
normally
at
the
last
session
or
the
last
day,
we'd
say
everyone
have
safe
travels
home,
but
maybe
that
just
means
walk
across
the
hall
or
upstairs
or
something
so
don't
slip
and
fall
as
you
walk
from
one
home
office
to
another.
Thank
you
very
much
people.
This
is
really
interesting
and
worthwhile.
I
think
we
made
a
lot
of
good
progress
and
look
forward
to
seeing
some
stuff
on
the
list.