►
From YouTube: IETF96-MILE-20160721-1000
Description
MILE meeting session at IETF96
2016/07/21 1000
A
C
E
Hello,
everybody
thank
you
for
coming,
so
it's
mile
managed
in
tonight
with
exchange.
So
from
today
we
have
a
new
chair,
so
Nancy
current
kindly
blunt
here
to
be
a
chair.
Thank
you
very
much
for
joining
the
gorgeous
chip.
So
this
is
a
note.
Well,
I,
think
you're,
all
familiar
with
that.
So
after
reading
through
we
can
go
through
this
is
the
agenda.
Let
me
begin
with
a
status
update
for
the
pie,
hole
working
group
draft
and
one
individual
draft,
any
others
in
there.
E
If
not,
we
want
to
proceed
following
this
agenda.
So
first,
let
me
update
our
status.
This
is
the
work
we
have.
We
have
three
working
domain.
First
is
a
data
breach
representation?
Second
job
transport?
Well,
it
is
a
guidance
guidelines
for
the
data
representations.
We
already
have
two
rfcs
and
we
currently
have
two
drafts
working
on
for
a
transport
we
have
two
RFC's
and
to
draft
a
still
work
in
progress
for
the
guidance
we
have
to
our
receipt
and
to
draft
has
to
work
in
progress,
and
this
is
a
model
status
for
the
I/o
addictive.
E
We
have
already
completed
IED
blasts
call.
So
after
a
bit
of
change,
we
would
be
published.
Irish
implication,
I
believe,
for
the
Jays
on
binding
initial
problem
is
just
submitted
as
an
individual
draft
for
the
transport
or
the
road-roller
graph.
We
complete
it
working
your
glass
skull,
but
we
have
made
a
big
change,
so
we
would
have
a
big
discussion
today
for
the
XMPP.
E
E
So
this
is
the
minus
song
by
number
2
2016.
We
want
to
submit
the
XMPP
grid
draft
and
also
rowley
draft
to
I
esc
by
robin
but
2016,
and
also
by
december
2016.
We
want
to
submit
kainis
draft
to
the
iesg.
That's
a
plan
we
have.
So
if
it's
okay,
we
want
to
move
to
the
first
agenda.
That
is
a
I
own,
a
piece
draft.
So
Robin.
Could
you
do
a
presentation?
Please.
F
Good
morning,
everyone,
my
name,
is
Roman
continued,
I'm
from
cert
and
we're
going
to
be
talking
about
I,
def
I
would
have
version
2
here
next
slide,
so
I
misspoke
a
little
bit
when
we
got
together
in
bonus,
eres
that
this
would
be
the
last
time
we
would
be
talking
about
it.
There's
been
quite
a
few
updates,
and
so
primarily
this
is
to
update
you
about
the
rapid
sequence
and
drafts
that
got
published
in
the
last
couple
months.
So
what
was
the
substance
of
those
changes?
Just
in
case
you're
new
to
this
I?
F
Oh
def
v2
is
primarily
trying
to
update
RFC,
50
70
and
that's
a
representation
for
for
cyber
indicators
and
incident
reporting.
Is
it
not
on
Oh
moving
up
and
sorry?
Is
that
better?
All
right?
Sorry
about
that,
so
esta
Key
said
the
status
of
the
draft.
Is
it's
been
through
a
number
of
kind
of
last
call's,
so
it's
with
80
follow
up
now.
There's
one
unclear
discuss
since
the
last
time
we
got
together
bonus,
eros
we've
had
eight
revisions,
and
that
was
to
address
working
group
last
call
ad
review
shepherd
review.
F
Itf
last
call
security,
review
and
I
ESG
review,
so
next
slide
so
talking
through
what
happened
in
those
eight
revisions.
So
the
first
thing
I
wanted
to
point
out
is
with
that
great
set
of
great
set
of
slides.
This
is
something
we've
been
doing
for
the
last
kind
of
two
years
to
point
out
that
there
are
no
new
incompatibilities
introduced
with
those
recent
revisions,
so
that
in
compatibility
list
is
what
it
was.
F
Last
time
we
talked
about
and
there's
an
actual,
obviously
a
section
in
the
draft
that
talks
about
what
that
phone
is
through
with
some
additional
explanation
next
slide.
So
the
first
thing
I
wanted
to
point
out
is
that
in
the
exhibit-
and
this
is
more
kind
of
what
is
the
relationship
of
this
document-
you
other
documents,
first
and
foremost,
we're
deprecating
50-70.
That
was
previously
in
the
in
the
document.
F
What
was
not
in
the
document
was
deprecating
6685,
so
that
has
been
done
and
a
new
edition
pulling
from
6685
is
that
there
will
now
be
expert
review
for
any
namespace
registered
with
ayanna
that
has
io
death
in
it
and
the
thinking
there
is,
if
you
have.
I
oh
def
in
your
namespace
you're,
probably
an
extension
we
want
to
be.
We
want
to
have
some
review
about
out.
You
know
what
extensions
might
look
like
just
to
make
sure
that
they're
appropriate
to
be
called
iof.
F
So
that's
now
in
the
draft
there's
some
guidance
now
about
weakening
frankly
how
rigorous
the
parsing
needs
to
be
so
two
key
changes
were
actually
in
5071
had
to
reject
syntax
errors.
Now
now
the
recommendation
is
just
should
there
were
significant
concern
about
dossing
iono
and
doing
the
download
of
all
those
various
numerator
tables
that
that
make
those
attributes
extensible.
F
So
now,
there's
there's
language
that
you
know
says
that
that
should
be
done
periodically
and
there's
reinforcement
to
say
you
know
in
no
new
world
should
you
dynamically
building
those
schemas
from
from
those
enumerated
tables,
so
some
stronger
language
around
the
must
in
the
ship's
next
slide,
please,
the
security
considerations
was
completely
was
complete,
scrubbed,
a
lot
of
new
things
added
a
new
section
on
privacy
implications
pointing
out
in
a
lot
of
detail
where
executable
content
might
be.
There
is
a
lot
more
language
related
to
Adam
and
negotiation.
F
What
fields
need
to
be
covered
in
that,
and
then
there
was
a
big
discussion
that
came
out
of
IU's.
Do
you
review
about
how
much
confidence
you
should
have
in
the
confidence
values
that
are
conveyed,
and
so
there's
a
bit
more
language
effectively
saying
be
careful?
Confidence
probably
doesn't
mean
what
you
think
it
is
really.
You
know
when
you
get
data
you're
going
to
have
to
rethink
what
it
is.
Don't
trust
the
people
that
then
set
set
you
that
data,
so
that
got
put
in
there
next
slide.
F
Please
there
were
a
couple
of
new
things
actually
added
out
right
to
the
data
model,
rather
rather
than
kind
of
the
interpretation
of
what
was
already
there.
So
in
the
05
of
the
IO
def
guidance,
a
couple
of
errors
were
pointed
out,
and
so
that
resulted
in
a
few
new
attributes
and
classes
getting
put
in
as
part
of
the
privacy
review.
F
There
is
to
do
to
new
things
added
for
addresses
so
now
there's
the
ability
to
convey
masked
privacy,
mast,
ipv4
and
ipv6
addresses,
so
you
don't
necessarily
have
to
give
a
full
address
kind
of
anymore
or
full
block
or
prefix.
You
can
mask
addresses
out
with
X's
and
then
back
to
this
idea
of
your
more
refinement
in
how
you
convey
confidence
and
things
net
with
indicators
now
it
possible
to
you
in
a
very
granular
way.
F
When
you
compose
you
know,
IP
address
with
a
domain
name
or
other
indicators
together,
you
can
add
a
tapper
blah
basis
in
an
indicator
actually
convey
confidence,
so
you
can
say:
I
have
confidence
in
this
first
part
of
the
indicator,
but
not
in
the
second
part.
So
next
slide
please
so
that
takes
us
to
the
end
I
think,
primarily,
if
you
have
questions
about
what
got
done,
I
think
we
can
clarify
them
here.
F
E
Thank
you
very
much
for
the
work.
I
have
one
question.
Look
it's
about
iono
you
said
implement
to
have
to
change
a
check
to
update
with
a
schemer
free
from
time
to
time.
That
means,
when
we
add
new
value
to
Zion
on
table
the
person
who
registers
about
you
how
to
update
the
schemer.
Is
it
correct
so.
F
The
way
the
language
was
previously
written,
it
would
imply
that
as
an
IO
Jeff
parser,
you
need
to
be
regularly
checking
the
eye
and
a
schema
in
not
quite
a
real-time
fashion,
but
something
close
to
it
and
dynamically
building
that
schema
all
the
time.
What
the
language
now
says
is
something
on
the
order
of
hey
vendors,
make
iof
parsers.
When
you
release
new
builds
of
your
of
your
partial,
you
should
get
the
new
values
for
my
Anna,
and
that
may
mean
that
you
might
have
to
change
your
parson
luggage
logic.
F
G
Good
morning,
so
today,
I'm
going
to
talk
briefly
about
some
of
the
work
that
we've
been
doing
on
on
Roli
I've
got
a
handful
of
issues
to
talk
through,
but
before
I
do
that
I
wanted
to
give
a
brief
conceptual
overview
of
what
we've
been
working
on
with
with
rolling
next
slide.
Please
so
Rowley
is
the
resource.
Oriented
lightweight
information
exchange.
I
got
up
that
slide.
G
It's
effectively
a
profile
of
both
the
Adam
publication
protocol
and
the
atom
syndication
format.
So
the
publication
protocol
defines
a
rest
based
approach
for
retrieving
information
resources
and
the
atom.
Syndication
format
describes
a
number
of
document
formats
that
can
be
used
to
describe
things
like
the
available
resource
collections
and
an
individual
resource
collection
or
an
individual
resource.
G
It
creates
a
system
that
allows
publishers
to
push
their
content
to
a
repository,
and
they
can
do
so
by
providing
granular
access
controls
as
to
who
can
publish
and
who
can
actually
see
the
information
that's
published.
The
draft
as
it
currently
stands
has
been
generalized
to
support
more
general
security
information
exchange.
It
was
originally
targeted
specifically
to
IO
def
exchanges.
G
G
There's
a
lot
of
overlap
between
what
we're
trying
to
do
here
in
mile
and
what
we're
trying
to
do
in
sac
I'm
relating
the
similar
kinds
of
information,
so
we're
trying
to
generalize
the
draft
in
a
way
that
the
same
transport
can
basically
be
used
to
satisfy
I'm
general
information
needs
next
slide,
please.
So
the
kind
of
the
entry
point
and
a
rolly
repository
is
something
called
a
service
document
which
is
a
type
of
Adam
pub
document.
G
The
service
document
describes
a
number
of
work
spaces
which
are
logical
collections
of
resource
collections
and
has
a
collection
element
which
defines
in
a
specific
resource
collection.
In
this
case,
we
have
a
resource
collection
which
provides
public
incident
information
relating
to
the
organization,
that's
providing
it.
We've
added
this
new
Adam
category
type,
which
is
information
type,
which
defines
the
type
of
information
as
being
incident.
So
this
is
an
extension
point
that
we've
defined
in
the
new
Rollie
draft,
which
basically
allows
you
to
characterize
the
type
of
information,
that's
being
provided
in
a
given
resource
collection.
G
The
reason
we
had
to
do
this
is
Adam
pub
was
originally
developed,
largely
for
blogging
kinds
of
applications.
So
there
was,
it
was
implied
that
you
were
basically
providing.
You
know,
blog
kind
of
information,
so
we
needed
some
way
of
actually
describing
in
a
more
rich
way,
a
the
types
of
security
automation,
information
that
was
being
provided
by
the
repository.
So
that's
what
the
Adam
category
element
is
being
used
for.
In
part,
in
the
current
role,
a
draft
next
slide
please.
G
So
this
is
an
example
of
a
rolly
feed,
so
every
document
type
in
enrollee
has
an
ID.
This
feed
has
an
ID
element
that
uniquely
identifies
the
feed.
It
duplicates
the
the
category
element,
because
what
a
client
may
actually
just
be
seeing
the
feed
for
the
first
time
instead
of
the
service
document,
it
really
depends
on
how
they're
discovering
the
repository,
meaning
every
every
document
and
an
atom,
pub
and
rowley
is
effectively
an
HTTP
resource.
G
So
links
can
be
passed
around
to
various
consumers,
so
they
can
be
accessing
a
rolly
repository
directly
through
the
service
document
where
they
discovered
it
initially
or
they
could
be
going
to
a
link
that
someone
sent
to
a
feed.
So
it's
important
to
have
this
category
information,
this
metadata
I'm
in
multiple
places,
so
another
aspect
of
the
feed
is:
it
provides
an
updated
link
or
an
updated
time.
Timestamp,
which
indicates
the
last
time
content
was
posted
to
the
feed
it.
G
It
contains
a
bunch
of
link
relationships,
so
Adam
pub
is
a
stateless
protocol
and
it
uses
links
essentially
as
a
way
of
identifying
state
transitions
within
within
the
repository.
So
these
links
provided
information
like
you
know
what
URL
you
would
access
this
for.
The
self
rel
would
be
what
URL
you
would
use
to
access
this
feed,
which
is
probably
the
one
that
you
use
to
retrieve
it
another.
The
other
link
has
a
rel
of
service,
so
this
would
be
the
link
that
you
would
use
to
retrieve
the
service
document.
H
H
G
Tag
is
right,
so
technically
you
could
version,
you
could
create
a
new
version
of
this
fee
by
changing
its
content,
which
would
be
a
new
instance
effectively
of
the
feed.
So
the
self
link
is
intended
to
point
to
the
specific
instance,
that's
being
provided
at
this
point
in
time.
So
if
you
made
a
change,
you
should
be
able
to
use
the
self
link
on
this
record
to
get
the
previous
instance
of
that
of
that
that
tea
before
the
change
so
you're
right,
you
should
be
able
to
do
that.
G
This
example
is
a
simple
mock-up,
and
so
it
doesn't.
It
doesn't
provide
enough
distinguishing
information
to
really
support
that
good
point
next
slide,
please
so
there's
an
extension
in
enrollee
Aryan
Adam
pub
that
also
allows
you
to
provide
paged
feeds.
So
the
idea
here
is
that
you
know
feeds
may
have
you
know.
G
Hundreds
thousands
of
records
which
you
know
could
be
a
lot
of
data
to
exchange
generally
rowley
feeds,
adam
pub
feeds,
are,
are
ordered
in
the
most
recent
entries
that
have
been
posted
to
the
feed
appear
first,
so
using
paging
you
can
effectively
retrieve
the
first
few
pages
gets.
You
know
the
most
recent
information
and
then,
if
you're
interested
in
retrieving
additional
historical
information
from
the
feed,
you
could
actually
view
multiple
additional
pages.
So
paging
provides
a
way
of
breaking
up
the
information
and
a
given
feed
over
over
a
number
of
different
pages.
G
So
we
have
some
description
on
how
to
use
paging
from
rolling.
This
is
a
new,
a
new
feature
that
has
been
recently
talked
about
in
the
draft
next
slide,
please.
So
this
is
what
a
rolling
entry
looks
like,
so
this
would
represent
a
given
a
given
resource,
an
atom
pub
there's
a
content
element
which
can
work
in
two
ways.
You
can
either
directly
embed
the
content
that
you're
you're
referencing
or
you
can
provide
a
link
to
where
the
content
can
can
be
retrieved.
G
G
This
content
would
have
a
better
sense
of
the
format
of
the
content
before
they
actually
retrieve
the
content
next
slide.
Please
so
I
talked
briefly
about
this
before
so
we
built
an
extension
system
around
rowley.
This
is
a
new
capability
and
the
current
draft
so
we're
effectively
using
an
eye
on
a
table
to
allow
registrations
of
different
information
types
to
be
made
in
the
initial
rowley
core.
There
are
no
information
types
defined.
G
Our
plan
is
to
write
the
series
of
use
case
drafts
that
would
describe
specific
types
of
information
which
would
then
make
the
the
registrations
with
I
Anna.
So
the
sea
cert
content
that
was
originally
in
the
rolly
draft,
we're
currently
working
on
a
second
draft
that
contains
all
of
that
original
content
and
basically
describes
incident
and
indicator
information
type
use
cases
for
ferroli,
so
we're
hoping
to
to
have
that
that
draft
ready
for
the
for
the
next
meeting.
G
We
were
pretty
close
this
time,
but
we
hadn't
finished
working
through
the
draft,
so
it
wasn't
entirely
clear
how
it
was
being
used
in
that
in
the
context
of
the
updated
core.
Yet
so
we
we
didn't,
publish
it
for
this
meeting
yet,
but
that's
our
first
priority,
basically
at
this
point
in
time
so
effectively.
What
this
will
allow
us
to
do
is
through
a
specification
required
registry,
allow
new
information
types
to
be
created
in
rowley
over
over
time
next
slide.
Please!
G
So
now
I
wanted
to
talk
through
a
handful
of
issues.
The
issue
numbers
correspond
to
the
the
issues
and
the
github
repository.
So
if
you
want
to
read
some
additional
detail
about
these
issues
or
comment
on
the
issues,
follow
the
github
link,
that's
in
the
at
the
top
of
the
draft
and
and
and
feel
free
to
comment
on
those
those
issues
there.
G
So
the
first
issue
we
have
is
the
the
previous
Rowley
draft
included
a
section
that
talked
about
the
forward,
slash
resource
URL,
and
it
was
basically
designed
to
provide
compatibility
with
a
rid
endpoint.
So
the
idea
would
be
that
if
the
organization
or
if
the
service
hosting
a
rolly
repository
was
was
queried
using
the
forward
slash
resource
that
that
would
either
redirect
the
user
to
a
rid
service
or
it
provides
some
resource
not
available
status
code.
Now
this
is
very
specific
to
you
know,
to
see
cert
and
and
and
rid
use
cases.
G
We
have
a
couple
of
options.
The
first
would
be
to
keep
it
in
the
rolly
core.
The
problem
with
this
option
is
it's:
it's
not
useful
for
non
incident.
Non
I,
o
def
use
cases
of
Roley,
which
we
expect
there
to
be.
You
know
many
of
those
kinds
of
use
cases.
We
would
effectively
be
requiring
additional
implementation
for
all
rolling
implementers,
even
even
if
they
were
not
interested
in
you
know
providing
capabilities
for
the
you
know
for
the
incident
I
o
def
kind
of
youth
case.
G
The
other
option
is
to
move
this
requirement
to
the
sea
cert
use
case
document
so
effectively.
If
the
repository
is
implementing
rowley
for
the
sea,
cert
use
case,
then
this
would
be
an
additional
requirement
that
it
would
have
to
to
implement.
This
would
effectively
allow
implementations
to
be
constrained
only
if
they're
providing
incident
data
to
support
this.
This
rid
compatibility
case
so
I'm
looking
for
opinions
on
whether
we
should
follow
a
or
b
or
maybe
an
another
option,
room.
F
D
F
That
use
case
I
have
to
write
the
code.
He
was
it's
written
up
in
some
document,
so
like
put
it
in
yourself,
but
I
thought.
Perhaps
he
might
be
it's
in
the
basics
back.
So
it's
enrollee
core,
but
it's
a
should.
Not
a
must.
So
if
you
that
functionality
you
have
to
build
in,
but
if
you
don't
need
it,
you
know
your.
J
K
K
D
D
I
G
Next
slide,
please
so
here's
another
another
issue,
so
an
atom.
You
can
have
service
documents
that
describe
the
available
collections
of
the
repository
you
can.
Each
collection
has
an
Associated
feed
document,
which
contains
an
enumeration
of
all
of
the
entries
of
that
feed.
I
was
showing
you
the
example
earlier
about
having
a
self
link
for
an
entry,
which
you
could
actually
then
use
to
point
back
to
a
document
that
describes
the
entry
itself.
G
So
an
optional
capability
of
adam
pub
really
the
only
two
documents
that
it
needs
to
be
able
to
support
our
service
documents
and
feed
documents.
An
alternate
additional
document,
type
that
a
service
could
provide,
is
an
entry
document,
so
you
know
for
a
given
entry.
It
could
provide
a
resolvable
resource,
so
we're
kind
of
at
a
crossroads.
This
was
something
that
was
somewhat
undefined
in
the
previous
Rowley
draft.
As
to
whether
there
was
an
expectation
that
repositories
would
provide
these
entry
documents,
the
you
know,
resolvable
link
for
an
entry.
G
Our
proposal
is
that
we
would
like
to
support
standalone
entries,
because
that
would
provide
a
mechanism
by
which
you
know
third
parties
could
pass
around
links
to
entry
records,
which
I
think
has
some
some
valuable
use.
So
this
proposal
would
be
to
provide
a
pointer
to
the
containing
to
support
both
the
the
entry
link,
as
well
as
to
provide
a
pointer
to
the
containing
feed
from
the
entry
resource
to
point
back
to
the
collection
that
that
the
entry
was
was
part
of.
G
G
G
D
G
Great
all
right
so
so
now,
when
I
was
showing
you
the
examples
of
what
a
rolly
entry
would
look
like.
I
shown
an
example
that
included
the
rolly
format
element,
which,
incidentally,
we
can
also
call
the
rolly
data
model
elements.
If
someone
has
a
has
a
preference
we've
been
kind
of
debating,
which,
which
name
to
call
it
but
it
but
effectively,
it
would
provide
an
indicator
of
the
format
used
to
express
the
the
content
that's
being
pointed
to
by
given
atom
content
entry.
G
The
idea
would
be
that
it
would
provide
some
additional
information
about
the
format
that
that
was
being
used
to
include
things
like
a
namespace
for
the
for
the
data
model.
That
is
that
it's
it's
described
using
maybe
a
version
of
that
data
model.
If
the
data
model
has
a
associated
version,
may
be
a
resource
identifier
where
you
could
find
a
relative
schema
or
a
data
model
definition
that
might
be
possible
in
some
fashion
and
perhaps
some
type
of
schema
type
that
would
describe
the
the
format
of
the
the
schema
document.
G
We're
all
ideas
that
that
we've
been
we've
been
talking
about.
Unfortunately,
there
are
I
couldn't
find
my
type
for
for
these
individuals.
Schema
documents
like
XML
schema,
suggests
that
you
use
the
mime
type
of
application,
XML,
which
doesn't
differentiate
a
schema
from
any
other
kind
of
XML
documents.
So
that's
not
terribly
useful.
So
in
order
for
us
to
do
schema
type,
who
would
probably
have
to
come
up
with
some
other
kind
of
registry
or
find
another
kind
of
registry
that
exists?
That
does
that,
for
us.
D
Nancy
can
one
jet
so
I
think
all
the
points
are
well-taken.
The
only
question
I
have
is
providing
the
globally
unique
identifier.
It
can
be
hard,
so
I
think
you're
going
to
have
to
provide
guidance
as
to
how
to
come
up
with
that
identifier
to
ensure
that
there's
global
uniqueness
and
you
need
to
define
the
scope
of
global
right.
G
G
What
are
the
thoughts
on
on
some
of
these?
These
questions?
Do
we
do
we
need
to
go
to
the
extent
of
providing
metadata
about?
You
know
the
format
of
the
the
content
element.
Do
you
think
that
that's
an
important
use
case
and
are
there
specific
we're
recommending
a
few
different
attributes
here?
Are
there
specific
thoughts
on
on
each
of
these
attributes.
F
G
G
You
would
like,
without
it,
without
defining
a
schema,
you
would
still
have
notionally
a
namespace
which
would
define
some
expectation
of
the
data
model.
So
I
don't
think
a
schema
is
explicitly
necessary.
If
you
want
to
validate
that
that
the
information
meets
that
data
model
expectation,
then
you
would
need
something
like
a
schema
or
some
data
definition
expression
for
the
cost.
H
G
So
another
way
we
could
do
it
is
if
we
and
I
have
a
follow-up
issue
on
this.
If
we
require
that
for
a
given
information
type
that
you
support,
specific
kinds
of
information
formats,
we
could
actually
define
in
the
specification
or
in
an
iono
registry,
but
the
required
schema
you
know
must
be,
and
then
we
don't
have
to
necessarily
declare
it
here
so
that
there
are
alternate
ways
of
doing
that.
I.
H
F
Roman
dinnae
do
I
tend
to
agree.
You
probably
need
to
specify
both
the
encoding,
which
would
to
me
would
be
like
its
schema
to
relax,
ng,
potentially
something
else.
A
lot
of
those
formats
you
describe
can
embed
in
them.
Then
the
formatting
of
what
it
is,
I'm,
envisioning
and
I,
don't
know.
I
can't
give
you
an
example
of.
Maybe
one
of
those
won't
have
that,
and
so
it
might
be
nice
to
give
additional
guidance
about
how
to
parse
it.
So.
F
Oh
yes,
or
a
do,
I
do
you
mean
encoding
as
in
yet
you
tfn
mean
more
like
JSON,
or
you
know,
maybe
CSV
and
if
I
said
CSV.
How
do
I
tell
you
which
flavor
you
know
how
to
parse
the
individual
fields
and
with
XML
I
can
point
to
kind
of
something
I'm,
imagining
a
format
that
perhaps
natively
I
can't
hurt
you
how
to
parse
that
and
you're
giving
me
the
flexibility
to
convey
all
that
sound.
G
G
Well,
no,
but
what
Romans
talking
about
here
is
not
the
serialization
format
of
the
content,
but
the
serialization
of
the
data
definition,
the
schema
exactly
you
can
you
can
already
define
the
serialization
method
of
the
content,
using
the
content
elements
and
and
the
associated
mind
type
for
that,
so
we
don't
have
to
do
that,
but
for
the
schema
we
would
need
to
provide
some
mechanism
to
declare
that.
So
this
is
great
feedback,
so
we
were
going
to
make
namespace
required
and
the
rest
optional
is
everyone.
Okay,
with
with
that,
anyone
concerns.
D
G
Is
issue
number
three
great
well
issue
number
four
schema
for
the
rolly
namespace.
So
if
we
had
this
format
element
we're
going
to
need
to
define
some
kind
of
schema
for
for
the
element,
we
have
created
a
section
as
a
placeholder
for
that
schema,
but
we
have
yet
to
to
actually
write
such
a
schema.
So
the
big
question
that
we
have
as
far
as
defining
the
schema
for
the
rolly
namespace
and
you
know
to
describe
the
format
element
is:
should
we
use
the
relax?
G
M
G
Any
other
comments,
all
right,
great
data
model
enumeration,
so
we've
talked
about
adding
this
information
type
extension
point
through
an
eye
on
a
registry.
Another
option
is
each
information.
Type
could
have
an
explicit
enumeration
of
the
data
models
that
can
be
supported
for
a
given
information
type.
So
this
would
be
effectively
a
way
of
restricting
the
list
of
available
information
models
or
I'm.
Sorry,
the
on
the
list
of
possible
data
models
that
could
be
used
for
a
given
information
type
to
some
pre
registered
set
of
data
models.
G
This
could
help
set
some
expectation
from
producer
consumer
perspective
on
on
what
data
might
be
seen
in
a
given
repository,
but
it
may
discourage
flexibility
in
preventing
providers
from
using
other
models
that
may
be
appropriate
for
a
given
information
type
over
time.
So
our
question
is:
should
information
types
have
explicitly
listed
data
models,
or
should
we
keep
it
open,
ended
and
effectively
use
the
format
element
to
describe
whatever
is
being
used
Roman
so.
F
G
G
I
F
Happens
if
I
want
to
use
rowley
for
a
formatted
when
I
tell
everyone
something
else
about,
and
that
sounds
like
we
might
need
more
machinery
for
that.
So
we
should
probably
talk
about
it
more
see
whether
there's
really
interested
in
doing
that,
but
I
would
argue
something
extensible
and
I
would
argue
for
private
things.
I
don't
have
to
tell
folks
about
so
that
would
be
not
just
in
the
I
n
registry.
Any.
G
Okay,
so
we
need
to
work
out
some
of
that
machinery
so
I'll.
Take
that
to
the
list
as
well
so
work,
that's
left
to
do.
I've
got
some
work
on
the
security
considerations
section
to
do
it's
a
little
anemic
right
now
we
have
done
a
lot
to
flesh
out
the
ionic
consideration
section
of
the
draft.
It
was
kind
of
interesting.
The
previous
draft
made
it
through
working
group
last
call,
but
there
was
a
lot
of
to
do
stubs
in
the
in
the
ionic
considerations
section,
so
it
probably
didn't
get
a
lot
of
review.
G
G
So
we
have
some
work
to
do
there.
The
appendix
contains
a
lot
of
the
use
case,
examples
that
were
in
the
original
draft
there's
some
major
inaccuracies
relative
to
Adam
in
some
of
those
examples
and
they're
not
entirely
consistent
with
the
draft
at
the
moment.
So
there's
a
lot
of
cleanup
work
that
needs
to
be
done
on
on
those
use
cases.
G
We
need
to
finish
doing
the
work
now
that
we're
getting
a
sense
of
what
needs
to
be
done
on
Roli
formats,
so
there's
there's
a
fairly
anemic
TLS
requirements
in
the
in
the
draft.
There's,
no
rationale!
That
explains
why
you
know
mutual
authentication
is
needed,
so
we
probably
need
to
just
say
a
little
bit
more
around
the
the
use
of
TLS
and
the
draft.
There
were
a
lot
of
mentions
of
user
authentication
and
authorization
requirements
in
the
original
rowley
draft.
G
There
was
a
specific
section
that
was
talking
about
exact
amol,
we're
not
certain
that
we
want
to
do
specific
user
authentication
authorization
schemes
in
this
cord
draft,
because
there's
a
lot
of
different
options
that
organizations
could
choose
from
one
option
might
be
to
you
know
to
do
some
companion
drafts
to
the
core.
That
would
talk
about
how
you
would
use
various
authentication
and
authorization
schemes
with
with
the
core.
That's
an
issue
that
we
plan
to
take
to
the
list
for
further
discussion.
G
Then.
Finally,
the
original
Rowley
draft
used
open
search
as
a
mechanism
to
support
defining
search
templates
and
allowing
for
search
of
the
repository
and
specific
feeds
that
was
very
under
specified
in
the
original
draft
and
is
still
somewhat
under
specified.
So
I
think
we
need
to
explore
open
search
a
little
bit
more,
better
understand
how
it's
going
to
be
used
in
this
in
this
case.
So
we've
got
some
work
to
do
there
as
well.
A
next
slide
please.
So
we
have
currently
published
revision.
Three
of
the
draft,
we're
definitely
looking
for
feedback.
G
We're
actively
working
on
the
seesaw
use
case
document
we're
hoping
to
have
that
document
be
have
a
call
for
working
group
adoption
once
we
can
get
a
completed
version
of
that
draft
out
there
and
it's
effectively
content
that
the
the
working
group
is
previously
adopted
because
it
was,
it
was
moved
out
of
the
the
current
draft,
so
we'd
like
to
get
that
back
I'm
in
front
of
the
working
group
and
then
there's
a
number
of
other
extension
use
case
extension
documents
that
we're
thinking
about
doing
for
Rowley.
So
one
around
software
management
information.
G
D
So
Dave
the
priority
here
is
to
make
sure
that
we
could
get
the
look
rowley
draft
moving
forward.
So
do
you
need
more
review
and
revision
3
before
you
get
the
next
draft?
Can
you
get
the
next
draft
out
and
the
question
is
by
when
so
our
milestone
is
to
try
and
get
this
I
mean
I'm
going
to
be
the
Shepherd
for
this.
So
the
question
is:
can
we
meet
the
November
deadline?
Yeah.
N
G
Can
probably
get
another
draft
out
to
talk
to
address
the
you
know
the
only
take
us
a
couple
weeks
to
get
a
draft
out
to
address
the
issues.
The
question
is:
we
have
some
discussion
to
do
on
the
list,
so
we'll
right,
we'll,
probably
need
a
couple
weeks
to
talk
through
those
issues.
So
maybe
a
month
from
now
we
could
have
another
another.
D
O
Kathleen
Moriarty
one
thing
with
this
draft:
it
was
well
written
to
begin
with
yeah.
So
if
folks
are
reading
the
draft-
and
you
think
it
looks
good-
we
need
to
know
that
right.
So
could
you
please
at
least
send
to
the
list?
I
read
the
draft.
It
looks
good
so
that
we
know
that
we're
getting
reviews
and
how
many
people
plan
to
review
it
would
be
really
helpful
to
know
so.
O
D
So
maybe
Dave
when
you
get
the
new
draft
out,
I
can
put
the
notice
where
you
can
to
second
to
get
more
reviews
and
then,
depending
on
the
feedback,
may
be
in
the
September
Kathleen.
We
can
put
out
two
mile
to
see
if
there
are
no
objections
to
just
move
it
forward
and
I
can
do
the
write
up.
Okay,
great.
D
Hi
I'm,
Nancy,
cam
wounded
again
and
I
have
no
slides,
because
I
presented
the
overview
of
XMPP
three
times
now
and
I
figured
I
didn't
need
to
do
it
again,
so
I
did
get
some
feedback
from
taki.
Thank
you
most
of
them.
I
consider
the
feedback
to
be
more
mainly
on
the
editorial
side
of,
and
I
can
try
and
provide
more
clarity.
Okie
on
points
like
how
would
a
client
find
an
exit,
MPP
server
and
in
XMPP
speak?
They
talk
about
topics.
D
The
topics
could
be
construed
as
data
models
in
the
context
here,
so
there
were
kind
of
the
two-level
love
you
can
have
many
topics:
okay,
those
can
also
be
discoverable,
so
I
will
respond
to
that
in
the
email
list
as
well
to
that
feedback
and
I'll
be
revving
the
draft
to
provide
a
little
better
clarity.
So
that's
really
the
only
update
I
have.
The
question
is
whether
this
is
as
the
individual
author
would
really
like
to
solicit
more
feedback
so
that
we
can
move
this
forward.
Chris
we're
still
in
revision,
0.
D
E
Just
wanted
to
ask
you
and
Christian
Takei
see
I,
maybe
it's
because
of
my
reading
program,
but
when
I
really
dis
draft
I
was
not
finding
a
world.
Must
so
I
wonder
with
her?
What
would
what
what
you
are
defining
was
not
so
clear
to
me,
so
you
are
showing
a
little
example
how
to
use
XMPP
for
the
purpose
of
XMPP
great,
but
if
we
want
to
build
our
implement
XMPP
great,
what
is
requirement
is
not
clear
to
me,
so
he
could
clarify
that.
That
would
be
helpful
for
me.
I
E
If
we
take
a
look
at
our
Rory
draft
Norwich,
what
defines
some
kind
of
syntax-
or
maybe
some
kind
of
wave
writing,
but
in
case
of
this
draft
usual
example,
so
I
wonder
what
what
they
find.
So
we
just
a
wave
writing
if
you
could
just
define
what
is
necessary
to
implement
a
complete
route.
That
would
be
helpful
for
me
just
a
comment.
H
So
Kristen
a
CO
and
I'm
gonna
try
and
answer
a
little
bit
of
your
comment
but
Nancy.
You
need
to
correct
me
if
I'm
wrong,
the
XMPP
grid
doesn't
define
what
data
it's
going
to
transfer
only
a
mechanism
to
coordinate
and
exchange
data,
so
the
the
musts
are
very
limited
because
of
that.
So
it's
really
the
describing
how
to
use
XMPP
and
the
infrastructure
to
do
the
coordination
and
send
the
messages,
whereas
the
messages
are
still
left
as
additions
to
to
XMPP
right.
D
You
can
now
transport
it
depending
on
the
requirements
of
the
application,
so
you
can
transport
it
either
using
asynchronous,
meaning
a
query
or
if
you
need
updates
on
the
IO
def
information,
you
could
register
meaning
subscribe
to
get
the
updates
to
that
information.
Using
the
pub
sub
mechanism,
so
I
mean,
and
that's
where
I'm
kind
of
struggling
of
I
don't
know
where
there
would
be
a
must
there,
I'm
looking
at
kathleen
wright
but
I'd
be
happy
to
if
there
are
clarifications
that
need
to
be
made
there.
You
know
the
ad
text
around
that
too.
O
So
Kathleen
Moriarty
I,
wouldn't
add
musts
unless
they're
needed.
You
know,
look
for
specific
examples,
so
taka
if
you're
reading
through-
and
you
see
a
section
where
you
think
normative
language
needs
to
be
applied,
call
out
that
specific
section
and
then
it
can
be
reviewed
by
Nancy
and
the
working
group
to
decide
if
that's
appropriate,
because
we
don't
want
to
put
in
requirements
that
aren't
necessary,
but
if
they
are
needed
so
that
we
have
interoperability,
then
of
course
we
need
them.
Thank
you.
So
that's
really
all
I
had.
E
A
I
Hello
I
with
presenta
the
guidance
12
and
I
saw
Bob.
You
old
is
presentation.
Firstly,
this
draft
came
to
provide
the
deadlines
or
I'll
decks.
Immigration,
for
example,
about
one
representation
of
homo
security
indicators,
and
also
me
about
use
case-
is
so
far
and
fast,
l,
a
visual
updates
from
the
previous
and
their
five
draft
and
then
show
to
the
wrist
and
then
discussion.
I
This
is
update
from
abs.
Draft
updates
is
mainly
focus
on
following
I
would
if
we
to
schema
a
fast,
and
we
will
update
our
budding
in
various
sections
and
to
make
a
content
creator
and
then
and
hos
update
and
educate,
rossak
section
to
depict
and
then
it
is
in
cake.
I
expression
Rosie
in
I
would
agree
to.
I
E
So
actually
maybe
you
know
this
document
has
been
standing
for
more
than
two
years
and
actually
of
offline
panels
and
the
me
or
has
been
working
a
lot
and
from
dispersion.
The
content
is
filled
and
sorry,
and
only
the
schemer
only
example
is
in
version
one
still,
so
we
had
to
change
it
to
the
Virgin,
to
example,
but
other
than
that
the
content
is
already
completed.
So
we
really
like
to
get
a
feedback.
Please
Dave
altameyer.
E
O
Kathleen
Moriarty,
so
I
owed
fe
2
is
fixed,
pretty
much
we're
just
waiting
on
one
ad
to
clear,
discuss
and
I
think
it's
only
been
a
time
factor
I
think
it's
going
to
clear
pretty
easily
once
that
ad
has
time
to
look
at
it,
so
consider
it
done
and
proceed
because
I
don't
think,
there's
gonna
be
substantial
changes
you
shouldn't
at
this
point.
Okay,
I
hope.
E
E
E
Yes,
Nick
Symmonds,
so
this
is
my
view.
This
is
my
view
of
JSON
and
XML.
Xml
structure
text
is
very
expressive
and
flexible,
but
it
is
very
heavy
for
passing.
Passing
happiness
is
a
problem
for
me
I'm
for
Jason
Jesus
structured
data,
so
it
is
simple
and
easy
to
define
the
data
types
and
lightweight
for
passing,
like
it
passing
the
very
important
for
our
use
case.
But
this
is
just
my
personal
view.
I'm
not
asking
you
where
that
is
the
correct
or
not,
but
depending
on
the
use
case,
is
the
preferred.
P
Like
the
difference
is
minor
in
some
sense,
but
of
course
the
do
you
really
want
to
go
shoot
up,
no
okay,
yeah,
so
so
the
size
is
different.
Are
you
making,
and
in
one
case
you
some
people,
so
you
have
schemas
for
chase
on.
You
have
schemas
for
xml,
but
the
encoding
is
it's
just
the
way
you
include
the
data
is
different
and
if
you
want
to
add
our
latest
pet
in
the
game
which
we're
going
to
discuss
a
little
later
today
in
this
session
you
can
add
a
column
for
SIBO.
O
Kathleen
Moriarty,
so
the
reason
they're
exploring
this
is
that
Jason
will
actually
get
used
more
and
that's
a
reasonable
reason
to
go
ahead.
If
I
Oh
F
is
going
to
sit
there
because
it's
an
XML
and
we
change
to
JSON
and
all
of
a
sudden,
it
gets
used
a
heck
of
a
lot
more.
That's
a
good
reason
to
go
ahead
and
I
I
suspect.
That's.
M
O
E
E
What
we
want
to
do
is
we
have
our
use
cases.
Maybe
last
year
neil
has
shown
to
our
system.
We
have
a
bad
night
since
our
system
that
monitor
the
traffic
coming
to
the
document
addresses.
So
we
monitor
the
dark,
green
traffic
and
try
to
provide
a
large
automatically
that's
what
we
have
as
our
application.
But
for
that
purpose
let
me
just
show
you
what
we
have
by
clicking
on
here,
which
insists
a
figure
of
this
pray
over
the
system.
E
So
maybe
house
in
this
system
before
so
we
have
this
kind
of
system.
So
we
are
monitoring
traffic
coming
to
the
document
address
of
our
organization.
Here
we
have
a
office.
The
pocket
are
coming
to
the
background
address
of
our
organization,
so
they
as
an
indicator
a
kind
of
indicator
of
malicious
activity
so
based
on
the
traffic
we
analyze
and
we
provide
a
lot
automatically.
We
do
not
have
operator,
we
just
do
automatic
analysis
and
send
a
lot
to
sell
member
organizations
that
what
we
are
doing,
yeah
and
sorry.
J
E
Really
comes
in
some,
so
we
have
more
than
500
organizations
using
our
system.
So
why
not
using
a
standard
format?
So
we
want
to
have
a
standard
format
for
the
alert
and
also
we
want
to
make
the
alert
usable
for
the
program.
We
won't
do
that
program
understand
a
lot
and
we
want
that
program.
Take
action,
three
ash
automatically.
So
for
this
purpose,
xml
l
was
not
usable
for
my
use
cases,
so
we
wanted
have
a
bit
Jason
biting.
Look
shy,
it's
okay!
E
So
this
is
our
current
alert
eating
xml
we
have
an
xml
are
at
and
also
takes
description
allowed.
So
this
is
a
excellent
abrasion.
So,
as
you
can,
as
you
can
see,
the
red
one
is
a
content.
The
time
and
also
IP
address
important
about
whatever
the
product.
Laterz
are
just
a
tag
so,
as
you
can
see
in
this
message,
the
content
that
source
mall,
so
we
think
this
is
redundant.
E
Could
you
guys
this
is
for
the
text
message
we
use
email.
This
is
much
more
readable.
Actually,
we
are
using
this
kind
of
taste
alerting
as
well,
but
this
is
not
usable
for
program.
So
why
don't?
We
have
something
in
between
between
xml
and
also
text
that
could
be
json
possible
by
the
way
I.
Don't
you
see
bore
as
well.
N
E
So
currently
we
are
building
a
JSON
binding,
so
the
easiest
way
to
build
a
JSON
is
converting
from
XML
directory
it's
easy
to
convert,
but
we
do
not
want
to
have
a
direct
conversion.
You
want
to
have
something
more,
so
this
is
what
we
want
to
do.
Of
course,
we
want
to
maintain
compatibility
with
iOS
version
2,
so
we
want
to
compatible
with
iOS
version.
2
and
also
expressiveness
is
not
increasing,
because
this
is
just
a
binding.
It's
not
extend
its,
not
extension,
it's
just
a
binding,
so
we
want
to.
E
We
do
not
want
to
increase
expressiveness,
and
we
also
want
to
consider
compatibility
with
sticks.
You
know
the
latest
verge
of
the
sticks
is
using
JSON.
So
why
not-
including
that
obvious
as
well-
and
we
also
Delta,
prepare
some
tools
to
cope
with
issues,
so
we
will
provide
conversion
tool
for
free.
So
here
what
we
want
to
define
more
is
a
facilitation
for
description.
For
instance,
we
want
to
change
the
name
of
the
element,
for
instance,
in
iof.
E
We
have
hot
pot,
is
array
actually
in
the
XML
in
case
with
XML
is
easy
to
understand
its
array,
because
we
have
a
schemer
but
engage
with
a
JSON.
We
do
not
have
to
use
a
schema
at
all
in
this
case,
why
don't?
We
have
a
name
like
this
photo
list.
The
name
itself
can
identify
that
we
are
using
array
it's
easier
and
also
we
have
to
change.
We
order
to
provide
some
kind
of
simplified
expression,
for
instance,
engage
with
our
XML
in
k
to
the
iotv
xml.
E
G
Take
a
good
question
on
the
previous
slide,
so
you
said
that
you're
not
gonna
try
to
increase
the
expressiveness
at
the
same
time,
you're
not
gonna,
try
to
decrease
the
expressiveness
right
here.
You
basically
want
to
include
all
of
the
same
content
that
can
be
expressed
in
Justin
and
I
are
deaf
or.
E
G
E
You
next
so
this
is
the
example
we
in
the
earlier
presentation
we
we
have
shown
the
format
of
the
alert.
This
is
the
iOS
version
to
a
Jason.
We
created
iotic
button
to
in
XML,
directly
converted
them
into
JSON.
Then
the
result
is
like
this.
This
is
far
from
not
good
looking,
so
we
want
to
modify
a
bit
of
the
place
exists,
for
instance,
in
XML
of
the
iodine
present
to
node
is
required.
That's
why?
If
we
convert
automatically,
we
have
this
kind
of
place.
E
We
want
to
get
rid
of
that,
and
also
we
have
a
IP
address
the
type
of
the
IP
address
under
code
number
everywhere.
It
could
be
just
agree
aggregated
so
for
this
purpose,
we
want
to
specify
some
draft
on
this.
That's
our
motivation,
yeah.
So,
based
on
that
I
have
published
the
first
version
in
the
mailing
list,
so
I
hope
you
can
review
it
and
I
have
three
question
after
the
first
one
is
I
had
some
difficulty
to
define
the
contents,
because
you
know
in
case
of
XML,
we
have
a
schemer.
E
So
if
it's
easy
to
define
but
in
case
with
Jason
I,
don't
know
whether
we
can
use
the
schema
for
writing
a
specification
or
we
have
better
way
to
define
some
sophistication.
If
you
know
some
idea
about
how
to
define
the
data
model
of
the
JSON
document,
I
would
be
appreciated
too
decent
opinion
and
also
it's
anybody's
interested
in
helping
to
work.
I'm
really
happy
to
call
work
with
that.
E
F
D
Is
it
too
soon
can
we
take
and
then
we'll
take
it
to
the
list
also,
but
can
we
take
another
hum
to
see
if
there's
interest
for
us
to
adopt
this?
As
a
working
group
item,
Oh
Kathleen's
coming
up
Oh
see
I
I
thought
you
were
like
okay,
so
those
who
are
in
favor
for
adopting
this
as
a
working
group
item?
Can
you
please
hum.
D
D
The
first
couple
the
drafts
are
ready
to
move
forward
on
Dave
you're,
gonna
Rev
and
we've
got
volunteers
to
review
either
this
one
or
the
next
version
of
the
rolly
draft
right
and
then
I
will
also
turn
a
new
version
for
the
xmpp.
But
please
keep
the
comments
coming
there
too,
so
that
we
can
meet
the
November
I'm
deadline
and
then
I'll
take
to
the
working
group
consensus
for
adoption
for
the
Jason
bindings.
I.
Think
with
that.
G
G
Feel
like
we
should
be
held
responsible
to
actually
provide
that
back
as
a
as
a
mild
stem
a
div,
altameyer,
so
yeah
and
the
process
of
generalizing
rowley.
We
had
to
remove
some
of
that
content
from
the
core
with
the
intention
that
we
would
be
providing
that
back
since
I
was
already
content
that
was
adopted
by
the
working
group.
I
feel
like
we
should
be
responsible
for
providing
that
back.
Yeah.
G
G
D
So
that
I
can
put
on
on
consensus
at
the
working
group
too
yeah
I
know
the
next
chair
is
trying
to
beat
us
out.
So
real
quick
can
I
take
a
hum
here
and
then
I'll
also
take
it
to
the
email
list.
Can
we
take
a
quick
hum?
Are
you
in
favor
of
pulling
out
the
sea
cert
use
case
as
a
separate
document
out
of
the
rolly
document
into
a
separate
one?
I
know
I
worded
that
poorly,
but
I
think
you
know
what
I
mean
those
in
favor.
Can
you
please
hum.
D
There
are
two
options.
One
option
is
to
pull
out
the
sea
cert
use
case
as
a
separate
document,
so
I
will
call
that
option.
One
option
two
is
to
have
that
content
be
an
appendix
of
the
current
rowley
document,
so
I'm
just
going
to
do
hum
for
those
in
favor
of
one
or
two.
So
those
in
favor
of
option
one,
please
hum
ok
hard
to
tell
option.
One
is
separate
document
option.
Two
is
appendix
so
I'm
having
a
hard
time
with
the
hum.
Is
it
ok?