►
From YouTube: IETF92-PRECIS-20150325-1520
Description
PRECIS meeting session at IETF92
2015/03/25 1520
A
B
D
D
B
E
A
D
Framework,
as
is,
is
done
the
and
we
have
Peter,
was
prepared
a
few
slides
on
the
the
last
two
documents.
I
think
what
we
have
met
new
ler
Miller
that
as
submitted,
is
a
shepherd
review,
but
then
a
nickname
the
shepherd
doesn't
sent.
This
is
right
up.
So
that's
one
missing,
I!
Guess
from
the
process
point
of
view.
C
E
E
D
So
this
is
what
Peter
prepared
Peter
sent
Andre
and
I
since
he's
not
here
and
that's
my
fault.
I
didn't
prepare
a
channeling
audio
from
him
that
I
should
have,
but
so
I'll
do
with
the
slides,
so
framework
done
a
proof
for
fabrication.
A
registry
is
done,
the
code
points
the
table
are
done
and
Peter.
Where
is
the
reviewing
the
table
to
make
sure
that
all
the
cool
points
are
okay
and
then
we'll
send
its
ok?
Then
they
will.
B
Yeah
so
basically,
a
relative
little
disc
has
changed
since
Honolulu.
The
username
profile
got
split
into
two
for
case-insensitive
case
insensitive
and
then
basically
the
document
was
brought
in
sync
with
the
framework,
changes
and
dates,
but
for
the
most
part
I've
well,
it
is,
it
is
done.
We
believe
it's
ready
for
working
group
for
I
TFS,
Cole
I
was
just
talking
to
Barry
I.
Think
what
we'll
ask
for
a
couple
of
apps
Directorate
reviewers
for
this?
That's
probably
one
way
of
getting.
You
know
more
of
yours.
D
Nickname
somewhat
similar,
updated
and,
from
the
other
address
working
group
last
call
feedback
and
ready
to
go
for
ITF
last
call
xmpp.
This
has
been
X,
MPP,
sweat,
2061
22.
This
is
referring
to
these
is,
has
been
working
group
last
call
in
the
too
well
in
the
XP
XMPP
working
group,
and
then
in
you
know
simultaneously
in
pracy,
and
we
think
it's
going
ready
for
ITF.
Last
call.
However,
this
is
done
on
the
XMPP
side,
so
it's
more
for
your
information,
I
guess
so.
I
just
I
have
a
question
on
this.
F
F
According
to
the
discussion
in
IT
90s,
the
mappings
document,
where
moved
to
working
group
last
call
after
framework
document,
I
Kevlar
score
is
done
so,
but
I'm
very
sorry,
I
had
not
realized
too
I.
I
had
not
finished
it
to
revise
the
mappings
document,
and
so
the
map
current
status
is
current
status
of
the
mappings
document
is
expired,
so
I'm
I'm
revising
the
mappings
document
to
quit
greatest
framework
document.
We.
F
F
D
E
G
Andrew
sullivan
on
the
mapping
document
on
this
is,
maybe
anticipating
a
little
bit
too
much
the
next
agenda
item.
But
you
know
we
just
heard
in
the
in
the
lucid
Boff
suggestion
that
one
of
the
directions
that
we
could
end
up
going
if
we
don't
have
a
lot
of
we
know
how,
if
we
don't
have
success
with
a
property,
is
essentially
a
significant
mapping
document.
G
Probably
a
significant
bit
of
advice
now,
I'm,
not
sure
whether
it's
the
same
mapping-
and
that
is
what's
not
clear
to
me
so
I
I
mean
I-
don't
actually
have
an
opinion
on
which
way
to
go.
But
it
seems
to
me
that
one
of
the
things
you
could
ask
yourself
is
whether
it
would
be
better
to
see
how
that
proceeds
in
order
to
proceed
with
the
mapping
document
or
to
publish
this
and
then
do
another
one
later.
H
Peake
Resnick
I
mean
I.
Think
the
more
important
point
is
I'm
guessing
it's
very
likely
that
the
mapping
kind
of
stuff
we
would
do
to
deal
with
the
lucid
issues.
Even
if
we
get
to
that
point,
are
going
to
be
very
different
from
the
kind
of
mapping
that's
being
described
as
sort
of
a
more
general
here's,
the
kinds
of
things
you
could
do:
mapping
wise
they're
dealing
with
very
different
looking
problem
spaces
I
think
they
will
of.
H
D
G
C
D
So
what
will
I
think
we
will
review
when
the
doc
the
new
version
comes
out
of
the
document
and
see
you
know
altogether?
If
you
need
to
do
something
more
or
less
depending
segue
to
the
placeholder
of
will
do
we
need
in
proceeded
to
think
about
you
see
this
is
or
what
what
happens
in
a
couple
of
years,
the
last
two
hours
we
know
what,
but
what
would
happen,
but
maybe
11
question
to
the
ideas
is
especially
the
right
own
to
to
start
this.
This
you
know,
preview,
see
the
work
or
not
or
doesn't
matter.
B
C
C
E
I
guess
the
summary,
and
so
Andrew
went
through
the
the
issues
and
then
proposed
five
possible
directions.
We
could
take
to
deal
with
them.
The
issue,
of
course,
is
how
to
deal
with
new
characters
that
come
that
changes
in
the
character
set
from
Unicode,
that
that
break
the
situation,
that
we
expect
and
we
looked
at
the
five
directions
and
added
a
sixth
and
then
took
a
hum
and
as
I
was
as
I.
Remember
it.
E
The
direction
that
we
decided
was
best
was
to
try
to
work
with
the
Unicode
people
to
come
up
with
a
new
property
on
characters
or
a
new
set
of
properties
on
characters
that
we
could
synthesize
a
our
prop.
A
derived
property
from
that
would
help
us
and
or
create
an
NF
I
normalization
format
for
IETF
that
again
well
for
identify
as
whatever
that
would
come
up
that
that
would,
that
would
have
to
be
something
we'd
have
to
work
out
with
Unicode
as
well,
and
that
the
back
the
back
up
of
that
is
to
say.
E
G
Think
the
only
thing
that
I
would
add
to
that
is
it.
It
wasn't
clear
at
least
to
me,
but
that
could
just
be
that
my
brain
is,
I
think
I
think
it
shriveled
a
couple
hours
ago
on
that
that
we
have
an
understanding
of
what
kind
of
property
exactly
it
would
be.
So
there
is
a
potentially
very
serious
problem
that
we
know.
We've
got
something
that
we
want
to
describe,
but
we
don't
know
what
it
what
that
description
is,
and
we
could
wander
around
in
the
dark
for
a
very
long
time.
G
And
then
I
thought
about
well
look
at
the
tremendous
energy,
and
you
know,
output
that
happened
in
this
working
group,
how
we
managed
to
get
everything
going,
and
that
worries
me
a
little
bit
because
if,
if
we
don't
get
the
engagement
from
the
people
who
are
going
to
consume
this
in
order
to
sort
of
figure
out
and
hammer
out
exactly
how
we're
going
to
how
we're
going
to
work
on
that,
I
don't
think
we'll
get
the
property.
I.
Think
we'll
end
up
with.
G
You
know
just
a
lot
of
speculation
and
and
then
we
won't,
because
my
sorry
to
ramble
here,
I
haven't
formulated
this
very
well.
My
my
interactions
with
people
who
are
active
in
Unicode
suggests
to
me
that
there
are
people
who
are
sympathetic
to
the
idea
that
we
need
I
mean
there
are
people
who
are
not
sympathetic,
but
then
there
are
people
who
are
sympathetic
to
the
idea
that
maybe
we
need
a
property
or
two
here,
but
they
want
us
to
describe
something
that
is
clear,
distinct,
distinguishable
and
and
sort
of
algorithmic.
G
H
This
Pete
again
I'm
much
more
bushy
tail
than
andrew
is
so.
Let
me
see
if
I
can
lay
out
why
quickly.
First
of
all,
the
end
of
the
session
I
heard
a
lot
of
people
say
well
the
work
that
we
would
invest
at
least
the
upfront
work.
We
even
invest
in
trying
to
work
with
the
Unicode
consortium
and
get
them
what
that
property
means
is
pretty
much
equivalent
to
the
work.
We
would
invest
to
try
and
come
up
with
a
set
of
warnings
or
bundling
rules
and
everything
else
that
goes
with
the
other
choice.
H
So
it's
not
wasted
work
in
either
event,
and-
and
some
of
it
is
agree,
I
agree
hard,
but
that
that
works
going
to
have
to
be
done
one
way
or
the
other
the
other,
but
that
I'm
a
little
more
saying
when
than
Andrew
about
is
with
regard
to
the
Unicode
consortium,
simply
because
I
think
the
work
that
we
have
to
do
here
is
not
stuff
that
we
sorry
guys.
One
meeting
place
is
not
stuff
that
we
can
possibly
do
on
our
own
right,
figuring
out
what
that
property
is,
and
what
is
even
plausible
to
do.
H
Is
something
that
is
going
to
be
an
interactive
process
with
Unicode
that
we're
going
to
have
to
say?
Is
this
a
distinguishable
thing
that
you
could
come
up
with
and
part
of
figuring
out
what
it
is
that
we're
missing
is
going
to
be
part
of
that
conversation?
I
think
that
conversation
is
worth
having
one
way
or
the
other
and
I'm
going
to
lose
the
thread
here,
because
my
brain
is
about
as
mushy
as
Andrews
the
oh.
H
The
other
thing
that
he
said
was
we're.
Gonna
have
to
get
the
people
who
are
wanting
to
use
the
profiles
again
involved
in
this
conversation.
I
think
that's
actually
only
marginally
true.
If
it's
true
at
all
I
think
we
went
through
the
process
and
decided
at
the
particular
compromise
we
made.
Okay,
these
are
characters
that
are
distinguishable
within
script
and
therefore
you
know
and
have
distinguishable
properties
and
therefore
okay,
to
use
as
identifiers.
So
we
made
a
category
error.
H
We
didn't
get
what
we
thought
we
wanted,
but
I
don't
think
we
have
to
go
through
the
process
of
asking
all
those
implementers
again
what
they
want.
I
think
we
have
to
figure
out
with
the
unicode
consortium
whether
we
can
actually
instantiate
what
we
thought.
We
wanted
with
properties
that
they
could
provide
so
I'm,
not
clear
that
we
actually
have
to
go
back
and
redo
all
the
work
that
we
did
here.
I,
don't
even
think
we
have
to
do
very
much
of
it.
E
I'll
push
back
on
the
penultimate
thing
that
you
said
that
so
getting
getting
anybody
else
involved
in
this.
Getting
the
consumers
of
this
stuff
involved
is
a
non-starter
agree
with
that.
No
one
except
a
handful
of
people
want
to
have
anything
to
do
with
this
kind
of
sausage,
even
if
they
want
to
eat
the
sausage,
but
we
have
here
a
specific
instance
of
something
that
breaks
our
assumptions
and
makes
us
want
to
do
this.
E
The
ultimate
properties
we
want
is
well.
This
is
this
character.
That's
safe
to
use
an
identifier
is,
but
that's
too
generic.
The
trouble
is
that
the
next
time
Unicode
changes
something
they
may
change
a
different
aspect
of
things
that
causes
the
characters
to
be
unsafe,
to
combine
with
other
characters
and
identifiers,
and
so
this
may
be
an
iterative
process
getting
either
getting
different
properties
or
getting
the
same
property
applied
differently
in
the
future,
when
Unicode,
7.2
or
eight
point
0
or
whatever
comes
out,
and
that's
the
part
that
I
worry
about.
D
C
C
I
C
I
Sorry,
as
a
consumer
of
these
rules,
I
can
express
at
least
the
particular
use
case
that
I
am
looking
at
and
it
may
actually
turn
in
to
a
way
of
describing
this
property.
This
mythical
property
that
we're
talking
about,
which
is
the
idea
that,
when
I
go
out
and
I
fetch
a
public
key
for
a
particular
email
address
and
I
get
back
a
public
key
that
has
a
slightly
different
identifiers
on
it
than
what
the
user
input.
I
So
if
a
user
types
in
Zurich
with
or
without
the
dots
over
the
you,
presumably
it
should
match
something
now
when
we're
talking
about
a
property,
maybe
that
is
a
good
way
of
describing
it
precisely
because
if
we
compare
this
to
how
when
we
do
a
search
and
again
I'm
an
American,
all
I
speak
english.
So
I'm
going
to
use
examples
from
english.
I
And
if
you
have
this
property
that
is
expressed
programmatically,
then
you
can
conduct
the
search
first
for
the
exact
normalized
string
that
was
provided
and
if
you
get
a
match,
return
it.
If
you
don't
get
a
match,
you
can
also
write
the
protocol
spec
such
that
the
server
would
presumably
conduct
a
second
search
where
this
property
is
disabled
or
turned
on
or
what?
However,
you
want
to
express
it
would
locate
the
possibility
of
an
equivalent
match
and
be
able
to
suggest
hey.
I
I
But
that's
basically
where
I
came
to
I
guess
the
only
other
thing
I'd
close
out
my
long-winded
ramble
with
is
by
saying
that
when
I'm
developing
a
system,
I
need
to
be
cognizant
of
a
situation
that
me
and
Pete
talked
about
where
some
systems
may
want
to
allow
a
situation
where
you
have
two
users,
one
that
spells
Erick
with
the
regular
you
and
one
with
the
dots
over
it.
And
some
systems
may
want
to
make
those
mutually
exclusive
where
you
could
have
one,
but
not
the
other.
I
G
Andrew
Sullivan
and
I
will
channel
myself
first
and
then
John
when
I
was
in
high
school
I
was
in
a
band
and
we
had,
among
other
things,
a
song
called
I
hate,
Motley
Crue,
the
lyrics
of
which
were
I
hate,
Motley,
Crue,
I
hate,
the
dots
above
the
you
and
I
didn't
know
that
lo
these
many
insider,
this
is
gonna,
be
chilly
that
I'm
the
Holy
anyway.
On
so
to
my
response
to
Jim's
question,
do
we
understand
this
is
essentially
giraffe?
Handlebar
bicycle?
No,
we
don't
know.
G
John
had
something
a
little
bit
more
saying,
which
is
essentially
depends
on
what
you
mean
by
we
and
understand
so
I.
Think
that
that's
fundamentally
what
the
what
the
work
of
that
we
would
need
to
do
under
loose.
It
is
on
that's
not
why
I
got
up
here,
though.
I
got
up
here
to
respond
to
two
berries
remark,
which
was:
if
you
Nico
changes,
this
again
stuff
could
could
shift
on
us
again.
I
I
think
we
want
to
be
very
careful
here.
Único
didn't
actually
change
anything.
They
had
a
system
that
just
didn't
work.
G
The
way
we
thought
it
did
and
what
they
did
is
they
added
a
code
point
under
a
set
of
conventions
and
principles
that
we
did
not
fully
grasp.
Now.
There
is
reason
to
suppose
that
no
English,
speaker
of
sufficient
technical
background,
could
have
read
the
definitions
in
the
unicode
standard
prior
to
70
and
understand
that.
G
But
it
appears
now
in
retrospect
that
there
was
a
fairly
consistent
set
of
principles
going
on
there,
and
maybe
it
was
just
a
bug
in
the
in
the
way
it
was
written
down
finally
to
channel
something
else
that
John
was
saying
which
is
on
a
different
topic.
The
Zurich
case
doesn't
involve
lucid
issue
and
is
very
a
fundamental
to
what
is
supposed
to
be
doing.
So
it's
it's
really
quite
quite
a
different
case.
In
particular,
normalization
won't
help
with
that
either,
but
it
turns
into
a
very
tricky
language,
sensitive
problem
and
the
language.
E
Clarify
in
what
Andrew
just
said,
I
I
did
this
is
Barry.
I
did
not
mean
that
unicode
had
changed
something
or
that
it
was
their
fault.
But
what
I
meant
to
say
is
that
in
the
future
there
might
be
some
other
aspect
of
how
they
make
decisions
that
we
were
equally
unaware
of.
Now.
That
would
trip
us
up.
H
H
In
in
your
implementation
and
something
you
really
want
but
play
see,
the
the
kind
of
property
that
we're
talking
about
is
strictly,
if
you
want
to
use
these
things
purely
as
identifiers
without
fuzzy
matching
that
you
want
all
of
the
false
positives
to
go
away,
and
once
we
get
into
the
fuzzy
matching
stuff,
we've
got
a
whole
different
problem.
So
we
do
want
to
separate
that
out.
We're
working
on
the
property
for
identifier
that
are
not
going
to
be
used
in
fuzzy
matching.
J
J
So
I've
got
limited
personal
experience
and
to
me
the
little
dots
on
the
letter
are
just
like
crumbs
on
the
page,
a
little
bit
of
dirt
I'd
brush
them
away
because
they
don't
matter
but
to
other
people,
they're
really
important,
and
we
need
to
not
make
the
mistakes
if
people
in
another
culture
were
having
this
discussion
about.
English
and
I'll
just
use
this
as
an
analogies,
they
might
say
that
letter
L
and
the
L
with
a
line
through
it.
J
Well,
they're
kind
of
the
same
thing,
but
they'll
be
the
line
to
it
is
a
tee
and
to
us
to
map
those
as
the
same
identifier
would
be
crazy
and
polish
has
an
L
with
a
line
in
it,
except
that
L
is
slanted
and
it's
pronounced
like
a
W
and
that's
not
a
tea
or
an
L.
So
our
intuition
that
it's
obvious
that
uppercase
and
lowercase
a
are
the
same
thing
is
a
very
dangerous
intuition
to
carry
on
to
other
scripts
I.
I
Was
just
going
to
say,
I
think
you
made
an
important
point
and
it
made
me
realize
that
what
this
problem
really
is
isn't
understanding
the
specific
languages,
because
we
have
matching
rules
that
are
specific
to
a
script
already.
The
problem
is
that
we're
building
systems
that
cut
cross-language
and
locale
boundaries,
where
we've
got
us
users
talking
to
people
in
Europe
that
speak
a
completely
different
language
and,
like
you
pointed
out,
have
their
solid
Oregon,
have
very
different
ideas
about
what
should
match
and
what
shouldn't
and
that's
where
the
problem
lies,
because
a
u.s.
I
D
D
I'm
not
sure,
there's
a
clear
conclusion,
but
it
was
a
placeholder
in
case
we
had
a
here.
You
know
work
item
for
a
preseason
last
item.
I
would
like
to
talk
to
is
something
that
has
been
has
been
discussed
a
bit
during
the
working
group.
Lunch
today
was
so
one
of
the
deliverables
of
this
working
group,
so
these
are
below
here.
Let
me
see
if
I
can
improve
the.
D
D
D
E
E
C
E
The
on
the
profiles,
I,
I,
think
what's
more
like
that,
probably
not
going
to
get
profiles
coming
in
tomorrow,
right
they're-
probably
going
to
come
in
a
while
later
if
they
do
so,
I
be
more
happy
to
charter
up
a
new
working
group
to
do
the
profiles
that
come
in
later,
but
on
the
advice
document,
whatever
yeah.
If
you
can
scare
up
enough
people
to
get
some
energy
go
for
it,
otherwise
I
don't
see
doing
it
in
the
current
working
group
will
work.
D
E
Peter
saint-andre,
the
best
way
to
work
on
the
advice
document
might
be,
might
be
to
provide
advice
through
expert
reviews
of
profiles
and
learn
what
the
topics
are.
That
would
need
to
be
covered.
So
I
guess
that's
by
way
of
saying
that
we
should
wait
on
doing
that
too.
Until
we
have
more
experience
with
the
existing
profiles
and
the
new
ones
that
are
requested.
I.