►
From YouTube: IETF115-CALEXT-20221108-1630
Description
CALEXT meeting session at IETF115
2022/11/08 1630
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
A
This
is
the
note.
Well.
All
of
this
applies
to
everything
you
do
this
week
at
IHF,
whether
you're
in
the
room
or
remotely
I'm
sure
you
have
read
it.
If
not,
please
do
and
Obey
all
the
instructions
therein.
A
This
is
the
agenda
that
I've
put
together
based
on
what
people
have
asked
for.
So
we
don't
need
to
stick
to
this,
but
this
is
the
guide
for
what
we
want
to
look
at.
As
Mike
appeared
in
the
queue
he
has
not
so
it's
subscription
upgrade
is
Max
document.
It
is
in
last
call,
but
it
turns
out
hello.
Mike
welcome.
Just
talking
about
subscription
upgrade,
which
is
in
last
call
it's
it's
you're
the
author
on
it.
A
It
has
a
section
in
it
which
is
still
outstanding,
questions
that
have
am
I
not
loud
enough,
I
feel
really
loud.
Thank
you.
Yeah
outstanding
questions
that
that
are
not
yet
resolved
in
there,
which
probably
should
be
sorted
out
before
we
send
it
to
ASG,
or
they
will
ask
me
questions
about
my
shepherding
skills.
So
what
do
you
want
to
do
about
that?.
A
So
the
subscription
upgrade
document
is
sitting
there.
It's
gone
no
comments
on
it,
but
it
has
a
outstanding
questions
to
be
resolved,
and
so,
when
I
went
to
write
the
shepherd's
statement
earlier
he's
going
to
have
some
questions
for
me.
B
I
think
that
was
yeah.
That
was
a
result
of
the
question
of
a
conversation
between
me
and
Ken,
and
we
I
think
we
just
needed
to
look
at
the
spec
to
see
what
was
valid
for
the
very
header.
It's
it's
really
just
a
matter
of
making
sure
we
got
it
right
all
right,
I
guess
we
could.
B
A
Cool
there's
also,
there
was
a
must
not
where
the
knot
wasn't
capitalized
and
the
must
was
that
we've
got
so.
How
about
I
will
send
you
a
quick
review.
C
B
A
D
So
the
the
last
month's
with
GS
calendar
have
been
all
about
the
scheduling
model
to
use
in
JS
calendar.
We
found
discrepancies
between
the
JS
calendar
and
the
I
calendar
schedule
new
models
and
had
a
couple
of
discussions
both
at
ITF
sessions
and
on
the
mailing
list.
What
to
do
about
it?
D
We
had
an
interim
at
the
end
of
September,
where
the
decision
was
made
that
we
go
with
the
JS
calendar
model,
and
now
we
need
to
make
this
work
with
Iceland
and
itip
in
the
sense
that
we,
we
obviously
need
to
stay
Backward
Compatible
with
calendaring
services
that
just
speak,
I
calendar
and
the
current
I
calendar
model,
but
we
want
to
add
new
properties
and
definitions
for
both
I
can
and
it
to
also
make
the
JS
calendar
specific
scheduling
model
aware
in
I
calendar
for
implementations
that
might
support
both.
D
Another
thing
is
that
in
the
on
my
next
presentation,
I
talk
about
GS
contact,
but
this
also
is
relevant
in
so
far
with
JS
calendar,
as
Chase
contact
is
very
likely
to
get
published
before
we
land
JS
calendar
Biz,
and
obviously
we
want
to
reuse
as
many
common
definitions
between
these
two
so
I
also
say
here.
Please
review
JS
contact.
D
D
D
It
would
be
very
great
if
you
get
more
reviews
from
the
calendaring
world
for
JS
calendar
abyss
and
also,
if,
if
people
are
coming
forward
with
their
implementations,
we
can
do
more
interoperation
testing
before
we
land
GS
calendar.
This
next
slide,
please.
D
So
some
more
some
more
information
on
the
scheduling,
so,
as
I
said
before,
we
now
defined,
what's
required
for
GS
calendar,
the
schedule,
ID
property
got
added
in
JS,
Kell
and
Abyss
over
JS
calendar
and
that
also
changed
the
definitions
of
Delegation
and
group
memberships.
D
D
D
D
D
It
looks
to
me
as
there's
there
is
some
heuristics
and
and
and
and
if
this
then
that
or
else
to
that
rules
and
I
generally
do
not
like
them
for
conversions,
because
these
are
always
the
things
that
implementations
then
could
get
wrong
and
in
combination
with
I
calendar
and
the
latest
after
we
have
figured
out
how
to
do
that
and
I
how
to
convert
it
in
Iceland.
We
need
to
look
at
itip.
This
hasn't
started
at
all
I.
D
We
definitely
need
to
make
sure
that
existing
eye
tip
formal
itip
rules
still
stay
for
backwards
compatibility,
and
then
we
need
to
Define
how
we
can
build
on
top
of
them
so
that
we
can
do
more
more
scheduling,
for
example,
using
server
scheduling
methods,
web
scheduling,
regular
imip
scheduling,
maybe
other
that
comes
in
a
JS
calendar
extension,
yes,
and
the
backwards
compatibility
as
I
said
is,
is
absolutely
crucial
to
make
this
work
next
slide.
Please.
D
So
these
are
the
next
steps
that
I
see
I,
think
scheduling,
Will
Keep
Us
busy
for
a
while
also
the
mapping
document
I.
Think
I
really
would
like
to
look
at
the
structure
and
organization
of
the
mapping
document.
Now
that
we've
basically
done
the
same
exercise
for
JS
contact,
it's
at
the
moment,
Mike
and
I
and
I
hope
Mike,
you
are
you
agree
with
me
on
that
are
are
really
bottlenecks
on
this
Mike
has
a
good
bunch
of
other
rfcs
to
work
on.
D
I
was
almost
completely
busy
in
RFC
work
with
JS
contact.
So
if
anyone
would
want
to
join
as
a
co-author,
please
please
let
let
us
know
I'd
be
very
happy
to
to
share
the
effort
with
with
other
people,
so
as
a
current
distance
I
think
it
it.
It's
really.
It's
realistic
to
aim
for
the
summer
ITF
in
July
for
work
worker
blast
call
that
would
be
exactly
a
year
after
we
start
a
JS
calendar
business
which
I
would
think
is
a
is
a
reasonable
time
frame.
D
If
not
I,
guess
we
can
discuss
after
my
presentations
that
presentation
now.
That
being
said,
I
do
know,
and
that's
probably
something
that
might
need
to
get
addressed
in
the
treatment
working
group
actually
is
that
we
already
have
J
map
specifications
waiting
for
JS
calendar.
This
that's
J
map
for
calendars
and
chain
map
for
tests.
Now.
D
I
I
don't
have
a
proposed
how
to
deal
with
this.
The
differences
between
JS,
Kevin
and
JS
calendar
base
are
not
that
big,
but
especially
in
terms
of
scheduling
that
got
the
the
rework
that
the
better
should
be
taken
into
consideration
rather
than
now
working
on
the
former
or,
let's
see
current
model.
D
B
E
B
Extend
you
know
getting
people
to
help
with
the
the
the
the
the
mapping
drift
I
mean
the
the
biggest
part
of
that
I
think
is
actually
implementing
the
the
mapping
and
and
simply
noting
what
what
you
do.
I
mean
it's
it's
hard
to
do
it
in
how
to
do
and
get
it
right.
If
you
don't
actually
implement
it,
because
some
of
the
stuff
we
discovered
came
about
as
a
result
of
implementing
it
and
then
running
into
these
roadblocks
that
needed
resolving
and
we
haven't
done
any
testing.
B
F
F
Oh,
this
is
Ken
from
first
Mill,
so
I'll
address
two
points.
So
as
far
as
joining
the
effort,
I
can
certainly
take
some
of
the
implementation
load
off
of
Robert's
hands
and
I
can
certainly
also
add
to
crafting
some
text.
As
far
as
the
last
point
I
see,
jmap
is
this:
a
protocol
and
JS
calendar
is
the
payload,
so
I
don't
think
we
necessarily
need
to
hold
jmap
up
unless
there's
a
change
in
this
that
affects
the
protocol,
but
I
don't
believe.
That's
the
case.
B
No,
no
I
think
the
fact
is
all
the
testing
I'm
doing
for
the
JS
counter
conversion
is
is
over
caldev.
B
I,
don't
think
they
should,
because
I
think
the
same
thing
will
occur
down
the
road.
I
mean
what,
if
we
get
another
representation,
we're
gonna
throw
J
map
away,
or
are
you
going
to
actually
allow
J
map
to
transport?
Other
representations.
D
So
maybe
let
me
clarify
I,
do
not
think
that
our
that
they
might
be
blocked
by
waiting
for
definitions,
but
these
specifications
are
defined
to
they
refer
actually
to
JS
calendar.
Now.
If
they
get
implemented
and
used
before
GS
calendar-based
lens,
then
we
we
need
to
deal
with
the
fact
that
there
will
be
GS
calendar
data
out.
That
is
using
the
current
JS
calendar
scheduling
model
rather
than
the
one
we
are
want
to
introduce
with
GS
calendar
Biz,
which
is
not
totally
off,
but
it's
different.
G
So
yeah
I
see
this
as
an
issue.
What
you
just
said,
potential
issue,
but
at
least
for
the
tasks
back
I
can
say
that
it's
probably
not
going
to
be
complete
very
soon.
So
for
that
spec
for
the
specifics
back,
it's
right
now,
I
wouldn't
see
it
as
an
issue.
I
would
more
see
this
as
like
an
issue
we
need
to
track.
So
you
know
like
make
sure
that
JS
calendar
is
somehow
in
the
final
State
before
we
finish
before.
G
B
I
was
going
to
say,
I
mean
the
thought
on.
The
last
point
is
if
you
could
express
those
requirements
in
more
abstract
terms
and
sort
of
more
like
a
data
model
rather
than
a
specific
representation
that
might
unblock
things
and
also
clear
things
up
for
the
future.
D
Yeah
I
mean
I
I.
Do
think
that
if
we
do
a
change
in
JS
calendar
this
to
the
current
definition,
we
could
even
make
this
backwards
compatible
with
JS
calendar,
and
that
change
would
be
that
currently
now
in
jsk
and
Abyss.
So
in
JS
calendar,
if
you
have,
if
you
delegate
it
to
another
participant,
you
use
the
good.
D
D
So
if
we,
if
relaxing
the
ruling
J,
is
current
Abyss
that
it
can
refer
to
participant,
ID
or
a
URI,
then
then
this
could
work
and
a
participant
ID
can
never
be
a
URI
because
it
doesn't
because
the
the
characters
do
not
allow
to
be
a
well-formed
URI,
but
I
guess
we
can
visit
this
on
the
mailing
list
or
or
later
in
the
RFC.
B
It
my
mind
does
re-raise
the
issue,
why
we
don't
have
a
version
number
in
JS
calendar.
D
Yeah,
that's
actually
something
I
wanted
to
bring
up
for
JS
contact,
but
I
I
would
be
happy
to
talk
about
it.
Now
for
GS
calendar
too
I.
B
I
suggested
a
while
ago
and
was
told
it
wasn't
necessary,
but
it
would
resolve
some
of
these
issues
and
if
you
knew
which
version
you
were
talking
about,
you
could
you
could
allow
for
these
issues
and
it
wouldn't
have
to
necessarily
be
backwards
compatible.
D
Yes,
incidentally,
yours
and
I
just
had
a
chat
exactly
about
this.
Also
before
this
session
and
yes,
I
agreed
that
a
version
number
that
we
use
for
handling
non
backwards,
competitive
changes
is
is
the
way
to
go
most.
B
D
Yeah,
so
this
this
might
be
a
good
argument
that
we
look
at
versioning,
GSK
and
Abyss,
so
that
we
can
then
already
start
using
JS
calendar.
But
then
implementations
are
aware
if
they
should
upgrade
or
not.
H
H
Is
it
the?
Is
it
a
problem
that
because
if
we
say
we're
working
group
classical
in
July,
is
it
a
problem
that
we
wait
for
GS
calendar
Biz
to
stabilize
and
then
move
to
a
gmap
or.
A
Just
that
we'd
like
to
get
the
jam
up
stuff
out
at
some
point,
but
no
otherwise
waiting
waiting
works
just
means
that
we
won't
have
a
spec
that
can
be
published
for
another
six
months
for
Gemma.
So
it
means
too.
B
A
B
So
I
mean
testing
would
would
certainly
reduce
the
the
churn
later
on,
because
yeah
so
I
think
we
need
to
push
for
getting
some
testing
done
and
not
just
two
of
us.
H
Or
if
we
don't
have
any
testing,
we
can
push
to
publish
that
and
then
we
we
make
sure
that
we're
going
to
have
a
gmabis.
B
Well,
yeah
troubles
people
when
they
see
it
or
just
just
suck
it
up
and
and
then
we're
stuck
yeah
yeah,
yeah,
yeah,
yeah
I
know
yes,.
G
Yeah
so
Charles
bomb
again
I
just
want
related
to
the
regarding
the
version
number
I
don't
see
from
it's,
probably
just
a
very
simple
key
value
thing:
I
would
assume
so
I,
don't
see
it
hurting
anyone
I
would
say,
but
I
don't
see,
big
need
for
it.
Neither
but
yeah,
probably
I
would
vote
for
putting
it
in
because
probably
doesn't
hurt.
A
B
E
F
A
Yeah,
it's
just
not
want
to
be
able
to
publish
it
so
that
other
people
can
interrupt
with
and
we
don't
want
to
publish
it
with
a
pre
using
the
string
when
it
hasn't
yet
been.
A
G
The
ad
type
comment,
yeah
I,
think
it
makes
a
lot
of
sense-
I-
probably
it's
probably
worse-
to
mention
that
this
should
be
or
May
and
probably
should
be
used
for
future
versions.
As
a
you,
you
know
new
Js
contact
or
JS
calendar
version.
Should
you
use
a
different
ad
type,
just
like
one
sentence
thing
in
the
spec.
A
I
D
Yeah,
thank
you,
I'm,
not
sure.
If
we
would
even
update
the
media
type,
we
can't
because
we
can
have
more
version
granularity
within
the
within
the
Json
data.
Then
we
can
just
put
versioning
for
for
sub
objects,
not
the
complete
format
but
I.
E
I
D
A
D
A
Cool,
so
the
action
from
that
is
yeah.
A
Editing
and
my
cool
shall
we
move
on
to
the
next
one
which.
E
F
D
John
all
right
cheers
contact
next
slide,
please.
So
we
are
complete.
We
have
worked
the
last
weeks
and
since
last,
ITF
on
getting
it
all
in
shape,
I'm
pretty
happy
with
the
result,
and
so
we
really
look
forward
to
thorough
reviews
so
that
we
can
now
polish
this
thing.
D
So
next
slide,
please
who's
summarizing
a
couple
of
changes
that
we
did
there's
a
ton
more,
but
we
we
we
changed
it
the
time
for
the
the
date
and
time
format
for
anniversaries.
It's
now
a
well-defined
value
in
so
far
that
it's
either
a
partial
date
or
or
it's
a
timestamp.
So
you
do
not
need
to
look
at
the
the
semantics
if
it's,
if
it's
just
partial
or
not,
does
not
come
out
of
the
string
format
anymore,
it's
indicated
by
the
type
of
the
value.
D
We
also
split
the
resources
property,
which
really
was
just
a
container
for
basically
any
URI
you
can
find
in
vCard.
We
split
that
into
more
specific
subtypes.
As
you
see,
media
links,
crypto
Keys,
calendars
scheduling,
addresses
for
scheduling,
addresses
we
use
the
same.
We
refer
actually
to
JS
calendar
to
use
the
same
scheduling,
methods
that
being
imip
and
other
as
it
currently
stands,
so
so
that
we
can
Define
scheduling.
Address
is
compatible
in
with
JS
calendar
in
a
JS
contact.
One
of
the
things
we
also
did
was
we.
D
We
introduced
them
when
we,
when
we
sorted
in
a
vCard,
you
can
have
either
an
Ayana
time
zone
name
for
a
time
zone
or
you
can
also
just
specify
an
offset,
and
we
initially
introduced
the
JS
calendar
time
zone
definition
so
that
one
can
put
arbitrary
time
zones,
for
example
the
time
zone.
That's
that's
just
using
an
OTC
offset
into
the
contact,
but
we
figure
this
actually
puts
too
much
burden
on
implementations
that
just
want
to
implement
GS
contact
because
they
now
need
to
implement
their
own
time
zone,
parlors
and
evaluations
and
stuff.
D
And
basically
we
want
to
push
people
to
use
Ayana
time
zones
rather
than
fixed
UTC
offsets
which
are
even
discouraged
in
the
vCard
RFC.
So
that's
why
we
simplified
the
model
next
slide,
please.
D
D
We
organized
the
conversion
document
now
so
that
it
should
look
very
familiar
to
people
being
familiar
with
the
vCard
rfcs.
We
basically
organize
it's
basically
organize
the
same.
You
can
so
you
can
have
like
the
B
card
RFC
and
the
conversion
RFC,
and
they
are
basically
following
the
same
line.
So
it
should
be
straightforward
to
to
write
the
conversions.
D
We
also
introduced
the
derived
parameter
that
might
introduce
in
I
think
it's
also
event
pop
I'm,
not
sure
anyway.
The
derived
parameter
on
a
property
now
indicates
that
this
that
the
value
of
this
property
actually
is
derived
by
the
implementation.
So
it's
not
a
user
defined
value,
and
so
that
so
implementations
can
know
that
this
is.
D
This
is
just
kind
of
an
ephemeral
value
that
actually
can
be
generated
from
some
other
information
in
the
in
the
same
cartilages
in
in
this
example,
and
we
mainly
use
that
for
JS
contact
cards
that
Define
a
name
so
having
a
name
defined
in
its
several
parts
of
the
name
being
the
first
name.
Last
name
whatever,
but
in
in
a
v
card,
the
full
name
property
is
mandatory.
D
We
added
a
couple
of
other
recalled
properties
that
mainly
were
just
required
to
map
a
couple
of
values
from
the
from
JS
contact
for
pronouns.
Specifically,
we
discussed
our
initial
Proposal
with
with
a
couple
of
LGBT
IQ
activist
groups,
and
it
it
got
refined
a
bit,
but
basically
the
the
feedback
was
very
positive,
so
I
hope
we
have
came
up
with
something.
That's
future
proof.
D
One
thing
we
did
is
now
that
we
have
this
labor
property
in
JS
contact
at
a
couple
of
places,
and
we
now
decided,
even
though
it's
not
a
standard
property.
We
guide
implementations
to
convert
this
to
the
xav
label,
which
effort
introduced
around
in
the
year
2000
or
so
in
their
address
books.
So
it's
it's
been
out
in
the
white.
D
Now,
since
more
than
20
years,
we
expect
all
implementations
that
ever
seen,
a
vCard
of
an
apple
client
can
deal
with
the
xab
label,
either
by
ignoring
it
or
by
actually
knowing
what
to
do
with
it.
So
it
seems
like
the
better
choice
rather
than
introducing
a
new
label
property
in
vCard
and
run
into
conflicts
if
there
is
an
exab
label,
but
also
a
new
label
type.
D
That
being
said,
I'm,
not
sure
if
we
should
register
the
xab
label
property
at
Ayanna,
I,
don't
know
if
that's
even
possible
for
an
X
property
but
yeah
I
guess
we
can
decide
this
after
this
meeting.
D
D
Some
of
them
we
figured
as
being
convenience
properties
for
simple
type
values
during
implementation.
It
turned
out
that
implementing
these
convenience
properties
is
way
more
work,
and
really
it's
not
convenient
at
all
in,
in
contrast
to
just
having
one
specific
way,
how
to
write
and
read
these
special
properties,
and
with
these
with
these
properties
and
the
rest
with
it,
we
are
now
able
to
fully
convert
between
v
card
and
JS
contact
without
loss
of
information.
D
That
doesn't
necessarily
mean
that
everything
in
a
vCard
is
kind
of
a
first
class
feature
in
JS
contact
and
the
other
way
around,
but
you
can
still
preserve
all
the
information
in
transit
by
converting
back
and
forth
over
a
couple
of
systems
that
might
talk
to
each
other
in
either
that
or
that
format,
so
is.
This
seems
like
a
good
goal
for
us
to
aim
at
I.
Don't
think
we
should
aim
for
complete
feature
priority
cool
next
slide.
Please.
D
So
that
being
said,
we
want
to
start
working
group
last
call.
We
we
found
a
couple
of
nits
that
we
want
to
change
in
the
document,
so
I
guess
we
might
want
to
update
the
document
before
we
go
into
last
call.
D
One
of
the
things
we
wanted
to
address
is
now
already
came
up
during
today's
JS
Canada
session,
which
is
versioning
I,
say
we.
We
discuss
and
come
up
with
a
proposal
for
that
very
soon
as
part
of
JS
contact,
working
group
loss
core
and
then
use
the
same
mechanism
also
for
JS
calendar,
and
so
that
being
said,
we
just
need
to
decide
when
start
when
to
start
last
call
that's
the
end
of
my
presentation,
cool
thanks,
Robert.
A
It
does
anyone
else
want
to
say
anything
on
it.
I
think
it
sounds
like
just
publish
something
this
week
and
do
a
work
in
group.
We'll
have
to
call
it
straight
away.
B
We've
got
the
coconut
stuff
coming
up,
we've
got,
Tuesdays
is
J
star
day,
so
we
could
perhaps
widen
the
audience
a
bit
and
maybe
something
would
come
up
there,
but
well.
B
Yeah
just
another
opportunity
to
to
discuss
this
and
ensure
there's
no
last
minute
problems.
D
So
how
long
typically
do
we
have
last
call
is
that
two
weeks
or
yeah.
A
D
Change,
I
think
it's
better
to
that
that
we
publish
a
new
version.
The
the
smart
stuff
we
found
is
clarifying
definitions
and
I.
Don't
think
we
need
to
go
into
last
call
with
something
we
know
which
might
be
not
as
clear
as
we
wanted
it
to
be
so
cool.
A
Thank
you.
Next
up
is
tasks.
B
Okay,
yep
there's
not
much
been
changed.
Unfortunately,
between
these
things,
I
did
make
a
whole
bunch
of
changes.
According
to
the
discussion,
we
had
either
the
last
one
or
the
one
before
having
got
over
the
fear
of
components.
B
So
I
did
introduce
this
V
status.
Property
I
rewrote
the
draft
to
to
use
that
the
issue
we
had
around
tasks
was
that
really
you
won't
be
able
to
report
changes
in
status
and
and
and
maintain
them,
and
it
needs
to
be
more
than
just
a
simple
status
property
so
that
it
now
allows
you
to
have
a
reason
which
is
usually
intended
to
be
something
fairly
structured
and-
and
you
can
add
comments
and
whatever
else
to
it
to
to
provide
more
detail.
B
I
got
around
all
sorts
of
of
problems
in
the
spec.
We
had
this
weird
group
parameter
to
try
and
group
things
together,
but
it
didn't
work
very
well,
so
these
status
can
we
move
on
to
the
next
one.
B
Oh
yeah,
there's
there's
a
couple
of
properties
we
introduced
was
this
reason
property.
It
was
already
around
as
a
parameter,
but
it
worked
much
better
as
a
property
it.
It
takes
something
like
a
a
fairly
well
defined
value,
which
is
usually
indicating
of
some
something
that
can
be
interpreted
automatically
by
by
things.
B
Oh
yeah,
that
was
a
that
was
an
afterthought.
I.
Think
you'll
forget
that
last
comment.
I
was
wondering
whether
in
fact,
summary
was
meant
the
same
sort
of
thing,
but
but
in
fact
summary
is
just
free
text
and
the
idea
is
to
try
and
make
reason
a
little
less
free
text-ish
for
for
automatic
processing
just
skip
onto
the
next
one,
and
this
is
just
a
summary
of
the
changes
I
made
here.
Oh
yeah,
that's
the
other
thing.
So
now
we
have
the
participant
property.
B
Just
following
the
the
the
backwards
compatibility
issues
with
you
know,
guide
in.
In
the
event
publishing
thing
we
could
just
use
participant
to
group
stuff
together
to
add
extra
information,
so
that
got
rid
of
a
whole
load
of
weird
parameters
we
were
attaching
to
to
the
attendee.
They
just
become
regular
properties
and
and
some
of
those
parameters
we
added
they
were
just
they
were
just
copies
of
of
pre-existing.
B
Properties
like
DT
stamp
can
be
used
to
show
when,
when
this
took
place-
and
we
can
just
add
comments
and
all
sorts
of
things
like
that-
you
can
input
of
these
status
inside
this.
So
you
could
have
a
track
of
how
the
state
has
changed
for
a
given
participant
in
the
in
the
task.
B
B
Next
next
one,
please
I
like
that,
I'm
going
to
keep
that-
and
there
was
some
there's
been
a
certain
amount
of
discussion
on
on.
We
had
people
on
a
bunch
of
calls
and
Cal
connect
and
and
I
think
there
was
some
issues
around
duration
and
estimated
duration,
largely
in
terms
of.
B
So
you
know,
duration
could
be
weeks
and
the
estimated
duration
can
be
about
three
hours,
but
it
also
we
we
spent
some
time
talking
about
stuff
at
a
complete
odds,
because
I
hadn't
noticed
and
some
people
had
that
5545
had
introduced
a
restriction
on
on
durations
required
you
to
have
a
DT
start
that
wasn't
there
before
it
suddenly
got
added
part
way
through
the
process
which
I,
never
noticed
and
and
I
think
that
needs
to
be
removed
and
I
think
I
I
reintroduced
another
slide
deck,
which
which
talks
about
that.
B
A
second
I
could
whiz
through
in
a
minute
if,
if
need
be,
but
I
think
we
we
just,
we
presented
that
and
never
went
any
further
with
it.
So
I'd
like
to
resolve
that
issue
as
well.
B
Is
that
it
or
is
this
something
else
you've
got
two
more
slides,
keep
going
then!
Oh,
yes,
yes,
this
I
think
is
the
is,
is,
is
this
as
as
the
the
Jason
stuff
is
coming
along
pretty?
Well,
we
probably
need
to
ensure
that
we're
reasonably
well
aligned.
My
incarnations
to
tr
is
not
to
add
too
much
to
this
task
specification.
It
deals
with
a
bunch
of
specific
issues
and
I'd
like
to
try
and
wrap
this
thing
up.
I'm,
not
sure
whether
in
fact
you
know
I
did
say
before
that.
B
Maybe
it
should
contain
Json
representations
of
of
what
we're
doing,
but
I'm,
not
sure
that
makes
an
enormous
amount
of
sense.
B
Actually,
it's
something
we
need
to
do
going
forward,
but
at
this
stage
I've
been
kind
of
just
push
this
thing
out
fairly
quickly,
and
then
you
know
suck
it
into
into
the
the
mapping
stuff
that
we
do
as
later
on
that
it
seems
to
make
more
sense
when
you
get
this
thing
out
of
the
way,
because
it's
been
pretty
well
discussed
already
and
and
I
think
I'd
like
to
see
it
out
and
done,
but
in
we
still
need
to
make
sure
that
we
don't
have
any
incompatibilities
between
where
we're
going
with
with
the
the
Jason
stuff
and
the
next
one
was
oh
yeah,
that's
right.
B
Yes,
as
I
said,
this
is
all
the
same
thing
there's
been
a
whole
bunch
of
of
suggested
things
that
could
be
added
to
tasks,
but
I
think
that's
where
we
should.
We
should
tie
that
in
with
what
we're
doing
with
JS
test
either
with
the
current
spec
that's
been
worked
on
or
as
a
separate
set
of
extensions.
After
that
comes
out,
it
depends
on,
but
I
don't
think
we
should
tie
that.
We
should
just
start
adding
stuff
to
this.
This
this
tasks
draft.
A
C
Hey
Mike
just
trying
to
clarify
so
this
final
slide
you're
mentioning
this
is
what
we
discussed
about
addressing.
We
suggest
tasks
of
also
stuff
like
issue
tracking
systems,
and
these
kind
of
things
is
that
what
you
had
in
mind.
B
B
On
there's
been
things
like
talking
about,
you
know
representing
check
boxes
and
things
of
that
kind.
Yeah.
B
I
think
all
that
stuff
I
think
unless
it's
fundamental
to
to
this
extension,
I'd
be
inclined
to
just
push
this
out
without
addressing
those
and
and
then
we
we
we
address
it
in
in
the
context
of
of
you,
know,
JS
tasks
as
well,
so
it
becomes
an
extension
to
to
either
an
extension
to
both
or
something
that
is
rolled
into
the
JS
tests,
thing
which
hasn't
been
around
as
long
and
maybe
you
know,
depending
upon
people's
feelings,
on
how
the
time
skills
work
there.
That
might
be
a
better
place
to
address
it.
C
So
I
think
my
opinion.
This
would
be
I
mean
the
idea
how
this
went
into
how
we
added
these
ideas
to
do
to
the
JS
task.
Work
was
basically
to
think
about
it
from
a
portability
perspective,
to
see
like
what
things
are
similar
to
tasks
in
you
know,
in
in
groupware
systems,
and
so
on
and
I
think
I.
Don't
think
that
necessarily
the
things
we
add
there
you
know
would
need
to
get
back
to
I
calendar.
C
B
B
A
All
right,
I
guess
I
should
take
this
one.
Then.
A
B
I'll
give
a
quick
read
over
the
trying
to
try
and
read
it
over
the
next
few
days
and
let
you
know
if
I
found
anything
because
I
didn't
make
a
number
of
changes
for
the
the
V
status
and
the
participant
stuff,
like
I.
Think
it's
okay,
but
I'd
like
to
give
a
last
check.
But
in
the
next
few
days
I'll.
Let
you
know
cool.
A
Thank
you
all
right
next
on
our
agenda.
According
to
this
is.
B
Oh
there's
the
the
the
date
time
stuff
very
quickly,
just
to
remind
people
where
that
was
with
the
duration
of
DT
start.
A
B
Yeah,
so
just
to
remind
people
when
somebody
pointed
out
that
yeah
it's
that
last
sentence,
if
duration
appears
in
to
do
prop,
then
DT
start
must
also
appear
That's,
that
that
was
not
in
in
2445.
It
was
not
in
most
of
the
drafts
for
five
five
four
five.
It
suddenly
appeared
around
draft
seven
and
nobody
knows
why
not
even
Bernard
it's
just
there
and
it
doesn't
make
any
sense
in
in
it's
it.
B
It's
sort
of
pretty
much
fundamental
to
a
task
is
that
you
be
able
to
say
how
long
it's
going
to
take.
You
don't
need
to
say
when
it's
going
to
start
until
you
decide
to
actually
do
it,
so
it
it's
and
in
JS
calendar
we
don't
have
that
restriction
it
it.
It
absolutely
does
not
make
sense
in
terms
of
how
tasks
work.
So
can
you
just
move
on
a
bit
we'll
try
and
get
this
to
this
fairly
fast,
so
yeah.
So
this
is
that
yeah,
that's
what
I
just
said.
B
So
if
we
turn
on
the
next
one
yeah
I,
guess
that's
what
I
just
said
again:
yeah
and
yeah
there
we
go
and
then
why
it
matters.
So
so
I
think
the
last
slide
is
the
question.
B
B
Okay,
so
they're
still
working
to
the
2445
approach,
so
I
would
suggest
what's
the
next
slide
and
I
think.
B
Yes,
so
the
question
was:
how
do
we?
How
do
we
do
it
is
it
do
we
consider
it
to
be
an
error?
Bernard
doesn't
think
it's
an
doesn't
think
of
it
as
an
error,
because
he
actually
put
it
in
there
quite
deliberately,
but
he
doesn't
remember
why
and
we
never
discussed
it
because
nobody
noticed
until
a
few
months
ago,
so
I
don't
know
how
we
we
approach
this.
B
Do
we
add
it
to
the
tasks
draft,
which
is
one
reason
why
I
need
to
make
a
change
over
the
next
few
days
and
say
we
we're
updating
five,
five,
five,
four,
four:
five:
two
at
five,
five,
four
five
to
correct
this
issue:
would
that
be
a
better
approach?
I,
don't
I,
don't
think
we
can
call
it
an
errata.
H
H
I'm,
usually
more
in
favor
of
date
as
a
Errata
are
pretty
hard
to
find
I.
Think
yes,
but
that's
maybe
I'm
underestimating
some
some
other
issues
with
that.
A
B
Reason
I've
run
through
this
again
is
because
I
don't
think
we
ever
made
either
we
didn't
make
a
statement
or
I
forgot
statement,
so
I'm
I'm
happy
to
add
an
update
specifically
to
the
for
this
issue
in
them.
In
the
test
draft
and
and
point
out
as
you
as
you
say,
most
people
will
miss
it
as
narata,
so
well,
I
mean,
as
an
update,
makes
more
sense.
F
I
I
initially
stood
up
to
argue
For,
Narada
and
I
thought
I'd
talk
to
Murray
about
it
in
Philadelphia,
but
now
I'm,
not
so
sure
that
I
had
and
that
listening
to
Mike,
it
probably
does
make
sense,
given
the
fact
that
two
of
the
bigger
implementations
don't
enforce
that
restriction.
So
there's
probably
no
big
rush
to
try
to
file
on
a
rata
and
just
mention
it
in
the
test
traffic.
As
you
said,.
B
Yeah
I'll
add
this
section
that
probably
closer
to
the
beginning.
That
says
how
this
updates
that
particular
issue
and
then
and
then
move
from
there.
So
there's
a
change
I
have
to
make
before
we
do
last
call.
A
E
Well,
yes,
erratas
are
for
bugs
and
errors
or
clarifications,
but
they
shouldn't
change
the
meaning
of
the
original
RC.
But
that's
that's
the
case.
That's
fine!
We
didn't
rata.
B
B
It
makes
sense,
but
it
just
seemed
more
like
an
update
and
given
at
least
two
of
the
major
libraries
didn't
ever
Implement
that
that
change
in
the
first
case
we're
in
a
pretty
good
position
and
and
undoing
it
now
probably
stops
people
doing
and
might
give
a
little
more
visibility,
but.
E
F
B
B
So
this
is
in
in
light
of
all
the
discussions
we've
been
having
lately
over,
you
know,
Jazz,
calendar
and
and
and
the
rest
of
it,
and
what
I
came
to
realize
was
we
really
could
do
with
a
better
eye
tip
specification.
It's
it's
full
of
it
could
be
much
shorter
than
it
is
and
it
and
it
could
clarify
situations
a
lot
better.
It
deals
with
each
component
type,
each
method,
each
thing
separately.
B
It
doesn't
make
it
clear
that
you
can
and
should
be
sending
minimized
components
in
a
lot
of
cases
that
only
send
as
much
as
you
you
have
to
send
so
I
I
thought
this
would
be
a
good
time
to
consider
a
rewrite
of
itip
which
doesn't
necessarily
change
it.
My
you
know:
change
the
actual
workings
of
itip
I.
B
Don't
think,
there's
anything
wrong
with
with
itip
as
it
stands,
just
that
it
it's
really
hard
to
work
your
way
through
that
spec
and
and
understand,
what's
being
said,
and
it
also
has
some
relevance
to
VPO
in
the
VPO
updates,
itip
and
one
of
the
biggest
sections
is,
is
the
itip
updates,
because
itip
is
such
a
huge
draft,
a
spec?
Rather
so
the
I
did
start
looking
at
what
a
Rewritten
itip
might
be
like
and
I
started
copying
and
pasting
a
lot
of
stuff.
B
F
Yeah
this
is
Ken,
so
Mike
and
I
discussed
this
previously
and
I.
I
also
think
it
definitely
needs
a
rewrite,
as
Mike
said
it,
that
the
top
level
focuses
on
components
and
then
runs
through
each
method
for
each
one
of
those
and
I.
Think
by
and
large,
the
methods
are
pretty
consistent
across
all
the
components
so
I
think
starting
with
those
and
it's
describing
the
differences,
makes
more
sense.
F
B
B
All
right,
well
then,
I
guess
I
will
put
a
little
more
effort
into
into
that.
Then
I
did
make
a.
A
A
You
all
right
and
now
in
theory,
I
think
if
I
unshare
these
slides
and
then
screen
share.
A
Here's
a
Milestones
so
submit
subscription
upgrade
document
for
publication
obviously
needs
to
be
updated
to
now.
That's
going
to
happen
this
week.
Hopefully,
tasks
draft,
we
think,
is
just
about
ready
as
well.
A
Oh
yeah,
thanks
Francesca,
yes,
I'll
have
a
look
at
that.
I
I
believe
that
should
be
fine,
but
I'll
I'll
take
a
glance
through
foreign
document.
B
Possibly
I
I
think
that
it
updates
itip.
So
my
thoughts
were,
if
we
can
get
it
straightened
out,
it
would
make
the
job
of
of
it's.
The
biggest
part
left
to
update
in
vpoles
is
doing
the
itip
updates.
B
A
F
I
think
I'll
have
time
between
the
holidays
to
do
pet
projects
like
this,
so
I'll
make
a
conservative
effort
to
actually
both
read
it
and
re-implement.
It.
B
A
Series
and
server-side
subscription.
B
Series
I
need
to
get
back
to
I
haven't
had
a
chance
to
even
look
at
them.
So
what
what
day
do
we
got
on?
There.
B
F
Still
getting
something
out
of
apple:
aren't
we
it
definitely
works.
I'm,
Martin,
Guida
tested
it
way
back
when
I'm
in,
like
cologne,
I
think
at
a
cal
connect,
but
nobody
seems
to
be
banging
down
the
doors
for
this.
So
I
don't
even
know
if
it
you
know
where
we
stand
with
it.
To
be
perfectly
honest,
let's.
B
Let's
read
it
through
again,
and
maybe
maybe
it
next
week,
we
can
talk
it
over
somewhere
and
see
whether
whether
it's
attractive
enough
for
any
of
us
to
want
to
implement
it
anyway,
right.
B
Well,
Apple
have
something
that
they
do
use
and-
and
it's
not
quite
this,
and-
and
it
was
certainly
Apple
who
raised
it
in
the
past-
I-
think
you're,
just
a
little
more
active
on
the
calendaring
side,
they've
become
a
little
less
active.
B
Yeah
I
wouldn't
be
surprised.
They
come
come
back
to
this
at
some
point
in
the
future.
E
B
A
At
least
it
gives
us
some
rough
idea,
Jazz
calendar
mapping
document.
We've
already
said
that
it's
going
to
be
more
like
July.
Do
we
want
to
do?
That's
got
just
kind
of
bits
in
there
as
well,
so
that
this
whole
set
just
kind
of
mapping
document
can
I
edit
the
title
as
well:
no
I
can't
without
creating
a
new
one.
That's
okay
near
enough
is
good
enough.
A
Do
we
have
any
other
Milestones
to
add
at
this
stage?
Probably
yes,
we
need.
B
F
Yeah
quick
question
for
the
chair
regarding
adoption
that
does
Mike
have
to
have
a
full-blown
document,
or
mostly
just
an
outline
of
what
the
new
you
know.
Table
of
contents
is
going
to
look
like.
B
I'm
gonna
do
a
big
copy
and
paste
operation
and
see
how
close
I
get
to
looking
and
I'm
trying
not
to
modify
text
that
matters.
Obviously
so
I
think
the
copy
and
paste
is
going
to
work.
A
B
A
E
A
Then
cool
Francesca,
if
you
could
hit
the
button
on
that
one,
when
you
have
a
moment
Okay
add
the
new
I
tip
one
I
think
we
are
done
any
other
business
before
we
run
away.