►
From YouTube: IETF-RSWG-20230928-2100
Description
RSWG interim meeting session
2023/09/28 2100
https://datatracker.ietf.org/group/rswg/meetings/
A
C
A
Boy,
the
delaying
on
muting
is
impressive.
Yes,
why
don't
we
get
going
I
hope
everyone
has
had
a
chance
to
read
over
the
note
that
I
sent
out
yesterday
and
if
you
haven't
looked
Brian
Carpenter
mentioned
that
he's
not
going
to
be
able
to
attend
so
sent
his
own
comments
on
those
we'll
start
by
mentioning,
although
I
hope
I
don't
have
to
display
that
this
is
an
ietf
meeting
and
therefore
the
note
well
is,
in
effect
so
all
of
ietf
processing
procedures,
including
I.
Well,
it's
not
an
IDF
meeting.
A
A
Basically,
Russ
and
I
chatted
yesterday,
as
I
mentioned,
with
Ecker,
to
sort
of
do
the
transition
to
the
new
chair
and
welcome
Russ.
Thank
you
for
jumping
in
on
this
and
congratulations
and
as
far
as
interim
for
today
and
tomorrow,
we
are
basically
going
to
open
the
floor
to
discussion
of
this
sort
of
broader
question
of
what
we
want
out
of
stability
out
of
archival
out
of
presentation
formats.
A
My
impression
for
the
past
month,
or
so
is
that
we've
been
dancing
around
sometimes
talking
across
purposes
and
so
I'd
like
people
to
sort
of
hone
in
on
those
questions
that
I
put
up
in
that
message.
Yesterday,
whoever
wants
to
jump
in,
we
can
use
the
queue
or
you
can
just
unmute
your
mic
and
if
it
gets
messy,
we
can
go
to
the
queue.
But
Joel
go
right
ahead.
D
Thank
you
Pete.
You
did
raise
interesting
questions
in
that
email
and
it
made
me
think
so.
Thank
you
to
start
with,
but
I'm,
not
at
all
sure
that
the
questions
actually
get
us
where
we
need
to
go
because
where
I
ended
up
was
thinking
about
all
the
ways
the
hypothetical
you
laid
out
could
go
wrong.
Having
nothing
to
do
with
the
question
you
were
trying
to
raise,
because
the
difference
between
pre-generated
renderings
and
we're
going
to
render
them
on
the
Fly
for
all
of
them
has
very
different
impacts
for
how
things
go
wrong
in
other.
D
Regards
and
I
simply
have
trouble.
Therefore,
using
that
as
a
paradigm
to
figure
out
what
do
I
consider
stable
I
do
think.
We
had
agreed
that
re-rendering
when
Rel
when
useful
was
okay.
That
was
in
the
rules
we
wrote
before
that
we
didn't
say
just
we
render
them
all
the
time.
I
don't
know
if
that
would
fall
within
it
or
not,
because
I'm
not
sure
it's
a
good
idea
in
and
of
itself,
and
therefore
I'm
not
sure
I
can
get
to
would
it
be
within
the
rules.
D
A
You
and-
and
you
know,
I
I
put
the
hypothetical
out
there
that
way,
simply
because
and
notice,
I
I
did
say
in
hypothetical.
Let's
say
that
the
the
that
the
production
Center
discovered
determined
that
it
would
be
a
lot
cheaper
and
a
lot
more
efficient
and
that
it
would
be
incredibly
useful
right.
We
were
going
to
premise
that
what
I
wanted
to
get
an
idea
of
from
folks
was
whether
you
thought
even.
E
Thanks
so
I
didn't
have
quite
the
same
view
as
Joel,
but
I
I
did
I
did
feel
that
about
the
first
question,
the
questions
two
three
four
and
five
I
thought
were
good
questions,
but
the
one
I
had
too
many
sort
of.
Oh
what
about
this?
What
about
that?
How
about
those
hypotheticals
that
that
was
the
one
that
just
seemed
to
be
really
stretching
the
hypothetical
bit.
E
A
A
A
That
would
be
acceptable
and
my
impression
started
to
become,
after
some
of
the
discussion
that
some
people
felt
that
no
presentation
formats
also
needed
to
be
stable
and
so
I
wanted
to
drill
down
on
how
essential
was
presentation
to
format
format,
to
people
and
maybe
there's
different
levels
but
sort
of
to
get
into
what
is
the
policy
statement
we
want
to
make,
because
the
policy
has
always
been
the
XML
stable
period
and
nothing
further
and
I
wanted
to
see
if
we
could
drill
down
a
bit
so
go
ahead.
Jay.
E
So
it's.
What
do
consumers
need
and
what
the
consumers
want,
that
are
the
I
think
the
more
important
things
are
nailed
down
and
that
then
drives
down
to
some
of
the
answers
about
these
questions.
I
think
doing
it.
This
way
around
is
which
is
problematic
for
me,
really,
that's
all
not
to
say
I'm
not
willing
to
do
it
I'm
very
willing
to
give
you
answers
in
triplicate.
If
you
want
about
these
things,
but
it
just
feels
like
the
wrong
direction.
F
Go
ahead:
oh
that's
good
Jay,
because
for
a
moment
there
I
thought
you
were
you're
going
to
be
shy
or
something
so,
thank
goodness
for
that
I
I
mostly
agree
with
Jay,
but
I
was
now
I've
been
trying
to
understand.
You
know
in
the
conversation
sort
of
where
Mark
you
know,
I
think
where
the
where
Martin
and
I
think
also
Karsten
and
others
are
are
coming
from.
F
You
know,
there's
a
I
I
think,
there's
a
a
desire
right
to
increase
sort
of
feature
velocity
and
to
provide
that
feature
velocity
across
you
know
the
existing
product
line
when
we
can
and
at
the
same
time
right
there's
there's
also
a
need
for
the
tool
chain
to
be
to
be
able
to
do
to
do
that.
Such
that
you
don't
keep
you
know
so
many
Forks
of
the
software
that
you
don't
know
how,
to
you
know,
fix
old
stuff
and
I.
I
feel
like
that.
F
F
Just
to
add
one
little
bit
of
flavor
to
that
I
I,
don't
mind
us
talking
about
wanting
to
get
to
say
a
place
where
we
have
that
feature
velocity,
but
what
I
am
a
little
concerned
about
is
doing
it
too
quickly.
So
if
we,
if
we
do
things
sort
of
step
by
step,
I
think
that'll
be
at
least
a
little
more
palatable.
I'll
stop
there
just
to
listen
to
I,
know
Eric.
F
E
F
G
Exactly
I'm
preparing
my
complaints
with
the
chairing
you
know
offline,
so
I'm
not
sure
I'm
ready
to
answer
these
questions
just
yet,
but
I
think
I
wanted
to
maybe
try
to
see
if
we
can
level
set
on
some
some
general
understanding,
so
I
think
the
first
thing,
I
would
say
is
I
think
like
what
people
consume
and
what
their
authors
basically
review
is
one
of
the
presentation
formats.
Now,
probably
not
all
the
the
people
consume
all
of
them.
G
Obviously
the
authors
in
my
experience
review
one
and
maybe
glance
at
the
XML,
but
I,
don't
think,
like
you
know,
I,
certainly
in
the
entire
time
I've
been
I
mean
I'm
in
ITF,
I,
don't
think
ever
hey
Richard
myself,
the
XML
was
like
doing
what
I
thought.
It
was
a
success
by
running
it
through
the
formatter
and
seeing
what
the
output
was.
So
I
think
that
if
anybody
like
really
disagrees
with
that,
I
think
that
you
could
still
speak
up
so
I
think
that's
just
like
I
think.
G
That's
actually
an
assertion
about
like
about
the
way
things
behave.
The
second
I
think
me
more
conversional
thing,
but
I
think
still.
A
plausible
assertion
is
that
you
know
if
things
are
not
treated
as
if
they
have
to
be
never
change,
then
the
stakes
are
screwing
up
or
lower
and
so
to
to.
Maybe
this
circle
is
a
little
bit
to
your
hypo.
G
You
know
if
it
is
the
case
that
we
like
re-render,
you
know
that
you
really
render
every
time
and
people
just
about
to
remember
every
time.
Then,
if
you
score
the
rendering,
once
or
twice
and
like
someone
catches
it
like.
That's
like
not
the
biggest
crisis
in
the
world.
You
know
I
mean
it's
worth
noting
he's
like
web
servers.
They
could
like
they
did
contaminated
I.
Think
it's
really
wrong
date.
At
any
time,
I
mean,
like
you
know
the
minute
you
allow
the
data
to
change
at
all.
G
G
So
so
I
think
you
know,
while
I'm
not
sure
how
I
feel
about
this
typo
of
like
costing
your
rendering
I
guess.
I
do
think
that
if
we
can,
if
we
persuade
ourselves
that
that
the
presentation
always
ever
change
at
all
and
then
there's
a
process
for
doing
that,
that
can
be
exercised
like
in
in
situations
other
than
extremists,
then
the
caught,
then
the
cost
of
error
in
a
rendering
will
come
somewhere.
B
I
think
I
think
at
this
point
largely
aligns
with
mine
the
the
sort
of
underlying
philosophy
that
I
think
we
managed
to
capture
reasonably
well
here,
which
is
that
the
interpretation
of
seven,
nine,
nine,
zero
and
and
friends
from
from
my
perspective
is,
is
one
that,
when
the
XML
is
the
same
but
ecker's
point
about
what
people
consume
and
use
and
whatever
is,
is
totally
relevant
here.
There's
a
number
of
cut
points
in
this
and
Pete
I
think
you've
really
taken
the
the
extreme
one.
B
In
your
note,
which
was
to
say
that
the
you
know
the
renderings
can
change
anytime,
I
think
what
I'm?
What
I'm
saying
from
the
discussion
is
that
people
are
looking
for
somewhat
more
stability
from
those
things,
or
at
least
some
ability
to
go
back
in
time
and
find
those
those
versions
of
things
that
were
rendered
in
a
particular
way
at
a
particular
point
in
time.
Just
because
we
wanted
to
make
sure
that
that's
absolutely
the
right
thing
to
do.
B
B
We
don't
force
someone
to
go
and
find
a
copy
of
XML
to
RFC
from
the
time
at
which
that
particular
RSU
was
published
and
used
that
in
order
to
ensure
that
they
get
exactly
the
right
whatever
it
is,
and
that
means
a
little
bit
of
care.
But
I.
Think
if
you
look
at
the
the
sorts
of
things
that
John
was
proposing
here,
that's
exactly
what
this
group
is
good
for
is
understanding
exactly
the
extent
of
which
the
changes
the
making
will
have
and
then
deliberate
about
those
those
changes.
A
A
C
C
It
is
right
to
the
idea
that
we
can't
change
the
access
formats
to
me
is
kind
of
absurd
and
as
long
as
we
are
kind
of
keeping
dated
versions
of
them,
which
is
kind
of
an
easy
and
already
solved
issue
I,
don't
see
any
problem
whatsoever
with
doing
that,
and
this
is
not
the
group
of
people
that's
going
to
do
stuff
willy-nilly.
So.
D
C
Not
too
worried
about
like,
let's
just
change
it,
because
it's
Thursday
that
doesn't
seem
like
a
reasonable
fear.
The
the
bigger
question
to
me
is:
can
we
change
the
XML
which
I
feel
like
we
don't
really
get
into
in
this
in
I?
Don't
know
if
that's
something
that
you
want
to
actually
talk
about
here.
A
A
It
also
leads
me
to
believe
that
there's
policy
that
can
be
written
about
presentation
formats
that
I,
don't
think,
is
solidly
written
at
the
moment,
so
yeah
I
I
do
think
we
get
to
the
question
of
what's
changeable
in
the
XML.
A
lot
of
my
questions
were
really
about.
People
seem
to
be
going
back
and
forth
about
issues
that
seem
to
have
to
do
with
presentation
and
not
the
XML
itself.
C
Yeah
I
mean
the
only
questions
you
answered
here.
You
asked
here
about.
Xml
was
what
are
the
upsides
and
downsides
right
like
to
to
changing
it?
To
me,
the
the
biggest
downside
of
not
changing.
It
is
in
shrining
errors,
making
the
old
XML
versions
hard
to
use
in
the
future.
It
makes
it
harder
for
us
to
manage
the
Corpus
in
a
sensible
way.
C
C
E
One
is
because
there's
an
error
in
the
underlying
data
I,
the
XML,
from
which
the
presentation
format
is
derived
a
second
one,
is
because
there's
an
error
in
that
rendering
of
that
specific
presentation
thing
and
the
third
one
is
because
we
have
chosen
to
enhance
the
that
rendering
in
some
way
unique
to
that
rendering
okay.
So,
for
example,
with
HTML,
say,
we've
decided
to
add
doubling
or
metadata
to
it,
for
example,
or
something
around
that
that
is
not
about
the
the
ROC
content.
E
It's
about
the
metadata
around
it
and
I
think
when
we
get
to
those
type
of
things
that
then
tells
from
those
reasons
that
drives
the
views
about
how
often
or
how
we
can
change,
because
we
that
there's
you
know,
though,
if
those
are
the
only
reasons
and
we
then
well
actually.
Sorry,
let
me
be
clear
if
we
take
that
nothing
in
there
drives
us
towards
any
particular
frequency
of
changing
or
anything
like
that.
H
B
B
Think
the
the
point
of
the
draft
is
to
describe
the
process
whereby
changes
are
possible
in
the
XML
become
possible,
and-
and
that's
something
that's
Robert
points
out
in
the
chat-
may
actually
be
necessary
for
all
of
the
existing
rfcs,
because
there
are
timestamps
in
those
that
are
not
tagged
with
the
time
zone
but
Pacific
time
in
some
way.
This
is
not
inconsequential
to
all
of
the
display
of
those
documents
probably,
but
it
has
implications
for
people
using
the
XML
in
other
ways.
B
I
think
a
lot
of
what
we're
talking
about
here
is
outside
of
what
I
believe
to
be
the
the
policies
that
we'd
set
out
for
this
group
and
I
would
I
think
this
is
probably
an
important
point
to
discuss.
I
think
the
generation
of
renderings
from
XML
is
something
that
this
group
should
not
Express
opinions
on
or
should
explicitly
disavow
in
the
extreme
and
this
and
then
maybe
maybe
in
in,
like
the
I'm
willing
to
go.
F
If
I
can
back
up
to
Jay's
separations
I
like
those
and
if
I,
look
at
I'm,
not
sure
I
I
want
this
group
to
be
entirely
hands
up,
but
it
mostly
hands
off
of
of
making
rendering
decisions.
The
only
I'm
going
to
sound
like
a
broken
record,
so
I'll
just
say
this
again
and
then
I'll
stop
saying
it.
The
only
thing
I
ask
is
that
we
be
incremental
in
our
approach.
So
what
I
liked
about
your
questions?
Pete
was
that
you
sort
of
Hit
the
polls.
F
If
you
will-
and
you
know
it
goes
back
to
you-
know
the
old
Leslie
Daigle
thing.
What
does
good
look
like
right
and
if
we
decide
that
you
know
good,
it
means
that
we
can
change
the
renderings.
We
have
the
you
know
in
all
of
those
three
categories.
We
might
have
different
rules
for
how
we
change
them
in
those
categories
and
I.
F
So
if
we
take
things
at
a
certain
Pace,
I
I,
don't
think
I
I
think
that's
a
good
way
to
go.
The
other
aspect
that
we
should
just
capture,
though,
is
how
we
reference
our
works,
how
those
references
remain
stable
in
terms
of
what
what
they
are
and
and
also
readable
right?
If
a
reference
becomes
a
hash,
we're
in
trouble.
A
F
Yeah
in
general,
I
I
agree
that
we
should
be
giving
broad
guidance,
but
you
know
we
certainly
don't
want
to
be
involved
in
every
change,
but
we
might
want
to
start
by
saying:
let's
try
a
few
specific
bit.
You
know
if
they're
people
want
to
do
big
changes,
maybe
the
first
couple
of
times
bring
them
to
the
art
to
the
rswg
right.
So
we
see
what
that's
like,
and
then
we
get
a
feel
for
what
we
have
to
pass
judgment
on.
What
we
don't
have
to
pass
judgment
on.
F
One
of
the
problems
we
have
is
we
have
a
whole
new,
it's
not
as
new
as
it
was
right,
but
we
have
a
relatively
new
structure
right,
and
so
we
need
to
learn
how
to
use
it
and
I
don't
want
to
get
into
the
rpc's
business
too
much
right.
Certainly,
if
they
spot
errors,
then
then
they
should
feel
free
to
correct
I.
Don't
see
you
know,
especially
on
individual
drafts,
individual
rfcs.
You
know
I
myself.
D
F
Because
I
then
spotted
Martin's
bug,
you
know
those
sorts
of
things
where
we
might
have
to
re-render
a
small
number
of
rfcs
because
of
that
or
even
a
large
number
of
rfcs,
so
long
as
it's
done
with
great
care,
where
there's
an
error,
I'm
almost
I'm,
pretty
much
okay
with
that,
we
start
talking
about
re-rendering
in
order
to
add
new
features.
I
would
like
to
just
pause
before
we
do
that
and
see
how
the
rest
of
the
re-rendering
process
works.
First,.
D
D
Then
I
think
we
should
stay
as
far
away
from
controlling
or
talking
about
policy
on
the
rendering.
As
practical
there
may
be
some
Corners
where
we
have
to
say:
hey,
don't
go
overboard,
but
in
general
we
should
be
staying
away
from
it.
The
RPC
and
the
tools
folks
have
to
work
out.
What
has
to
be
done
have
to
fix
bugs
if
things
don't
work
if
things
get
rent
or
wrong
Etc.
D
So
as
long
as
we
stick
with
that
premise,
but
I'm
I'm
specifying
that
caveat
over
again,
because
it
is
very
clear
that
there
are
folks
who
don't
want
to
stick
with
that
premise.
And
if
we
change
the
premise,
then
the
whole
question
of
rendering
suddenly
becomes
much
more
important
and
exactly
how
we
change
the
premise
determines
what
we
need
to
have
policy
about
and
I
I.
Don't
want
to
speculate
as
long
as
we
take
that
view.
D
I
do
think
we
still
need
should
allow
changes
to
the
XML
which
do
not
change
the
content
of
the
of
the
RFC
I.
Don't
actually
think
we
need
to
go
retrofit
date
time
time
zones
into
the
old
ones,
I
think
that's
a
bad
example
heck.
We
had
ones
that
had
only
months
in
them.
It's
okay,
the
world,
didn't
stop,
because
you
didn't
know
exactly
what
day
in
February
of
that
particular
year,
the
document
was
published.
It
won't
stop
because
you
didn't
actually
know
for
a
hundred
percent
provably
certain
what
time
it
was
really
published.
D
Hex,
we
don't
even
know
what
time
it
was
really
published.
Time
zone
is
a
Mark
we
put
in
it
to
to
give
a
reference.
I
have
no
problem
with
putting
in
time
zones
in
the
future,
but
I
don't
think,
there's
any
need
to
go
back
and
fix
the
XML
for
that.
On
the
other
hand,
if
we're
not
going
to
be
able
to
use
that
dag
postal
Line
library,
we
have
to
do
something,
so
we
can
render
stuff.
D
F
D
H
Okay,
so
you
know
the
question
of
oh:
it
doesn't
change
as
long
as
it
doesn't
change
the
content
of
the
XML,
suppose
somebody
transitions,
suppose
somebody
you
know,
and
they
don't
want
their
dead
name
associated
anymore.
Does
that
count
if
you're
looking
to
see
what
somebody
else
somebody
has
authored
before
and
after
they've
transitioned
I
mean
how
do
you,
you
know
you
can't
it's
hard
to
do
those
kind
of
searches
but
and
I
was
primarily
a
comment
on
minor
comment.
The
one
I
want
to
know
more
is
I.
H
H
A
I
mean
answering
for
myself
that
I
I
thought
you
were
asking
a
different
question
that
to
me
sounds
like
something
we
could
do
with
buy-in
from
the
streams
I.
Don't
think
we
would
ever
deign
to
do
that
independently,
okay,
but
I.
Think
if
we
were,
that
would
be
a
significant
policy
change
that
we
could
theoretically.
A
H
H
G
It
is
not,
and
so
I
I
I
don't
want
to
I
mean
we
have
a
number
of
different
people
suggested
canonical
definitive
whatever.
But
you
know,
if
you
imagine
some
imagine
some
hypothetical
defect
in
which
the
XML
clearly
said
one
thing,
but
the
XML
RC
clearly
like
did
something
else.
You
know
changed
a
one
to
a
zero
or
zero
to
one,
and
it
is
all
the
renderings.
G
You
know
we
would
not
go,
and
you
know
we
would.
We
would
look
extremely
silly
and
sustain
that
the
value
was
actually
into
XML,
because
that
is
not
not
how
people
interpret
interpret
the
situation
so
so
so,
whatever
like
terms
you
wish
to
apply
to
it,
the
thing
that
is
important
is:
is
a
pharmaceutical
consume
and,
as
our
earlier
produce
so
I
think
that
that's
the
first
thing
I'd
like
to
say
the
second
is,
it
seems
to
me
that
there
are
there.
G
Are
there
really
are
three
tiers
of
changes?
One
might
imagine
too
to
these
documents,
however.
However
one
can
see
for
them.
One
is
I,
think
the
ones
that
Joel
will
say:
don't
change
the
content,
namely,
oh,
oh
sorry,
May.
Fourth
years,
there's
things
that
are
bit
for
a
bit
identical,
they
may
say
like
ml,
but
but
the
but
that
but
every
single
rendering
format
is
identical
because,
like
hey,
we
added
a
space
or
something
that
is
not
non-semantic
in
an
SML
language.
G
Then
there
are
things
which
I
think
we
agree,
don't
change
the
content
in
any
meaningful
way,
but
but
but
but
we
do
change
the
bit
for
bit
rendering.
So
you
know
change
a
page
break
or
maybe
add
a
period
or
something
like
that.
Like
you
know,
you
know
face
and
have
a
graphical
error.
Then
there
are
things
of
the
form
that
rich
suggested,
which
do
change
the
content,
but
not
the
semantics.
G
Changing
people's
email
addresses
or
changing
people
or
changing
people's
names,
and
then
finally,
you
know
semantic
changes
and
I.
Think
all
four
of
those
need
to
be
like
potentially
considered
I
think
the
ones
that
like
I
I,
think.
Obviously,
you
would
need
you
a
week.
One
could
draw
the
line
anywhere
if
you're
on
a
line,
and
currently
the
line
is
like
it's
like
at
the
very
bottom
right.
G
B
Level
I'm
kind
of
okay,
with
with
echo's
position
here
which
is
like
we
should.
We
should
make
it
the
thing
that
people
use
the
problem
is
that
there's
no
one
thing
that
people
use
and
I'm
also
kind
of
I.
Think
at
the
view
that
we
should
probably
do
this
incrementally
and
and
do
small
steps
at
a
time
and
I
heard
Joel.
B
Basically
earlier
saying
exactly
what
the
draft
that
I
wrote,
attempts
to
say
and
so
I
think
that
if
we,
if
we
try
to
concentrate
on
those
questions,
we
would
get
ourselves
a
little
bit
further
in
this
conversation,
I
think
Echoes.
Ultimately,
right
people
read
the
text
on
HTML
version,
so
I
don't
know
how
many
people
read
PDF,
but
that's
another
another
problem.
B
The
the
questions
that
I
think
are
most
important
in
this
context
are
understanding
what
guidance
we
give
the
RPC
in
terms
of
generating
the
the
presentation
formats
and
what
changes
we
allow
now
and
then
in
the
future,
to
the
The,
Source
format
and
I.
Think
that's
that's
where
I'd
like
us
to
concentrate
our
efforts
incrementally
incremental
changes,
as
opposed
to
big
ones,.
G
You
know:
we've
there's
been
a
bunch
of
discussion
about
that
about
the
that
the
potentialism
that
want
to
want
to
say
here,
I'm,
not
sure
I've
had
anybody
say.
Yeah
Morton's
draft
goes
too
far
as
understood
by
the
way
people
have
been
characterizing
it
here.
So
I
think
it
might
be
useful
to
hear.
Are
there
people
who
think
that
Martin
like
I'm,
not
sure
if
it's
far
enough
but
I'm,
fine
I'm
fine
with
doing
it?
So
are
the
people
here?
F
G
F
That
I'd,
like
the
draft
to
reflect,
is
what
you
said
right,
let's
be
incremental
about
how
we
go
about
this,
it's
okay
to
do
an
r,
a
couple
of
RFC
revs
on
this.
In
my
opinion,
in
terms
of
policy
like
so
that
we
set
the
policy
to
you,
know
to
slow
start,
and
then
we
we
reset
the
policy
to
have
a
broader
scope
to
allow
more
change
as
we
get
more
as
we
get
more
experience
and
I'd
like
to
see
that
covered.
F
H
B
F
E
E
E
What
matters
to
me
is
the
correctness
of
the
content,
so
it's
perfectly
possible
that
we
may
do
something
in
the
XML,
so
we
may
make
the
change
the
XML
to
add
some
new
features
to
it
that
do
not
affect
the
PDF
rendering.
Okay,
in
that
circumstance,
I
see
no
reason
to
re-render
the
PDF.
In
fact,
I
actually
think
it's
preferable
to
leave
the
PDF
as
it
is,
rather
than
to
re-render
it
and
I.
A
B
Responsibility
there
I
heard
what
he
said
on
the
the
mailing
list.
I
have
an
open
pull
request
against
the
draft
that
sort
of
tries
to
capture
some
of
the
intent.
I
think
I
may
have
shared
that
almost
at
one
point.
I
can
make
a
revision
to
the
to
the
draft
at
any
time
there.
Just
wasn't
enough
change
queued
up
to
really
make
that
worthwhile,
but
I
can
certainly
do
that
if,
if
that
makes
people
more
comfortable.
G
Preview,
respond
to
Jay,
I
I
think
it
would
also
be
okay
if
we
did
not
if
we
don't
re-render
all
the
documents,
the
time
that
at
the
time
that
that
the
the
tools
changed,
I
think
that
okay,
so
I
think
the
XML
changes
were
documented,
which
would
be
rendered.
That's,
like
seems
like
bad
practice,
is
not
too
I.
G
Think
the
tools
changed
I,
don't
think
it's
necessary
written
anywhere,
necessarily
but
I
think
I
want
to
distinguish
between
I
think
the
Minimus
changes
to
the
output
and
real
changes,
the
output,
so
concretely
the
outputs
maybe
have
a
time
stamp
in
them
and
if
nothing
that
changes,
but
the
timestamp
then
I
think
it's
reasonable.
That
I
think
it's
reasonable
to
say
well,
older,
rendering
is
fine,
but
as
a
matter
of
software
validity
you
know
the
software
should
be
regenerating
every
time
we
make
a
change
the
XML.
G
We
should
be
regenerating
all
the
rfcs
and
verifying
that
only
diminished
and
intended
changes
were
made
to
the
outputs
because
yeah,
it's
just
simply
a
matter
of
having
appropriate,
appropriate
software
engineering
practice.
I.
Think
if
you
do
that,
then
it'll
be
fine
to
say.
Well,
you
know
these.
The
only
difference
is
the
output,
a
and
output
B
is
the
timestamp.
G
We're
not
going
to
put
the
timestamp
effectively
is
a
fun
thing
to
say,
and
then
of
course,
I
will,
like
repeat
what
I
said
earlier,
which
is
if
we
get
comfortable
doing
the
renderings
reasonably
frequently,
and
we
need
to
that's
an
issue
if
we
accidentally
inadvertently
introduce
a
change
which
we
didn't
mean
to,
and
it
looks
bad
and
then
we're
like
well
now,
I
guess
we'll
push
the
rearender
button,
it'll
be
fine,
so
I
think.
If,
if
we,
if
we
make
we
rendering
a
low-cost
operation
and
it
becomes
less
important
every
time.
A
C
C
This
is
a
very
broad
thing
to
say:
I,
don't
know
exactly
what
thing
would
be
you
know
changing
and
and
how
it
would
change
right.
But
I
would
imagine
that
we
have
some
known
problem
documents
or
some
known
problem
scenarios
that
we
could
test
things
against
when
things
get
changed,
whether
we
publish
them
or
not.
A
E
Thanks
I
think
it's
important
to
remember
that.
Well,
I,
don't
remember:
I'll,
explain,
I,
think
that
re-rendering
is
a
high
risk
operation
and
is
a
it
is
inevitably
a
high
risk
operation,
because
I
do
not
think
that
there
is
any
practical
mechanism
whereby
we
can
take
two
renderings
of
the
same
thing
and
ensure
that
we
have
not
accidentally
damaged
it.
Somehow,
the
content,
without
using
a
lot
of
Human
Resources
to
do
that,
I
think
it
by
the
very
nature
of
it.
E
It's
not
something
that
can
be
that
the
correctness
can
be
checked
easily
automatically
across
that
and
therefore
for
me
that
makes
it
high
risk
and
therefore
that's
something
that
I
would
suggest
we
have
tried
to
avoid
doing,
except
when
we
have
to
it
should
not
become
even
if
it
becomes
a
trivial
thing
to
do.
Technically,
it's
still
to
me
is
not
something
we
should
be
doing
unless
we
have
to.
E
Yeah
well,
the
risk
is
that
that
the
rendering
the
new
rendering
has
a
bug
in
it
that
misses
some
part
of
the
content
or
something
so
we've
had
regular
examples
of
PDFs
rendered
with
bits
missing
from
them.
Okay,
so
we
we
have
a.
There
are
all
sorts
of
things
that
can
go
wrong
within
the
rendering,
but
detecting
those
is
a
hard
problem,
and
that's
why
I
don't
think
we
should
be
doing
it
except
you
know
when
we
have
to.
F
If
we
don't
have
that
automated
tooling,
we
might
not
catch
that
change
for
years
and
also
going
to
a
point
that
Ecker
made
right.
If
we,
if
there
is
a
change
right
and
the
authors
aren't
available
right,
do
we
really
or
you
know,
or
if
the
you
know,
the
isg
hazard
you
know
turned
over
if
it's
whatever
the
case
may
be
right.
F
D
I
think
I'm
going
to
be
saying
largely
what
Jay
said
from
a
slightly
different
angle.
We
had
this
discussion
on
the
list.
People
said
we
need
to
re-render
in
order
to
know.
If
we
worked
it
right
and
I
asked
how
the
heck
would
you
know
if
you
did
it
right,
because
you
can't
tell,
and
yes
there
are
things
you
can
check,
but
you
can't
automatically
check
all
of
the
aspects
and
we
can't
manually
check
each
and
every
one.
D
So
in
fact
a
claim
that
we
would
be
incurring
technical
debt
if
we
don't
re-render
them
doesn't
actually
seem
to
stand
up
because
we've
we
we're
not.
We
can't
avoid
the
technical
debt
by
re-rendering
them.
I
am
not
prepared
to
turn
the
community
of
users
of
the
RFC
series
into
beta
testers
of
our
changes.
That
is
as
far
as
I'm
concerned
and
unacceptable.
I.
A
G
Yeah,
so
maybe
maybe
I
tried
to
tease
a
few
things
apart.
First
of
all,
I
think
there's
I'm
not
happy
to
have
another
word,
there's
re-render
and
there's
publisher.
So
my
position
is
to
be
clear
that
the
system
should
in
continuous
integration,
re-render
every
single
RFC
and
check
it
against
the
and
check
it
against
the
previously
previous
rendering
and
then
throw
it
away.
G
It's
fine,
but
it
should
regenerate
it
and
that's
probably
a
form
of
that's
a
form
of
testing
for
regression
right
and
then
and
I'm
more
than
happy
in
the
circumstances
to
not
publish
the
output.
But
you
have
to
be
running
the
tools,
respect
to
J's
point
I'm,
sorry,
but
I
shall
understand.
I,
don't
understand
the
argument
here,
like
the
check
should
be.
G
Is
it
bit
for
bit
identical
module
of
the
changes
we
know
it
introduces
and
if
the
tool
chain
and
if
you're,
introducing,
if
you're
introducing
changes
the
tool
chain
that
are
producing
bit
for
bit,
not
identical
things-
and
you
didn't
mean
it-
you
know
problems
with
the
tool
chain
and
and
so
like.
So
so,
there's
no
ways
to
deal
with
this,
which
is
you
have
true?
You
have
you
rerun
the
tools
and
if
it's
before
been
an
ethical,
then
you're?
G
D
F
Little
late
here,
my
brain's
running
just
a
little
bit
slower
and
we
do
have,
but
four
minutes
left
so
yeah,
so
I'll
try
and
be
brief.
I
think
there's
a
fair
amount
of
Common
Ground
here
from
which
we
can
build
I'm,
actually
pretty
optimistic
on
what
I'm
hearing
Eric
you're,
you
do
have
a
lot
more
experience
in
that
tooling
aspect.
You
know,
I,
like
I,
said
I
had
that
discussion
with
John
online.
F
D
F
F
You
know
in
in
in
at
the
end
of
days,
if
you
will
doing
re-rendering
but
not
republishing
at
some
point
and
then
you
know
going
backwards
from
there
and
you
know
what
what's
our
first
step,
we
have
to
figure
that
out
and
and
I
don't
want
to
micromanage
the
RPC,
but
I
want
I
want
to
make
sure
that
we're
also
doing
this
at
a
pace
where
the
RPC
can.
You
know,
learn
get
operational
experience
boy,
I'm,
beginning
to
sound
that,
like
like
a
broken
record
again
so
I'll
stop.