►
From YouTube: IETF114-HTTPAPI-20220729-1400
Description
HTTPAPI meeting session at IETF114
2022/07/29 1400
https://datatracker.ietf.org/meeting/114/proceedings/
A
A
C
C
B
B
B
This
is
the
note.
Well,
if
you
haven't
seen
it
before
it's
because
you've
been
late
to
all
of
the
other
meetings
or
your
eyes.
Weren't
open
yet
be
good
to
each
other,
don't
hide
patents.
We
have
a
process.
We
have
a
process,
someone
so
meeting
tips.
Everyone
should
know
this
by
now,
also
sign
in
Via
meet
Echo.
If
you're
in
the
room,
there
is
a
take
the
mobile
phone
app
starting
the
QR
code,
that's
on
the
back
halfway
through
the
room
or
outside
the
room.
B
C
B
E
E
The
goal
for
this
draft
is
to
communicate
service
limits,
so
clients
can
stop
before
being
traveled
out
and
the
basic
goal
was
to
align
all
the
original
existing
fields
and
stop
headers
proliferation.
So
we
didn't
want
to
invent
a
new
way
of
doing
just
to
consolidate
the
shape
in
which
something
already
happens,
and
we
added
another
field
to
express
limiting
policy
move
on.
E
E
E
We
added
privacy
configurations
and
we
got
a
lot
of
more
a
lot
of
interesting
in
their
fields,
thanks
to
especially
Mark
Nottingham,
and
to
all
the
folks
that
supported
this
specification
in
the
integration
period.
Next,
and
so
we
are
currently
two
open
issues.
The
first
one
is
not
to
allow
rate
limiting
fields
on
trailers,
because
no
one
uses
them
and
it's
way
too
complex
to
Define
all
this
Behavior.
E
E
E
D
E
E
So
my
our
opinion
is
and
is
to
be
consistent
with
the
original
goal
of
this
specification
and
try
to
consolidate
a
long-standing
practice
to
provide
something
that
must
value
for
current
implementer
I.
Think
that
in
in
the
future,
if
the
current
ecosystem
changes,
we
could
be
open
to
make
a
new
specification
for
rate
limiting
fields
and
providing
a
way
of
combining
the
information.
But
in
this
case
we
think
that
the
the
result
would
just
be
to
have
another
standard
that
nobody
uses.
E
So
the
first
goal
for
us
is
to
consolidate
the
current
ecosystem
around
the
specification
in
the
future
is
implemented
field
that
there
is
some
operational
experience
and
provide
feedback,
a
positive
feedback
on
a
combining
the
field.
We
can
make
a
red
limit,
big
Maybe,
but
currently
I
think
this
is
not
an
option.
We
want
to
gather
and
join
all
the
implementers
existing
implementers
under
one
in
the
future.
E
One
will
have
these
one
Consolidated
community
on
rate
limiting
field,
if
the
implementers
feel
or
if
the
work
group
things
that
the
ecosystem
is
ready
for
an
updated
specification.
We
will
have
a
Consolidated
group
of
implementers
of
this
specification
of
this
pack
and
we
can
move
the
Consolidated
Community
to
a
new,
improved
Maybe.
H
Roberto
I
understand
your
your
arguments
here,
but
it's
just
not
appropriate
to
have.
You
know,
make
a
decision
that
is
made
on
arguments
or
or
on
data
that
is
not
brought
to
the
working
group
by
the
people,
making
the
arguments
that
makes
me
really
uncomfortable
I
think
we
need
to
have
a
discussion
as
a
working
group
and
talk
about
the
pros
and
cons
and
make
a
decision
as
a
working
group.
Not
just
have
the
editors
say:
well,
we've
talked
to
a
bunch
of
people
and
we
think
that
it
should
be
this.
E
E
This
was
the
result,
so
I
I,
just
done
don't
want
to
I
just
wanted
to
clarify
that
we
tried
to
accommodate
this
requests
and-
and
we
think
that
in
the
future
we
have
no
objection
to
to
move
that
to
to
to
a
structured
field.
What
I
I
am
not
sure
that
is
the
right
thing
to
do
is
just
to
to
have
structured
Fields
as
a
goal.
E
In
my
opinion,
structural
field
is
not
a
goal
per
se.
Okay
to
go
here
to
for
the
original
goal,
for
this
specification
is
to
consolidate
a
standard
and
about
political
proliferation,
the
the
it
is
not
to
force
anyone
to
adopt
structural
field,
even
because
we
don't
have
the
faults
in
this
case
for
pushing
structural
fields
in
an
ecosystem
that
is
currently
not.
E
C
B
C
Is
anyone
yeah,
okay,
so
I
want
to
I
want
to
focus
on
the
goal
here,
which
is
to
express
this
information
in
a
way
that
the
people
can
use
and
I.
Think
that
this
debate
about
structured
Fields
is
really
the
the
nub
of
it.
I
I
honestly
find
the
the
spelling
of
this
information
across
three
fields
to
be
a
little
odd,
but
there
are.
There
are
aspects
of
that
that
make
me
think
that
maybe,
under
certain
circumstances,
the
having
separate
Fields
could
be
somewhat
advantageous
in
the
sense
that
there's
this.
C
This
reset
field,
for
instance,
is,
is
stable,
where
the,
where
the
other
ones
might
not
be
on
on
a
per
request
basis,
so
I'd
rather
concentrate
on
those
sorts
of
arguments
than
than
these,
like
Mark
I'm
a
little
uncomfortable
with
the
the
way
the
this
is
being
being
argued
and
seemingly
decided.
I
think
this
is
at
some
level
the
editors
work
for
the
working
group
and
need
to
need
to
try
to
capture
the
the
decisions
that
are
made
here.
B
G
B
B
B
B
B
G
B
B
B
F
H
Yeah
is
it
working
it's
working
yet:
okay,
I
I
I'll.
Let
Martin
give
his
opinion,
but
for
me
it
is
there's
an
aesthetic
aspect
to
it.
There's
a
kind
of
a
you
know,
don't
repeat
yourself:
it's
it's!
The
having
three
headers
is
very
repetitive.
There's
questions
about.
You
know
how
they
interact
and
and
generally
in
HTTP
we
have.
You
know
we
don't
spread
things
across
multiple
headers
unless
there's
a
good
reason
for
it,
and
there
are
sometimes
good
reasons
for
it,
but
I
don't
see
any
here.
I
think
the
the
most
probably.
H
The
biggest
reason,
though,
is,
is
that,
if
we're
going
to
specify
these
as
structured
Fields
but
make
them
look
like
they're,
just
simple,
integers
and
simple,
you
know
so
that
and
and
really
the
draft
currently
downplays
the
fact
that
they're
structured
fields-
and
this
was
discussed
quite
a
bit
in
the
issue-
it's
a
bit
of
an
attractive
nuisance
and
that
people
will
say.
Oh
look,
it's
just
an
integer
I'll,
just
parse
it
as
an
integer
and
that'll
break.
H
I
think
the
expectation
in
the
ITF
is
is
that
you
will
specify
parsing
materialization
to
at
least
as
as
high
a
level
as
structured
Fields
does.
So,
if,
if
you
know
that
to
me,
I
think
is,
is
the
path
you'd
take?
If
you
want
this
to
be
three
headers
is
say:
okay,
it.
You
know
you,
you
specify
a
parsing
in
the
serialization
algorithm
for
each
one.
That's
bespoke,
but
there's
not
a
great
reason
to
do
that,
because
we
already
have
these
algorithms
defined.
H
C
That
was
a
lot
I'm
I'm
hoping
to
capture
all
of
it,
so
I
I,
agree
with
everything.
Mark
said.
I
also
think
that
in
this
case,
this
can
be
a
lot
more
efficient
and
simpler
in,
in
the
sense
that
it
is
an
atomic
unit.
At
the
point
that
you
have
everything
together
and
splitting
across
multiple
multiple
Fields
means
that
you,
you
need
to
go
looking
at
multiple
places
for
the
for
the
information.
I
personally
think
that
this
is
much
easier
to
to
process
from
a
a
usability
perspective.
D
A
A
lot
of
comments,
speaking
is
an
individual
one
of
my
concerns
about
rate.
Limiting
editors
always
has
been.
The
practice
is
to
re
once
you
support
returning
these
rate
limiting
headers,
you
return
them,
basically
on
every
response
and
I
think
there
there's
a
burden
on
the
client
and
the
burden
on
the
network
to
transfer
those
things
on
every
single
response
and
the
simpler
that
we
can
make
this
from
a
processing
perspective.
On
the
client
side,
the
better
and
having
just
one
header
to
parse
I
think
is,
is
easier
and
simpler.
E
Okay,
I,
the
the
argument
excuse
me
here
is
that
a
I
think
that
if,
if
it
would
be
simpler
and
easier,
somebody
else
who
would
have
done
it
in
the
sense
that
the
the
actual
what's
trade
implementation
provide
free
Fields.
So
this
happens
independently
on
what
we
may
argue
about,
what's
more
efficient
because
implemented
to
do
it
in
in
another
way.
E
E
A
E
You
can
probably
just
use
remaining
and
reset
values
to
shape,
to
shape
your
policy,
but
in
in
my
experience
with
the
implementers
I
know,
those
values
are
used
in
different
ways,
depending
on
the
kind
of
interaction,
so
in
some
cases
they
they
use,
even
even
the
policy.
Indeed,
even
the
policy
value
to
to
make
photograph,
for
example,
in
other
they
consider
that
requests
can
be
multiplexed,
so
they
assign
each
a
couple
of
triple
of
fields
to
different
users
from
the
a
single
client.
E
So
yes,
there
is
the
possibility
that
one
gateway
to
received
some
fields
and
lowers
them,
for
example,
depending
on
the
how
many
services
this
Gateway
is
services,
so
the
possible
the
possibility
to
mangle
these
fields
is
different.
Both
internally
one
is
a
structure
and
on
the
web,
and
in
case,
for
example,
an
intermedia
is
processing
those
fields.
The
the
the.
E
B
D
B
We're
going
to
close
the
queue
on
this.
Obviously
we
have
to
have
discussion
on
the
mailing
list,
encourage
please
people
who
were
involved
in
the
API
community
that
aren't
commenting
to
either
comment
in
the
pull
request.
Remember
the
working
group
decided
to
use
GitHub
and
and
or
the
mailing
list,
let's
figure
out
as
Spencer
would
say:
let's
make
good
decisions,
so
Roberto
move
on
to
your
FAQ.
E
D
D
E
E
We
have
different
goals
for
this
specification,
but
the
just
the
yaml
D
was
moved
to
the
w3c
world
group
that
is
working
on
Json,
ID,
so
Cara
for
this
presentation.
We
just
focused
on
yaml
and
plus
Yama
structure,
syntax
suffix,
because
there
are
nothing
API
engagement
schema.
We
still
have
a
lot
of
work
to
do
next.
E
We
have
the
other
things.
We
focused
the
the
yaml
in
another
draft
and
we
almost
completed
the
Yemen
data
registration
with
security
until
probability
configuration
fragment
identifier,
multi-documented,
yam
of
streams
and
a
strength
and
con
efforts
with
Yama
community
for
rest.
Apis
I
said
before
there
is
still
other
work
to
do
next.
E
E
So
this
is
one
of
the
points
should
every
plastic,
yaml
media
type
use
the
same
fragmented
identifier
of
application,
yaml,
the
yes
Alexa.
We
will
register
the
placental
suffix
to
together
with
yaml,
so
the
proponents
says
that
structured
syntax
facets
are
a
way
to
implement
list
of
substitution
principles.
So
if
something
is
valid
for
application
yaml,
it
should
be
valid
for
any
plasma
media
type.
E
We
think
that
this
can
affect
future
media
types.
For
example,
a
Json
schema
Plus
yaml,
or
link
linked
data
plus
yaml
already
well
for
General
schema.
They
already
defined
a
fragment
identifier
certification,
so
if
they
were
forced
to
use
the
same
application,
yaml
fragmented
amplifier.
This
means
that
the
it
will
be
impossible
to
use
to
register
schema
plus
yaml
using
the
same
fragment.
E
It
does
not
require
that
plus
yaml
and
yamo
have
to
have
the
same
fragment
identifier.
So
since
this
is
not
a
requirement,
I
think
that
I
would
favor
these
the
ability
for
new
implementation
to
to
use
yaml
to
extend
the
syntax,
with
with
respect
to
Define,
different
media
types,
the
or
to
have
inconsistent
implementation
between
something
plus
Json
and
something
plus
yaml.
E
D
A
Not
sure
I
don't
know
that
I've
seen
this
on
the
the
the
spec
and
but
I
sorry
in
the
discussion
and
I
did
see
it.
The
the
this
conversation
about,
if
you
use
plus
yaml
you
have
to
support
the
native.
Is
this.
This
SSS
fragment
ID
and
the
one
mitigator
to
that
might
be,
for
example,
open
API,
Plus,
yaml,
open
api's
use
of
yaml
is
limited
to
what
yaml
calls
Json
schema,
not
to
be
confused
with
the
thing
that
is
called
Json
schema.
Yaml.
E
D
A
E
F
A
A
E
A
E
E
C
Roberto
Roberto
can
I
interrupt
yeah
sure
I
am
completely
incapable
of
following
what
you're
saying
here.
Can
you
write
down
something
for
the
notes?
Please
I've
been
really
struggling
to
pause.
What
you've
been
saying
and
I'm
I'm,
mostly
following
along,
but
that
last
little
bit
I
completely
lost
you.
A
The
suggestion
that
Roberto
is
saying
is
just
because
application,
yet
slash,
yaml
uses
this
fancy
format.
It
doesn't
mean
that
plus
the
animals
have
to
do
it.
If
they
want
to
support
this
fragment
identifier
with
the
anchors,
then
they
can
explicitly
say
in
their
media
type
registration
that
they
support
the
format.
The
fragment
identifier
that
uses
anchors
did
that
help
at
all.
A
And
I
think,
because
this,
what
you're
saying
Roberto
that
868
38
doesn't
require
that
they
need
to
have
the
same
fragment.
Id,
then
I,
think
being
explicit
in
media
type
registrations
as
to
which
ones
which
fragment
identifiers
are
supported,
is
seems
to
me
like
a
a
very
valuable
solution
and
solves
the
problem.
Mark.
H
H
Do
the
right
thing
that
if,
if
the
people
forget
or
they're
lazy-
or
you
know
whatever
that
they,
there
is
still
a
fragment
identifier,
syntax
that
is
sensible
for
that
format
available,
but
they
can
opt
out
of
it
so
that
that's
without
knowing
too
much
about
the
specifics
here.
I
have
no
idea
what
SS
says
is,
for
example,
but
that's
the
general
pattern
that
I've
seen
in
the
past
I
think
foreign.
B
E
Excuse
me
the
interoperability
considerations,
to
defer
this
to
the
gamma
specification,
or
we
can.
We
can
Define
another
draft
either
under
the
ITF
or
other
organizational
umbrella,
but
I
don't
know.
Maybe
you
think
that
it's
something
we
must
have
a
way
for
conducting
gamma
to
Jaden
in
this
specification
or
not.
E
A
I
I
will
just
comment:
I'm
not
sure
I'm
allowed
to
voice
an
opinion
here,
but
as
an
individual
I
would
defer
this
to
the
yaml
swag.
The
ammo
spec
is
attempted
to
define
a
way
to
limit
yaml
usage
that
was
compatible
with
Json
schema.
If
you're
saying
that
there's
holes
in
there,
let's
go,
let's
go
ask
them
to
close
those
holes.
E
B
D
I
C
B
C
B
A
B
A
H
I'll
have
to
go
and
check
that
we
do
have
finally,
a
pull
request:
much
belated
for
a
Json
LD
context
as
an
appendix,
but
there's
been
a
fairly
robust
discussion
on
the
details
of
that
and
it
it
doesn't
look
like
it's
actually
been
resolved.
Yet
I,
don't
know
enough
about
Jason
LD
to
comment,
whether
it's
good
or
not.
So
as
an
editor,
I
I'm
a
little
concerned
about
incorporating
it
without
wider
review
and
I'm
still
not
sure
that
it's
actually
necessary
to
put
it
in
the
specification.
H
I
Yeah,
can
you
hear
me?
Yes,
yes,
okay,
great
hi,
everybody.
My
name
is
Eric
yeah,
so
it's
not
so
much
about
Jason
LD
right
in
the
end
Jason
hell.
He
is
a
mapping
mechanism
into
interpret
Jason
as
RDA
and
I.
Think
that's
where
the
problem
is
because
if
you,
if
you
specify
the
mapping
into
RAF,
you
have
to
settle
on
an
rdf
vocabulary
right
because
essentially
that's
what
you
will
standardize
the
RDS
vocabulary
that
the
Json
gets
mapped
to
and
I
think.
I
I
H
H
G
A
A
But
the
big
issue
is:
what
started?
How
does
the
conversation
is
use
structured
fields
and
turned
into
hey?
How
do
why
don't
we
just
completely
redesign
this
API,
this
HTTP
header,
to
a
completely
different
thing?
So
Eric?
Do
you
want
to
just
give
us
what
the
current
state
is
there
and
or
Mark?
Do
you
want
to
jump
in
ahead
of
time.
A
I
A
long
discussion
in
in
the
GitHub
issue
and
I
don't
want
to
kind
of
rehash.
The
whole
thing,
I
think
what
we,
what
we
have
ahead
of
us
now
right
and
that
it's
great,
that
we
have
this
meeting
so
that
maybe
we
could
also
have
like,
like
a
pole
around
that,
because
I
I
really
would
like
to
know
what
people
are
thinking.
I
So
so
the
draft
as
it
is
now
has
been
written
kind
of
to
be
in
line
with
the
the
sunset
header
field,
which
is
has
been
an
RFC
for
a
little
while
and
and
that
that
was
kind
of
the
motivation
to
have
something
similar
for
deprecation,
and
it
also
uses
the
same
syntax
right
and
then
a
little
while
ago.
There
was
an
issue
proposing
that,
instead
of
using
that
syntax,
which
may
not
be
great
going
forward
because
it's
harder
to
parse
than
some
other
syntax,
we
could
switch
to
structured
Fields.
I
Here
there
are
again
and
and
use
structured
Fields.
Instead,
my
feeling
was
that
it
would
be
better,
even
though
I
agree
that
the
structure
field
way
is
better
in
a
vacuum.
But
since
deprecation
and
sunset
are
pretty
closely
related,
my
my
takeaway
was
I.
Think
it's
better
if
those
two
Fields
work
the
same
way
and
use
the
same
syntax,
so
this
is
kind
of
where
the
first
decision
would
need
to
be
made.
I
So
right
now
the
draft
still
is
using
the
the
sunset
syntax,
which
is
the
the
iso
date
format
and
and
in
that
issue
that
Daryl
I
think
is
showing
here
there's
a
long.
If
you're
interested
right,
you
can
look
it
up,
but
it's
it's
a
long
discussion
and
then,
at
the
end
of
the
discussion
right,
we
also
get,
and
there
was
a
I
think
there
was
an
idea
that
kind
of
at
the
same
time,
Roberto
and
Mark
had
and
I.
I
I
You
could
distinguish
four
apis
and
then
that
header
would
just
be
called
something
like
life
cycle
and
it
could
have
different
time
stamps
in
it,
and
it
could
always
use
structure,
fields
or
anyway,
always
the
same
syntax,
and
that
would
make
it
easier
to
have
one
place
where
the
life
cycle
info
is
going
so
I
kind
of
like
that
idea.
What
I
don't
like
is
that
this
would
basically
mean
to
start
from
scratch,
so
that
I
think
in
my
mind,
is
the
downside
and
I.
I
I
I
H
G
H
We
can
hear
you
separate
from
this
whether
or
not
it's
a
structured
field
or
not
I
find
the
idea
of
a
life
cycle.
Header
really
intriguing,
I
think
it.
It
would
be
really
nice
to
have
one
place.
You
can
go
and
look
and
find
about.
You
know
the
the
status
of
the
API
you're,
interacting
with
and
and
where
it
is
in
its
life
cycle,
so
that
that
to
me
seems
like
really
nice,
rather
than
having
it
spread
across
multiple
headers
I.
H
H
H
But
if,
if
you
know
the
reason
is
compatibility
with
Sunset
and
we
decided
to
go
that
way,
then
fine,
what
I'm
more
interested
in
getting
feedback
from
this
working
group
is,
is
and
I'm
now
going
to
hijack
this
session.
Thank
you
very
much
in
the
HTTP
working
group,
we're
talking
about
adding
a
date
type
to
structured
Fields
as
part
of
the
retrofit
draft
and
they're.
H
You
know
we
we're
at
this
decision
point
because
retrofit
ads,
structured
equivalence
to
the
date
header
and
the
expires
header
and
the
last
modified
header,
which
are
all
dates
so
now,
is
the
opportunity
to
introduce
the
date
type.
If
we're
ever
going
to
do
that,
and-
and
so
you
know,
the
the
HTTP
1.1
serialization
of
it
could
look
like
an
ISO
date.
You
know
where
the
net
sign
at
the
front
as
discussed
in
the
pr
or
it
could
be
an
at
sign
with
just
an
integer.
C
H
It
representing
an
Epoch,
you
know
second,
since
January,
1st
1970.,
and
what
I'm
asking
for
here
is
feedback
on.
You
know
if
we
defined
a
date
type
in
in
structured
Fields,
would
that
make
it
more
interesting
to
use
structured
fields
for,
for
you
know,
cases
like
deprecation
and
other
things
in
this
working
group.
H
So
far,
the
discussion
in
the
HP
working
group,
I,
I'm
I,
my
reading
of
it
is-
is
that
people
think
that
the
textual
representation
should
probably
just
be.
The
at
symbol
is
the
sigil
to
denote
that
it's
a
date
and
then
an
integer
after
it,
which
is
not
as
human
friendly,
but
it's
easier
to
parse
and
serialize
and
a
tool.
C
H
Reliably
recognize
that
thing
to
present
it
in
a
human
friendly
fashion,
if
need
be
so
any
kind
of
feedback
that
people
had
would
be
super
super
helpful
and
if
people
here
don't
want
to
use
it
if
they
that
that's
not
interesting
in
whatever
form,
that's
good
information
to
take
back
to
the
HP
working
group
too,
so
I'm
done
hijacking.
Sorry,
please
return
to
your
normal
flight.
I
I
think
if,
if
to
go
the
life
cycle
route,
I
think
it
would
make
sense
to
really
design
it
in
a
way
that
it
is
extensible
and
and
if
we
want
to
make
it
extensible,
we
need
to
come
up
with
some
extensibility
model
and
it
probably
will
be
some
kind
of
registered
date
thing
and
I
I.
Don't
think
we
can
wiggle
our
way
up
to
that
point,
I
mean
either
we
say
this
should
be
future
proof.
Then
we
have
to
think
about
how
we
want
to
make
a
future
for
you.
I
I
H
Mark
okay,
I'm
gonna,
disagree
with
Eric
there
I
think
it
would
be
super
super
easy,
because
if
it's
defined
as
a
structured
field,
then
it's
going
to
be
either
a
list
or
a
dictionary,
and
that
is
naturally
extensible
and
you
don't
need
to
registry.
All
you
do
is
is
that
the
next
time
you
want
to
add
one
of
these
things.
You
have
another
RFC
that
Updates
this
one
and
it
adds
a
new
value.
That
is
the
simplest
extensibility
model,
the
ITF,
and
we
do
it
all
the
time.
H
A
One
comment:
Mark
about
the
dates
going
back
to
the
date
think
you
say:
integer
plus
epoch
I
have
experienced
working
with
teams
where
they've
said
they've
used
integer
fields
and
then
there's
the
question
of
well.
What
is
your
origin
time
for
the
epoch
and
my
understanding
is?
There
are
different
origin
times
floating
around
for
Epoch
now,
maybe
that's
just
because
I
spend
too
much
time
in
a
Microsoft
world,
but
is
it?
A
A
A
I
So
my
recommendations
first
ask:
should
we
just
move
on
with
deportation
as
we
have
it,
because
it's
finished
pretty
much
so
we
we
could
just
have
it
if
we
want
to
have
it,
and
would
that
be
good
or
not
just
finishing
the
application
in
one
way
or
the
other,
and
then
the
second
question
would
be
for
those
who
sorry
I
misspelled.
So
the
first
question
is
so:
should
deprecation
be
syntactically
aligned
with
sunset,
or
should
it
be
something
else
that
is
supported
by
a
structured
field?
F
D
G
G
I
So
maybe
I
can
jump
in
here.
So
it's
it's,
not
a
scientific
poll
I've
seen
sunset
being
recommended
in
some
API
guidelines
here
and
there
it's
not
that
everybody
uses
it,
but
it's
something
that
I've
seen
a
doctor,
at
least
in
some
cases.
I
have
received
a
few,
not
many,
but
a
few
questions
around
deprecation
asking
hey:
when
is
this
ready?
We
would
like
to
make
that
part
of
our
guidelines,
so
we're
not
sure
if
we
should
reference
it,
because
it's
just
a
graph,
so
I
would
say
at
least
there's
interest.
I
A
I
C
A
I
I
A
A
I
I
C
A
C
A
H
A
A
C
Yeah,
so
we
had
some
discussions
in
the
Ohio
walking
group
earlier
this
week
and
we
essentially
concluded
to
take
the
the
pieces
of
this
work
that
are
relevant
to
that
and
and
take
it
there
and
and
probably
I'll
abandon
doing
anything
more
generic,
so
I
mean
there's
some
stuff
in
there.
That's
interesting,
but
I,
don't
think
it's
really
worth
pursuing.