►
From YouTube: IETF104-DISPATCH-20190325-0900
Description
DISPATCH meeting session at IETF104
2019/03/25 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
Okay,
so
we're
gonna
go
ahead,
get
started
and
the
blue
sheets
are
out
there.
Please
remember
to
sign
it.
A
You
will
note
it
well
read
it.
If
you
haven't
read
it,
you
should
really
read
it.
Okay,
so
here's
our
agenda.
People
can
bash
the
agenda.
We
started
bashing,
just
the
fact
that
the
agenda
was
not
there
in
an
email
but
anyways
and
we'll
have
just
a
few
minutes
to
updates
from
area
directors.
A
These
are
you
know
what
I
updated
these
this
morning,
but
anyways.
So
we're
gonna
rearrange
these
a
little
bit
because
Brian
Rosen
had
travel
difficulties,
so
he's
not
here
yet
so
we're
gonna
we'll
leave
that
to
the
end.
If
he's
not
here
by
the
time,
we
get
ready
transition
to
art,
we'll
leave
it
to
the
end,
then-
and
if
he's
still
not
here,
the
chairs
are
run
through
slides,
okay
and
then
we're
gonna.
Do
the
JSON
contact
we're
gonna,
try
and
do
remote
see
how
that
goes
again.
A
It's
Monday
morning,
first
time
and
then
when
packaging,
and
then
we
switch
over
to
the
art
area
and
we'll
let
the
IDs
talk,
we'll
talk
about
boss,
new
working
groups
and
then
we've
got
on
dursa
stewing,
the
the
JSON
canonicalization.
A
Okay,
anybody
have
any
comments
on
the
agenda
and
next
time,
I'll
come
pay
or
might
not
tell
you
when
it's
there:
okay,
okay,
dispatch.
Okay
here
are
deadlines
and
again
we
just
work
backwards
from
the
main
IETF
draft
deadline.
And,
coincidentally,
these
are
the
exact
same
gates
that
align
from
2016
as
I
took
slides
for
2016
and
I.
Didn't
I
just
had
to
change
the
year?
A
Yes,
these
are
Montreal
device,
yeah
I
camp
1:05,
yes
Montreal.
It
would
like
to
give
people
the
heads
up
right,
okay,
and
then
here
is
the
link
to
the
wiki.
This
is
where
you
can
find
further
information
on
a
regular
basis:
okay,
working
with
deadlines.
Again,
we
have
hashed
some
of
this
on
the
mailing
list.
A
People
did
really
well
this
time
in
terms
of
making
deadlines,
which
we
appreciate
and
again
it's
helpful
to
put
dispatch
in
the
draft
name,
because
it
makes
it
a
whole
lot
easier
for
me
to
do
double
checks
and
try
and
pull
up
the
right
drafts.
I
did
upload
or
point
out
that
there
are
three
specific
working.
Your
documents
associated
with
this
that's
in
the
meeting
materials
and
as
I
as
best
as
I
could
figure
out.
So
I
don't
guarantee
it's
all
of
them
and
there
is
Jeffrey
and
I.
A
We
had
the
discussion
on
the
list
for
people
that
bothered
reading
all
of
that
and
we're
not
sure
that
individuals
can
actually
do
replaces.
So
if
you're
like
changing
the
name
of
your
individual
draft,
whether
or
not
you
can
can
they
do
it
when
something?
Okay,
this
is
the
whole
thing.
So
when
we
were
trying
to
figure
it
out,
the
upload
tool
was
blocked.
You
couldn't
go
to
pretend
you
were
gonna
upload,
something
to
see
what
it
was
that
you
could
choose
from.
C
A
Thank
you
I
appreciate
that,
okay
and
again
a
reminder,
the
mailing
list
we
do
have
I,
don't
know
why
we
say
right
there.
That's
interesting,
I,
guess
liked
it.
Anyways
cuz
I
is
gone.
So
the
art
discussion
list
is
our
data,
ATF,
dot,
org
and
then,
of
course,
dispatch
dispatch
at
IETF,
dot,
org
and
that's
something
you
know,
people
if
you're
looking.
D
A
B
I
every
time
we
get
questions
about
what
belongs
in
art
and
what
belongs
of
dispatch
and
the
answer
to
that
is
fuzzy,
but
in
general
things
that
art
discussions
are
for
things
where
there
is
work
that
might
be
of
interest
to
people
and
and
you'd
like
to
see
if
people
are
interested
in
have
some
feedback
and
maybe
dream
up
some
support
for
it
dispatches
for
work
where
we're
actually
talking
about
proposals
to
have
the
IETF
do
something
and
figuring
out
where
we
need
to
do
that,
work,
etc.
I.
A
C
A
Can
come
up
here
now,
just
you're
not
gonna
talk
yet
just
don't
say
anything
yet:
anyways,
okay,
so
here's
our
box
and
other
meanings,
the
the
VI
mi
I,
don't
know
how
people
pronounce.
That
is.
Be
me,
Demi,
be
me:
okay,
it's
gonna
meet
Thursday
other
meetings.
You
know
for
people
that
pay
attention
to
the
agenda,
there's
an
open
space
on
Wednesday
for
people
to
have
these
side
meetings.
So
there's
several
of
those
the
there
is
a
meeting
for
the
rum
working
group,
kind
of
a
pre-meeting
gather
interested
parties.
A
I
want
to
do
work
on
that
and
then
there's
W
PAC
web
package
is
gonna,
have
a
side
meeting
and
then,
though,
has
various
issues
they're
gonna
discuss
as
well
at
Wednesday
and
there's
a
full
link.
If
you
click
on
that
again,
it's
on
a
wiki
of
all
the
site
meetings
and
there
is
still
actually
open
space
that
people
had
topics.
They
wanted
to
arrange
meetings
for
okay,
new
working
group
since
IETF
103,
not
just
in
our
area.
A
Okay,
sorry,
okay,
so
we
were
going
to
give
on
the
agenda.
We
had
a
few
minutes
for
the
eighties
to
say
some
stuff
early
on,
because
you
notice
that
we
don't
have
Murray
and
:
up
here
anymore,
and
we
do
want
to
thank
him.
I
want
to
thank
them
for
being
co-chairs
for
the
past
what
three
years
for
three
years.
A
Well,
so
a
long
time
so
:
has
been
my
co-chair
since
he
stepped
down
as
an
18
right
before
that
the
original
my
original
co-chair
was
bin
Saleh
and
he
became
an
80
and
then
:
step
down.
That
sekolah
became
a
pattern.
There
is
a
pattern,
so
I
just
stay
here
all
the
time
and
other
people
come
and
go
so.
A
A
Okay,
that's
exactly
right!
Okay!
So
so
again
we
didn't
want
to
thank
Murray
and
:.
Murray
was
wonderful
because
Murray
did.
The
chair.
Charts
have
a
whole
time,
but
he
was
my
coach
here,
so
that
was
lovely
I
appreciate
that
I.
F
B
A
A
So
well
we're
just
giving
you
this.
This
is
a
token
it's
not
a
very
secure
token.
Well,
it
is
of
our
our
appreciation
and
we
decided
that
you
really
didn't
want
to
have
to
consume
multiple
models
before
you
went
back
you
might
want
to.
But
what
we'll
do
is
you'll
get
a
delivery
in
Dallas
of
other
gifts.
Oh
yes,
thank.
B
Here
it
is
a
this:
is
a
republic
exclusive
I
believe
it
is
probably
a
Czech
whisky,
but
it's
in
check
so
I
can't
read
it.
G
B
D
G
G
F
B
B
H
Okay,
I'm
Jef
Raskin.
This
is
Co
hey.
Why
don't
we
work
on
chromium
on
web
packaging
and
we
were
asked
to
come
here
a
second
time
we
presented
in
I
think
ITF
99
here
to
to
dispatch
the
first
time.
We
think
we're
going
to
be
ready
for
a
ball
for
next
next
meeting,
but
we
want
to
get
the
the
feel
of
the
room
for
kind
of
where,
where
do
we
actually
standardize
this?
H
So
to
avoid
assuming
that
that
everyone
knows
what
we've
been
doing,
I
wanted
to
present
kind
of
what
web
packaging
is
and
describe
where
we
are.
So
why
do
we
want
to
do
this?
We
want
to
allow
people
to
load
websites
peer-to-peer
instead
of
over
there,
perhaps
a
very
expensive,
or
only
on
part
of
the
month
internet
connection.
H
Also,
let
you
optimize
the
transfer
of
small
resources
and
possibly
signed
exchanges.
Let
let's
see
DNS
optimized
cross-origin
resources
like
send
them
over
the
same
connection,
we're
still
figuring
out
whether
that
works
in
a
private
way.
We
also
want
to
allow
third
parties
to
say
yes,
this
is
website
is,
is
good
on
some
axis.
You
can
imagine
doing
some
static
analysis
over
it
and
having
your
your
client
trusted
a
little
more.
If
someone
you
trust,
says
that
it's
it's
beneficial
or
you
can.
You
can
do
buy
no
transparency
with
this.
H
Based
on
your
feedback,
we
split
signed
exchanges
from
bundles
exchanges
to
explain
that
that
distinction
scientist
changes
have
a
signature
on
a
single
HTTP
request/response
pair.
You
get
cross-origin
trust
in
them,
based
on
a
certificate
like
TLS,
but
not
actually
usable
for
TLS.
It
has
a
separate
extension
they
may
expire
after
about
a
week
to
avoid
long-lived
XSS
exploits,
and
you
can
update
the
signature
so
that
after
that
expiration
you
can
make
a
cheap
request
to
to
say.
Yes,
this
thing
is
still
good.
Instead
of
having
to
transfer
the
whole
thing
again
bundle.
H
H
H
For
example,
we've
got
this
list
of
websites
that
are
publishing,
signed
exchanges
or
working
on
publishing,
signed
exchanges
to
to
get
the
the
benefits
of
getting
the
right.
Urls
I
think
the
Washington
Post
is
especially
excited
about
about
having
their
content
under
their
URL
and
not
not.
The
Google
com,
URL
didja
cert
is
issuing
the
certificates
you
need.
Cloudflare
is
building
support
for
for
generating
sign
exchanges
from
from
domains
that
they
that
they
host
or
proxy
and
chrome
73
is
shipping
a
version
of
signed
exchanges.
H
Now
the
fact
that
we're
shipping
it
makes
a
bunch
of
people
nervous
because,
often
when
you
ship
something
it
gets
locked
in
stone,
we've
we've
designed
so
that
this
will
not
be
locked
in
stone.
There's
a
I.
We
put
the
URL
of
the
site
exchange
at
a
fixed
location
in
the
format
so
that
when
we
upgrade
formats
and
drop
support
for
the
old
ones,
if
people
are
still
serving
the
old
format,
you
get
a
redirect
instead
of
just
a
broken
site.
H
So
we
think
that
will
let
us
move
on
to
a
more
a
more
standard
format.
As
as
we
develop
the
standard,
we've
got
a
bunch
of
documents
defining
this
whole
system,
so
the
first,
the
first
one
is
the
is
the
ITF
side
specification
of
the
format
and
then
the
second
one
describes
particular
checkpoints.
So
right
now
we're
we're
working
on
on
publishing
the
zero
three
checkpoint,
which
defines
what
chrome
ships
and
what
the
the
sites
that
I
mentioned
are
generating
and
that
should
let
everyone
interoperate.
H
While
we
work
on
the
next
version,
we
have
a
ycg
repository
and
specification
that
define
how
this
all
interacts
interacts
with
web
browsers.
So
how
you,
how
you
fetch
them,
how
a
browser
loads
it
and
then
we
have
a
preliminary
specification
for
bundles
and
an
overview
of
all
the
use
cases
that
were
that
we're
trying
to
achieve
so
next.
We
need
to
get
get
feedback
from
these
deployments
and
incorporate
that
into
specifications.
We
need
to
make
sure
that
we're
not
completely
breaking
the
security
of
the
web
and
improve
any
points
that
that
aren't
quite
right.
H
We
need
to
specify
and
implement
bundles
mark
Nottingham
and
the
w3c
tag
or
organizing
a
workshop
sometime
between
now
and
the
next
ITF
I.
The
last
time
I
heard
mark
might
correct
me:
yes,
daya,
be
not
not
just
mark
to
get
feedback
from
from
publishers,
see
what
see
what
they
think,
what
their
concerns
are
and
we
like
to
hand
ownership
of
the
documents
to
standards
bodies
right
now.
These
are
things
that
I
can
change
unilaterally
or
Google
can
change
unilaterally
and
that's
a
bad
idea.
We
want.
H
We
want
you
all
to
own
the
the
kind
of
the
definitions
we
want
to
change
them
by
consensus,
not
just
because
I
woke
up
on
the
wrong
side
of
the
bed
one
day
and
so
that
questions
I
believe
for
this
room
are.
How
do
we
put
this
on
the
standards
track?
Should
we
create
an
IETF
W
working
group,
the
scheduled
side,
meeting
on
Wednesday,
assuming
that,
if
this
group
decides
to
go
that
direction,
we'll
probably
start
working
on
on
the
Charter
and
AB
off
for
the
next?
H
The
next
meeting,
part
of
it
might
go
to
an
HP
working
group.
If
that's
where
you
all
want
it,
we
we
believe
part
belongs
in
the
w3c
or
what
WG
to
integrate
with
the
fetch
spec.
But
it's
it's
possible
that
that
you'd
say
the
IETF
doesn't
care
about
this
at
all
and
everything
should
it
should
go
through
the
w3c.
What
WG
track
so
here
here
are
some
links
that
you
can
follow
when
you,
when
you
look
up
the
slides
online
and
Kohan
I
are
here
to
answer
questions
and
and
participate
in
the
discussion.
A
A
I
Well,
what's
pretty
close,
as
it
was
I
think.
J
I
am
thanks.
I
For
betting,
okay,
well,
maybe
that
thanks
for
presenting
this
I
mean
first
things.
First
I
mean
this
is
pretty
clearly
a
major
architectural
changes
inside
of
the
web,
so
there's
no
possible
way.
This
can
like
not
be
coded.
Some
kind
of
off
I
have
a
number
of
concerns
with
actionable
size
structure.
So
I,
don't
this
use
a
little
surface
than
here
any
boss.
Discussion
probably
should
talk
start
with
use
cases
not
with
like
what.
How
do
we
standardize
this
particular
technology
I
mean
we
have
that
document
of
use.
I
That,
but
there
seems
you
know,
plus
it
is
I'm
sure
that
this
topic
is
this
roster,
not
what
you
said
is
the
answer
of
these
use
cases
or
that
all
those
use
cases
it
matter
and
neither
of
those
things.
Obviously
true,
so
we
should
always
start
with
that,
because
one
thing
that
happens
when
you
look
at
the
use
cases
may
be
in
a
very
technical
solution.
I
I
Are
not
exclusively
about
URL
substitution
problems.
Are
they
in
have
a
number
of
good
system
effects
that
are
not
that
are
in
fact
made
worse,
I,
suppose
I'm,
not
better,
so
and
in
particular
the
it's
not
clear
that
it
is
not
clear.
The
use
cases
necessarily
have
to
involve
loading
the
entire
target
web
page
from
the
front
from
the
referring
site.
The
question
is
how
to
increase
performance
of
that
not
to
load
the
entire
page
under
this
goggle
desire
for
the
Monday.
Its
aim
is
important
use
cases.
I
Similarly,
it's
not
all
clear
to
me.
These
cases
involve
offline
to
online
transition
are
actually
important,
so
you
know
I
mean
I
mean
I.
Don't
really
want
to
go
to
extremes.
You
know,
but
I
think
I
took
a
few,
a
lot
of
feedback
from
these
cases
and
they
were
like
and
largely
response.
I
got
was.
We
think
these
cases
are
important,
so
go
pound
sand
so,
like
I'm,
not
really
sure
what
you
think
I
had
like
an
obligation
to
go
back
and
forth
with
you
for
like
the
year
on
this
topic,.
I
A
I
H
K
Wendy
Seltzer
w3c,
yes,
as
you
mentioned,
w3c,
is
interested
in
use
cases
and
which
you
think
that
there's
a
lot
of
distance
between
use
cases
and
solutions
and
gathering
they
that
the
people
who
need
to
cut
packaging
solutions
together
to
to
figure
out
where
they're
their
needs
might
converge
and
what
the
solutions
look
like.
And
what
piece
of
the
solution,
this
might
be
seems
to
be
an
area
where
we
also
wanted
to
help
be
part
of
the
the
forum
for
discussion.
So
thanks
for
bringing
ideas.
L
Iam,
so
I
I
think
we
need
a
buff
to
get
this
conversation
into
a
more
normative
regular
than
you,
so
we
can
make
some
decisions,
or
at
least
you
know,
no
one
can
say.
Well,
I
didn't
come
that,
because
that
was
just
your
thing
or
whatever
I
do
my
hearing
actor
and
then
a
little
bit
of
windy.
L
This
criticism,
or
this
observation
that
there
are
lots
of
different
use
cases
on
the
table
here
potentially
and
from
what
I've
heard,
not
only
from
them
but
from
other
folks
I've
talked
to
is,
if
I
wanted
to
meet
those
use
cases.
What
I
come
up
with
to
do.
That
might
not
necessarily
look
like
when
packaging,
and
so
that's
I
think
what
we
probably
need
to
dig
into
as
a
community.
More
than
anything,
I
think
the
buff
is
a
perfectly
good
way
to
do
that.
L
I
think
the
workshop
we're
gonna
hold
is
another
way
to
get
some
information
about
that.
My
question
for
you,
Jeffrey,
is:
if
the
community
comes
to
a
place
where
we
agree
that
these
use
cases
or
some
subset
of
more
important
to
address,
but
that
the
solution
for
whatever
reason
and
of
course
the
reason
needs
to
be
reasonable.
It
does
not
look
like
web
packaging.
You
know.
Are
you
still
on
board
for
that
level
of
change?
I.
H
Believe
so
the
the
big
question,
in
my
mind,
is:
can
we
convince
the
amp
team
to
switch
over
to
the
new
thing
and
and
if,
if
they
wind
up
not
switching,
then
their
ecosystem
effects
are
still
there
and
we
still
don't
have
a
standard
answer
for
them.
But
if
we
find
something
that
that
is
totally
different
from
this
and
still
satisfies
the
use
cases,
then
great
okay,
well,.
L
G
Hello,
come
on
James,
given
the
sort
of
complicated
sort
of
assess,
I,
don't
quite
understand
the
interaction
speech,
but
of
how
you
might
see
this
going
forward
between
IT
FWC.
What
working
group
can
you
talk
to
that
a
little
bit
more
and
what
you
expect
out
of
the
IETF
versus
just
not
bring
into
the
ITF
at
all
like
what
like?
What
do
you
expect
to
get
out
of
the
ITF
on
this?
In
the
most
positive
picture,
right.
H
So
I
believe
that
that
the
folks
here
that
we
need
to
take
into
account
the
the
knowledge
here
of
the
security
guarantees
of
the
internet
kind
of
the
meaning
of
the
HTTP
scheme,
they,
like
all
of
the
interactions
with
TLS,
there's,
there's
a
lot
of
expertise
here
that
we
need
to
use
and-
and
so
the
the
question
is
really
like.
How
do
we?
How
do
we
get
that
into
the
right
like
into
the
structure,
and
how
do
we
incorporate
all
of
that?
H
So
that's
that's
what
I
currently
expect
the
the
specifications
to
look
like,
but
but
that's
gonna
be
totally
up
to
kind
of
the
working
groups
that
that
own
it,
the
w3c
or
what
WG
split
is,
is
often
contentious
right
now,
we're
in
the
YC
G,
which
is
formally
part
of
the
w3c
but
like
fetch,
is
in
the
what
WG
and
so
I'm
hoping
to.
Let
that
side
kind
of
are
you
out
exactly
how
that
split
works.
E
N
E
E
Other
thing
I
wanted
to
go
back
to
was
the
use
cases
thing,
and
that
is
the
use
case.
I
most
care
about
here
is
the
anti-censorship
use
case.
It's
up
to
them
personally
care
about
a
great
deal
and
I've
talked
to
a
number
of
people
who
do
peer-to-peer
networking
in
mesh
based
networks,
who
would
be
very
interested
in
using
something
like
this
word
available
in
common
applications,
because
what
they're
trying
not
to
do
is
to
have
formats
and
methods
that
are
in
applications
which
identify
the
user.
E
Who
want
to
avoid
censorship,
so
I
have
a
really
strong
hope
that
what
comes
out
of
the
Bob
it's
usable
for
that
and
is
adoptable
by
a
broad
swath
of
browsers
and
HTTP
based
mobile
frameworks,
because
I
think,
like
many
other
anti
censorship
techniques
of
the
broader
the
community,
that's
actually
using
it,
the
less
it
becomes
a
signal
of
interest
and
I
think
that's
very
important
for
that
use
case
here.
Thank.
P
Q
It's
a
mom
Thompson
thanks
for
doing
this.
One
thing
that
concerns
me-
and
maybe
you
weren't
thinking
about
when
you
said
it,
but
one
thing
that
really
concerned
me
here
was
that
you
said:
maybe
the
amp
team
want
take
that
or
or
something
along
those
lines.
Q
Their
input
process
is
critical
to
this,
and
if
this
is
gonna
work,
then
the
amp
team
has
to
actually
be
involved,
and
I
would
also
say
that
that
this
is
not
the
only
example
of
this.
This
there's
other
people
doing
very
similar
sort
of
things
and
I.
Don't
know
how
much
reached
out
those
have
you
reached
out
to
say
the
Apple
news
folks
or
any.
H
H
Q
Ideally,
yes,
but
you
know
in
all
these
situations,
we
respect
the
fact
that
there's
a
lot,
what
happens
in
the
IDF
that
may
not
be
relevant
to
these
people
and
traveling
is
expensive
and
time-consuming
and
difficult,
and
even
this
participation
would
would
be
it's
not
a
huge
imposition
at
that
point.
That
would
be
a
lot
more.
Q
F
In
York
working
for
the
internet
society,
but
not
speaking
for
them-
and
we
do
need
a
ball
because
I
think
we
do
need
to
be
clear
on
the
use
cases,
because
some
of
the
use
cases
I
have
as
a
publisher
of
websites
are
different
than
some
of
the
other
ones
that
you're
having
in
that
and
to
Martin's
point
I'm.
Also
very
much
interested
in
deployability
in
my
use
case
is
fairly
simple.
F
In
some
cases,
I
want
something
that
allows
me
to
do
mobile
caching
and
allowing
our
web
sites
to
be
deployed
into
low
bandwidth
environments
in
weight,
packaged
and
bundled
in
ways
that
is
standard
and
it's
not
Google
amp
or
Facebook.
It's
art
Facebook.
It's
an
articles
or
Apple
news.
Whatever
else
so
I
would
say
to
the
point
as
it
looks
at.
If
there
is
sort
of
off
it
would
be
very
useful
to
have
some
buy-in
or
some
at
least
from
some
of
those
different
parties
to
say.
I
I
I
see
a
real
case
scenario
here,
which
is
that
discus,
Mart
ITF
gets
adopted,
we're
like
remotely
negotiating
with
amp
people
for
you,
and
then
they
decide
out
to
play
it,
and
now
we
are
senility
with
nobody
wanted
and
and
point
which
has
no
other
employers
and
ample
use.
That's
bad
so,
like
I,
think
I
want
to
start
more.
Martin
said
if,
like
the
eight
people
can't
be
bothered
to
show
up
to
this,
like
I,
just
understand
why
she
Turner's
yeah.
H
G
Iii
mean
if
you
want
us
to
take
I
just
took
I,
know
nothing
about
this
technology,
don't
care,
but
I'm
just
going
to
tell
you
how
idea
is
going
to
react
to
that.
If
a
group
of
people
that
is
going
to
totally
change
the
architecture
of
their
fundamental
product
doesn't
want
to
show
up
to
the
meeting
to
discuss
it,
people
are
unlikely
to
take
it
very
seriously
that
the
odds
that
they
will,
even
even
if
they
send
to
the
lesson,
email,
we're,
definitely
100%.
Implementing
that
it's
going
to
be
met
with
a
major
credibility
gap.
A
M
A
B
A
quick
recap
for
the
minutes:
I
think
what
I
heard
was
that
I
bought
with
a
good
idea.
We
need
to
discuss,
use
cases
first
before
the
solution
and
that
we
need
to
make
sure
that
the
people
who
are
really
going
to
implement
and
use
this
are
engaged
in
that
process.
So
if
the
minutes
can
make
sure
we
capture
that
part.
B
A
A
B
B
C
A
A
S
S
So
the
goals
of
this
effort
are
basically
to
provide
standardized
data
model
for
contact
and
group
information
that
should
be
an
advancement
or
enhancement
of
vCard.
We
are
aiming
at
providing
a
JSON
based
format.
We
are
not
necessarily
tied
to
to
the
exact
data
format.
It's
more
to
take.
The
model
we
are
interested
in.
This
is
coming
mainly
from
the
observation
that
the
that
the
vCard
model
in
one
way
is
very
much
used
in
the
industry.
S
We
would
like
to
narrow
down
the
or
or
remove
the
pitfalls
arising
from
these
different
formats,
so
it
should
be
simple
to
process
and
it
should
be
extendable
in
a
way
that
that
different
vendors
or
different
use
cases
can
still
build
on
a
on
a
core
format
or
data
model.
That's
shared
by
by
hopefully
the
majority
of
implementations.
S
Doing
that
we
we
intend
to
start
from
the
current
vCard
semantics,
but
we
explicitly
do
not
require
or
do
not
aim
to
be
a
hundred
percent
backward
compatible
with
vCard.
We
have
seen
other
efforts
in
the
past,
for
example,
X
card,
which
is
translating
vCard
into
X
XML.
There
is
also
an
effort
if
I
recall
correctly,
which
represented
me
card
information
in
chases,
but
again
was
very
much
tied
to
the
2d
semantics
of
V
coordinates
and
it's
wire
format
which
made
it
kind
of
difficult
to
process.
S
S
K
P
So
as
a
as
a
cat,
calyx
culture
I
think
we
well,
there
is
a
current
trying
to
to
have
ulti
stuff,
new
mapping
and
I.
Think
it's
a
it's
good
good,
not
to
let
it
be
called
aside.
This
change,
so
I
would
be
in
favor
to
have
that
work
down
were
this
work
is
to
be
done.
I'm
we
used
to
have
a
lot
of
different
groups.
That
seems
not
too
good.
My
that's
an
ad,
so
maybe
I
would
be
happy
to
have
all
this
and
a
perfect
for
one
written
group
being
can.
P
So
we
used
to
have
very
different
working
groups
right,
so
we
we
used
to
have
a
lot
of
different
working
groups
working
on
the
v-cards
time
zone
calyx,
and
I
would
be
in
favor
of
merging
oldest
working
group
into
one
so
but
that's
a
more
VAD.
So
that's
why
I
think
Alex
might
be
a
good
place
for
Alex.
A
G
G
Who
work
primarily
on
collaboration
and
messaging,
which
also
uses
all
this
technology,
so
I
would
lean
towards
and
also
the
stuff
gets
bit
put
behind.
All
the
other
deliverables
of
the
working
group,
so
I
would
argue
for
a
very
small,
focused
working
group.
Just
to
do
this
would
be
sort
of
my
mind,
leaning
but
I'd
be
glad
to
see
it.
F
C
F
F
I
agree
that
you
don't
want
to
limit
yourself
to
what
can't
what
you
can
do
that
requires
direct
mapping,
but
history
tells
us
that
the
card
versions
in
particular
get
ossified
and
it's
difficult
to
get
people
to
change
their
v
card
implementations
to
the
more
modern
ones.
So
I
would
like
you
to
as
you
develop
this
keep
as
much
mapping
as
possible
in
there
to
allow
it
to
be
ported
to
older
versions
for
implementations
that
haven't
been
updated.
S
R
Hi
I'm
Jim,
Fenton
I've
got
a
question.
Maybe
in
a
little
bit
different
direction
then
were
to
organize
this,
but
I
guess.
My
question
is:
do
we
have
I
have
a
sense
that
vCard
is
something
that
people
don't
love,
but
it's
going
to
because
of
all
of
the
ways
that
they're
used
in
end-user
implementations.
It's
going
to
be
very
hard
to
get
people
to
change,
just
as
it
is
to
get
hard
to
get
people
to
change
between
vCard
versions,
and
this
is
this
would
potentially
be
a
bigger
change.
R
S
F
Yeah
this
is
parrot
leave
the
topic
back
in
responding
to
that
history
has
shown
us
with
vCard
that
when
we
update
vCard
versions,
new
implementations
implement
the
new
versions
and
I
think
this.
Would
there
be
no
difference
here?
I
would
expect
new
implementations
to
go
in
this
direction,
but
we've
also
seen
that
old
implementations
are
just
never
update.
F
S
One
more
thing
is
that
I'm
also
not
so
sure
about
I
mean
we
card,
obviously
is
used
for
exchange
of
contact
information,
but
it's
not
necessarily
City
storage
format.
So,
while
I'm
not
too
sure
if
it
will
really,
if
we
really
see
that
much
difficulties
into
adopting
a
new
format,
but
that's
as
I
said
it's
just
guessing,
it
monitor.
R
A
N
So
what
I've
heard
is
there
is
some
interest
and
it's
not
clear
whether
this
is
going
to
be
suggestion,
whether
it's
go
to
collects
J
map
or
in
your
working
groups.
That's
to
be
decided,
but
I
think
there
is
still
a
question
of
how
many
people
are
interested
in
implementing
and
like,
for
example,
a
robot
you
mentioned
that
there
are
API
is
popping
up
that
are
trying
to
map
regard
to
JSON,
so
I
think
yes,
I!
Think
as
well.
You
know
sort
of
it's
another
input
buoyant
and
talking
to
people
about
this.
M
B
B
J
J
It
does
come
to
do
John,
Peterson
yeah,
so
I
mean,
like
I,
know,
for
a
project
we're
working
on
in
a
working
group.
We're
kind
of
shopping
for
a
way
to
do
be
card
with
JSON,
and
there
is
an
existing
are
see
that
his
standards
track.
That
describes
had
to
do
that
and
it's
okay
and
like
if
this
is
better
than
we
might
do
this
instead.
J
Yeah
we're
we're
looking
it
like
JSON
versions
of
e
card,
we're
like
okay.
There
is
an
existing
standards
track
thing
for
this
right
for,
like
Jake
zombie
carp,
and
if
this
is
like
a
better
ER
I
mean
I
was
just
looking
at
the
draft.
It's
kind
of
a
sketch.
It's
not
like
I,
can
tell
from
looking
at
the
draft.
If
you
know
this
is
gonna
turn
out
to
be
better,
then,
or
is
it
77095,
but
yeah.
J
No,
no,
it
doesn't
mean
anything
you
asked
if
there
are
people
interested
doing
something
in
this
space
that
you
you
cast
a
pre
white
net,
so
I'm
just
gonna
have
to
say
yes,
I
raise
my
hand
but
I
clarified
there.
There
are
applications
for
doing
B
card
with
JSON
and
like
if
this
turns
out
to
be
better
than
our
existing
standards
track.
Rfc
to
do
so,
then,
like.
D
N
A
A
L
O
L
I
know
a
show
hands.
Folks
in
the
room
who
saw
it.
Hey.
Have
you
folks,
folks
who
think
that
it
would
be
a
fit
for
presenting
in
this
room?
I
mean?
Maybe
you
got
everything
out
of
the
first?
Alright,
so
maybe
I'm
wrong,
but
I
thought
I'd.
Just
let
you
know
meet
you.
Oh
I
thought
those
the
second
session.
Oh
okay,.
C
A
T
T
They
are
based
on
the
idea
that,
in
order
to
secure
a
signature
or
a
data,
rather
you
have
to
abase
encrypted
base64
encrypted,
and
that
is
fine,
particularly
for
the
applications
that
sort
of
grew
up
with
jbs
like
ORF
and
open
ID,
but
for
information.
Centric
systems
like
the
one
I
working
with
it
didn't
fit
so
well.
I
was
involved
in
a
bank
project
where
we
had
signed
messages
for
layers
of
sign
messages,
and
for
that
it
means
to
have
base64
encoding
on
each
of
these
layers.
It
would
make
documentation,
debugging,
etc,
rather
horrible.
T
So
therefore,
I
started
to
look
on
that
possibility
of
making
a
canonicalized
version
of
JSON,
which
would
be
similar
to
what
we
had
in
in
XML.
However,
I
didn't
want
to
bring
all
the
complexities
of
XML
into
the
Asian
world.
That
would
be
counterproductive.
So
the
question
here:
is
it
possible
to
do
this
in
a
reasonable
way.
T
Canalization
can
be
done
in
slightly
different
ways.
One
is
to
do
it
completely
on
the
text.
Level
I
dropped
that
idea,
because
that
means
essentially
that
you
have
two
entirely
different
horses.
First,
you
parse
your
message
with
the
standard
parser
and
then
you
take
the
same
message
and
feed
it
to
a
can
organizer
that
fits
very
bad
with
the
existing
tool
chain.
The
idea
was
to
make
it
possible
to
integrate
into
existing
tools,
so
the
proposal
that
is
exist
as
a
draft
now
is
not
only
a
design
of
mine.
T
It
is
actually
design
of
several
people
that
have
brought
good
ideas
and
it
starts
with
characterization
of
the
native
JSON
elements
you
can
see
from
this
example.
What
you
get
is
that
you
order
properties,
remove
white
space,
normalize
numbers
and
also
make
strings
escape,
have
the
same
escaping
and
that's
necessary
to
be
to
be
able
to
do
signatures.
There
is
a
limitation
of
the
proposal,
and
that
is
that
the
number
jason
number
must
fit
into
an
ITV
7-5
for
double
precision.
T
That
doesn't
mean
that
your
applications
need
to
be
limited,
but
for
the
chemical
ization
you
need
now.
Some
people
think
that
colocalization
means
that
you
have
a
completely
unique
format,
and
that
is
a
possibility.
Unfortunately,
since
Jason
is
very
limited
type,
wise
people
stuff
things
into
strings
and
in
order
to
create
a
completely
canonical
form,
you
would
have
to
expand
the
springs,
the
the
embedded
data
types-
and
that
is
something
which
is
doable,
but
we
excluded
that
and
we
settled
on
the
team
settled
on
creating
a
hash
evaluation.
T
T
T
So
this
is
essentially
what
this
is
about
and
I'm
saying
that
what
this
is
is
a
started
as
a
research
project
to
see
if
it
is
actually
possible
to
do
chemical
ionization
of
json
and
it
is-
and
we
have
identified-
let's
say
the
quirks-
the
things
that
you
must
be
aware
of
in
order
to
use
it
for
some
people.
It
works
perfect
for
some
people
it
won't
be
a
good
choice
and
it
can
continue.
T
It
will
continue
or
with
solutions
that
will
expand
even
signature
containers,
because
if
you
have
a
can
go
back
here
to
the
first
here
you
see
a
signature
on
the
third
line,
a
JVs
detached
signature.
If
you
actually
have
chemical
ization,
you
can
even
make
the
signature
container
in
clear
because
it
can
use
the
same
system,
and
that
means
you
can
see
algorithms,
public
keys
etc,
which
is
pretty
nice.
U
A
V
Carson
Bowman
that
there
are
three
things
I'm
will
be
trying
to
say
that
see
we'll
get
them
all
together.
So
the
first
thing
is
what
this
is:
he
it
is
a
deterministic
mapping
from
a
data
model
object
through
serialization,
yes,
and
the
problem
we
had
with
Jason
is
that
the
originator
of
jason
has
steadfastly
refused
to
define
the
data
model.
So
what
we
actually
have
done
is
we
did
a
little
part
of
that
which
is
called
I
Jason.
Yes,
so
this
is
kind
of
half
of
the
way
going
toward
defined
data
model
Jason.
V
Yes,
whatever
this
book
turns
out
to
be
it's
going
to
define
a
data
model
that
kind
of
might
be
the
data
modification
or
something
from
we
don't
know
it
means
on
ideation,
actually
right
just
trying
to
say
this
cannot
be
done
without
you,
training
the
Jason
data
model,
at
least
as
it
applies
through
this
yes,
I-
think
that's
a
good
thing
to
do.
Number
one
number
two:
there
are
some
details
of
the
the
current
deterministic
mapping
that
you
proposed.
Okay,
that
I
don't
like,
but
I,
think
that's
not
relevant
from
this
discussion.
V
Okay,
so
I
wouldn't
put
in
utf-16
dependencies
in
there
and
things
like
that,
but
that's
separate
US.
Yes,
sir
discussion,
what's
the
use
case,
okay,
so
I
have
a
guy
sitting
beside
me
yesterday,
the
hackathon
who
was
using
that
language
talking
about
his
tools
always
putting
on
different
data
when
he
was
running
tests.
So
he
cannot
compare
the
data
between
different
permutations.
That's
a
very
good
use
case.
That's
what
I
would
like
to
have
this
form
comparing.
T
Output
data-
well,
that's
actually
outside
of
of
the
scope
for
this,
because
data
in
since
this
thing
putting
data
objects
inside
of
string
makes
its
it
creates
it
for
that.
You
need
another
specification
where
you
canonical
eyes
the
embedded
data
types.
That
means
that
the
canonical
eyes
must
know
what
data
types
are
embedded
in
strings.
V
D
V
That
we
have
recognized
that
a
specific
application
may
want
to
go
ahead
and
define
a
later
model,
its
application
data
model
and
be
a
deterministic
mapping
for
Jason.
Do
you
have
any
particular
application,
you're
thinking
of
because
I
don't
know
too
much
about
that?
Well,
we
have
tons
of
applications
in
the
constraint
space
that
has
descriptive
metadata
in
the
form
of
Jason.
So
we
are
interested
in
that,
but
it's
okay.
V
So
once
we
have
this
defined
Jason
data
model
level,
we
can
write
educational
standards
that
not
only
define
the
application
data
model
but
also
say
how
exactly
this
is
mapped
into
the
place
and
data
model,
and
we
are
solving
this.
The
problem
you
had
on
the
previous
slide,
I,
said
separately,
so
I
think
this
is
a
good
thing
to
have
and
I
have
at
least
one
use
case
now.
I
would
like
to
add,
but
it's
mainly
for
sake
this
I,
don't
like
the
idea
of
embedded
signatures,
so
yeah,
but
wiki
will
discuss
that
later
on.
R
Matthew
miller,
for
what
this
is
defining
it,
it's
it's
probably
okay,
I,
like
Carsten
I
I
mean
it
would
be
good
to
have
a
better
understanding
of
what
what
are
the
use
cases
were
trying
to
cover
here.
Awesome.
It's
like
hearts.
That
said,
I
mean
one
in
my
experience,
the
very
simple
data
types
in
JSON
get
you
only
so
far,
and
it
is
not
as
far
as
most
applications
need
to
go
things
like
sets
more
complex
data
types
it
gets.
It
gets
really
complicated.
R
I
Eric
rajala
so
trying
to
wrap
my
head
around
the
province
state.
So
when
we
designed
Jose
and
then
I
guess
some
seaboard.
All's
on
this
theory
we
splitted
canonicalization
because
experience
been
in
all
previous
short,
all
presidential
from
economical
ization
had
been
debacles
and
not
just
xml,
teasing
and
and
so,
and
so
we
explicitly
decided
that
there
wrapping
was
better.
I
There
was,
I
think,
some
thought
that
sharp
containment
between
search,
meaning
the
wrapper
and
the
and
the
thing
being
signed
was
good,
though
I
think
that
wasn't
a
she
particularly
well.
So
it
seems
to
me
that
you
want
to
backtrack
on
both
those
decisions
which
may
or
may
not
be
a
good
idea.
It
could
certainly
have
been
wrong,
but
I
guess
I'm
trying
to
understand
what
the
problem
statement
with
those
designs
is
and
as
far
as
I
can
tell
it
comes
down
to
you
don't
think
it's
legible.
It
comes
food.
I
T
I
T
T
Because
it
doesn't
make
sense
to
if
it's
not
necessary
to
basics
before
the
idea
was,
is
it
actually
necessary
and
I
found
out?
It
is
not
necessary.
If
you
put
some
constraints
on
your
Jason,
it
will
work
fine
and
you
can
keep
your
Jason
objects
in
Jason
and
you
can
embed
it
makes
the
messages
more
clear
with
Jas
you
have
the
messages
embedded
in
signature
containers
with
this
system.
You
rather
have
messages
that
are
signed,
that's
sort
of
the
opposite
and
it
for
people
that
are
interested
in
information
based
system.
T
I
H
V
That
cost
Norman.
It
would
maybe
just
like
to
add
that
specific
basics-
you
for
problem
of
course,
also
comes
up
in
other
environments
and
that's
one
of
the
things
that
SIBO
actually
solves.
So
for
me,
it's
not
so
much
a
problem
of
other
people
that
might
be,
but
again,
I
would
really
like
to
discuss
the
deterministic
civilization
part
here,
because
that
that's
the
thing
and
whether
that's
useful
for
security
or
not
I,
actually
don't
care
because
I
want
it.
For
the
other
users.
I
see.
T
I
I
think
it's
important
to
sharpen
this
question
about
whether
it's
security
or
not,
because
the
use
cases
are
different
and,
in
particular
your
two
respects
in
one
respect,
having
like
a
deterministic
serialization
for
protocol
purposes,
as
you
suggest,
requires
that
a
much
deeper
relationship
with
the
inner
content,
as
opposed
to
just
like
this,
is
a
string
that
happens
to
have
semantics
rerender
edge
and,
and
the
second
is
that,
if
we
screw
it
up
like
it,
doesn't
anything
up
for
non
security
purposes.
I
Maybe
it
doesn't
matter
so
much,
but
if
you
screw
up
for
security
purpose
is
actually
quite
bad,
so
I
think,
like
figuring,
exactly
we're
going
to
accomplish,
probably
like
actually
the
lower
part.
V
That's
women,
so
let
me
clarify
that
you
cannot
stand
the
dyes
standard
mapping
from
an
application
data
model
to
a
JSON
data
model
without
also
standardizing
the
equivalence
relationship
the
application
has,
and
this
kind
of
rules
out
doing
unless
you
are
embedded
in
the
application
I
mean
you
are
standardizing
the
application
when
you
are
standardizing
the
equivalence
relationship.
So
this.
V
Is
true,
it
is
really
an
application
issue,
so
we
really
have
to
start
from
the
JSON
data
model
and
get
all
that
about
application
data.
So
somebody
has
to
take
care
of
doing
deterministic,
encoding
of
application
data
into
the
JSON
data
model,
and
then
this
takes
off
and
does
the
deterministic
encoding
of
the
JSON
data
model
into
adjacent
street.
T
I
see
this,
what
you're
saying
is
a
superset
of
this,
because
this
is
sort
of
a
lower
form
of
canonicalization
that
enables
you
to
hash
json
messages,
while
you're
talking
about
a
full
canonicalization
that
requires
definition
of
each
of
embedded
data
types,
they
exact,
serialization
people
said
to
me:
why
not
go
for
seaboard?
You
know
you
don't
have
this
problem,
they
see
seaboard
as
the
solution
and
forget
about
Jason
and
I.
That
is.
V
V
Q
I
was
just
gonna
ask
her
if
we
defined
a
canonicalization
fallout
with
no
expectation
of
security.
Do
you
really
believe
that
it
would
never
be
used
in
in
the
security,
sensitive
context,
yeah?
Okay,
the
answer
was
not
for
the
record.
Well
yeah.
We
could
totally
put
a
big
warning
on
it,
but
then
the
new-fallen
would
allow
us
to
put
that
in
flashing
right
blink
tag.
Yeah
I
will.
G
Be
the
first
person
ignoring
that
warning,
but
not
the
last
selling
things
I
just
gonna,
say
I
mean
you
know
having
things
in
him
at
the
point
of
JSON
has
to
put
things
in
human
readable
form
right.
This
is
clearly
about
making
it
in
human,
readable
form
right,
and
there
are
some
times
where
that's
useless
and
there's
sometimes
was
advantageous
of
it
like,
for
example,
some
of
our
own
specs
and
IETF.
That
put
this
in
this.
G
Have
it
wrong
for
years,
and
no
one
noticed
because
the
you
couldn't
catch
it
on
casual
explanation,
I'm
thinking
of
some
of
the
stir
token
signatures
we're
just
wrong,
we
would
have
noticed
we
could,
if
they
weren't
base64-encoded,
so
I'm,
not
saying
that
that's
a
trait
I'm,
not
arguing
with
the
security
guys
that
this
would
be
better
or
worse.
I'm.
Just
saying
we
have
blown
this
mistake
on
the
other
side,
but
I
mean
the.
I
I
guess
this
is
probably
working
on
discussion.
Insects,
dispatch
as
well,
but
a
clear
separation
between
the
container
and
the
contained
is
actually
critically
important.
This
is
why,
like,
for
instance,
we've
moved
to
AE
algorithms
in
Macross
that,
across
across
the
IETF,
to
precisely
avoid
people
being
able
to
work
on
the
data
without
before
the
CRO
traffic
transporters
that
verify
it's.
Okay,
so
so
designing
a
system
that
makes
it
easy
to
ignore
occurred.
You
have
to
transform
and
undesirable,
not
desirable.
W
So
this
pew
Resnick
and
two
efforts
point
right
there.
This
is
a
trade-off,
so
one
of
the
things
that
happens
when
you
encode
the
whole
bucket
and
is
that
applications
implementers,
take
that
whole
thing
and
pass
it
off
to
the
library
code
for
the
security
stuff
and
get
out
whatever
comes
out,
and
there
are
times
where
that
is
exceedingly
inconvenient.
For
instance,
the
the
general
example
in
IMAP
is
I
can't
do
crap
without
taking
the
whole
s/mime
thing
and
hand
it
off
to
someone.
W
I
cannot
manipulate
any
of
the
internal
bits
and
give
the
user
experience
I
want
to
give,
even
if
I'm,
going
to
go
and
do
all
of
the
security
stuff
I've
got
to
download
all
this
crap
onto
a
device
that
maybe
is
too
small
to
do
that.
So
there
are
advantages
in
having
all
of
the
well
I
and
I.
Understand
that
the
point
is
you
shouldn't?
Do
that
says
the
security
person
and
I
get
that?
W
But
if
I'm
supposed
to
trust
where
the
implementer
I
can
at
least
present
the
user
experience
of
there's
a
part
here
and
I
can
tell
you
what
sort
of
part
that
is
and
put
the
appropriate
icon
and
then,
when
the
user
finally
clicks
on
it,
I
can
take
the
bucket
bits
and
hand
it
off
being
able
to
have
structure
that
is
protocol,
readable
and
then
the
security
inside
it.
And
maybe
this
goes
too
far.
But
having
that
structure
is
useful.
T
I
can
comment
on
that.
There
is
a
something
called
open
trust
protocol
and
this
a
group
called
tip
that
have
exactly
this
problem.
They
uses
Jay
bass
with
base64
encoding,
but
since
they
wanted
to
know
what
kind
of
object
is
coming
on
the
line,
they
had
to
add
an
artificial
Jason
container
outside
which
is
sort
of
ridiculous.
They
have
a
two
layer
structure
where
the
outer
layer,
of
course,
is
not
signed,
and
that
was
for
convenience.
They
want,
they
have
one
line
a
channel
and
they
can
send
different
objects.
T
I
A
B
A
F
B
A
C
A
X
X
Interpreter
services
in
different
countries
work
in
different
ways.
In
some
there
are
there
commercial
or
enterprises
that
have
government
funding
when
they're
used
by
authorized
people
and
they
compete
with
one
another.
So
there's
multiples
of
them
and
the
users
want
to
be
able
to
use
the
same
device
with
all
of
them
and
that's
not
the
way
it
works
now
when
they
changed
providers
they
have
to
change
devices
because
they're
all
proprietary,
so
the
goal
is
to
create
a
standardized
device
that
can
be
used
with
multiple
service
providers.
X
So
this
is
the
device
interface.
There
are
other
profiles
for
provider
to
provider
and
that's
not
in
scope
for
this
work.
I
do
have
a
draft
that
was
developed
in
another
environment.
That
is
the
bait.
We
hope
is
the
basis
for
it,
but
it
doesn't
have
to
be
that's.
Rosen
grew
0-0
and
we
do
have
a
room
reserved
10:00
to
11:00
on
Wednesday
to
get
going.
If
you
are
interested
and.
B
As
we
go
to
the
next
slide,
I
want
to
interrupt
you
for
just
a
second
and
let
people
know
this
is
actually
a
working
group
in
formation,
so
we're
actually
a
bit
past
the
normal
dispatch
process.
The
Charter
is
currently
an
external
review
and
I
think
it's
highly
likely
that
we
will
have
a
working
group
within
the
next
small
number
of
weeks.
So
what
you
can
kind
of
see
the
discussion
here
and
this
discussion
on
Wednesday
is
to
try
to
jumpstart
that
work.
So
so
keep
that
in
mind.
This
is
real
work.
X
X
X
X
You
know
there's
people
who
would
like
to
be
there,
who
won't
be
able
to
be
there.
I
will
see
if
I
can
arrange
something,
but
I
don't
think
we
can
work
on
it.
Well,
we're
coming,
okay,
so
the
Charter.
So
there's
these
instances
of
the
arrests,
video
relay
service
that
use
sip
and
it's
used
to
communicate
with
speech,
impaired
people
videophone
to
an
interpreter
interpreter
uses
a
phone
call
to.
We
can
use
any
other
mechanism
and
you
can
do
it
both
ways.
X
Just
for
your
interest,
there's
already
an
open-source
implementation
of
the
draft
that
I
have
that's
being
worked
on
and
they're
committed
to
implement
the
whatever
comes
out
of
this
work.
So
there
will
be
existence
proofs
of
this
work
when
we're
done
so
the
device
is,
could
be
a
purpose-built.
Video
phone
could
be,
you
know
a
box
or
it
could
be
code,
that's
downloaded
on
a
PC
or
something
like
that,
and
what
we
want
to
make
sure
of
is
that
all.
D
X
X
So
the
output
of
the
group
is
a
single
document,
which
is
the
profile,
and
it
includes
video,
real-time
text
and
audio
and
it'll
represent
our
current
thinking
on
all
of
those
things
we're
not
trying
to
not
reinvent
the
world
with
who
the
wheel,
we
will
reference
things
that
exists.
We
don't
really
want
to
build
anything
new
and
particular
we're
gonna,
try
and
reuse
a
lot
of
the
work
that
WebRTC
did
and
the
media
we're
not
anticipating
any
protocol
changes
at
all.
There's
no
gonna
be
no
protocol
work.
X
X
We've
talked
a
lot
about
the
interaction
of
this
in
WebRTC
we
backed
off
a
little
bit
on
on
it
in
the
Charter,
but
we
want
to
make
sure
we
would
like
to
make
sure
that
you
could
implement
this
client
by
using
a
web
RTC
implementation
so
that
the
server
created
the
SIP
that
this
profile
defines
that's,
not
an
explicit
goal.
It's
just
a
thing
we'd
like
to
figure
out,
and
at
any
rate
we
want
to
maximize
the
interoperability
between
WebRTC
implementations
in
this
again
we're
trying
to
reuse
the
work
not
to
invent
new
stuff.
X
So
that's
that's
the
goal,
so
there
is
there's
a
requirement
that
it
be
interoperable
with
emergency
services.
The
ITF
has
done
work
on
that
we're
going
to
include
that
work
which,
by
the
way,
is
being
implemented
in
the
United,
States
and
Canada,
and
a
couple
of
other
places
so
we're
going
to
reference
the
existing
eco
at
work.
A
D
X
Yeah
I
don't
want
to
get
I,
don't
want
to
get
constrained
by
the
word
profile,
but
it'll
be
up
to
the
workgroup
to
decide
how
much
of
the
stuff
that's
in
that
draft,
which
includes
things
like
provisioning
of
the
device
we
want
to
include.
But,
but
yes,
it's
really
a
little
bit
beyond
the
SIP
profile
because
it
does
get
into
provisioning
things
again.
We
don't
need
to
have
that
there.
The
current
draft
has
it,
but
it's
it's
not
the
most
important
part
of
it.
X
X
The
mechanisms
that
we
want
to
use
include
the
language
tagging
mechanisms
that
we
developed
and
slim
so
that
you
know
that
you've
got
a
American
sign
language,
video
on
one
side
and
English
audio
on
the
other
side.
So
if
you
wanted
to
translate
French
audio
to
English
audio
I,
think
the
what
we're
talking
about
is
going
to
work
just
fine.
X
L
Q
Thompson,
yes,
the
M
stands
for
that
in
the
middle.
Oh,
okay!
Yes,
it
is
a
man-in-the-middle.
Actually
yeah
I,
don't
see
a
lot
of
discussion
invented
the
Charter
and
I
only
have
the
the
type
of
contents
of
the
document
in
front
of
me
right
now.
But
how
much?
How
much
thinking
all
that
aspect
of
things
have
you
done.
X
X
In
the
US
there
are
multiple
competing
providers
and
there's
a
database
that
associate
Sat
Ella
phone
number
with
which
provider
is
the
the
current
provider
and
there's
an
express
way
to
select
another
one
in
the
signaling
so
that
you
can
do
this
thing
called
dial
around,
which
the
Charter
actually
does
reference,
which
allows
you
to
select
a
provider
expressly
from
one
end
or
the
other
from
the
originating
end.
So
the
originating
call
the.
X
Q
X
Z
Z
X
I
I
think
that
that's
it
is
something
that
we
have
completely
ignored
and
that's
wrong.
Sorry,
we'll
fix
it.
It
you,
you
really
do
want
to
know.
I'm
now
worried,
I'm,
gonna,
be
I,
mean
I'm
now
inventing
mechanism
and
then
I
said
I
wasn't
going
to
do
any
protocol
mechanisms
and
so
like
that's
an
issue
but
I.
That's
why
we
have
these
things,
that's
why
we
discuss
it
and
it
and
we
knew
when
we
brought
it
into
the
full
process
that
we
were
going
to
get
issues
like
this.
So
thank
you.
G
I
mean
if
you
do
end
up
inventing
new
protocol.
Dinis
it'll
never
be
implemented
across
any
of
the
devices
outside
of
the
center,
so
it
will
I
mean,
as
you
well
know,
it
won't
deploy.
So
I
mean
I
love
your
current
drop.
It
seems
to
be
as
secure
as
you
can
possibly
make
it
yeah
and
the
limits
of
what
will
actually
deploy
yeah.
R
X
AA
X
X
X
We
do
note
that
the
interface
between
providers
has
to
work
if
1:1,
if
you
have
a
point-to-point
call
and
one
is
on
one
provider
and
others
on
another
provider
than
the
two
providers
have
to
have
an
interface
that
works,
but
that
is
out
of
scope.
There
is
a
document
that
does
that
for
the
providers,
on
the
other
hand,
if
we
go
and
mess
with
the
Codex,
it
may
affect
that,
and
we
understand
that
next.
X
This
is
the
whole
Charter
in
one
page.
It's
exactly
the
same
text.
I
just
wasn't
sure
which
one
would
be
easier
to
deal
with
just
go
right
on
I
put
up
here
the
outline
from
the
draft.
Just
so
you
know,
what's
in
that
draft,
I
I,
don't
need
to
read
it,
it's
just
giving
you
the
idea
of
what's
in
there.
X
It
deals
with
security.
It
deals
with
again
a
few
things
that
get
a
little
bit
beyond,
because
it
includes
car
Daffy
and
a
couple
of
things
for
contacts
and
the
provisioning
thing
and
mail
waiting.
So
those
are
the
things
that
are
in
the
in
the
draft
as
it
exists
now,
but
again
will
be
subject
to
contributions
and
discussion
in
the
workgroup
next
I
think
that's
the
last
right.
So
this
is
the
status
that
we
said.
We've
got
this
Charter
discussion
going
underway.