►
From YouTube: IETF92-JOSE-20150324-1730
Description
JOSE meeting session at IETF92
2015/03/24 1730
A
A
B
C
B
The
information
which
you
would
normally
find
on
our
charter
page
is
is
here.
Document
status
is
so
all
of
the
documents
which
are
actually
in
our
view
to
have
written,
have
been
written.
They
have
all
gone
to
the
RSC
editor.
There
are
currently
two
drafts
which
are
in
the
Edit
state,
and
all
of
the
rest
of
the
drafts
are
actually
in
the
rest
state
waiting
for
those
two
drafts
to
get
finished.
B
The
agenda
will
start.
We
will
finish
the
administrative
stuff,
we'll
talk
about
the
the
two
documents
which
we
have
which
are
doing
cozy.
We'll
have
some
discussion
about
cozy
after
that
and
then,
as
time
permits
will
totally
will
have
a
presentation
from
mike
about
his.
He
managed
signatures
and
potentially
talk
a
little
bit.
B
The
one
issue
that
we
currently
have
on
the
thumb
draft
document
are
the
thumb
print
document,
which
was
requested
for
input
during
last
call,
but
we
didn't
actually
receive
any
from
anybody
is
the
thumbprint
draft
is
currently
on
standards
track,
given
that
it's
no
longer
actually
defining
any
things
which
are
going
to
be
actively
and
immediately
used,
such
as
header
parameters,
but
just
defines
an
algorithm
fry
to
do
something.
There
is
a
question
of:
should
we
move
it
down
to
some
standards
track
the
informational?
A
A
Matt
Miller,
you
know
they're
being
2119
language,
and
this
doesn't
necessarily
bother
me
it's
if
you're
going
to
do
this,
then
one
must
do.
This
is
fine
with
me
and
as
far
as
the
document
itself,
I
thought
it
sent
something
list,
but
I'm
fine
with
information.
E
Mike
Jones
Microsoft
I
know
of
one
other
standards
document
in
another
body
that
would
take
a
normative
reference
to
it.
Should
we
finish
it
I,
don't
think
either
status
would
prevent
that
from
happening
I'm
more
curious.
What
the
standard
ITF
practice
is
for
just
making
this
decision
and
I'm
fine
either
way
just
follow
what
we
would.
F
B
We
obviously
want
to
use
seaboard
idioms
rather
than
Jose
it
rather
than
Jason
idioms
whenever
possible.
So
we
can
lose
some
of
the
things
like
base64
encoding,
because
we
have
natively
binary
encoding,
we'll
probably
do
a
bit
of
changes
in
terms
of
naming
things
so
that
we
can
save
a
whole
lot
of
space.
If
we
use
integers
we're
somewhere
strings
are
used
in
in
places
there
are,
maybe
so
there
can
be
some
places
where
we'll
keep
strings
some
places
where
we'll
probably
swap
strings
to
be
integers
just
because
it
presses
everything
down.
B
There
are,
however,
things
that
we
will
want
to
reuse
we're
going
to
basically
won't
use
the
same
algorithm.
Registering
we
may
add
some
algorithms
to
that
registry
in
factory
almost
certainly
will
add
some
outcomes
to
that
registry,
but
we're
actually
going
to
keep
the
same
infirmary
the
structure
where
we
can
we're
going
to
keep
the
header
parameter
registry,
so
basically,
the
things
that
we
get
defined
into
cozy
for
things
like
core
will
actually
be
available
for.
B
Anyone
who
is
using
Jose
stuff,
as
well,
for
example,
is
quite
possible
that
the
sequence
number
which
they
are
talking
about
having
for
replay
will
be
useful
in
some
various
algorithms
that
are
various
places
that
are
you
currently
using
Hosea
for
some
reason,
various
reasons
and
we're
also
going
to
try
to
keep
some
of
the
basic
paradigms.
So
you
know
this
in
terms
of
how
you
structure
things.
B
That's
going
to
tend
to
stay
pretty
much
similar
next,
so
Kirsten
produced
a
document
which
is
out
there
and
he
basically
took
the
simplistic
approach
that
is
we're
going
to
keep.
Almost
all
of
the
structure
is
currently
there're
in
in
Jose
and
just
replace
it
with
seaboard.
So
basically,
you
start
by.
You
know
any
place
where
you
you
have
binary
data.
You
actually
use
a
binary
encoding.
You
don't
use
base64
encoding.
We
obviously
use
seaboard
rather
than
Jason
for
actually
doing
the
encoding.
B
We
use
integers
for
map
names
in
the
large
number
places,
but
not
necessarily
everywhere
and
with
encoding
using
maps
and
raised
in
places
we
might
use
periods.
His
original
document
actually
continue
to
use
maps,
but
it's
easy
enough
to
change
it
into
using
periods
and
a
lot
of
plays
in
a
lot
of
places.
Joe.
D
D
So
it
allows
you
to
do
extensions
without
having
to
register
them
so
that
the
sort
of
the
the
cool
way
of
doing
it
is
you
register
all
the
ones
you
think
you're
going
to
use
and
then
allow
people
to
use
strings
for
whatever
else
they
want
to
use.
We
could
decide
whether
that
was
an
approach
we
wanted
to
use
here
or
not,
but
that
seems
to
have
worked
at
least
conceptually
in
some
other
protocols
and.
B
B
So
this
is
what
an
encoding
looks
like
using
the
diagnostic
dump,
that's
much
easier
to
read
than
using
the
hex
dump,
even
though
I'm
sure
there's
way
too
much
information
there
for
anyone
to
actually
want
to
read
pick
up
the
slides
later,
if
you're
actually
interested.
This
is
actually
an
encoding
of
yes,
it
must
be
two
signatures.
B
B
So
the
document
that
I
wrote
uses
a
lot
of
the
same
approach:
we're
using
seaboard
we're
using
base
using
binary,
update,
64
I've,
actually
ran
ahead
and
replaced
several
of
the
maps
with
arrays,
so
we
keep
maps
for
headers,
but
we
use
arrays
for
the
all
the
external
structures.
For
you
know
what
the
signature
is.
What
this
signature
data
is
recipient
structure,
the
encrypted
structure
I,
actually
because
I'm,
a
firm
believer
in
it
separated
signatures
in
max
I,
don't
believe
that
the
same
thing
plus
for
max.
B
We
want
to
actually
be
able
to
do
recipients
stuff,
so
we
can
actually
do
key
management
with
it.
That's
no
was
I
did
that
long
before
the
draft
came
out
that
Mike
did
for
key
management
with
bridge
with
jws
and
I'd,
actually
reused
the
exact
same
structure
for
the
encrypted
body
and
for
recipients,
so
the
same
code
deals
with
both
of
them
which
actually
potentially
save
save,
save
some
code
there.
Next,
and
so
this
is
basically
what
the
exact
same
example.
B
I
had
up
there
before
looks
like
with
the
the
Seaboard
diagnostic
dump,
and
you
really
aren't
going
to
see
that
many
things
there's
some
extra
nulls
in
there
and
send
some
places
where
curly
brace
is
tremendous
into
square
brackets.
I'm
not
actually
going
to
go
through
the
structure
of
what
my
stuff
looks
like
is
I've
got
as
in
the
slides.
It's
also
in
the
draft,
so
we're
now
going
to
go
on
and
look
at
some
of
the
design
decisions
that
I
made
that
I
thought
were
actually
very
reasonable
to
do
so.
B
We
strive
start
by
they
see
if
you're
looking
at
at
size
comparisons.
So
this
is
basically
I
went
ahead
and
applied,
the
you
know,
use
integers
or
other
than
strings
22
draft
that
Arsene
produced-
and
this
is
basically,
if
you
have
you
know
once
I
nor
one
Mac
one
when
encrypt
it
show
encryption.
So
these
are
three
different
messages:
they're,
basically
minimal
messages.
So,
for
example,
the
Mac
does
the
designer
only
has
unprotected
headers
it
doesn't
have
unprotected
and
protected
headers.
B
The
sizes
would
be
the
same
whether
you
had
unprotected
headers
or
protected
headers
in
terms
of
both
Carsten
and
mice
encoding.
If
you
had,
if
you
added
other
fields
that
the
sizes
would
would
go
up
and
down,
and
would
they
wouldn't
actually
happen,
just
come
out,
basically,
the
same
nut
sizes
all
the
time.
This
does
not
include
things
like
IVs.
This
is
basically
just
the
overhead
of
encoding.
The
basic
structure.
B
Okay,
next,
okay,
so
basically
I
did
analysis
of
what's
the
cost
differential
on
doing
maps
versus
erase,
and
this
is
again
assuming
you're
using
integer
indexed
maps.
So,
if
you're
doing
an
array,
it
costs
you
a
bite
to
have
a
null
in
some
place
that
you're
not
doing
something
they're,
not
using
that
field.
So
if
you
aren't,
if
you
don't
have
authenticated
header
fields,
then
it
costs
you
about
to
have
a
null
in
there,
because
you
still
have
to
keep
the
element
filled
in
the
Iraq.
B
D
B
B
Yeah,
because
otherwise
is
trying
to
I
need
to
annotate
it
so
that
people
could
actually
understand
what
it's
there
it's
what's
there.
Basically,
it
was
enough
for
me
to
figure
out
what
was
going
on
and
not
much
more
so
AV.
Looking
at
the
body
of
a
signature,
there
are
four
fields
that
are
in
the
body
of
its
signature.
Basically,
you
always
have
two
of
them
filled.
You'll
always
have.
Basically
the
de
sumption
I
was
not
doing
detached
content,
so
you'd
always
have
a
content.
You'd
always
have
some
header
fields
in
the
signature.
B
There's
a
signature
item:
you
always
there
three
items
there's
always
two
of
them
filled.
So
basically
that
can
give
you
gives
you
an
idea
and
the
signature
body.
It
doesn't
really
matter
whether
you
have
an
array
or
a
map
is
just
going
to
come
out
about
the
same.
Both
both
ways,
depending
on
whether
you
decide
to
fill
those
extra
fields,
seem
to
try
damn.
B
It
is
a
little
bit
cheaper,
probably
to
have
the
array
rather
than
the
map,
because
you
know
you're
always
going
to
be
paying
that
one
extra
byte
for
having
the
map
or
fragment
and
they
rate
in
the
array,
but
you're
paying
two
extra
bytes
over
the
terms
of
app
for
the
further
for
that
I'm.
Similarly,
of
that
analysis
up
here
for
an
encrypted
body,
the
recipient
and
basically
the
recipient
structures
in
terms
of
what
you're
transmitting
on
the
wire
for
for
doing
anarres
is
the
only
real
big
loser.
B
On
the
other
hand,
it's
quite
possible
that
we'll
look
at
it
and
say
the
fact
that
you're,
using
basically
identical
code,
44
doing
the
recipient
body
and
the
recipient
struck
a
structure
that
the
encrypted
body
in
the
encrypted
structures
gives
you
enough
of
a
code.
Savings
on
the
chip
that
you're
willing
to
pay
that
that
that
additional
wire
cost.
B
B
The
one
issue
that
comes
up
that
we're
going
to
potentially
have
to
deal
with
in
some
way
is
implementations
may
have
to
be
able
to
deal
with
having
either
the
string
value
or
the
integer
value
there.
So
it's
like
I
know:
I
can
always
send
the
integer
value,
but
I
may
receive
the
string
value
because
I'm
receiving
it
from
someone
who
doesn't
produce
that
yet
because
they
rolled
it
out
before
we
say
they
will
the
string
out
before
we
sign
them
the
number
and
may
actually
be.
B
In
that
case,
you
have
to
send
them
the
strength.
I
don't
know
so
that
that's
actually
something
that's
this.
We
need
to
think
about
in
terms
of
as
we
move
forward
and
we
add
new
extension
things
and
we
assign
numbers
to
them.
What
happens
in
terms
of
do
we
actually
assign
numbers?
How
soon?
How
quickly
do
we
need
to
sign
numbers?
Do
we
need
to
set
up
an
early
member
assignment
process
so
that
we
don't
get
the
strings
rolled
out
instead
of
the
integers?
B
Next
one
of
the
things
that
I
did
in
the
array
structure
is
I,
went
ahead
and
assigned
an
element
in
the
base
array
to
say
this
is
what
the
type
of
the
structure
is.
I
did
not
try
to
do
any
sort
of
fancy,
I'm
going
to
infer
the
type
based
upon
something
else.
It's
cursed
and
suggested
that
we
can
potentially
actually
assign
some
seaboard
tags
to
identify
what
the
structure
the
structure
types
are
looking
at.
B
A
D
Joe
Hildebrand,
so
I
would
suggest
that
when
we
go
down
this
path,
we
figure
out
what
the
subset
of
C
board
that
we're
going
to
be
using
is
so,
for
example,
we
might
not
need
floats
for
this
work,
in
which
case
the
thing
that
I'm
using
to
parse.
This
doesn't
need
to
include
all
the
float
parsing
yeah,
so
it
saves.
D
And
I
also,
probably
wouldn't
want
to
do
the
streaming
bits,
for
example,
and
the
next
thing
that's
right
on
the
lip
of
that
would
be
tags
for
me
and
I.
What
I
found
with
tag
so
far
is
that
they're
useful
when
I
want
to
create
a
particular
datatype
on
receiving
so
I
want
to
tag
the
thing
as
a
date,
so
that
I
create
a
date
object.
Instead
of
creating
a
string
object,
we
may
or
may
not
have
any
of
that
where
that
sort
of
syntax
level
of
creating
the
right
object
is
as
important
to
us.
B
A
B
B
D
Joe
Hildebrand
again,
I
have
no
opposition
to
having
tags
and,
as
I
mentioned
tags
for
me
are
right
on
the
line
that
I
could
be
argued
either
way
on.
So,
if
there's
a
good
reason
to
do
it,
I'm
all
for
it.
If
there's
not,
we
probably
save
10
bytes
in
the
implementation
or
something
it's
it
doesn't
save
that
much.
But
it's
a
little
bit
mm-hmm.
B
So
as
I
separated
the
max
structure
and
the
signature
of
structures,
as
I
said,
it's
easier
to
discuss
the
security
properties
of
what
you're
doing.
If
max
and
signatures
aren't
put
in
the
same
pot
and
is
quite
likely
in
in
the
IOT
world
that
they're
not
going
to
be
doing
signatures
anyway.
They're
actually
going
to
be
doing
max
almost
all
the
time,
because
they
want
something
small
that
they
can
stand
across.
The
wire
I,
wouldn't.
A
B
B
I
mean
no
I
mean
the
implementation
will
support
boat.
But
if
you
in
point
of
fact
separate
the
two
of
them,
then
that
allows
you
to
say
you
know
we
just
can
basically
not
include
any
of
the
signature
stuff
and
in
under
this
library
and
if
we're
doing
encryption
and
then
half
the
mac
stuff
is
already
included
anyway,
because
the
recipients
that
there's
the
structure
furred
for
managing
your
keys
on
on
for
the
for
the
mac
structure
and
for
encryption
structure
is,
is
they're
identical.
They
exactly
the
same
thing.
B
The
single
encryption
structure,
it
simplifies
code-
and
you
know
what
part
of
what
I'm
hearing
for
about
a
third
of
the
IOT
people
is.
We
don't
have
enough
space
to
do
anything.
A
third
of
them.
Have
we
have
enough
space
to
do
a
small
amount
of
things
and
a
third
of
them
is
well.
We
got
lots
of
space.
We
can
do
just
about
anything.
B
It's
you
know
depends
on
which
people
you're
talking
to
and
what
day
it
is
again
we're
basing
it.
We
basically
can
do
a
ad
here,
app
algorithms,
which
may
be
useful
in
terms
of
enforcing
some
some
things
down.
The
line
in
terms
of
things
like
this
is
actually
the
name
of
the
algorithm
we're
doing.
Mike
Mike.
B
One
of
the
other
thing
that
allows
for
is
is
at
some
point
in
the
future.
We
can
move
from
the
composite
algorithm
set
to
it
to
a
Chinese
menu
algorithm
set.
It's
not
clear
that
that's
a
good
idea,
but
the
ability
to
do
so
at
some
point
in
the
future
is
something
I,
don't
necessarily
want
to
preclude.
So,
basically,
we
can
talk
about
what
the
the
the
algorithm
is
at
the
encrypted
message
layer.
We
can
talk
about
what
the
algorithm
is.
B
B
B
Okay,
I
did
move
the
off
that
the
author
TV.
If
the
tag
into
the
crypto
text
I
haven't
moved
the
IV
into
the
text
into
the
ciphertext,
it
is
potentially
something
we
want
to
think
about,
especially
for
some
algorithms.
I
know
that
the
the
people
who
presented
in
a
stood
a
we're
basically
talking
about
one
of
the
things
that
they
want
to
do
is
use
implicit,
nonces,
implicit
IVs
with
CCM,
so
that
they
don't
trap
to
transport
and
explicit
IV.
B
And
the
question
at
that
point
is:
do
you
signal
that
by
just
having
an
empty
IV
field,
or
you
signal
that
by
we're
going
to
roll
the
IV
into
the
ciphertext
stream
and
the
algorithm
is
just
going
to
know
whether
this
starts
with
it
with
an
IV
or
not?
That's
you
know.
Part
of
the
question
is,
for
example,
are
there
going
to
be?
Is?
Are
the
two
different
communities
who
are
using
the
CCM
code,
one
who
once
IV
is
in
one
who
doesn't
want
IVs
and
I?
B
When
we
did
the
analysis
on
which
way
we
should
go
for
Jose,
it
wasn't
really
clear
that
one
version
was
was
preferred
over
the
other
version
in
terms
of
the
libraries
that
are
there
and
since
basically,
a
lot
of
the
times
we're
going
to
be
rolling
into
new
or
existing
code,
it's
going
to
be
whatever
they
want
to
do.
Anyways.
It's
probably
not
gonna,
make
a
whole
lot
of
difference.
It's
not
that
hard
to
strip
the
I
to
strip
the
tag
off
the
back
and
feed
it
in
separately.
B
One
of
the
things
I
did,
which
is
a
cleanness
of
design,
as
opposed
to
something
that
that
potentially
really
needs
to
be
done
is
I,
basically
separated
out
nunna,
fin
dicated
and
authenticated
attributes
in
hat
put
the
man
in
a
lot
more
places.
So
since
we're
using
the
same
structure
for
the
base
encrypted
message
in
four
recipients,
obviously
I
get
both
the
the
hole
for
authenticated,
unauthenticated
attributes
for
free
at
that
point
for
signatures.
B
B
Similarly,
in
the
vicinity
and
on
the
mac,
the
the
back
value
computed
applies
to
just
what's
in
the
message
layer
with
the
payload.
If
you
had
authenticated,
attributes
in
the
recipient
would
be
authentic.
That
would
be
authenticated
by
you
know
the
key
rap
algorithm
that
you
would
be
using
at
that
layer.
B
B
B
What
is
hip
Thank,
You
host
identity
protocol,
which
basically,
he
was
trying
to
figure
out
how
to
do
everything
with
as
few
of
cryptographic
primitives
as
possible,
and
he
got
to
the
point
where
it's
like
he
had
a
es
on
the
in
a
crypt
mode.
What'd
you
do
GCM
CCMS
you're,
fine
on
that,
because
that's
all
you
need,
because
you're
doing
calendar
plus
plus
a
CBC,
he
tried
to
great
get
a
mode
of
doing
H
max
orquidea
variation,
and
that's
where
he
got
hung
up
is
doing
a
kdf
function
with
just
in
aes
encrypt
operation.
B
It
turns
out,
if
you
have
a
good
random
key
to
start
with
your
fine.
If
you
have
a
bad
random
key
to
start
with,
you
can't
really
use
an
a
yes
to
do
that.
You
really
need
some
sort
of
hash
function
there,
rather
than
a
Mac
function,
to
do
that.
Initial
compression
of
the
the
not
quite
so
random
data
into
random
data,
and,
of
course,
you
know
we're
kind
of
assuming
that
you
would
also
additionally
potentially
have
easy
an
elliptic
curve.
B
I
mean
people
who
will
review
the
documents,
comment
on
the
documents
implement
documents
depending
of
the
approach
I'm
intending
to
to
edit
the
document,
but
I'm
planning
to
do
it
on
github,
so
people
can
make
pull
requests
if
they
want
to
actually
help
edit
the
document
as
well
so
people
who
are
interested
in
work
in
working
on
this
scene.
This
work
done
also
David.
B
Looking
at
how
many
people
are,
you
know
really
really
eager
to
get
work
done,
as
opposed
to
just
I
want
to
get
work
done.
It
was
just
kind
of
we've
got
two
approaches:
we've
got,
we've
got,
we've
got
Carson's
document
and
we've
got
my
document.
Both
of
them
are
probably
reasonable,
starting
places.
My
document
has
quite
a
bit
more
changes
from
the
hose,
a
document
than
what
Carson's
does
and
I
don't
know
how
much
that
people
actually
have
stomach
for.
So,
let's
discuss
which
document
you
think
is
probably
a
better
starting
point.
C
C
So
it's
not
in
the
Charter,
you
know
even
just
this
week
into
it,
and
we're
only
on
Tuesday
I've
been
in
two
different
sessions
where
this
would
be
of
interest.
One
was
red,
xed
and
the
other
was
ace.
Ace
even
came
up
with
a
generalized
thing,
because
this
wasn't
ready
yet,
but
the
working
group
didn't
adopt
it
and
I
think
if
it
was
done
outside
of
the
working
group
that
actually
could
make
a
difference
for
them,
because
then
they
could
reference.
C
This
cozy
implement
a
cozy
method,
implementation,
whatever
you
want
to
call
it
rather
and
just
incorporate
that
in
the
draft
that
they
were
talking
about,
I
think
it
would
be
important
to
split
it
out,
because
these
other
groups
are
interested
and
I,
don't
know
that
people
will
notice
that
the
work
is
being
done
in
Jose
right.
I
think
it's
different
enough
that,
with
the
iot
focus
on
it
doing
a
short
working
group
to
stand
up
to
get
this
done
and
get
the
right
attention
on
it.
C
So
the
ACE
people
get
in
the
room
that
are
interested,
so
red
X
folks
get
in
the
room
that
are
interested
and
they
have
applications
that
could
be
using
this
on
gsma
and
and
other
things
so
I
don't
know,
I
think
it
might
be
important
enough
to
split
it
out.
But
if
that
happens,
I'd
want
to
see
it
done
very
quickly,
and
I
think
there's
this,
but
I'd
like
to
get
the
sense
of
you
know.
B
A
C
You
know
this.
The
switch,
I
think,
would
be
good
for
lots
of
different
reasons
and
there's
probably
more
that
I'm
not
even
mentioning
but
yeah.
I
don't
see
a
problem.
If
the
energy
is
there,
you
get
a
charter
done
with
having
one
ready
for
prague,
especially
with
the
emphasis
from
ace
like
in
the
room
ace.
C
A
lot
of
the
folks
said
I'm
in
the
room,
because
I
need
to
see
this
done
and
they're
really
interested
in
the
space
and
they're
following
along
and
not
everybody's
contributing,
but
they
need
all
these
problems
for
IOT
solved,
and
this
is
going
to
help
them
right.
So
if
they
can
reference
something
that
folks,
with
the
clue
on
how
to
do
see,
bore
and
implement
this,
that
they
can
point
to
I
think
it's
going
to
make
a
difference.
So
yeah,
I
I,
would
help
you,
okay,.
B
So
so,
basically
I
mean
if
in
terms
of
process,
as
long
as
we
don't
say,
we
want
to
do
this
work
and
in
the
Jose
working
group
we
would
need
a
new
mailing
list
need
a
case.
So
we
can
spend
that
up
quickly
and
then
it's
just
a
question
of
whether
we
spend
the
time
writing
a
charter
and
creating
a
working
group
which
is
not
necessarily
bad
Joe.
E
D
Joe
Hildebrand
I
think
Kathleen's
on
the
right
track
there.
As
far
as
I'm
concerned,
I
would
like
to
have
a
very
frank
discussion
about
what
the
new
charter
ought
to
be.
I
mean
we'd
have
to
do
that
and
recharter
an
exercise
doing
that
in
a
separate
group
would
allow
us
to
finish
off
the
little
bits
and
bobs
we've
got
here.
Have
us
yes
soon,
but
to
have
a
separate
list
for
the
new
stuff.
So
we
don't
sort
of
have
to
intermix
them
terribly
much.
D
I
like
the
idea
of
making
sure
that
people
can
find
it
in
the
fanfare
of
a
new
working
group
is
one
of
the
ways
to
get
a
little
bit
of
extra
attention.
I
think,
particularly
with
with
the
support
from
from
the
area
director
directly,
as
we
have
here,
without
having
to
go
through
the
whole
sort
of
off
cycle,
necessarily
I
assume.
B
D
G
Yeah
Phil
home
baker.
You
know
the
fact
that
you
are
now
having
to
spin
up
a
new
working
group
to
change
the
format
of
the
encoding.
I
think
really
speaks
to
an
architectural
problem
when
just
when
Jason
came
onto
the
scene,
the
reason
I
was
very
keen
on
it
was
I
wanted
to
standardize
on
one
data
model
across
all
of
the
things
I
wanted
to
do,
and
now
I've
just
been
looking
watching.
This
and
I
did
make
comments.
When
see
what
was
being
discussed.
I
said
that
I
thought
it
was
the
wrong
approach.
G
C
So
if
you
have
proposals,
I
would
get
those
in
right
away.
The
Jose
is
as
close
to
being
done
with
their
charter.
So
it's
something
that
fits
in
the
Charter
and
and
you
you
think
you
can
fix
some
of
these
things
and
you
can
make
it
with
with
in
JSON
work.
Then
you
I
ask
you
to
has
it
it's
been
submitted.
G
C
G
C
D
Joe
Hildebrand
well.
D
So
one
of
the
proposals
is
a
relatively
straight
porting,
with
no
semantic
changes
and
might
not
require
a
new
working
group
depending
upon
how
we,
how
we
approached
it.
One
of
the
things
that
the
people
who've
done
a
little
bit
see
borrar,
saying
I
believe,
is
that
a
slightly
more
idiomatic
use
of
C
bore
will
have
benefits
in
terms
of
the
size
of
the
code
need
to
parse
it
and
the
size
on
the
wire
etc.
D
So
those
changes
into
the
idioms
of
the
syntax,
the
target
syntax,
are
the
things
that
probably
sort
of
this
for
me
anyway,
into
being
a
little
more
see
more
specific
and
making
sure
we've
got
those
people
in
the
room,
etc.
So,
that's
for
me
I,
don't
see
that
as
an
architecture
issue
necessarily
with
Jose
I
see
this
as
a
an
issue
with
trying
to
do
the
best
seaboard
that
we
can
for
the
target
audience.
E
Meg
jones
I've
read
both
drafts
in
detail.
I
think
there's
great
things
to
take
from
both
of
them.
I
like
that
Carsten
did
basically
a
literal
re-encoding
I,
like
that
Jim
substituted
arrays
for
maps
in
places
where
that
made
sense.
I'll
note
that
in
some
sense
that's
what
we
did
with
the
compact
encodings.
We
had
a
raised
where
the
array
de
limiters
were
actually
periods
rather
than
using
Jason.
E
So
if
I
had
a
preference,
I
would
start
with
carstens
draft,
but
applying
the
array
changes
at
a
meta-level
I
do
think.
It's
and
Joe
and
I
had
talked
about
this
in
Kirsten,
but
it's
pretty
critical.
If
this
is
going
to
happen
fast,
that
we
have
the
meta
discussion
about
what
kinds
of
changes
to
Jose
do,
we
want
to
entertain
and
decide
them
up
front
rather
than
sort
of
relitigate
throughout
the
process.
If
we
do
that,
we
could
end
up
34
years,
like
we
have
here
and
I,
think
that's
not
what
anybody
wants.
A
Matt
Miller
I
agree
that
I
think
we
need
to
you
know,
be
very
upfront,
very
quick
and
very
concise
and
what
our
requirements
are.
I
do
have
a
personal
preference
that
we
unify
our
key
management
model,
but
it
would
be
good
to
have
this
done
this
stuff
done
quickly.
However,
I
don't
want
us
to
be
rushing
to
get
something
done
and
have
to
come
back
later
and
fix
it.
F
A
Just
because
I
was
in
line
anyway,
Martin
taunton
the
question
of
things
like
the
transformation
that
Mike
was
talking
about.
It's
probably
the
sorts
of
things
that
I
would
rather
this
sort
of
effort
focus
on
rather
than
you
know,
people's
wishes
and
dreams
about
what
Jose
could
have
been.
Unfortunately,
but
there
are
some
concerns
with
moving
to
an
array
based
thing
as
opposed
to
a
map,
and
there
are
advantages
in
either
direction
and
extensibility
in
and
various
trade-offs
that
that
need
to
be
made.
F
F
B
Kathleen,
just
do
it
do
we
want
to
have
some?
Do
we
want
to
nominate
somebody
to
take
initial
cut
at
a
charter
or
a
small
set
of
people
to
do
an
initial
credit,
Chartres.
C
A
C
C
C
D
B
A
So
you're
a
salon
right,
I
presented
the
orbiting
security
drafts,
okay,
yeah,
you
know,
and
so
I
mean
we
basically
have
a
set
of
abuse
cases
where
we
think
this
is
interesting
and
we
got
a
good
reception
at
ice
today.
But
there
is
there's
also
discussion
about
how
it
fits
into
the
coop
architecture,
which
so
I
mean
the
extreme
pressing
deadlines
which
I
hear.
Is
we
don't
need
it
tomorrow?
But
we'd
like
we
like
not
end
up
in
a
couple
of
years
ahead?
So
so,
but
there
are.
A
A
A
A
So
I
suspect,
Hannah's
I
suspect
this
I'm
from
the
discussion
that
we
had
to
be
useful
in
two
places.
One
was
in
the
solution
that
gun
go
and
present
it
on
sort
of
end-to-end
security
when
you,
when
you
have
a
client
talking
to
some
resource
over
to
get
some
some
data,
but
the
other
the
other
place
wait.
This
could
be
useful
is
in
the
context
of
something
where
the
authorization
server
passes,
encode
some
information
and
wants
to
have
a
compact
encoding.
This
is
not.
Data,
obviously
is
we're
talking
about
authorization,
information,
keys
and
etc.
A
There
heat
transport
mechanism,
and
in
that
case,
and
that
would
be
I,
think
a
fairly
integral
part
of
the
solution,
because
I
in
ace,
because
that's
what
all
of
the
proposals
would
definitely
need,
and
currently
you
can
add
a
cook
up
something
on
your
own
or
use
the
JWT
or
similar
trade,
a
ver
que,
etc
mechanism.
But
I,
ideally,
would
be
good
to
have
this
sort
of
more
compact
version.
If
available.
A
In
a
mall,
so
dime
working
group
share,
so
there
is
also
some
ongoing
discussion
regarding
the
need
for
end-to-end
or
20
mm
and
true
in
security,
and
so
for
the
time
being,
there
is
on
this
service
requirements
or
security
requirements,
but
I
think
that's
at
the
next
meeting,
we've
stopped
speaking
about
solution
at
the
initial
time
it
was
about
we're
using
JSON
facades,
so
I
think
that
will
be
also
interested
by
this
work.
Okay,.
F
E
I'll
just
say:
there's
a
PowerPoint
or
actually
a
PDF,
which
is
now
in
the
meeting
materials.
I
encourage
people
to
read
it,
I'm
not
going
to
go
through
it.
The
one
actually
go
to
the
next
to
last
slide.
E
Reuse,
I
have
no
problem
with
that,
and
that
was
the
lesson
there's
a
completely
separate
question,
which
is
whether
people
are
interested
in
a
way
they
weren't
before
and
having
key
management
for
max,
and
I
really
don't
have
an
opinion
in
that.
I
just
wanted
to
get
down
for
the
record.
While
we
still
had
a
working
group,
how
I
would
reuse
stuff
were
we
to
decide
to
do
that
and
I'm
not
presupposing
a
decision.
That's
probably
a
good
list
question
and
I
don't
have
an
opinion.
G
There's
an
acne
buff,
that's
one
of
the
things
that's
happening
is
it
was
starting
to
use
Jason
and
Jersey,
possibly
in
applications,
and
so
is
starting
to
find
issues
when
we're
trying
to
apply
it.
One
of
the
things
we
quite
like
is
a
direct
encoding,
a
directing
serialization
that
doesn't
involve
base64
because
of
I'm
reading
through
a
draft
I
do
not
want
to
be
reading
examples
that
are
a
base64
encoded
of
what
I
want
to
look
at.
So
I
have
written
a
draft.
G
G
E
Was
actually
just
going
to
support,
fill
in
the
sense
that
I
do
hear
people
coming
up
to
me
saying
I
have
a
payload
that
I
have
a
way
to
transmit
without
it
changing.
How
can
I
do
a
sign
without
doing
the
base64
I
think
there
could
be
a
one
page
draft
that
we
could
do.
That
would
do
that
as
an
extension,
even
though
we
chose
not
to
do
that
before
and
I
think
we
should
at
least
have
that
discussion
on
the
list
before
we
close
the
group,
it's
definitely
Jose
extension.
It's
not
a
different
thing.