►
From YouTube: IETF101-MILE-20180322-1810
Description
MILE meeting session at IETF101
2018/03/22 1810
https://datatracker.ietf.org/meeting/101/proceedings/
A
E
B
All
right,
good
afternoon,
good
evening,
everyone
happy
Thursday
homestretch
last
session
for
the
day.
Yeah
don't
go
there,
okay,
so
welcome
to
the
mile
working
group.
So
if
you're
not
here
for
mile,
you
can
choose
to
listen
in
or
do
something
else
instead
next
slide,
so
hopefully
by
now
you
are
very
familiar
with
the
updated
note.
Well,
so
I
will
not
keep
you
guys
any
longer.
I'm
presuming
you
guys
know
all
this.
B
So
I
guess
we
can
do
the
next
slide,
but
I'm
gonna
take
a
pause,
so
go
ahead
and
do
do
the
agenda.
Yeah
so
will
will
go
ahead
and
take
su.
Do
you
want
to
give
the
status
okay
so
again
in
the
interest
of
time?
This
is
the
agenda.
We'll
do
the
quick
agenda.
Bash.
Does
anybody
have
comments,
or
can
we
just
move
forward
great
okay?
So
before
we
get
to
the
model
status,
what
the
chairs
would
like
to
do
is
gratefully
and
deeply
thank
our
outgoing
ad
as
an
ad.
B
She
has
been,
or
continues
to
be,
a
personal
friend
advisor
and
guide
to
both
of
us.
So
we
will
sorely
miss
you
as
our
ad
Kathleen,
but
yes
I'm,
relying
on
that.
So
we
decided
to
give
you
something
that
may
have
a
little
alcohol
but
gluten-free.
B
And
also
with
that
I
wanted
to
welcome
our
new
area
director.
I
guess
we're
gonna
do
something
a
little
new,
so
he
apologizes
for
not
being
able
to
be
here,
but
he
is
actually
not
a
security
area
director,
but
was
the
chair
prior
chair
before
my
joining
and
that's
Alexi,
so
we're
looking
forward
to
having
him
back
okay.
So
with
that,
let
me
turn
it
over
to
Takeshi.
So.
C
This
is
a
state
as
a
mile,
as
you
can
see,
we
have
completed
a
lot
to
work
on
Tina
for
the
data
representation.
We
have
already
published
RFC
7970,
so
the
remaining
specs
we
have
to
work
on
is
JSON
you're
deaf.
Regarding
transport.
We
have
a
lot
to
do
so.
We
still
have
to
work
on
XMPP
great
for
the
Rolly
Rory
Cole
was
already
published
in
February,
but
we
still
have
a
sisters
Rory,
so
we
basically
have
to
work
on
JSON
and
you're,
deaf
she's
at
Rory
and
XMPP,
great
and
so
on
and
the
milestone.
C
B
B
So
so,
as
I
mentioned,
the
Rolly
sea,
sir
I,
did
put
out
a
call
for
adoption
and
it
was
positive
and
I
tried
to
send
out
the
yes
Steven,
graciously
and
I
accepted
it.
This
morning
did
submit
the
actual
working
group
version
of
the
draft
and
I'm
presuming.
That's
what
you'll
provide
the
update
for
yeah,
so
I
think
with
that
we
should
just
go
ahead
and
let
Steven
go.
F
Okay-
oh
it's
louder
now
for
those
of
you
that
were
in
sac
home,
there
should
be
a
couple
duplicate,
slides,
so
try
and
get
through
those
and
then
into
the
body
of
what
I
actually
want
to
get
into
next
slide.
Please
so,
as
I
talked
about
before
these
are
the
Rolly
drafts
that
are
currently
being
thought
about
or
being
worked
on.
There
is
the
c-cert
document
here
in
Miele,
like
Nancy
said
that
was
just
officially
posted
as
a
working
group
document
this
morning,
the
software
descriptor
document
that's
in
sockem,
which
was
also
updated
recently.
F
There
is
a
rolly
discovery
draft
that
I
want
to
talk
about
today
in
this
presentation
as
a
personal
draft
and
in
the
future
we
might
work
on
something
specifying
search,
and
there
has
been
interest
in
this
room,
in
particular
with
working
on
a
JSON
version
of
Roly,
which
I'll
talk
about
later,
as
well.
Next
slide,
so
Roly
was
published
as
RFC
832,
so
that
is
very
exciting.
Thank
you.
The
working
group,
everyone
in
this
group
that
contributed
to
that
document,
either
as
review
or
comments.
F
So
Roli
c-cert
adopted
as
a
working
group
document,
it's
draft
IETF
mile
roll
EC,
sir
zero
zero.
So
as
per
the
discussion
that
we
talked
about
last
time,
an
IETF
100,
we
had
some
comments
regarding
the
requirements
when
an
I/o
def
content
is
being
carried
in
the
entry.
We
have
these
requirements
that
came
into
play
as
soon
as
you
started,
carrying
io
def
I.
Think
Chris
put
in
a
bunch
of
comments
about
that.
So
thank
you.
We
have
relaxed
those
requirements.
What
that
means
is
that
it
is
much
easier
to
actually
carry
io
def
enrolling.
F
It
was
a
little
bit.
It
was
too
difficult
before
there
was
all
these
requirements
all
these
different
things
you
had
to
do
so,
and
it's
not
much
easier
to
actually
carry
io
def
in
a
Roley
entry.
It's
much
easier
to
implement
it's
much
easier
to
parse.
It
all
makes
a
lot
more
sense,
so
those
are
really
really
good
changes.
I'm
really
happy
with
that,
and
then
in
this
most
recent
version
we
also
made
a
number
of
small
editorial
net
changes,
updated.
F
All
of
our
references,
I
went
through
and
just
made
a
series
of
small
updates
in
the
future.
There
are
some
things
that
we
would
like
to
change
moving
forward,
so
the
document
is
currently
an
informational
draft
because
it
does
not
have
particularly
many
normative
requirements
moving
forward.
We
would
like
to
upgrade
some
of
the
requirements
around
properties
and
categories
in
order
to
make
sure
that,
inter
compatibility
is
maintained
when
you're
dealing
with
iof
and
other
c-cert
datatypes
and
move
some
of
these
requirements
up
to
musts,
so
those
changes
have
not
happened.
Yet.
F
G
Jordan
yeah
so
I'd
like
to
help
work
on
this
document,
because
I
am
very
interested
in
the
top
media
type
being
supported
by
this
I
do
know
a
thing
or
two
about
that:
the
app
the
actual
registration
for
sticks
is
being
done
elsewhere.
So
we
won't
need
to
worry
about
that
here.
So
I
am
in
the
process
of
submitting
that.
G
F
H
On
yeah,
actually
in
the
media
type
registrations,
I
don't
see
one
for
IO,
deafplus,
JSON
I
guess
maybe
this
is
directed
towards
taki.
As
the
editor
of
that
draft,
are
you
planning
on
doing
a
media
type
registration
for
FRA,
Adela's,
JSON.
F
I'm
not
gonna,
get
reset
yeah.
You
would
be
happy
to
help
so
I
just
went
through
the
process
of
learning
how
all
these
media
type
registrations
work.
So
I
drafted
up
the
swig
tag,
plus
XML
media
type
and
in
software
descriptor,
so
I'd
be
happy
to
show
you
that
and
I
did
check
and
there's
no
media
type
registration
for
I/o
deaf.
F
Unless
anyone
you
know
knows
otherwise,
but
I
did
not
see
one
so
I
think
that
it
would
be
the
best
course
of
action
for
us
to
register
that
media
type
so
that
we
can
be
using
it
enrollee.
In
order
to
describe
these
iof
documents
be
able
to
tell
the
consumer
hey.
This
is
IO
def
at
the
moment.
My
plan
is
to
do
it
in
the
actual
document.
The
c-cert
document
itself,
although
I
was
talking
to
Ben.
F
Oh
yeah
he's
not
here
because
he's
not
responsible,
AD
anymore
or
not,
for
this
I
mean
here
eck
amended
that
we
talked
to
the
designated
expert
for
media
types
and
asked
him
if
it's
best
to
do
it
in
the
document
itself
or
to
do
it
in
an
additional
document.
So
I'll
figure
that
out,
but
it
is
my
plan
to
register
the
io
def
media
type
for
Rowley,
so
we
can
be
using
that
and
then
yeah
we'd
like
it
to
be
standard
track
once
we
make
those
changes
which
will
be
soon
next
slide.
F
B
B
So
once
you
give
me
the
update
once
you
post
the
update-
sorry,
let
me
know
so:
I
can
I
mean
so
once
we're
done,
I
was
going
to
ask
for
people
to
help
review
and
provide
feedback
depending
on
the
feedback.
If
there's
very
little
changes
and/or,
if
they're
all
editorial,
then
I
can
then
ask
the
question
to
the
group:
do
you
believe
this
draft
is
ready
for
last
call
right.
B
I
B
B
B
B
F
This
is
work
that
is
relevant
to
the
core
and
I
want
to
talk
about
this
for
a
few
minutes,
because
it's
it's
important
and
relevant
to
people
that
care
about
Rowley,
and
this
is
something
that
was
actually
taken
out
of
the
core
document
in
order
to
get
it
through
publication
as
quickly
as
possible.
So
your
next
slide,
please,
we
do
not
discuss
discovery
in
the
Rowley
core
document,
but
we
used
to.
We
took
it
out
because
it
was
something
that
was
going
to
delay
the
publication
of
Rolex.
F
It
was
something
that
we're
gonna
have
to
go
and
figure
out
and
write
all
this
text.
For
so
we
took
it
out
of
the
Rowley
core
document
in
order
to
get
Rowley
published
it's
quite
as
possible,
it's
something
that
is
still
important,
because
at
the
moment,
the
only
way
for
early
repository
to
be
discovered
is
for
someone
a
human
to
input,
a
service
document
location,
the
full
URL
for
it,
which
requires
some
kind
of
side
channel
communication
right.
They
they
pull
it
off
of
the
front
page
of
a
website,
someone
emails
it
to
them.
F
They
stumble
across
it
by
accident
and
and
just
find
a
service
document
laying
there
one
way
or
another,
a
human
actually
has
to
be
involved
for
this
service
document
discovery
process
and
clearly,
as
a
machine-to-machine
mechanism.
That's
probably
not
how
we
want
to
be
doing
things.
We
want
to
specify
a
discovery
mechanism
that
allows
for
machines
to
automatically
discover
the
full
locations
of
service
documents
from
a
domain
name.
That's
that's
the
kind
of
top-level
requirement
here
next
slide.
F
So,
in
order
to
accomplish
this,
I've
posted
a
new
draft,
it's
really
short
because
it's
just
kind
of
the
framework
right
now
it's
a
starting
point.
We
have
a
lot
of
ideas
on
how
we
want
to
do
discovery
then
I'm
going
to
go
over.
We
have
the
technologies
in
mind
and
how
we're
going
to
use
them.
We've
even
started
working
on
some
implementation
of
it
and
actually
getting
testing
of
it
up
and
running
already.
So
we
have
a
really
really
good
starting
point
on
this:
we're
not
doing
R&D,
we
kind
of
know
what
we're
doing.
G
You
going
to
walk
through
those
examples
and
how
what
you're,
proposing
okay,
because
I'm
one
of
those
weird
people
that
still
runs
their
own
bind
server
and
I've
tried
playing
around
with
this.
Because
we
have
a
desire
for
this
and
another
tangental
thing
and
have
yet
to
find
a
decent
solution.
So
I'd
be
curious
to
see
what
yeah
so.
F
I
yeah
I
believe
we've
found
a
decent
solution.
That's
that's
my
belief
anyway.
So
next
slide,
we
found
two
different
ways
of
doing
this.
One
is
DNS
SD
and
the
other
is
an
apt
Oh
records.
The
first
DNS
SD
is
represented
defined
in
RFC
67-63,
it's
based
on
DNS.
It
builds
out
basically
your
typical
zone
file
stuff,
but
apply
a
whole
suite
of
extra
requirements.
On
top
of
that,
in
order
to
basically
expose
arbitrary
information,
so
it
allows
for
arbitrary
data
passing
through.
I
F
Dns
query
system
and
and
full
path
resolution
from
DNS
queries,
so
using
DNS
SD
would
allow
us
to
using
a
specific
resource
type
go
in
and
actually
from
the
query,
pull
out
the
full
path
of
a
rolly
service
document,
as
well
as
any
number
of
roli
service
documents
in
after
records
defined
by
to
nine
one.
Five
would
also
let
us
do
the
same
thing,
but
with
a
lot
of
downsides
that
make
it
I
think
not
the
right
choice
for
this.
It
was
originally
designed
for
the
s
IP
protocol.
It's
based
on
reg
X.
F
It's
a
little
bit
heavy
weight.
It's
complicated.
It
would
be
really
difficult
to
define
in
the
document.
It
would
be
long
and
kind
of
difficult
and
and
really
the
killer
for
me
is
that
it
requires
additional
implementation
on
the
DNS
server
side.
Dns
SD
just
works
since
it's
using
existing
fields
to
fill
in
information
and
additional
requirements
on
top
of
that,
DNS
SD
just
automatically
works
on
any
existing
DNS
server.
So
that's
cool,
so
we're
moving
forward
with
DNS
SD,
but
I
wanted
to
give
the
two
technologies
that
were
possible
solutions
up
there.
J
J
It
is
probably
still
too
complicated,
but
I
mentioned
it
for
completeness
the
other
is,
and
the
dot
well-known,
well-known,
URI
forms.
Yeah
I
I
see
that
that
not
noted
that
I
last
I
looked
and
I
confess
I'm,
not
I'm,
not
keeping
up
to
date
on
it,
but
taxi
I
run
Oh
over
in
the
stick.
Land
was
using
dolt.
Well,
no
yeah,
so.
F
So
was
Rolly.
Originally
we
actually
had
dot
well
known,
specified
in
the
core
document,
and
when
we
took
it
to
the
is
iesg
they
said
it's,
they
said
no.
They
said
that
dot.
Well
known
is
not
designed
for
that
purpose.
They
say
we
were
effectively
misusing
it
for
as
just
this
kind
of
arbitrary
pointer
when
it's.
J
F
It's
it's
because
it's
it's
pointing
to
a
specific
instance
of
a
resource
it
it's
it's
not
this
yeah,
yeah,
I
and
I
could
go
back
to
the
email
chains
and
and
see
that's
all.
That's
all
on
the
mile
list.
There
was
lots
of
feedback
on
it,
but
ya
know
we
tried
dot
well-known,
and
these
two
are
the
the
remaining
I.
Don't
know
you
get
you
napped
or
I'd,
not
heard
about,
so
that
thank
you
for
pointing
that
out.
I'll,
take
a
look
and
see
if
it
fits
on
this
list,
but
yeah.
G
Sure
right
so
yeah,
so
I
actually
found
another
one.
I'm
gonna
dealt
with
some
really
interesting
ways
of
viewing
text
records
and
some
stuff
like
that.
To
do
a
lot
of
this
I
tried
these
in
my
buying
server
and
I.
Couldn't
get
this
to
work
well,
so
I
really
I'll
help
you
work
on
the
document
right,
I'll
help.
G
H
F
Yes,
we
do
have
DNS
SD
working,
it
was
works.
Well,
next
slide,
so
we're
moving
forward
with
DNS
SD
in
the
document.
Just
because
it
we
checked
the
other
options.
We'll
take
a
brief
look
at
you
nap
der,
but
it
seems
like
DNS.
Sd
is
just
the
right
choice
for
this.
It's
simple.
It's
easy
to
specify.
It
makes
the
document
much
shorter
and
easy
to
read
and
it's
so
much
easier
to
implement.
So
unless
someone
has
has
another
solution
and
I
will
look
at
you,
neptr
then
I
think
DNS.
F
B
So
I
guess
we
can
ask
right
now.
Does
the
group
believe
that
we
should
address
discovery
for
roli?
Can
I
have
a
home?
Please
is
there
anyone
that
objects
or
does
not
believe?
Can
you
hum
please?
Okay,
so
that's
good.
It
seems
like
given
the
discussion.
We
still
need
to
look
at
options.
So
let
me
ask
the
question
more
directly.
You
put
out
a
draft
yes
right.
How
many
have
read
that
draft
okay?
So
we
need
to
have
that
draft
reviewed
before
we
can
say.
B
F
B
F
And
the
other
thing
my
last
item
on
here
is
at
the
last
IETF
we
had
in
groom
in
room
interest
in
starting
a
JSON
version
of
Roly
I
haven't
written
a
single
word
of
it,
but
I
would
like
to
take
a
chance
now
to
see
if
there's
anyone
in
this
room,
who
would
be
interested
in
beginning
to
do
authorship
or
contribution
on
that
document.
I
know
taki,
you
were
interested
and
Bret
was
interested
as
well.
Yes,
I.
G
F
G
A
G
G
B
K
F
Great
sounds
good
all
right,
so
I'll
reach
out
to
everyone
that
have
volunteered
the
two
people
and
we'll
get
a
draft
ready
for
the
for
the
I
guess,
we'll
just
start
working
on
it,
it's
possible.
We
could
have
it
for
whenever
this
interim
is
and
if
not
I'll
have
a
first
draft
ready
for
the
next
IETF,
okay,
and
that
is
rolling
for
today.
I
think.
Unless
there's
the
next
slide,
hiding
which
I
don't
think
they're
it.
Okay,
I.
B
Wow
you're
tall
I
got
it
I.
Think
I
think
this
works,
cuz
taki
will
be
up,
and
you
know
okay,
so
I'm
really
reporting
out
from
all
the
great
work
that
Peters
seen
Andre.
My
co-author
did
on
next
life.
So
this
is
just
really
really
brief.
B
So
from
the
last
set
of
feedback,
I
had
way
too
much
stuff
in
there
that
tried
to
show
the
entire
workflow,
and
so
the
suggestion
was
that
perhaps
I
have
cut
too
much
out
of
the
draft,
and
also
the
request
was
to
do
a
better
mapping
of
how
XMPP
could
be
used
and
milds
more
specifically
how
we
could
use
it
with
I/o,
deaf
or
how
io
deaf
could
be
carried
through
the
XMPP
system.
Next
slide,
please!
B
B
You,
but
given
some
of
the
feedback
and
Sakon
I,
guess
the
question,
so
I
did
these
lights
before
you
present
it
so
again,
the
whole
notion
was
to
show
that
and-
and
we
didn't
want
to
put
all
of
the
different
chips
in
there
right
but
was
just
to
show
you
the
example.
The
base
example
of
how
you
could
carry
information
using
the
XMPP
as
a
base,
foundational
architecture
as
well
as
XMPP
as
a
transport.
B
The
question
now
is
whether
we
need
whether
this
group
feels
that
we
need
to
put
more
on
here
or
as
we're
now
unfolding
interoperability
and
sockem,
whether
we
do
another
well
I
still
think
we
should
do
a
separate
one,
that's
specific
to
sockem,
since
this
one
is
specific,
IO
death.
But
this
is
where
I
need
more
guidance
because,
prior
to
second
I'm
willing
to
say
this
is
ready
for
for
another
review
and
then,
if
everything's,
okay,
then
I
think
we're
ready
to
do
another.
M
M
N
B
F
So
I
heard
the
most
recent
version
the
question
I
had
was
regarding
the
requirement
level
of
the
you
know
like
the
first
seven
sections,
the
non-security
requirement,
stuff,
yeah
I,
don't
think,
there's
I
think
there's
like
one
requirement
in
that
in
all
of
that.
So
from
all
the
way,
from
the
beginning
of
the
document
down
to
security
considerations,
there's
like
one
or
two
normative
words
and
then
there's
like
30
and
security
considerations
and
so
I'm
wondering
from
an
implementation
perspective.
You
know
how
do
you,
how
do
you
conform?
F
F
B
F
B
B
B
I
can
I
can
turn
another
revision
and
I
can
try
and
do
it
before
you
know
by
minute
mid-april.
So
so.
C
D
C
So
now,
let's
meet
up,
let
me
update
JSON
binding
draft,
so
me
myself
and
Roman
Emil
is
working
for
a
JSON
binding,
and
this
is
very
easy
well
compared
to
the
other
box,
it's
a
binding
of
as
a
JSON
to
the
ionic
button,
so
I
just
want
to
quickly
update
what
I
have
done
so
based
on
the
discussion
at
ie
gave
100
we
just
revised.
What
we
do
is
just
minimizing
the
pages.
We
have
60
pages.
Well
now
we
have
39
pages.
We
minimize
a
lot
gone
please.
So
this
is
a
structure
of
Dortmund.
C
We
have
a
just
like
the
same
way
as
a
deaf
person.
We
have
a
data
type
on
JSON
data
model.
Another
example
and
schema
calm,
please.
So
in
the
data
type
section
we
have
a
table,
we
decided
not
to
write
sentences
st.
it's
a
too
long.
We
don't
have
a
mapping
table.
If
we
take
a
look
at
the
table
we
can
see.
This
is
all
the
type
of
the
IO
def
defined
by
I
will
fight
until
we
can
see
how
we
implemented
that
by
using
JSON.
It's
very
simple.
That's
the
same
way.
C
C
Second,
please
so
in
Section
3.2,
this
is
very
important.
I
guess
this
is
a
list
of
the
changes
I
made
because
we
are
using
JSON.
We
have
to
change
a
bit.
So
this
is
the
kind
of
a
change
I
did
so,
for
instance,
we
use
attribute
and
element
without
any
difference.
They
are
equally
treated
other
members
over
the
class
and
we
deviate
some
classes.
Hello
class
is
deleted.
Application
head
across
it
deleted
signature
data
class
indicated
attackers
observable
reference
for
us.
We
could
close
what
an
idiot
as
we
discussed
in
the
previous
meeting.
C
They
are
just
continuous.
They
were
prepared
for
the
semantical
purposes,
so
we
delete
it,
but
it
does
not
mean
anything
to
the
content
of
the
data.
I
guess
so
this
yes,
so
in
the
JSON
schema
section
we
have
a
schema
defined.
So
basically,
the
document
is
only
for
the
schema
other
than
schema
everything.
Just
information
in
section
five,
complete
schemas
written
other
place
is
just
explanation
not
normative.
This
section
is
only
no
motive.
C
The
problem
is
here:
I,
don't
with
you
can
see.
Json
schema
is
not
yet
published
at
an
RLC.
That's
a
problem.
We
wanted
to
finish
this
work
today,
but
we
cannot
because
of
this
reference
issue.
Json
schema
is
still
individual
draft
and
we
cannot
reference
it
as
a
trust
for
reference
for
the
standard
track
RFC.
So
so.
B
B
H
B
C
G
O
C
What
I
wanna
do
if
I
move
all
the
JSON
schema
to
the
appendix
and
I
will
create
the
schema
by
using
c
d,
BF
c
DD
l
in
the
main
body
text.
In
this
way
we
do
not
have
any
problem.
I
guess
I
just
hope
people
can
wait
until
I
understand
how
to
write
c,
DD,
l,
I'm
not
sure,
but
maybe
one
month
three
months,
I
can
produce
new
draft
and
try
to
ask
you
to
review
and
we
hopefully
can
finish
it
ASAP
as
well.
B
O
G
O
It's
unclear
whether
that's
the
new
shiny
thing
in
terms
of
adoption,
but
there's
no
other
way
to
specify
how
to
say
it
in
JSON.
Otherwise,
because
if
we
didn't
do
that,
the
document,
would
we
be
two
pages
saying
here's
parsing
guidance
about
how
you
do
one
thing:
well,
how
you
take
the
thing:
that's
an
XML
and
do
it
in
JSON.
So
that's
the
only
way.
Standards
way
that
right
now
we
can
specify
how
to
state
things
in
JSON,
I.
G
H
Dave
well,
tomorrow,
I
think
I
think
the
value
that,
when
providing
schema,
is
that
it
helps
implementations
with
ensuring
that
they
can
form
with
the
model
that
we're
describing
and
it's
also
non
ambiguous.
Whereas
you
know
having
you
know,
textual
pros
can
be
non
ambiguous,
but
it's
a
very
hard
lift
in
order
to
it
to
try
to
get
to
that
to
that
level.
So
you
know
having
some
normalized
vocabulary
for
the
the
model.
You
know
really
can
help
with
clarity
in
in
implementing.
J
I'm
going
to
assert
that
the
kinds
of
developers
that
Bret
refers
to,
as
as
the
aviary
you
know,
they're
the
web,
2-0
developers
and
other
people
who
refer
to
as
the
cool,
kids
and
I
hope
open
enough
to
stay.
To
saying
that
I,
don't
think
that
they
are
also
the
kinds
of
programmers
who
will
care
or
be
able
to
handle
any
kind
of
json
schema.
I
O
C
C
L
L
The
first
is
our
customizing
or
existing
Oasis
combat
us.
There
is
this
many
Oasis
combat
and
combat
zone
libraries,
for
example,
on
JSON
to
XML
or
XML
to
JSON
XML
to
JSON.
It
was
a
trying
to
track
these
tools
suitable
for
simple
conversion,
but
difficult
to
implement
custom
mapping,
rules
between
JSON
and
XML
and
second
approach
is
using
Excel,
SL,
T
and
X
types
eat
in
France,
Rita,
C,
0,
and
it
have
two
factions
and
wines
JSON
to
XML
and
the
other
is
exhibit
to
JSON.
L
L
L
L
But
I
think
I
it's
a
implementation
program
of
the
Python
library,
but
it
could
cause
a
loss
on
some
other
generators
but
data's.
So
we
may
we
may
consider
and
see
that
was
not
to
remove
these
set
of
occasions
in
that
JSON
draft.
A
A
B
C
B
H
B
Alright,
so
we're
down
to
the
a
OB
there's,
anybody
want
to
raise
anything
going
once.