►
From YouTube: IETF103-SECEVENT-20181107-0900
Description
SECEVENT meeting session at IETF103
2018/11/07 0900
https://datatracker.ietf.org/meeting/103/proceedings/
C
E
B
A
B
H
H
Are
we
identifying
them
by
a
phone
number
and
in
some
cases,
that
identifier
is
more
than
one
value
like
to
issue
a
subject
which
might
be
different
from
the
issuer
of
the
token
itself,
or
we
need
to
have
some
additional
metadata
and
they're
explaining
how
to
interpret
the
value
if
we're
talking
token
hashes?
So
here
we
are
the
solution.
This
spec
provides
is
defining.
Subject,
identifier
types,
it's
a
schema
that
explains
how
to
express
a
subject
identifier
and
what
the
properties
in
that
identifier
mean.
H
H
Along
with
the
type
we're
then
defining
a
subject,
identifier
as
a
JSON
object,
subject,
identify
err
has
a
type
that
goes
back
to
one
of
these
and
then
it
the
JSON
object
contains
claims
based
on
what
is
defined
by
the
subject
identify
our
type,
so
example
is
helpful.
Here's
an
example:
event
from
risk
is
the
account
disabled
event.
H
The
bolded
part.
There
is
the
part.
That's
coming
from
this
specification
here.
The
risk
definition
for
account
disabled
says
that
it
has
a
subject
claim
in
its
its
payload,
and
the
type
of
that
subject
claim
that
subject
claim
is
a
subject
identifier
in
this
case.
It's
a
subject,
identifier
using
the
issuer
and
subject
type.
H
Where
are
we
at
with
this?
We
just
put
out
o
right
before
cutoff
for
for
this
meeting,
we've
got
use
cases
for
in
risk,
I'm,
not
aware
of
anybody
else.
Who's
talked
about
adopting
this
or
there's
been
some
people
saying
hey.
This
is
a
good
idea,
but
I'm
not
aware
of
anybody
else,
any
any
other
specs
are
going
in
and
putting
it
in
and
then
Google
and
Amazon
both
have
implementations
for
this
in
progress
as
part
of
the
work
we're
doing
for
for
risk.
H
So
big
change
from
0
to
0-2
was
we
added
semantics
for
each
of
these
subject,
identifier
types
that
was
the
big
feedback
in
Montreal
was.
We
should
be
clear
on
what
these
mean
so
I
took
a
stab
at
that
not
sure
I,
like
the
CB
values,
I've
provided
so
I
kind
of
want
to
go
over
that
here
with
everybody
and
get
some
more
feedback
on
those.
So
let's
look
at
this.
H
If
you
look
at
the
document,
I
left
one
of
the
types
off
here-
I
ID
token
claim
and
we'll
get
to
that
later,
but
if
we
focus
on
email,
phone
and
issue
or
subject
as
three
of
the
types
defined
in
the
document,
if
you
look
at
the
document,
this
is
what
it
provides
is
the
the
meaning
for
each
of
those.
It's
just
a
user
account
oriented
definition.
H
H
I
In
the
right
direction,
like
question
about
phone
I
mean
I,
can
sort
of
saw
really,
if
you
want
some
sort
of
I
can
sort
of
see
the
semantics
of
the
Americas.
That's
how
you
typically
use
email
for
account
recovery,
but
do
you
use
phone
in
the
same
way
right,
and
what
does
communication
mean
in
this
way?
Are
we
in
this
sense
right?
Are
we
talking
about
SMS
phone
calls?
What
right
there
it?
The
semantics
doesn't
seem
as
clear.
A
That's
used,
among
other
things,
an
open
idea
to
connect
discovery,
webfinger
and
other
things,
and
you
have
plenty
of
account
identifiers
that
are
not
email
addresses
so,
for
instance,
I'm
self
issued
at
Twitter.
You
know
there
may
be
an
email
address
associated
with
it,
but
that's
not.
The
primary
key
did.
A
H
B
A
A
H
B
H
What's
in
the
spec,
what's
in
the
draft
right
now
is
kind
of
defining
the
actual
subject
itself,
as
this
is
a
user
account,
the
proposed
text
shifts
what
we're
defining
we're,
no
longer
being
specific
about
the
nature
of
the
subject,
but
we're
instead
talking
about
how
do
these
identifiers?
How
do
these
values
relate
to
that
subject,
which
is
a
bit
of
a
different
shift,
so
I
liked.
A
The
word
identified
in
the
previous
slide
better,
so
go
back
to
the
current
slide.
I
would
change
it
to
subject
that
is
identified
with
the
specified
email
address
and
subject
that
is
identified
with
the
specified
phone
number
that
mirrors
the
audience
language
in
job
and
sam'l.
When
you're
saying
an
entity,
that's
identified
with
such-and-such
an
audience.
Oh
all,
righty.
Thank
you.
Yeah.
H
Happy
to
get
the
feedback
one
thing
I
think
we
I
was
trying
to
capture
with
this
was
communicated
and
we
can
discuss
on
list.
If
this
is
the
right
idea
is
that
email
and
phone
should
be
actual
functional,
email
address
and
phone
number,
not
something
that
is
just
formatted
to
look
like
one.
That's
the
the
intention
here,
if
there's
better
language,
to
use
for
that
happy
to
get
feedback
on
that
and
change
that,
but
that's
the
intent
behind
the
use
of
communicated
there.
K
G
Original
semantic
definitions
are
much
more
specific,
much
more
concrete,
and
so
whether
the
correct
or
not,
they
actually
define
semantics
with
the
new.
The
new
stuff
is
just
wish.
She
was
saying
my
mind
and
then
to
the
Twitter
thing:
I
think
that
would
be
covered
by
issue
a
subject
so
I,
don't
think
why
not?
Why
not?
Twitter
is
the
issue
and
subject
as
self
assured.
G
G
I
agree,
given
that
some
people
actually
use
Twitter
for
account
verifcation,
specifically
key
base.
Does
that
I
think
we
need
something
that
would
cover
that
sort
of
thing
and
then,
on
the
bigger
question
a
few
slides
ago,
you
had
uniquely
identifies
I,
don't
think
the
identifier
should
uniquely
identify
a
subject
and
that's
actually
a
key
point.
G
We
pick
and
I
talked
about.
It.
I
gave
the
example
of
I'm,
giving
my
wife's
phone
number
as
verification
or
secondary
or
tertiary
verification.
For
my
account
you
should
be
sending
all
of
my
identifiers,
but
some
of
them
may
not
be
unique
to
me
and
that's
fine
and
the
receiver
will
will
decide
what
to
do
with
them.
I
think.
H
C
C
The
example
you
just
gave
with
the
recovery
email
address
is
a
good
example
by
an
email
address
can
function
as
an
identifier
or
as
an
address
in
case
of
a
recovery.
It's
used
as
an
address.
It
doesn't
uniquely
identifies
your
account.
You
typically
use
the
email
address
as
an
identifier
in
a
way
that's
unique,
so
you
can
have
implementations
where
a
user
account
has
identified
by
email
address
and
the
same
address
can
share.
It
can
be
shared
among
user
accounts
for
account
recovery.
C
C
D
C
G
G
G
H
Okay,
so
it
sounds
like
that's
something
we
want
to
take
up
on
the
list
and
get
broader
feedback
on
sort
of
unique
or
not,
and
then
also
the
question
of
the
semantics
I,
like
the
idea
of
bringing
identified
by
back
into
it.
I
think
that's
appropriate
identified
with
yes
yeah
happy
to
receive
some
text
for
that
and
cool
great
all
right.
Let's
move
on
so
you
recall,
I,
said
I
left
off
one
of
the
types
for
that
on
the
semantic
slides.
That
type
is
ID
token
claims.
H
The
use
case
for
this
type
is
where
we
have
a
open
ID
connect,
client
that
could
be
using
any
of
issuer
subject
or
phone
number
or
email
as
the
claims
that
they
understand
they're
receiving
an
ID
token
from
an
Opie
and
well.
We
would
like
them
to
be
always
using
a
issuer
in
subject.
They
might
not
be,
they
might
just
be
matching
based
on
email
address.
So
how
do
we
communicate
with
that
client?
If
we
don't
necessarily
know
what
which
of
the
identifiers
is
we've
given
them
they're,
actually
using
the
so?
H
The
the
few
problems
with
this
one
is.
It
makes
the
semantics
of
that
really
weird,
like
you're
sort
of
have
to
start
defining
it
as
well.
In
the
case
where
this
claim
exists,
then
it
means
this
or
it
means
that
it's
also
duplicating
definitions
for
other
types.
Now,
you've
got
definitions
for
an
email
claim
in
a
subject,
identifier
type
kind
of
in
both
places,
both
in
the
email
type
and
even
the
ID
token
claims
type,
and
it's
arguably
too
limited
in
that.
H
You
can't
use
it
to
express
that
you
have
multiple
emails
for
the
same
subject
or
multiple
phone
numbers
for
the
same
subject:
you're
locked
into
one
of
each
of
those.
Those
possible
types
so
alternative
that
I
am
proposing
here
is
an
aliases
type,
which
is
basically
a
container
for
a
list
of
subject,
identify
er
types
as
excuse
me,
a
list
of
subject
identifiers.
H
So,
instead
of
having
this
I
strictly
defined
in
terms
of
which
types
it
can
contain,
this
is
arbitrary.
You
can
put
any
number
of
different
subject
identifiers
of
different
types
in
it.
The
constraint
is
that
they
all
have
to
resolve
to
the
same
subject.
They've
all
got
to
be
identifying
the
same
subject
advantages.
We
have
a
lot
more
flexibility
here.
H
The
semantics
are
a
lot
clearer,
we're
reusing
types
that
get
defined
elsewhere
and
we
can
automatically
start
using
types
new
types
as
they
are
defined
elsewhere,
and
it
does
this
without
introducing
any
complicated
for
people
who
don't
need
to
care
about
it.
If
you
don't
care
about
aliases
and
you
just
ignore
it,
so
an
example
of
what
this
would.
What
this
could
look
like
is
here
here,
we're
just
showing
the
subject
type:
we're
not
showing
the
set
event
definition
around
it.
G
H
D
Right
cool,
so
I
didn't
stay
up
late
for
nothing
all
right,
so
anyway,
I
had
a
question
about
this
aliases
construct.
What
I
was
wondering
about
this
is
that,
where
we,
this
is
getting
a
little
bit
too
into
the
weeds
of
the
semantics
of
the
term
aliases,
but
to
me
that
implies
that
there
is
a
primary
identifier
and
then
a
set
of
secondary
tertiary,
etc.
So
importantly,
that
there's
some
sort
of
preferred
order
of
dereferencing
that
I
should
be
doing
to
all
of
these
identifiers.
D
H
The
intention
here
isn't
to
try
and
express
or
enforce
a
particular
hierarchy
of
identifiers.
The
reason
I
chose
the
word
aliases
is
because
it
makes
it
clear,
to
my
mind,
at
least,
that
all
of
these
identify
the
same
thing
that
this
isn't
something
where
you
can
throw
a
bunch
of
identifiers
in
for
a
bunch
of
different
subjects
and
all
of
a
sudden,
you
have
a
batch
security
event.
Token,
like
it
doesn't
work
like
that,
all
right.
So
when
it.
D
D
Is
really
good,
I
think
that
that's
very
important
that
this
all
wrapped
down
to
the
same
person
or
entity
whatever,
but
when
I
was
what
came
to
mind
is:
could
this
instead
be
a
parameter?
That's
added
to
all.
Subject
types
so,
basically,
along
with
subject
type,
you
have
aliases,
which
is
other
subjects
as
opposed
to
it
being
its
own
subject,
type
I
see.
H
D
B
In
the
open,
ID
Connect,
though
they
you
know
it
sort
of
prides
a
number
of
identifiers
I
mean
the
background
on.
This
has
got
driven
by
open
ID
Connect,
where
the
relying
party
got
a
number
of
identifiers,
and
you
don't
know
which
one
they
chose
since
who
uses
their
primary
key
and
now
you're,
trying
to
say
use,
send
them
all
the
same
identifiers
again.
D
H
H
H
M
Bret
Jordan,
I,
aliases,
I'm,
fine,
with
I,
think
it's
pretty
easy
to
understand
and
when
it's
just
an
alias
or
something
like
at
the
top
level.
You
know
these
are
the
various
other
things.
If
you're
going
to
start
referencing
things
that
might
exist
elsewhere
or
an
external
references
concept
is
maybe
a
little
more
appropriate.
Thank
you.
H
H
B
H
Yes,
it
needs
it
needs
to
match
the
format
of
a
of
an
email
address.
That's
all
that's
in
there
today.
So
the
question
is:
is
that
fine?
Do
we
just
kind
of
punt?
On
that
whole
conversation?
Do
we
need
to
explicitly
say
we're
not
canonicalizing,
or
do
we
need
to
open
the
can
of
worms
and
give
some
strict
canonicalization
rules
Lucy.
J
A
Email
address
is
a
term
that
you
need
to
better
specify,
at
least
in
the
draft.
For
instance,
RFC
821
defines
a
bunch
of
valid
email
address,
syntaxes,
one
of
which
would
be
the
string
dick
space
heart
space
left
angle
bracket
dick
at
amazon.com
right
angle
bracket.
That's
a
valid
e
address.
I,
don't
think
it's
what
you
mean
the.
H
A
A
B
If
I
could
just
jump
in
so
most
production
systems
now
will
do
some
kind
of
canonicalization
of
whatever
the
user
entered
in,
so
that
it
turns
into
the
same
string.
When
you
go
to
login
right,
I
could
type
capital
D
dick
dot
capital,
H
heart
at
gmail.com,
or
all
lowercase
declared
at
gmail.com
I
can
change
the
caps
and
systems
will
all
figure
out
that
most
systems
will
turn
will
canonicalize
that
into
the
same
set
of
characters
independent
of
how
I've
typed
it
in.
A
A
B
Running
around
also
in
production,
that's
what
people
do
and
so
there's
not
a
canonical
email
format,
because
people
do
different
canonicalization
in
production
and
so
when
you're,
trying
to
when
you're
getting
a
set
that
has
a
subject
in
it.
How
that
other
system
canonicalized
and
how
you
canonicalize
may
not
be
the
same
and
so
you'll
need
to
canonicalize
the
subject
you
got
and
then
use
that
canonicalize
string
to
search
your
system
to
find
the
same
subject.
B
B
Informed
yeah,
the
question
is:
should
we
try
to
specify
canonicalization
and
I
just
wanted
to
bring
that
up
so
that
we
don't
have
that
on
the
list?
That's
that's
it's
good!
Well,
we
can
have
it
on
the
list.
It's
a
good
topic
to
discuss
here
and
see
if
there's
anyone,
that's
interested
in
doing
canonicalization,
Mike.
A
K
So
Benkei
duck
there
be
dragons
and
whether
or
not
you
talk
about
them
or
not,
they're
still
there
so
there's
I
didn't
hear
the
word.
You
said,
then
there
be
dragons,
oh
yeah,
and
so
you
know
there's
several
different
aspects.
Some
use
something
you
sort
of
touched
on
already
how
your
there
might
be
a
single,
authoritative
issuer
who
generates
the
initial
email
address
and
if
Jason
and
John
were
reliable,
you
know
carriers
for
opaque
white
strings.
K
That
might
be
okay
and
you
could
just
use
that
one
authoritative
value
we've
had
plenty
of
discussion
about
canonicalizing
JSON
on
many
lists,
so
I
don't
feel
a
need
to
replicate
that.
But
that's
not
the
only
potential
issue.
So
if
we
look
at
you
know,
RFC
5321
or
5322,
which
are
the
latest
core
email
related
stuff
they've
got.
K
For
all
of
that,
you
know
that's
the
topic
for
other
working
groups,
but
we
definitely
need
to
say
something
that
you
know
there
are
concerns
here
and
you
need
to
be
careful
what
you
do
and
there's
potentially
not
even
ITF
consensus
on
what
the
right
thing
to
do
is
so
we
can't
really
offer
super
concrete
guidance.
It's.
G
So,
with
my
hat
on
I'd
like
to
focus
the
discussion,
I
think
so
far,
this
concerns
us
that
this
is
the
kind
of
forms
that
we
would
like
to
avoid.
My
question
to
the
room
and
Mamie
are
on
the
list
is
whether
this
is
really
really
important
to
anybody,
and
specifically
whether
people
think
that
if
we
don't
add
a
hashing
of
addresses
as
an
option,
this
is
not
going
to
fly.
This
is
useless,
otherwise,.
M
Right,
Jordan,
yeah
I
think
there's
always
issues
when
we
deal
with
canonicalization
of
either
data
or
the
structure.
But
that's
part
of
the
reason
why
we
have
a
broken
internet
is
because
working
groups
aren't
willing
to
pay
the
cost
to
figure
these
things
out.
Do
it
they
just
we
just
continually
over
the
past
thirty
years,
that
I've
been
involved,
just
keep
punting
it,
and
so
that's
why
everything's
broken
and
so
I
think
that
would
need
to
be
some
care
and
diligence
done
here.
M
If
we
ever
want
any
of
this
stuff
digitally
signed,
because
if
people
are
just
gonna
put
it
in
random
things
and
you
have
no
way
to
replicate
or
reproduce
you
know,
you
basically
actually
have
to
keep
the
entire
byte
stream
of
the
original
data
so
that
you
could
never
you
know.
So
it's
a
little
soapbox
of
mine
but
I
think
when
possible
we
should
do
specificity.
So
what
are.
B
M
A
H
B
H
H
This
is
something
that
services
might
want
to
use
if
they
are
trying
to
exchange
events
with
a
party
where
they
don't
know
if
they
have
a
shared
account
or
not,
but
they
think
they
might
so
if
it's
a
it's
Amazon
and
Facebook,
we
might
want
to
send
a
hash
of
an
email
address.
So
if
facebook
has
an
account
for
that
email
address,
they
can
recognize
that
if
they
don't
we're
not
giving
them
a
real
customers,
email
address.
H
Obviously,
if
you're
going
to
have
stuff
it
makes
it
really
hard
to
do
that.
If
you
don't
have
a
canonical
form
for
that
or
if
you
don't
have,
if
both
sides
aren't
structuring
that
the
same
way
so
I'm
not
convinced
necessarily,
that
means
we
have
to
do
canonicalization,
but
it
definitely
complicates
matters
that.
K
Benedick
I
guess
the
the
hashing
is
sort
of
the
most
simple
thing
you
could
do
this
or
the
privacy
protection,
and
there
may
be
a
more
complicated
thing,
isn't
offer
slightly
better
guarantees.
What
I
actually
came
up
to
the
mic
to
say
was
sort
of
a
more
generic
question
about
the
document
as
a
whole,
and
it
may
just
be
that
I
forgot
since
Montreal,
because
they've
been
too
much
other
stuff
going
on,
but
the
example
he
presented
had
the
subject
and
any
type
associated
like
present.
Alongside
the
actual
subject,
values
and
I.
Couldn't
remember.
H
Can
think
of
a
use
case
in
risk
where
that
has
come
up
in
discussion?
I,
don't
think
it
impacts
the
structure
of
the
subject.
Identifier
though
I
think
for
that
we
would
probably
just
have
a
list
of
subject.
Identifier
types
all
right
thanks
any
other
questions
or
comments
on
subject
identifiers
before
we
move
on.
N
Identity,
finally,
one
thing
I
was
a
bit
surprised
not
to
find
in.
There
was
an
actual
defined
claim
for
a
subject.
Identifier
type
like
in
all
the
examples
you
have.
N
H
N
H
Part
of
that
I
think
comes
from
the
context
where
we're
doing
this
we're
in
we're,
assuming
that
that's
going
to
be
provided
as
part
of
the
definition
for
the
event
payload
and
that's
defined
by
whichever
specs
are
defining
events,
if
you
think
there's
value
in
defining
a
subject,
identify
or
claim
you
know
a
jock
level
claim,
we
can
talk
about
that.
There's
obvious
concerns
around
how
that
plays
with
existing
issue
or
sub
and
drew
how
we
work
with
that.
But
I
think
that's,
that's
maybe
worth
bringing
up
on
the
list.
Okay,.
B
N
Makes
sense,
I
was
looking
to
sort
of
prematurely,
maybe
using
an
example
and
use
in
another
context
and
got
to
the
point
where
I
needed
to
put
it
in
a
claim
and
then
thought
whoa
man.
What
do
I
call
this
and
so
I'm
not
sure
if
it
makes
sense
to
standardize
it
or
not,
but
yeah
I
can
raise
the
question
and
even
if
we
don't
I
suppose
it
might
be
helpful
to
have
some
some
wording.
Some
advice
towards
usage
outside.
B
N
H
Settle
I,
don't
think
so.
I
think
the
set
defines
a
subject
claim
I,
think
that
leaves
it
up
to
the
events
to
define
that
in
the
event
payload
I
think
it
says
that
events
should
define
that
if
it's
different
from
the
subject
in
the
of
the
set,
but
it
doesn't
go
into
any
more
prescription
than
that
yeah
I
I
could
I
could
certainly
see
value
in
standardizing
on
a
subject
identifier,
alternative
claim
to
sub
yeah,
and
that
this
might
be
the
right
document
for
that.
N
H
H
That's
with
a
push
based
set
token
delivery
using
HTTP.
We
are
doing
that
by
having
a
transmitter
make
a
set
transmission
request.
What
are
you
doing
with
my
slides?
Thank
you.
A
transmitter
makes
a
set
transmission
request
to
the
event
recipient.
The
request
body
is
the
set
itself.
Content
type
is
application.
Second
job,
that's
pretty
much
all
there
is
to
it
from
the
transmitter
side,
the
event,
the
recipient.
If
it's,
if
it's
successful,
if
they
parse
the
set,
if
they
like
it,
they
send
back
a
202
accepted.
H
H
H
H
This
is
further
iterating
on
it.
After
that
split
I
rewrote
the
abstract
introduction
and
some
of
the
technical
description
to
make
a
little
bit
more
sense.
Now
that
we're
just
talking
about
one
protocol
at
a
time
pulled
out
a
bunch
of
content
that
wasn't
necessary,
wasn't
really
contributing
a
lot
of
non
normative
stuff
made
some
minor
Corrections,
and
we
added
the
Ayana
registry
for
error
codes,
which
was
one
of
the
big
pieces
of
feedback
that
we
got
so
one
of
the
concerns
people
had
about
splitting
the
draft
was
duplication
of
content
between
the
two
were.
H
H
All
of
these
look
to
me,
like
things
where
we
can
just
have
pole
reference
push
and
be
done
with
it
and
eliminate
that
duplication.
We
may
or
may
not
be
able
to
do
that
with
the
failure
response
structure.
It
depends
on
I,
think
Mike
has
a
pending
at
of
the
poll
product
protocol
description,
and
so
it
may
or
may
not
fit
in
there.
Well,
we'll
see
how
that
turns
out.
H
So
open
item,
something
that
came
out
in
our
discussion
discussion
between
editors-
is
that
our
list
of
error
codes
currently
in
the
draft
aren't
very
well
defined.
There's
about
12
of
them
and
it's
not
clear
there
they're
not
very
well
differentiated
from
one
another.
So
you
have
scenarios
where
it's
not
clear.
What
kind
of
error
code
you
should
be
sending
back?
It
could
be
one,
it
could
be
another.
H
The
other
interesting
thing
about
these
is:
they
are
mostly
jha
errors.
If
you
look
at
the
error
error
codes,
almost
all
of
them
relate
to
processing
of
shots.
You
know
validating
signatures,
decrypting
JW
EES,
that
sort
of
thing
so
they're
not
set
focused
so
to
kind
of
give
an
example
of
what
I
mean
by
that.
So
here's
the
current
set
of
error
codes
of
these
only
three
of
them
really
relate
to
something
that's
specific
to
set
the
rest
are
all
job
related
or
basic.
H
Syntax
related
I
did
take
a
stab
at
like
if
I
were
to
revise
these
and
come
up
with
more
specific,
clear
error
codes.
What
would
that
look
like,
and
even
when
I
did,
that
I
ended
up
with
almost
entirely
error
codes
that
are
related
to
jobs,
so
that
leads
to
a
number
of
questions.
Is
there
an
existing
list
of
job
error
codes?
We
can
reference
instead,
I
am
not
aware
of
one
but
I'd
happily
learn
about
one
if
it
exists
mics
shaking
his
head,
no.
H
G
This
kind
of
looks
like
bike
shedding
to
me.
I
think
we
need
to
define
a
few
error
codes,
I,
don't
much
care
whether
there
are
the
existing
ones
or
the
ones
you
proposed,
and
we
just
need
to
make
sure
that
generally
applicable.
So
most
people
who
implement
reasonable
parsers
will
will
be
able
to
make
sense
of
them
and
speaking
of
park,
shedding
I
think
we.
A
Like
Jones
Microsoft,
to
the
extent
that
we
think
that
we've
sliced
the
error
space
so
finally
that
different
implementers
would
use
different
ones
for
the
same
condition,
and
that
tells
me
we
should
probably
collapse
the
number
into
a
smaller
set
of
more
general
ones
unless
the
distinctions
are
actually
really
semantically
important.
So
I'll.
H
H
A
Will
be
an
error
space
used
for
this
protocol,
so
some
of
those
errors
will
be
about
jobs.
Some
will
not,
but
it's
fine
for
us
to
define
our
own
error
space.
That
doesn't
mean
that
other
groups
would
necessarily
want
to
or
have
to
use
those
when
the
errors
are
about
John.
So
I
think
that's
just
a
different
thing
that
we
don't
need
to
concern
about
ourselves,
we're
in
a
particular
scope.
Let's
build
an
airspace
that
works
for
that
scope.
H
So
part
of
why
I
want
to
bring
that
up
is
implementation.
Wise
people
are
going
to
be
building
this
stuff
on
job
parsers
that
are
going
to
be
written
a
certain
way,
there's
potential
value
if
those
parsers
are
emitting
a
common
set
of
errors
that
can
just
be
forwarded
on.
If
not,
then
that
forces
the
implementer
to
kind
of
map
between
whatever
errors
their
parser
is
generating
and
whatever
error
is
the
particular
protocol
requires,
in
this
case,
since.
A
N
O
N
B
N
Do
you
I
so
originally
I
provided
quite
a
bit
of
fidelity,
but
it's
human
readable
fidelity
intended
more
a
develop.
Who
is
there
to
be
able
to
figure
out
what
the
hell's
going
on
right,
but
there
there
was
no
programmatic
fidelity
that
a
library
might
look
for
specific
error
codes
and
map
that
to
something
or
take
some
retry
action.
I
have
since
tried
to
retrofit
a
little
of
that
where
possible,
but
you
know
that
how
I
did
that
is
probably
different
than
how
somebody
else
did
it,
whether
they
did
it
at
all?
B
N
B
N
N
Probably
yes
and
I
think
that
for
a
protocol
and
at
least
the
error
codes,
the
only
real
reason
to
have
differential
error
codes
is
if
the
application
can
take
some
meaningful
action
off
of
the
error
code.
Otherwise,
you
want
to
have
something
available
like
a
description
field.
That'll
help
a
developer
during
the
development
and
bugging
phase
no-one's
going
on,
but
it
but
it's
it
doesn't
have
to
be
as
I'm
still
going
for
the
word.
You
know
static
or
define
an
intro.
H
N
N
H
K
It
really
seems
like
the
motivation
for
trying
to
go
into
that
broader
scope
and
get
a
broader
consensus
on
these
definitions
would
only
be
relevant
if
we
had
some
interoperability
need
for
their
usage
and
to
a
large
extent
there
isn't
gonna,
be
any
you
oughta
make
automatable
or
mechanical
actions
that
you
can
take
based
on
receiving
these
error
codes
and
so
once
you're
getting
a
human
involved.
There's
a
lot
less
need
for
a
uniform
agreement
on
what
the
values
are.
So.
A
A
H
So
it
sounds
like
the
the
what
that
the
one
place
where
Interop
could
potentially
be
valuable,
the
library
layer,
the
ship
has
long
since
sailed
on
any
benefit
there.
So
we'll
go
back
and
look
at
the
existing
list
of
error
codes,
see
if
we
can
resolve
the
ambiguities
and
propose
a
new
list
with
probably
less
fidelity
than
then.
What's
there
now
just.
B
Want
to
poke
that
way,
you're
suggesting
micro,
you
suggest
me
do
what
we
do,
but
throw
off
where
we
have
an
error
code
and
then
we
have
a
description
field
and
the
developer
puts
whatever
they
want
in
there.
We
don't
specify.
What's
in
that
description
field,
we
just
make
it
available.
Yes,
that's.
H
H
G
B
G
A
A
A
So
in
Montreal
I
talked
about
what
I
thought
was
the
status
of
the
pawl
draft,
as
well
as
made
a
bunch
of
comments
about
the
push
draft
and
I'm
happy
to
report
that
there's
been
a
lot
of
progress
on
both
since
then,
as
Annabelle
just
explained
to
you.
The
language
has
been
substantially
simplified,
actually
in
both
drafts.
A
There's
now
the
error
code
I
in
a
registry
which
the
pawl
draft
now
references
rather
than
duplicates,
there's
some
other
places
where
I
referenced,
duplicated
language,
rather
than
repeated
it
and
I
did
around
after
Annabelle
did
the
round
where
I
went
through
my
four
months
old
review
comments
on
both
drafts
and
where
they
were
applicable
and
didn't
really
change
the
meaning
of
any
of
them.
I
applied
them.
Both
a
lot
of
that
was
just
blocking
and
tackling
like
aligning
the
language
with
the
already
approved,
set.
A
Spec
and
Annabelle
did
do
a
review
of
that
before
I
updated
that.
So
that's
all
good
progress
next,
so
what
I
didn't
do
to
Paul,
despite
what
you
might
have
thought
from
what
I
said
in
Montreal
is
I,
at
least
in
this
round
did
not
make
any
breaking
changes
but
more
to
discuss.
So
what's
next,
I
must
admit.
I
frankly
ran
out
of
time
when
doing
these
edits
before
the
submission
thing,
I
had
iw
and
Fido
and
whatnot,
so
I
still
have
to
do
another
pass.
A
There's
places
where
there's
two
different
parameters
that
are
not
handled,
orthogonal
e1
sometimes
says
you
should
ignore
the
other
and
that
doesn't
seem
like
clean
protocol
definition.
So
in
this
next
round,
I'll
take
a
pass
it
thinking
about.
How
would
I
do
this
says
that
the
programming
logic
does
not
represent
an
odyssey.
A
There's
also
some
remaining
descriptions
of
functionality
without
clear
motivation
for
them.
That's
not
actually
actionable
so,
for
instance,
says
that
you
may
reach.
Yes,
you
may
reissue
a
set,
but
it
doesn't
say
when
or
why
you
would
do
that
or
what
the
recipient
should
do
if
that
ever
occurs,
so
that
either
needs
to
be
made
clear
and
actionable
or
ripped
out,
and
this
is
a
place
where
I
would
covet
reviewers.
Who
could
give
informed
opinions
of
as
developers
about?
How
would
you
use
this
and
why
so.
A
Well,
that's
pretty
resounding.
We
need
people
to
read
that
further
than
the
spec
next
so
I'm
here
with
Annabel
reporting
that
we've
made
significant
progress
before
I
heard
that
we
were
going
to
possibly
do
working
group
last
call
I
already
wanted
to
make
the
point
as
an
editor
of
both
suspects,
that
people
should
get
their
eyes
on
the
push
draft,
because
I
think
it's
mature
enough
that
it
could
use
and
withstand
broad
review.
A
A
P
P
B
To
get
this
stuff
closed
out,
we've
you
know,
I,
think
Annabelle.
There's
some
tweaks
you're
going
to
do
for
push
some
discussion.
Items
are
subject:
identifiers
and
Mike.
You've
got
some
work.
Aren't
that
you've
carved
up
for
it
going
to
do
on
pull
thinking.
Maybe
we
can
have
an
interim
meeting
where
we
could
discuss
those
revisions
and
see
if
we
can,
you
know,
keep
our
progress
here
at
velocity,
so
we
can
wrap
these
things
up.
G
G
Alright,
so
next
on
the
agenda
is
new
work,
so
we're
getting
all
three
drafts
one
way
or
another
across
the
finish
line,
and
the
question
now
is
whether
there's
anything
else.
Oh,
we
close
the
Working
Group,
probably
shortly
after
Prague.
So
if
there's
anything
big
that
you
can
think
about,
that
should
belong
to
secure
vents
feel
free
to
speak
up
now,
all
sent
send
it
to
the
list.
Welcome
to
Prague
equipped
with
your
wonderful
new
ideas,
otherwise,
we'll
be
done
once
there
three
drafts
go
to
iesg.