[Uri-review] Re: [saag] Re: Re: Re: Fwd: [IANA #1449893] Registration of URI scheme 'cttps'

--===============0539442046641522858==
Content-Type: multipart/alternative; boundary="00000000000039af590651a44da9"

--00000000000039af590651a44da9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with Paul that this is a silly registration and that the
specification is incomplete.

However, I think that Section 7.2 and then Section 7.4 are clear that
no specification is required. Specifically:

S 7.2:

   3.  If the registration request is for a 'permanent' registration
       (or, optionally, for any other registration if desired):

S 7.4.
   References:
     Include full citations for all referenced documents.  Scheme
     registration requests for 'provisional' registration can be
     included in an Internet-Draft; when the documents expire or are
     approved for publication as an RFC, the registration will be
     updated.  A scheme specification is only required for 'permanent'
     registration.

In fact, as I read this text, for a provisional registration I could
simply provide a template with no real details at all other than the
POC, Change controller, etc. As Ted says, the rest of the text is just
kind of non-binding for provisional registrations.

Whether this is a good policy is a distinct question, but it seems to
me that the real argument here is whether it's worth having a separate
provisional category at all rather than just having everything being
FCFS. It's not like we're at risk of running out space, though I
suppose we might run out of cool-sounding schemes.

-Ekr






On Tue, May 12, 2026 at 12:21=E2=80=AFPM Mark Baker <[email protected]> wrot=
e:

> On Tue, May 12, 2026 at 3:09=E2=80=AFPM Paul Wouters <paul.wouters@aiven.=
io>
> wrote:
> >
> >
> > On Tue, May 12, 2026 at 10:21=E2=80=AFAM Ted Hardie <[email protected]=
> wrote:
> >>
> >> Hi Paul,
> >>
> >> If you read section 7.1 of RFC 7595, you will see that the provisional
> registrations are provided on a first come, first served basis.  This
> serves the primary goal of the registry, which is to avoid collision amon=
g
> different uses of what might appear to be the same URI scheme.  The
> guidelines in section 4 do have requirements, but only at the SHOULD leve=
l
> and they are intended to be guidelines to the registrant.  The process fo=
r
> updated a registration to permanent or making a new permanent registratio=
n
> directly is the one in which the invited expert's approval is required.
> >
> >
> > A first come, first serve does not mean that you can register anything
> without proper specification.
> >
> > As you can see in section 7.2 of RFC 7595, there are a few MUSTs, and
> one of them is to comply to Section 3, see the Section 7.2 MUST heading a=
nd
> bullet point 3
> >
> > We are not to judge the merit of proposals, but we do judge proposals
> for proper specification that can be understood and implemented and that
> they don't simply offer what is already offered by existing registrations=
.
> This proposal fails both these last points.
>
> Wearing my designated expert hat, Ted is correct. The 7.2 MUST
> reference to section 3, is for permanent registrations only, which
> this is not.
>
> Mark.
>
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

--00000000000039af590651a44da9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree with Paul that this is a silly registration and th=
at the<br>specification is incomplete.<br><br>However, I think that Section=
 7.2 and then Section 7.4 are clear that<br>no specification is required. S=
pecifically:<br><br>S 7.2:<br><br>=C2=A0 =C2=A03.=C2=A0 If the registration=
 request is for a &#39;permanent&#39; registration<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0(or, optionally, for any other registration if desired):<br><br>S 7.4=
.<br>=C2=A0 =C2=A0References:<br>=C2=A0 =C2=A0 =C2=A0Include full citations=
 for all referenced documents.=C2=A0 Scheme<br>=C2=A0 =C2=A0 =C2=A0registra=
tion requests for &#39;provisional&#39; registration can be<br>=C2=A0 =C2=
=A0 =C2=A0included in an Internet-Draft; when the documents expire or are<b=
r>=C2=A0 =C2=A0 =C2=A0approved for publication as an RFC, the registration =
will be<br>=C2=A0 =C2=A0 =C2=A0updated.=C2=A0 A scheme specification is onl=
y required for &#39;permanent&#39;<br>=C2=A0 =C2=A0 =C2=A0registration.<br>=
<br>In fact, as I read this text, for a provisional registration I could<br=
>simply provide a template with no real details at all other than the<br>PO=
C, Change controller, etc. As Ted says, the rest of the text is just<br>kin=
d of non-binding for provisional registrations.<br><br>Whether this is a go=
od policy is a distinct question, but it seems to<br>me that the real argum=
ent here is whether it&#39;s worth having a separate<br>provisional categor=
y at all rather than just having everything being<br>FCFS. It&#39;s not lik=
e we&#39;re at risk of running out space, though I<br>suppose we might run =
out of cool-sounding schemes.<br><br>-Ekr<br><br><br><br><br><br></div><br>=
<div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"=
gmail_attr">On Tue, May 12, 2026 at 12:21=E2=80=AFPM Mark Baker &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">On Tue, May 12, 2026 at 3:09=
=E2=80=AFPM Paul Wouters &lt;<a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Tue, May 12, 2026 at 10:21=E2=80=AFAM Ted Hardie &lt;<a href=3D"mai=
lto:[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:=
<br>
&gt;&gt;<br>
&gt;&gt; Hi Paul,<br>
&gt;&gt;<br>
&gt;&gt; If you read section 7.1 of RFC 7595, you will see that the provisi=
onal registrations are provided on a first come, first served basis.=C2=A0 =
This serves the primary goal of the registry, which is to avoid collision a=
mong different uses of what might appear to be the same URI scheme.=C2=A0 T=
he guidelines in section 4 do have requirements, but only at the SHOULD lev=
el and they are intended to be guidelines to the registrant.=C2=A0 The proc=
ess for updated a registration to permanent or making a new permanent regis=
tration directly is the one in which the invited expert&#39;s approval is r=
equired.<br>
&gt;<br>
&gt;<br>
&gt; A first come, first serve does not mean that you can register anything=
 without proper specification.<br>
&gt;<br>
&gt; As you can see in section 7.2 of RFC 7595, there are a few MUSTs, and =
one of them is to comply to Section 3, see the Section 7.2 MUST heading and=
 bullet point 3<br>
&gt;<br>
&gt; We are not to judge the merit of proposals, but we do judge proposals =
for proper specification that can be understood and implemented and that th=
ey don&#39;t simply offer what is already offered by existing registrations=
. This proposal fails both these last points.<br>
<br>
Wearing my designated expert hat, Ted is correct. The 7.2 MUST<br>
reference to section 3, is for permanent registrations only, which<br>
this is not.<br>
<br>
Mark.<br>
<br>
_______________________________________________<br>
saag mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">saa=
[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" targ=
et=3D"_blank">[email protected]</a><br>
</blockquote></div>

--00000000000039af590651a44da9--


--===============0539442046641522858==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVXJpLXJldmll
dyBtYWlsaW5nIGxpc3QgLS0gdXJpLXJldmlld0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5k
IGFuIGVtYWlsIHRvIHVyaS1yZXZpZXctbGVhdmVAaWV0Zi5vcmcK

--===============0539442046641522858==--