►
From YouTube: IETF100-MILE-20171116-1810
Description
MILE meeting session at IETF100
2017/11/16 1810
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
B
C
D
A
Okay,
let's
get
started
so
that
I
optimistically
think
we
can
maybe
get
done
early
all
right
so
good
afternoon
to
the
almost
next
to
two
last
sessions.
Well,
the
last
session
for
today.
So
you
are
in
the
mile
working
group.
If
this
is
not
where
you
want
to
be
it's
up
to
you
so
I'm,
not
gonna,
read
through
the
note.
Well,
I
think
everybody
knows
that
by
now.
So
let's
go
on
to
the
next
slide.
A
Okay,
so
we'll
give
a
quick
status
of
where
we
are
now
with
respect
to
the
different
drafts,
then
we'll
have
Stephen
provide
updates
to
the
two
Rolly
drafts
that
he's
been
working
on
then
oh
I'm,
sorry,
we're
gonna
have
the
guidance
draft
first
update,
then
Stephen
and
then
I,
don't
think
I
need
the
full
ten
minutes.
Literally
I'll
just
need
two
minutes
to
provide
an
update
on
the
XMPP
and
then
taki
will
provide
the
update
on
the
new
submission
for
the
Jason
binding.
A
A
Okay,
so
where
we
are
now,
when
you
look
at
the
Charter
and
the
work
that
we
set
out
in
this
working
group,
we
currently
have
three
drafts
that
have
been
adopted
as
working
group
drafts
so
in
the
base
spec,
it's
representing
io
def
in
JSON
format.
So
that's
the
new
draft
that
techie
will
be
talking
about
and
then
for
the
transport.
F
F
A
F
F
Impotent
when
it's
rebuilt
from
the
noid
he
pointed
out
include
inconsistency
of
XML
language
repute,
which
is
optional
in
RFC
791
zero.
But
it's
mandatory
in
the
schema
and
this
program
is
I,
was
presented
by
tactic
Assange
at
the
last
mile
session
and
probably
I
think
it
will
be
fixed
in
errata
next
right
and
other
comments.
It's
a
shoes.
F
Comments
float
that
just
ringing.
Oh,
it's
I
think
I,
it
seems
important
and
she
says
what
is
what
is
a
preference
of
the
distrust
to
be
an
informational
or
to
be
a
BCP,
the
answer
of
all
sides?
Yes,
it
is
as
it
stays
as
informational
and
she
has
also
agreed
at
so
and
finally
are
we.
We
are
now
and
fixing
a
story
or
mistakes
with
RFC
editors.
F
A
G
D
My
email
scripts,
it
alright
doesn't
matter.
Okay,
I
am
Steven,
bang
Hart
from
NIST
and
I
am
here
to
provide,
hopefully
the
kind
of
last
status
update
here
on
the
work
that
we've
been
doing
on
the
Roley
core
document.
So
the
version
14
was
just
posted
like
this
morning,
actually
I
think
so.
The
data
tracker
now
represents
version
14,
so
I'm
gonna
go
ahead
and
walk
through
the
current
status
of
the
draft
here.
Only
if
you
could
go
to
slide
2
for
me
here.
Thank
you.
D
D
We
have
resolved
that
issue
with
the
remaining
members
of
the
isg
that
had
those
discusses,
and
we
updated
that
in
version
14
I
think
I'm
going
to
talk
a
little
bit
more
about
this
issue
later,
on
a
slide
to
kind
of
clarify
what
exactly
changed.
What
the
impact
is,
what
it's
going
to
mean
for
the
draft,
but
ultimately
it
means
that
the
Ayana
registration
for
dot
well-known,
has
been
removed
from
the
draft
is
kind
of
the
long
short
of
it.
I'll
get
into
a
little
bit
more
detail
on
a
later
slide.
D
So
since
IETF
99
we've
had
a
very
successful
ad
review,
a
successful
art
review,
successful
iesg
review.
We've
made
a
ton
of
editorial
changes.
The
document
is,
is
in
a
much
better
place.
Always
it
continues
to
improve
so
really
happy.
With
all
the
review
we've
been
going
through,
we've
had
a
couple
minor
normative
changes,
nothing
that
is
particularly
implementation
breaking
or
anything.
That
really
should
be
too
much
of
an
impact.
So
these
are.
These
are
small
changes
next
slide,
please.
D
So
a
really
quick
walk
through
all
the
changes
that
have
happened
since
Prague,
just
to
make
sure
that
everyone
is
up-to-date
with
the
things
that
have
happened,
so
versions,
9
and
10
came
very
quickly
one
after
another,
and
this
reflects
pretty
much
all
the
changes
that
happen
during
the
ad
Review.
This
included
some
editorial
changes.
We
adjusted
the
language
that
we
use
when
we're
talking
about
TLS,
primarily
we
we
recommend
against
the
use
of
TLS
1.30
round-trip
time
resumption.
D
There
are
some
nasty
replay
attacks
that
come
into
play
with
that
feature,
enable
that
are
particularly
damaging
to
restful
services
and
that
are
just
not
compatible
with
the
kind
of
security
nature
that
Roly
is
dealing
with
here,
and
so
we
recommended
that
that
feature
be
turned
off
in
TLS
1.3.
It's
not
it's
not
normative.
It's
not
a
must,
but
we
do
recommend
that
in
the
draft
for
security
purposes-
and
we
also
updated
our
security
references
in
security
considerations
next
slide,
please
version
11
was
the
AR
T
review.
D
We
updated
TLS
references,
making
many
references
out
to
seven
five,
two
five.
This
allowed
us
to
shorten
a
section,
make
it
easier
to
read,
make
sure
that
people
weren't
slogging
through
these,
like
four
paragraphs
of
text
that
is
really
horrible
to
read.
Now
it's
much
cleaner.
We
reduced
the
severity
of
requirements
around
the
/resource
/name.
D
Plantations
a
little
bit
more
freedom
around
how
they
deal
with
the
root
resource.
We
were
a
little
bit
what
we
felt
was
and
the
art
reviewer
was
felt
overly
restrictive
with
that
root
resource,
preventing
implementations
and
servers
from
actually
able
to
use
that
resource
for
other
things.
So
there
was
concern
with
that
roman.
D
D
Language
in
the
role
ec
cert
draft
remains
the
same,
so
does
that
need
to
be
made
consistent
based
on
that
feedback?
No,
there's
there's
no
consistency,
issues
that
happen
there,
the
language
in
this
user
draft
as
far
as
I,
intend,
unless
the
working
group
decides
otherwise
to
state
a
salmon
c-cert,
so
that
it
more
strongly
supports
the
rid
resource,
because
that
was
a
pretty
cool
use
case
in
in
that
text
in
the
original
Rolly
document,
when
it
was
a
like
rollio
2,
or
something
like
that.
D
D
The
other
big
change,
big
minor
change
in
the
IRA
RT
reviews
that
we
switched
from
you
our
eyes,
I
mean
we
switched
from
I
our
eyes
to
you
our
eyes.
We
had
a
couple
comments
about
that
about
some
problems
that
that
brings
up
and
the
some
of
the
issues
with
the
fact
that
current
implementations
of
Adam
we're
switching
to
you
our
eyes
anyway,
and
then
in
order
to
maintain
interoperability
and
compatibility,
it
would
be
best
if
we
made
that
switch
as
well.
D
We
agreed
with
that
review
note
and
we
made
that
change
in
the
in
the
document.
Next
slide,
please
versions,
12
and
13
contain
our
iesg
review
again.
This
is
more
editorial
fixes.
Some
example:
inconsistencies
were
fixed,
reflect
some
of
the
new
changes
that
we
made.
We
updated
our
terminology
boilerplate
to
be
CP
14,
which
notably
includes
the
better
clarification
around
lowercase
requirement
text,
and
there
were
a
few
lines
that
imposed
extra
requirements
on
security,
consortiums
that
reviewers
felt
were
unnecessary.
D
Security
consortiums
know
what
they
want
to
do
best
and
we
needn't
really
be
telling
them
exactly
what
they
need
to
be
doing.
So
we
relaxed
several
of
those
okay
next
slide,
so
this
was
version
14.
These
changes
have
been
made
over
the
github
on
the
github
repo
over
the
last
couple
of
days.
If
you've
been
following
that,
however,
this
version
was
just
posted
to
data
tracker
yesterday
and
the
posting
of
this
draft
cleared
two
of
our
discusses
and
the
last
discuss
is
hopefully
pending
being
cleared
in
shortly.
D
This
change
removes
the
Slashdot
well-known
registration,
which
means
that
there
needs
to
be
a
new
way
of
reliably
and
automate
ibly
discovering
rolling
service
documents.
So
the
isg
review
talked
about
the
fact
that,
even
with
a
dot,
well-known
registration,
it
is
not
guaranteed
for
the
service
document
to
actually
be
located
at
this
location
and
that
we
weren't
actually
completely
achieving
our
goal
of
full
discovery
anyway,
and
so
we
needed
a
more
full
solution.
D
So
we
have
removed
that
well-known
registration
allowing
those
discusses
to
be
cleared
and
we've
started
work
on
a
rolly
discovery
draft
to
provide
a
fully
specified
fully
automated
solution
for
service
discovery
for
Rowley
we're
investigating
the
relevant
technologies.
Things
like
na
pointer
and
service
records,
DNS
SD,
all
these
things
so.
I
Dave
I
just
wanted
to
provide
I,
think
more
detailed
description
of
the
discussion
that
we
had
with
the
number
of
folks
on
the
IHG,
but
it
was
mostly
Adam
Roche
and
Ben
Campbell's
objections
to
the
dot,
well-known
registration
that
we
were
working
to
address.
So
their
concern
was
that
we
should
be
telling
a
more
complete
discovery
story
that
that
you
know
simply
defining
dot.
Well-Known
still
doesn't
provide
a
mechanism
by
which
you
can
discover
the
the
host
and
port
that
you're.
I
You
know
that
you're
accessing
we
mentioned
service
documents
as
a
as
a
way
of
doing
that,
but
we
actually
had
no
normative
requirements
around
that
solution,
so
their
preference
was
for
us
to
define
a
more
complete
discovery
story.
So
one
of
the
things
that
we're
going
to
do
is
we're
going
to
to
start
a
rolly
discovery,
draft
that
that
that
could
potentially
bring
back
in
the
the
work
that
we
that
we
pulled
out
now,
there's
a
number
of
different
ways
to
go
about
doing
this
discovery
scenario.
I
D
We
want
this.
We
want
this
out
as
quickly
as
possible.
We
know
it's
something.
That's
important.
In
the
meantime,
we've
provided
text
in
the
Rowley
core
about
guidance
on
how
you
may
distribute
that
URL,
so
that
people
can
find
your
service
places
that
you
should
put
it
using
link
relations
and
your
and
your
web
page
stuff
like
that.
D
So
we've
provided
some
guidance
on
the
best
way
to
do
that
and
we're
really
fast-tracking
working
as
hard
as
we
can
on
this
discovery
draft
and
then
some
minor
minor
errors
that
we
fixed
in
the
schema
that
we
noticed
that
were
not
major
changes.
They
were
just
formatting
errors
that
we
that
we
noticed
so
next
slide.
D
Okay,
so
that
is
all
the
changes
that
we
made.
That
takes
us
all
the
way
up
to
version
14,
which
is
the
most
recent
version
on
the
data
tracker
and
is
the
version
that
has
all
these
discusses
cleared.
So
I
want
to
thank
everybody
for
their
review
comments,
advice
and
contributions.
It
was
a
lot
of
people
kind
of
work
together
to
make
this
as
best
as
it
could
be,
and
it
was.
It
was
a
collaborative
effort,
so
thank
you
to
everybody.
Hopefully
we
get
this
thing
done
where
we're.
D
D
So
there
has
been
some
updates
to
the
extensions
that
we've
been
working
on
and
I
talked
about
the
software
descriptor
one
in
the
sack
and
working
group.
We've
also
made
an
update
to
the
Caesar
trollee
extension.
We've
been
updating
it
to
a
new
format
and
trying
to
reduce
the
amount
of
text
in
it.
We
really
want
it
to
be
easier
to
read.
We
want
it
to
be
less
long,
so
I'm
gonna
talk
a
lot
about
not
alone.
D
I'm
gonna
talk
a
little
bit
about
the
c-cert
roli
extension
next
and
the
changes
that
we
made
in
that.
So
we
created
a
template
file
that
is
used
to
create
roli
extensions.
This
is
a
kind
of
fill
in
the
blank
build
your
own
roli
extension
kind
of
file.
That's
something
that
we're
currently
hosting
out
on
github
to
share
with
people
in
the
future.
Is
this
something
that
we
want
to
put
on
the
wiki
four-mile?
J
J
I
J
It's
not
clear
if
it's
on
the
wiki
either
we
put
things
on
the
wiki
people,
don't
look
at
the
wiki,
and
so
it's
really
up
to
the
group
to
remember
where
it
is
and
let
them
know
where
it
is,
of
course,
we'll
send
out
a
link.
If
you
guys
want
to
put
a
link
to
it
on
a
wiki,
you
can
do
that.
You
can
put
it
in
the
wiki
you
can
do.
However,
you
want,
we
just
put
it
there
for
our
own
use
and
it's
there
for
anybody
else
who
wants
to
use
it
as
well.
J
D
A
D
Is
horribly
objecting
to
that?
That's
that
is
a
link
that
I
can
provide.
Okay,
perfect,
okay,
next
slide,
so
I'll
try
and
go
through
this
here.
So
I
want
to
talk
about
two
issues
that
I'd
like
to
have
resolved
in
this
Easter
extension
and
I.
Think
that
I
want
to
talk
to
the
group
about
it
to
try
and
figure
it
out.
One
of
this
is
the
one
that
Roman
we
just
talked
about.
You
know
five
minutes
ago
about
the
the
slash
resource
for
rid.
D
So
it's
a
must
requirement
in
this
Easter
extension
at
the
moment
that
a
server
must
implement
the
forward
slash
resource.
If
you
are
going
to
use
the
incident
indicator
information
types
in
the
c-cert
extension,
we
think
that
that
might
be
too
restrictive
on
Roly
repositories
that
want
to
stand
up
incident
and
indicator
repositories
and
would
instantly
have
that
resource
be
restricted.
D
H
H
I
Walter
Meyer,
so
the
text
in
the
in
the
core
Rowley
right
now
it
says
that
the
resource
may
be
supported
for
compatibility
with
existing
deployments
that
are
using
transport
of
real-time
internet
work.
Defense
messages
read
messages
over
HTTP
TLS,
but
the
problem
is,
is
what
happens
if
you
have
a
rolly
server,
that's
supporting
the
see
certain
information
type
and
it
doesn't
have
rid
and
the
organization
doesn't
have
a
rid
endpoint.
I
Having
it
be,
a
must
requirement
seems
like
kind
of
a
not
so
convenient
requirement.
If
that's
the
case,
so
one
of
the
things
that
we're
thinking
about
and
trying
to
clean
that
situation
up
is
you
know
trying
to
adjust
the
wording
in
a
way
that
you
know
would
have
it
be
sensical
from
that.
From
that
perspective,.
H
H
D
Would
be
great
for
clarity,
so
yeah
one
one
solution
to
this.
Actually
that
I
do
not
have
as
a
proposal
down
here
is
to
say
make
this
a
conditional
must,
as
Dave
put
it.
If
you
are
supporting
rid
and
I
forget
the
RFC
number
I
think
it's
six
five
35,
if
you're
supporting
that
you
must
support
that
/resource
behavior,
as
defined
in
the
spec.
Does
that
make
sense
as
to
what
you
were
thinking
yeah.
D
A
D
D
D
Minutes
I
can
do
two
minutes
works
for
me.
Okay,
there
are
a
large
number
of
requirements
in
the
c-cert
document
that
are
specific
to
when
you
are
using
io
def
enrollee.
This
means
that
if
you
have
an
IO,
def
data
format
type
in
your
early
repository,
there
are
extra
requirements
on
how
your
Roly
repository
must
behave.
That
means
it's
a
longer
spec.
That
means
it's
a
more
restrictive
spec.
That
means
that
a
repository
that's
carrying
io
def
is
behaving
differently
than
a
repository
that
is
not
carrying
io
def.
D
We
need
to
review
those
I
have
specific
requirements
in
the
new
context
of
a
more
generalized
Roley
I
believe
that
those
io
def
specific
requirements
can
be
reduced
and
removed.
Such
that
Roly
repository
is
carrying
io
def
do
not
behave
differently
than
your
other
Roly
repositories.
I
think
that
increases
interoperability
and
I
think
that
means
it's
easier
for
people
to
stand
up.
I
owed,
Everly
repositories,
so
I,
don't
I,
don't
have
a
proposal
here,
but
I
wanted
to
see.
If
the
group
felt
strongly
about
io
def
specific
specific
requirements
in
the
CCR
document,.
L
L
Requirements
on
the
io
def
document
itself,
so
I've
never
understood
why
we
have
those,
especially
in
that
it's
XML
and
well-structured,
and
the
server
should
be
able
to
convert
that
from
an
io
def
document
into
the
links
all
by
itself.
Otherwise,
this
whole
computer
computer
communication
thing
is
a
myth.
Agree,
yeah,
I,
absolutely
vote
for
striking.
That
ok
noted
thank.
D
You
so
I
will
include
that
in
the
updated
draft
that
I
post
as
well.
Luckily,
thankfully,
that
will
greatly
reduce
the
length
of
the
document,
which
makes
it
easier
for
people
to
read
and
look
at,
which
is
really
really
great.
Shorter
documents
get
more
people
to
read
them,
so
that's
very
exciting.
Okay,
that's
my
two
minutes.
I'm
done
I
was
maybe
a
little
bit
longer
than
two
minutes,
but
that's
what
I
do?
Okay!
A
I'll
give
some
time
back:
cuz
I'm,
not
gonna,
take
the
full
ten
minutes,
so
we
put
the
XMPP
not
we,
the
chair,
put
the
X
I'm
I'm.
Now,
just
acting
as
an
individual
sorry
XMPP
grid
draft
went
to
last
call
received
still
more
feedback
that
it
was
issues
with
readability,
so
in
an
attempt
to
make
it
simpler,
I
think
perhaps
I
cut
too
much
text
out
where
I
thought
there
was
just
too
much
redundancy
or
repetition
of
how
the
flow
worked.
A
In
my
endeavor
to
just
say
it
once
I
think
I
cut
too
much
out.
So,
for
instance,
there
were
comments
to
how
one
might
do
the
discovery
I
had
taken.
Those
examples
out
so
I
need
to
put
them
back
in,
as
I
was
working
with
two
of
the
commenters,
those
being
Peter
st.
Andre
and
now
I
can't
remember
the
other
gentleman's
name.
A
So
in
my
conversations
with
Peter,
his
lipo
kind
of
went
out
and
said
really
what
we
need
to
do
is
to
just
do
that:
mapping
of
their
vocabulary
to
our
vocabulary
and
when
I
started
explaining
the
use
cases,
he
actually
found
the
sack
of
terminology
and
said.
Let
me
use
that
as
my
reference.
It
really
helped
them
and
as
it
turns
out
where
we
originally
thought
we
would.
He
said
it
may
just
be
easier
for
me
to
start
from
scratch.
A
It
ended
up
that
we
didn't
need
to
once.
He
found
the
terminology
draft
right.
So
next
slide.
Please.
So
basically,
I
want
to
thank
Peter,
because
we've
had
several
conversations
now
in
interchanges.
He's
really
helping
me
improve
the
draft,
we're
not
quite
there
yet
so
would
still
encourage
you
to
look
at
it
and
let
us
know
if
we're
in
the
right
directions,
but
I
do
know
that
we
need
to
put
tighter
focus
on
how
the
broker
function
and
discovery
works.
So
some
of
that
text
needs
to
be
put
back
in
next
slide.
A
Please,
and
we
need
to
add
those
examples
back
in
so,
whereas
before
yes,
I
took
the
lazy
route
and
reference
jet
268,
not
from
the
whole
notion
of
how
it
was
used,
but
really
to
show
how
it
was
referencing,
the
I/o
def
schema,
which,
as
it
turns
out,
we
don't
need
to
do
at
all
so
I
just
need
to
recraft
examples
to
show
how
to
do
that.
So
we
ran
out
of
time.
Just
no
excuse.
A
M
M
So
let
me
talk
about
so
let
me
talk
about
adjacent
binding
of
that
you
live
draft.
So
thanks
to
that
previous
discussion,
we
just
made
a
zero
impression
over
adjacent
mapping.
Draft
go
please
so
this
is
the
current
status
with
a
draft
so
based
on
the
discussion
in
IKEA
1919
Prague,
we
established
a
new
working
group
draft,
so
in
the
one
version
I,
we
finished
writing
from
the
beginning
to
the
end.
M
A
M
M
M
If
I
have
a
Japanese
description,
it
could
be
okay,
but
if
we
have
an
English
description,
we
have
the
Abba
extra
Brad
you'd
like
a
value,
less
Windows,
but
if
I
was
a
user
of
the
Jason
I
want
to
write
like
this
way
right
side
description
in
these
windows,
it's
much
more
simple,
and
even
for
me
other
japanese.
I
prefer
to
use
english
wording
rather
than
japanese.
M
Usually
so
I
prefer
to
have
a
description
and
description
ml
instead
of
having
just
description
using
the
MM
string,
but
it
makes
sense
for
you
decision
than
what
I
mean
left-hand
side
uses
MLS
drink
for
English
and
for
Japanese
right-hand
side
uses
string
and
also
just
just
string
I
think
just
using
a
string
is
usually
easier
and
more
compact
because
we
use
the
ISM
I
want
to
make
it
more
shorter.
Our
use
case
is
for
machine
I
promise
in
usage,
so
making
it
more
compact,
very
important.
A
L
Cristinaw
Co
Carnegie
Mellon,
so
I
I'm,
fine,
with
either
version
I
understand
the
desire.
The
more
interesting
question
for
me
is
that,
could
you
make
it
so
they
in
machine
to
machine?
So
if
I
had
a
program
that
could
translate
the
XML
document
to
JSON
it
could
it
could
it
get
it
right?
And
then,
if
I
wanted
to
go
back
from
that
converted,
JSON
representation
back
to
XML,
would
it
still
have
fidelity
to
the
original?
Thank.
M
L
I
said
so,
I
mean
I've
looked
through
what
what's
there
now
the
the
the
draft
and
you
touch
on
some
parts
of
this
and
I,
don't
think
it
can
be
fully
I,
don't
think
it
could
be
a
dumb
converter.
I
think
you'd
have
to
make
a
converter
that
understood
io
def.
The
question
is:
can
we
have
rules?
Can
you
make
the
the
draft
I'm?
Okay
with
doing
it?
You
know
using
string
when
you
want
to
as
long
as
the
draft
can
be
written
such
that
we
can
build
interoperable
converters.
M
G
M
I
Dave
altameyer,
like
it's
a
clarifying
question,
so
I
was
looking
through
the
draft
and
you
know
there
are
things
in
IO
def
like
string
reference:
oh
no
I'm,
sorry,
software
reference
that
make
use
of
the
XML
any
type,
which
means
that
you
can
embed
arbitrary,
XML
content
and
and
niño
def.
If,
on
the
subject
of
round-tripping
so
being
able
to
go
from
XML
to
JSON,
you
know
back
to
XML,
do
you
do
you
have
any
thoughts
on
how
you
you'll
support
those
there's
round
trips
of
that
arbitrary
XML
content.
M
Can
wait
I
mean,
generally
speaking,
my
understanding,
so
your
question
is
about
how
we
can
convert
any
type
to
XML
right,
that's
right,
difficult,
I,
guess,
one
way
of
converting
any
type
into
JSON
is
using
a
base64
base64
encoding
based
on
that
I
want
to
convert
it
back
to
XML,
so
I
not
want
to
change
any
structure
of
the
XML
document.
I
just
want
to
convert
it
into
a
string
by
using
this
64
coding.
In
this
way,
we
can
make
it
back
to
what
is
you
know?
Okay,
thank
you.
M
So
I
will
just
come
back
to
the
rainiest
later,
but
I
couldn't
hear
any
object
at
this
moment
so
for
now,
I
will
try
to
go
to
the
right-hand
side
solution.
If
you
have
any
objection,
please
let
me
know
later
on
the
mailing
list,
so
binary
strings.
Yes,
the
X
I'm,
saying
okay,
the
X
I
usually
fight
until
has
two
type
of
binary
string.
First,
my
the
basics:
you
fall
other
one.
It's
extra
decimal
I,
wonder
whether
we
did
both
was
in
for
Jason
I
mean
for
XML.
M
A
L
H
Right
so
back
to
Rome,
engineer
CMU
so
back
to
the
case
where
I
want
to
take
JSON
converted
to
XML
and
then
convert
it
back
to
JSON
or
the
other
way
XML
to
JSON
back
to
XML.
If
you
don't
support,
both
you're
gonna
lose
that
the
original
XML
document
was
encoded,
with
whatever
representation
that
you
dropped.
Is
that,
okay,
it
wouldn't
be
the
same
document.
L
H
M
You
I
guess
we
have
to
review
anyway.
Thank
you
for
the
discussion.
I
know
one
is
again
with
we
can
make
it
more
simple
or
not.
Last
question
so
I
found
out
that
these
hype
classes
in
IO
2002
has
only
one
element
for
XML.
This
is
very
important
for
the
semantic
purpose,
but
for
Jason
this
is
just
extra
space.
Why
don't?
We
just
omit
those
classes
for
Jason?
That's
a
question.
M
D
M
H
Roman,
didn't
you
see
mu
yeah
I
mean
again
I.
Think
it's
great
to
use
the
idea
of.
Can
you
go
XML
JSON
and
get
the
XML
back?
Those
are
container
classes,
I,
think
a
number
of
them
don't
have
any
kind
of
data.
So
what
we
would
just
have
to
put
in
the
draft
are
more
complicated,
parsing
or
converting
guidance
to
say,
hey.
You
know,
there's
semantics
in
the
nesting
in
JSON,
so.
A
Okay,
the
battery
is
dying
on
this
one
too,
so
it
has
been
a
well
I
mean
an
inside
the
in
all
the
rooms
that
the
mics
were
terrible.
Okay.
So
what
I
wanted
to
do
was
revisit
the
milestones
and
go
through
it
just
to
make
sure
that
both
were
on
track
and
to
figure
out
what
we
do
moving
forward
so
currently
I'm
scheduling
to
have
the
XMPP
grid,
ready,
hopefully
after
the
Thanksgiving
break,
if,
if
not
a
week
or
so
after
that,
so
the
intent
there
is
to
do
another
working
with
less
call.
A
A
Let
me
defer
the
discussion
on
what
we
do
with
a
role
ec
cert,
because
right
now
it's
not
an
adopted
working
group
item
so
that
I
think
merits
more
discussion.
The
json
io
def
we
did
adopt,
we've
got
the
first
draft
has
well
you
just
posted
it.
Today,
so
I
would
encourage
people
to
review
it.
I
think
I
might
just
put
out
a
request
for
a
reviewers
just
so
we
could
help
get
the
momentum
going
on
the
list
and
go
from
there.
A
A
Let
me
talk
about
the
Rolly
c-cert
extension
draft.
So
it's
currently
not
an
adopted
working
group
item
I
had
posted
I
believe
at
least
once
for
review
and
adoption.
We
only
received
one
review
and
comment
and
the
comment
was
that
it
didn't
belong.
It
wasn't
part
of
the
Charter.
So
even
though
we
had
whoops,
even
though
within
the
group
here
at
the
Prague
face-to-face,
we
did
the
hum.
There
was
enough
interest
in
the
mail
list.
A
Nobody,
but
the
one
questioning
response
came
to
so
I
wanted
to
open
up
the
discussion
here,
but
would
also
encourage
that
when
we
put
the
call
for
adoption
and
approval
on
the
list,
even
though
you
voted
here,
you
also
need
to
vote
on
the
list.
Does
that
make
sense
yeah,
you
guys
have
questions
no.
H
I
Dave
Walter,
Mayer,
I,
guess
I'm
a
co-author
on
it.
I
actually
have
interest
in
that
I
actually
have
interest
in
implementing
the
draft,
so
I
I
don't
want
to
hide
behind
the
fact
that
I'm,
you
know,
write
writing
the
draft
I
actually
plan
on
using
the
draft
and
and
think
that
that
the
work
is
important
of
a
specific
interest
is
also
being
able
to
expand
on
some
of
the
sticks.
Related
capabilities
in
the
Caesar
extension.
I
D
Agree
on
that,
however,
the
c-cert
extension
declares
all
of
the
support
for
IO
def.
You
had
that
chart
up
at
the
beginning
of
the
working
group
meeting,
showing
the
restful
block
for
transporting
io
def
there.
Yes,
so
that
C
sort
extension
is
really
combined
with
the
Roli
core.
What
fulfills
that
block
on
your
on
the
little
Charter
chart
there
and.
A
D
G
Sorry,
I'm
vertically
challenged
Bret
Jordan,
editor
and
author
of
Styx
co-chair
of
taxi
I,
really
like
what
you've
done
with
Rowley
and
I
would
like
to
work
on
a
draft
to
make
a
JSON
representation
of
Roly,
but
I
don't
want
it
to
go
off
and
do
all
the
work.
If
this
working
group
is
not
interested
in
a
JSON
based
version
of
Roly,
so
I
would
like
to
know
if
this.
A
L
A
M
M
A
A
Okay,
so
I
don't
like
coming.
Is
it
okay?
If
I
ask
for
a
show
of
hands,
you
want
me
to
look
at
you
want
me
to
put
the
Charter.
Oh
okay,.
A
A
G
I
would
be
interested
in
working
on
in
and
submitting
a
draft
to
this
working
group
for
a
JSON,
binding
I.
Guess
you
would
call
it
for
Rolly,
but
I
don't
want
to
go
off
and
do
all
that
work
and
write
all
the
content.
If
this
working
group
is
not
interested
in
it
at
all,
so
I
would
like
to
propose
I'm.