►
From YouTube: URL URI Working group meeting 6
A
A
There
were
not
much
discussion
on
idea
for
compact
url,
so
I
have
added
that
as
the
first
item
for
this
meeting
today
I
have
seen
there
are
some
new
comments
added
to
the
agenda
with
respect
to
this
proposal
and
also
to
the
fem,
of
course,
so
yeah
trey.
If
you
would
like
to
maybe
start
from
adding
points
for
this
particular
ascent
item.
B
Sure
I
only
posted
last
night.
I
should
post
it
sooner.
If
anyone
wanted
to
comment
on
it,
I'm
linking
it
in
the
chat
now,
but
I
mostly
specked
out
what
bolt
11
like
payment
request
for
ethereum
would
look
like
with
you
know
several
of
the
tlv
tag,
types
that
trying
to
sort
of
one-to-one
match
what
681
supports
in
terms
of
different
kinds
of
messages.
B
B
I
know
there
is
some
objection
to
that,
but
I
thought
it'd
be
interesting
to
spec
it
out
in
case
that
could
convince
anyone,
and
I
thought
it
was
interesting
because
if
you
use
the
more
optimized
versions
of
a
more
optimistic
versions
of
how
to
communicate
some
of
this
information
like
assuming,
we
have
some
kind
of
global
token
contract
registry
that
is
generally
agreed
upon,
and
we
can
refer
to
that
instead
of
actually
including
the
full
addresses
using
like
token
lists
or
something
assuming
you
can
do.
That
and
people
have
enos
addresses.
B
Then
you
actually
end
up
with
similar
to
in
681,
really
really
short
payment
requests.
Since
you
don't
even
need
to
include
something
like
like
the
signatures
or
the
function
names
themselves
so
like,
like
you,
don't
need
to
say
to
call
the
transfer
function.
So
I
I
don't
know.
I
thought
it
was
neat
to
spec
that
out
aside
from
that,
I
don't
really
have
too
much
else
to
say.
B
A
A
A
All
right,
that
is
good.
Maybe
we
can
move
on
to
the
next
item,
which
is
about
the
update
since
the
last
meeting,
the
first
sub
item,
that
is
issue
67,
I
believe
that
is
merged
and
that
do
not
need
any
discussion
any
longer
yeah,
because
the
proposal
is
already
added
as
withdrawn.
So
I
think
the
author
should
be
good
enough
to
use
that
in
eip831,
so
yeah.
A
D
No,
I
think
that
I
will
see
what
will
happen
with
the
you
other
eips
that
are
dependencies,
that
I
actually
removed
the
dependency,
but
I
plan
to
include
it
back
so
once
that's
all
set
up,
I
think
we
can
move
move
to
the
next
stage
for
that
jp.
Maybe
I
don't
know
the
the
other.
Aips
are
already
good
to
be
used.
C
C
A
D
So
I
tried
to
remove
the
dependency
because
it
was
not.
It
was
a
stagnant
dependency
and
it
was
not
really
like
needed.
It
was
more
like
a
formal
thing,
just
included
as
a
japanese,
so
as
but
as
it's
it's
getting
finalized
as
well,
so
I
can
use
it
in
this
eip
as
well,
so
I
prefer
to
use
it
to
keep
the
definition.
I
think
it
makes
sense.
A
E
E
Yeah,
okay,
good
so
yeah.
So
one
question
is
regarding
the
so
if
it's
going
to
depend
on
eip
a31,
and
that
is
the
ui
format
for
ethereum,
one
thing
that
actually
have
some
question
is
like
right.
Now,
the
it's
more
defined
general
format
defined
for
ui,
but
eip4804
is
for
url,
which
will
have
the
basic
schema,
comma
and
then
double
slash
and
some
something.
So
I'm
suggesting
that
we
can
basically
set
up
some
prefix
as
the
double
slash
with
example
web3.
E
But
I'm
wondering
whether
if
there
is
any
restriction
or
prefix
or
when
we
should
put
this
kind
of
like
the
url
format,
explicitly
in
a
specification,
for
example,
that
before
the
prefix
pro
well,
we
may
have
the
double
slash
part
as
optional
if
it's
designed
for
url.
So
this
is
just
one
questions
for
dependency.
C
E
C
Right
so
so
I
guess
the
the
difference
would
be
a
urn
versus
a
url.
So
is
my
understanding.
Is
the
url
describes
where
to
get
a
document
as
opposed
to
urn
which
doesn't
describe
where
to
get
it,
and
it's
just
a
name.
So
our
4804
urls
are
sorry.
Our
4804
uris
are
the
urns
or
the
urls,
and
I
think
technically,
they're
a
urn
because
they
don't
give
you
like
a
server
address
to
go
to
they.
C
E
Yeah,
I'm
not
quite
sure
the
difference
between
you
are
and-
and
you
are
l
at
ui
and
I'm
pretty
sure
like.
Basically,
it
is
kind
of
like
a
similar
way
as
http,
including
the
format,
including
the
how
the
basic
query
and
authority
that's
what
I
read
from
the
document
saying
that
if
it's
in
discount
format,
then
it's
truly
like
a
url,
but
definitely
I
can
find
a
specific
document.
However,
where
the
url
is
defined
in
the
in
the
in
the
ui
document.
E
I
think
there's
one
document
that
formally
defined
what's
url
and
you
can
put
it
there
and
then
to
see
hey
whether
in
this
ui
format,
if
there's
a
convenient
way,
it's
also
be
able
to
support,
url
and
and
also
precisely
mentioned,
that
4804
is
kind
of
like
uil,
instead
of
like,
maybe
other
no
or
maybe
perhaps
also
a
uf
uim.
So
so
probably
we
need
to
some
effort
to
dig
in
and
find
out
the
difference
there.
C
E
C
E
This
is
one
thing
that
we
are
also
exploring,
but
actually
it
doesn't
change
the
current
content
of
opporaco4
because,
as
we
discussed
previously,
we
are
going
to
put
it
in
a
separate
eip
for
for
supporting
different
services.
So
right
now
the
current
format
is
still
after
some.
Some
changes,
then
yeah
and
then
we
are
also
going
to
change
their
return
types
to
returns.
E
E
C
I
I
don't
necessarily
see
a
problem
with
supporting
both.
I
think
it
would
be
better
to
define
returns
as
like
the
canonical
one
and
maybe
have
a
note
for
backwards
compatibility,
because
you
want
to
write
your
standard
as
like
how
you
want
it
to
be
seen
and
how
you
want
it
to
be
used
and
less
as
a
document
describing
what's
already
there,
because,
like
yeah
but
yeah,
whatever
you
want
to
do
is
fine.
I
think
yeah
yeah.
E
In
general,
there
are
a
couple
of
basically
company
members
approach
me
and
saying
that
they
would
like
to
apply
the
standard,
and
so
they
say
well,
it's
kind
of
like
immutable
format
or
it's
a
power
compatible,
and
I
think
that
I
think
this
is
something
that
we
are
going
to
do
so
yeah.
I
think
yeah
yeah
sam
you're,
right
yeah,
so
basically
it's
it's
better
than
we
can
just
we
will
put
fixing
returns
as
kinetic
when
say
region
types
is
optional,
but
not
recommended.
Yeah
great
cool.
A
I
think
that
was
the
last
item
listed
here
on
the
agenda
for
today's
discussion,
but
there
is
one
more
question
in
my
mind,
which
I
would
like
to
share
with
all
the
participants
here.
Do
we
think
that
we
need
a
bi-weekly
meeting
for
this
out
of
the
volatile
meeting?
That
is
there
for
like,
where
we
have
all
industry,
ebola
developers
and
one
meeting
led
by
sam
wilson?
A
C
A
E
A
Yeah,
and
in
addition
to
that,
like
we
can
probably
move
the
discussion
that
is
related
to
a
wallet
discussion
like
core
discussion
to
that
wallet.
Dev
meeting.
However,
if
there
is
any
question
common
concern
related
to
the
process
of
eip,
like
there
were
a
few
proposals
in
stagnant
status
like
831
and
2400,
which
we
try
to
bring
it
to
the
live
status
and
start
moving
it
pushing
towards
final.
If
there
are
any
questions
around
that,
if
authors
need
help
with
that,
sam
wilson
is
also
planning
to
lead
this
another
meeting
that
we
have
on
tuesdays.
A
A
E
A
A
A
C
A
Okay,
that
sounds
good
cool.
This
looks
like
a
quick
meeting
for
today.
Anyone
wants
to
add
anything
else,
I'm
going
to
update
the
notes
in
the
same
hackindy
document
and
share
it
in
the
discord
channel.
Probably
that
would
be
the
last
for
this
sort
of
meeting.
However,
we
are
open
if
we
need
any
kind
of
any
discussion.
Yeah
definitely
reach
out
and
we'll
try
to
have
meetings.