►
From YouTube: IETF-EMAILCORE-20221207-1630
Description
EMAILCORE meeting session at IETF
2022/12/07 1630
https://datatracker.ietf.org/meeting//proceedings/
A
D
E
B
C
B
So
I'll
look
and
do
some
discussions
on
the
trace
header
fields
on
the
mailing
list
and
offline.
It's
quite
clear
that
we
are
not
quite
ready
to
discuss
this,
so
the
proposal
is
for
chairs
to
create
design
team,
including
chairs,
and
editors
of
5321,
based
on
5322
bits.
If
anybody
else
wants
to
be
included
on
the
team,
please
let
chairs
know
and
the
design
team
will
come
up
with
a
specific
set
of
changes
to
the
both
documents.
This
is
kind
of
a
follow-up
to
what
was
discussed
at
itf115,
but.
B
B
B
F
G
B
B
E
A
Because
so
my
sense
is
for,
for
any
of
these
that
say,
standards,
action
or
iesg
approved
experimental
that
that
phrasing
comes
from
before
ietf
review,
existed,
I,
don't
see
any
issue
with
going
to
ietf
review
and
leaving
it
up
to
the
iesg,
whether
it's
appropriate
to
approve
an
informational
or
not
I,
don't
see
a
functional
difference
between
experimental
and
informational.
In
that
regard,.
B
Foreign
yeah
and
speaking
personally,
I
will
also
know
that
I
actually
wrote
and
received
how
the
field,
pasta
and
I'm
getting
some
very
interesting
results,
including
that
I
observe
other
values
like
HTTP
and
HTTP
rest
are
being
used
which
probably
should
be
registered,
I,
don't
think
the
experimental
they
are
already
in
use.
So
if
somebody
is
to
write
a
document,
that's
probably
going
to
be
informational.
B
F
The
key
question
here
is
whether
whether
we
should
go
even
further,
because
as
soon
as
you
start
making
the
argument
for
HTTP,
for
example,
you're
making
an
argument
that
that
the
independent
stream
ought
to
be
able
to
to
publish
a
document
called
big
codes,
transport
mechanism
for
email
and
and
register
with
that
informational
documentary
transport
mechanism
as
well.
I
started
really
strong
feelings
about
it.
But
if
we're
going
to
prevent
ITF
informational,
then
then
we're
at
that
boundary.
B
This
actually
brings
a
good
point.
I
was
actually
checked
what
we're
using
internally
and
we
have
various
other
transports
as
well,
which
again
I,
don't
think
they
might
be
documented
in
the
specification,
but
I
doubt
they
will
be
its
stream
documents.
If
we
decide
to
publish
anything
like
cftp
and
stuff
like
that,.
F
You
see
increasingly
unwilling
to
publish
gorilla
companies
specification
of
doing
so
and
so
and
it's
pushed
into
the
independent
stream
years
ago.
This
used
the
iitf
stream
documents
without
coming.
However,
that's
an
improvement
or
a
step
backwards
as
our
present-day
reality
and
the
only
other
thing
which
concerns
me
about
these
kinds
of
changes
is
the
IFC
having
changed
its
mind
to
change
his
mind
again,.
H
Because
I,
don't
I
think
we
want
these
documented,
but
I,
don't
think.
There's
a
big
downside
to
this
I
mean,
unlike
with
I,
think
there's
no
big
downside
to
having
a
bunch
of
these
in
the
long
run,
even
if
some
of
them
are
goofy
and
and
yeah
I
I
guess
I
would
be
okay
with
RFC
required
I'm.
Given
the
amount
of
well
consider.
If
the
isg
thinks
you
know
someone's
trying
to
register
something
idiotic
in
here,
they
can
push
back
against
the
independent
stream
and
say
hey.
H
F
E
G
Do
I.
Have
that
understanding
wrong,
because
it
sounds
to
me
like
what's
being
talked
about
now.
Raises
the
bar
and
and
I
don't
mean
relative
to
history.
I
mean
just
in
general.
Has
a
higher
bar
than
Regis.
Registration
typically
should
have
absent
a
clear
understanding
of
the
danger
of
registering
something
that
ain't
great.
A
Comment
was
just
I,
I
agree
with
what
Pete
said:
I'm
good
with
RFC
required
I
would
be
good
with
specification
required
as
well
I.
Don't
think
we
want
to
go
any
lighter
than
that,
because
we
do
want
the
specification
to
be
reviewed
for
these
things,
but
the
independent
stream
gets
reviewed
sufficiently
these
days.
That
I'm
good
with
RFC
required
and
I
agree
with
Dave
that
we
we're
better
off
encouraging
the
registrations.
B
B
B
E
H
I
typed
into
the
chat
room,
but
I'll
repeat
it
here,
just
in
case
I,
I
agree
with
Dave
and
principal
on.
The
first
come
first
serve
sort
of
default
mode,
and
my
thought
is
with
regard
to
message:
headers
the
odds
that
putting
a
new
stupid
one
in
really
doesn't
increase
the
interoperability
problem
for
anybody
else,
whereas
in
here,
because
things
might
want
to
parse
this
in
interesting
ways,
it
marginally
increases
the
possibility
of
an
interoperability
Problem
by
putting
crap
in
here.
H
F
If
people
do
creative
things,
we
might
or
not
agree
about
where
the
margin
lies,
but
I'm
a
little
bit
hesitant
about
getting
very
liberal
with
these,
as
distinct
from
the
others
and
to
a
considerable
extent-
and
we
could
say
this
inspected
even
wanted
to.
If
people
want
to
do
creative
things
here
without
going
through
a
serious
registration
review
process,
then
let
them
create
new
header
fields
and
then,
let's
argue
about
whether
those
Heather
Fields
or
Trace
fields
or
not,
but
but
but
I.
F
If
we
have
to
go
lower
than
that,
I'd
suggest
doing
the
same
two-track
thing
that
we've
tentatively
set
up
for
service
extensions.
So
if
somebody
doesn't
want
to
play,
they
have
to
explicitly
identify
themselves
as
not
wanting
to
play.
And
then
we
just
indicate
the
community
that
they
are
doing
this,
but
aren't
playing.
A
B
And
this
via
registry,
there
is
currently
two
values
registered,
but
it's
kind
of
actually
I
think
what
occurred
to
me.
While
doing
this
slide
is
I.
Have
this
mule
RFC,
which
is
multicast
email
not
published
on
ITF
stream,
which
really
should
have
registered
a
via
value,
because
it
you
can
consider
it
a
gateway.
B
E
A
F
C
F
This
makes
me
in
in
this
hierarchy
of
things
between
new
Heather
fields
and
messing
around
with
the
assistant
with
with
new
clothes
with
Clauses
in
existing
registered
Fields,
especially
ones
which
are
heavily
used
and
and
people
are
dependent
on,
like
pursued
I
I.
Think
there's
a
hierarchy
here.
I
think
this
is
more
dangerous
than
tampering
with
the
existing
existing
Clauses
and
putting
new
values
on
them
and
and
and
again
explicitly
pushing
people
toward
toward
new
header
Fields.
E
B
B
E
E
A
B
E
D
A
All
right
well
never
mind,
then
I'll
just
say,
as
I
said
on
the
list.
I
I
think
this
is
a
great
proposal
and
I'm
I'm
very
happy
with
with
where
it
sits.
It
strikes
the
right
balance
between
giving
people
the
opportunity
to
get
broader
review
and
input
from
the
community,
while
still
allowing
them
to
register
lightweight.
If
that's
what
they
want.
A
H
F
Since
you,
you
and
Barry
have
supported
this
mailing
list
and
and
I'm
taking
silence
for
everybody
else
during
this
discussion
is
concerned.
Unless
anybody
has
other
suggestions,
I'm
gonna
make
an
announcement
on
the
mailing
list
that
I'm
about
to
go
to
work
on
on
sorting
this
out
and
and
taking
out
the
spare
text
and
whatever
and
give
people
24
hours
to
respond
to
that
and
then
move
on.
Just
that's
a
reasonable
strategy.
B
E
A
A
F
Then
that
state,
then
something
becomes
a
trace
field
or
not
simply
but
author
declaration
and
to
the
extent
to
which
we
think
any
of
the
I
should
say
simply
by
registering
declarations,
documentation
that
required
and
to
the
extent
to
which
we
think
any
of
this
stuff
about
blocks
of
things
and
ordering
and
putting
things
together
and
not
intercoursing
stuff
is
of
any
value
whatsoever.
Having
something
be
a
trace
field
or
Not
by
author
declaration
is
sort
of
the
end
of
that.
F
So
I
have
a
because
of
that
concern
and
again,
depending
on
what
other
decisions
we
make
about
Trace
fields.
My
my
suspicion
is
that
we
should
make
this
that
we
should
put
this
into
the
Dual
track
model
and
and
not
require
not
permit.
Somebody
to
to
declare
something
as
Trace
field,
except
by
IDF
review,.
E
F
Again,
parenthetically
is
that
if
we
start
talking
about
other
kinds
of
blocks
like
reset
blocks,
then
arguably,
if
we're
going
to
put
something
in
the
registry
that
says
something
it's
a
trace
field,
we
should
allow
for
other
kinds
of
declarations.
If
something
is
part
of
a
different
kind
of
block
list,.
B
B
F
B
B
E
B
Right:
stick
it
about
78
octet
limit
versus
99
998
length
limit
I
suggested
some
possible
text
in
a
private
message
is
Pete.
Do
you
have
an
opinion?
Obviously
we
need
to
discuss
this
on
the
mailing
list,
but
I'm
just
trying
to
get
a
get
an
idea
whether
people
think
this
is
a
useful
addition
to
the
document.
H
B
B
H
F
My
concern
here
is:
we've
got
another
working
group
that
is
busy
doing
things
with
time
zones.
I've
got
two
concerns
versus.
We
got
another
working
group
which
is
busy
doing
things
with
time
zones
in,
in
all
sorts
of
other
things,
and
at
least
the
if
we're
going
to
do
something
which
is
different
from
that
working
group
from
what
that
working
group
is
trying
to
do,
then
I
think
we
should
at
least
be
explicit
about
that,
and-
and
the
second
concern
is
every
I
mentioned
this
on
the
list.
F
I
think,
is
that
every
use
we
have
had
so
far
in
a
standard
strike,
email
specification
that
has
used
data
receipt
Fields
as
far
as
I
know
has
has
done
so
as
a
time
stamp.
So
it's
always
the
date
at
which
something
happens
as
soon
as
we
start
having
specifications
floating
around,
including
the
one
which
is
now
in
last
call
which
are
talking
about
future
dates
that
all
the
issues
with
sedate
and
calex
have
been
struggling
with
about
how
you
specify
future
dates.
What
their
semantics
are
fall
into.