Subject: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Jul 2020 09:00:30 -0700

The IESG has received an appeal from Tim McSweeney regarding
draft-mcsweeney-drop-scheme and his related registration requests to IANA.
The appeal has been posted on the appeals page:

https://www.ietf.org/standards/process/appeals/

Additional information has been requested from both Tim and IANA.  Once
those details have been received, the IESG will proceed to evaluate the
appeal and render a decision.

Barry and Murray, ART Area Directors

For the IESG

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 Jul 2020 12:24:35 -0400

Two of the point in the appeal talk about overriding a consensus, but from the appeal text, I cannot tell where the consensus was reached.  I suspect that there is context know to people that have been involved in this since April, bt that does not include me.  Can these pointers to the consensus call(s) be provided?

Russ

> On Jul 16, 2020, at 12:00 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> The IESG has received an appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme and his related registration requests to IANA.  The appeal has been posted on the appeals page:
> 
> https://www..ietf.org/standards/process/appeals/ <https://www.ietf.org/standards/process/appeals/>
> Additional information has been requested from both Tim and IANA.  Once those details have been received, the IESG will proceed to evaluate the appeal and render a decision.
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Jul 2020 17:46:16 +0100

Russ

I make no comment on the content of the thread, but I think you need to look
at
https://mailarchive.ietf.org/arch/msg/uri-review/Zm_spdzPvzlf7uXMdLKQ4xMSXlU
/

Cheers,

Adrian

From: ietf <[email-masked]> On Behalf Of Russ Housley
Sent: 16 July 2020 17:25
To: Murray S. Kucherawy <[email-masked]>
Cc: IETF <[email-masked]>
Subject: Re: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme

Two of the point in the appeal talk about overriding a consensus, but from
the appeal text, I cannot tell where the consensus was reached.  I suspect
that there is context know to people that have been involved in this since
April, bt that does not include me.  Can these pointers to the consensus
call(s) be provided?

Russ

On Jul 16, 2020, at 12:00 PM, Murray S. Kucherawy <[email-masked]
<mailto:[email-masked]> > wrote:

 <https://www.ietf.org/standards/process/appeals/>
https://www..ietf.org/standards/process/appeals/

For the IESG

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jul 2020 09:22:30 +1200

Thanks Adrian. I noted this comment a long way down the thread:
"You cannot register a URI scheme that does not conform to the RFCs which
govern URIs."

Regards
   Brian Carpenter

On 17-Jul-20 04:46, Adrian Farrel wrote:
> Russ
> 
>  
> 
> I make no comment on the content of the thread, but I think you need to look at https://mailarchive.ietf.org/arch/msg/uri-review/Zm_spdzPvzlf7uXMdLKQ4xMSXlU/
> 
>  
> 
> Cheers,
> 
> Adrian
> 
>  
> 
> *From:*ietf <[email-masked]> *On Behalf Of *Russ Housley
> *Sent:* 16 July 2020 17:25
> *To:* Murray S. Kucherawy <[email-masked]>
> *Cc:* IETF <[email-masked]>
> *Subject:* Re: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme
> 
>  
> 
>     On Jul 16, 2020, at 12:00 PM, Murray S. Kucherawy <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Jul 2020 16:15:24 +0200

> I make no comment on the content of the thread, but I think you need to look at https://mailarchive.ietf.org/arch/msg/uri-review/Zm_spdzPvzlf7uXMdLKQ4xMSXlU/

I can quickly summarize what I read in that thread:

- a proposal was made for a registration in the URI scheme registry
— over the course of the thread, several people explained why that was not technically a proposal for a URI scheme, and pointed to relevant RFCs (this would be the part that I’d call consensus); some made other comments as well
— the thread degenerated into a mode that is best described by the German phrase “Ich esse meine Suppe nicht” [1].

Grüße, Carsten

[1]: https://de.wikisource.org/wiki/Der_Struwwelpeter/Die_Geschichte_vom_Suppen-Kaspar

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 17 Jul 2020 10:07:48 -0500

Carsten,

> Grüße, Carsten

deleted to

> [1]:
> https://de.wikisource.org/wiki/Der_Struwwelpeter/Die_Geschichte_vom_Suppen-Kaspar

I'm using a browser that translated automatically into English.

Why do I not already know this story?

Thank you for making my day!

Spencer

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Jul 2020 12:05:40 -0400

> Why do I not already know this story?

I too used a browser which translated into English -- sadly though I'm
still mystified.

I understand all of the (translated) words, but I'm unable to parse
the meaning of the story/idiom - healthy kid used to like eating soup,
but then for some reason claims/decides that he no longer eats soup,
and dies.
I did manage to find (on https://en.wikipedia.org/wiki/Struwwelpeter):
 Die Geschichte vom Suppen-Kaspar ("The Story of Soup-Kaspar") begins
as Kaspar (or "Augustus" in some translations), a healthy, strong boy,
proclaims that he will no longer eat his soup. Over the next five
days, he wastes away and dies.

Is this a "someone (unreasonably) digs their heels in, and then is
sufficiently unwilling to change that they suffer bad consequences"?

Note: I really am not being snarky; it seems that the Suppen-Kaspar
(and other Struwwelpeter stories) are well understood within Germany.
I understand the morals behind the other stories in the series, but
the Suppen one I sadly don't get -- I did find a much longer English
translation (https://germanstories.vcu.edu/struwwel/kaspar_e.html ),
but I *still* don't get the underlying message - *why* did he decide
he didn't like soup? What's the moral? Do what your parents tell you?
Be flexible? Don't "cut off your nose to spite your face"?

Idioms fascinate me,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Jul 2020 18:16:34 +0200

On 2020-07-17, at 18:05, Warren Kumari <[email-masked]> wrote:
> sufficiently unwilling to change that they suffer bad consequences”?

I just wrote in a different thread, offline:

> Its a very useful metaphor for someone who just doesn’t want to accept some part of reality and incurs unwanted consequences from actively, happily ignoring it.
> I haven’t found an English-language equivalent…

Sorry about turning this into a thread about German culture.
You of course have Mark Twain, but I’m not going to cite him on-list on this issue.

Grüße, Carsten

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Jul 2020 12:39:16 -0400

> > Its a very useful metaphor for someone who just doesn’t want to accept some part of reality and incurs unwanted consequences from actively, happily ignoring it.

Ah! Now I get it! Cool, thanks....

> Sorry about turning this into a thread about German culture.

*You* didn't, Spencer and I did :-)

Idioms can be interesting and a useful way to communicate something
with substantial subtleties. Perhaps we should have an ietf-offtopic@
list where we can have general chats to share interesting asides,
etc..... although, the more I think about it, the more I suspect that
that is what ietf@ is :-)

W

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 17 Jul 2020 12:48:09 -0500

Hi, Warren,

On Fri, Jul 17, 2020 at 11:39 AM Warren Kumari <[email-masked]> wrote:

> > > Its a very useful metaphor for someone who just doesn’t want to accept
> some part of reality and incurs unwanted consequences from actively,
> happily ignoring it.
>

I wonder (for about 30 seconds) about a mailing list or, maybe better, a
wiki on obscure language at the IETF. This would absolutely have worked
there, for follow-ups, and I'm pretty sure I'm hard enough to understand
that I could populate half of it myself.

I remember the first time I used the phrase "let me give you a heads-up"
with a Chinese manager, who had no idea what I meant until I explained that
some animals post a lookout to watch for predators while everyone else
eats, so when the hawk flies over, the lookout barks or whistles and
everyone else raises their head to see what is happening. Meerkats do this (
https://animalfactguide.com/animal-facts/meerkat/#:~:text=One%20meerkat%20will%20stand%20on,lets%20out%20a%20distinctive%20bark.
)

Or, I could have googled for https://www.theidioms.com/heads-up/, but I
like meerkats.

Best,

Spencer

---

From: Larry Masinter <[email-masked]>
Date: Fri, 17 Jul 2020 11:31:14 -0700

RFC <http://www.rfc-editor.org/rfc/rfc7595.txt>  7595, "Guidelines and Registration Procedures for URI Schemes", June 2015

as modified by https://www.rfc-editor.org/errata/rfc7595 was a mistake.

The idea behind RFC 7595 was to change https://www.rfc-editor.org/info/bcp35 to make “provisional” registration FCFS.

And the errata was correct in its identification of the problem that FCFS is incompatible with having requirements that need to be checked.

But the proper remedy (as this case shows) should have been to change it back to “expert review” as it was in RFC 4395.

If “expert review” could optionally be accomplished by (dis)approving a Pull Request in an IANA-maintained Git repository (as was recently done for .well-known) so much the better.

--

 <https://larrymasinter.net/> https://LarryMasinter.net  <https://going-remote.info/> https://going-remote.info

---

From: Tim Bray <[email-masked]>
Date: Fri, 17 Jul 2020 11:44:18 -0700

I just wanted to tip my hat to the folks on the mailing list for treating
this submission with much more respect and patience than it probably
deserved; an admirable display of adulthood and restraint.

On Fri, Jul 17, 2020 at 11:31 AM Larry Masinter <[email-masked]> wrote:

> RFC 7595 <http://www.rfc-editor.org/rfc/rfc7595.txt>, "Guidelines and
> Registration Procedures for URI Schemes", June 2015as modified by
> https://www.rfc-editor..org/errata/rfc7595
> <https://www.rfc-editor.org/errata/rfc7595> was a mistake.
>
> The idea behind RFC 7595 was to change
> https://www.rfc-editor.org/info/bcp35 to make “provisional” registration
> FCFS.
>
> And the errata was correct in its identification of the problem that FCFS
> is incompatible with having requirements that need to be checked.
>
> But the proper remedy (as this case shows) should have been to change it
> back to “expert review” as it was in RFC 4395.
>
>
>
> If “expert review” could optionally be accomplished by (dis)approving a
> Pull Request in an IANA-maintained Git repository (as was recently done for
> .well-known) so much the better.
>
>
>
> --
>
> https://LarryMasinter.net <https://larrymasinter.net/>
> https://going-remote.info
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 18 Jul 2020 10:38:34 +1000

On 18 Jul 2020, at 4:31 am, Larry Masinter <[email-masked]> wrote:
> 
> RFC 7595, "Guidelines and Registration Procedures for URI Schemes", June 2015
> 

I was wondering the same thing. I know we had extensive discussions about that draft, and IIRC at the time several folks (including me) pointed out that FCFS is incompatible with the notion that new schemes should be rare.[1]

Looking at the current registry and the large number of provisional registrations without a specification, I'd be sorely tempted to make it Specification Required, so that there's at least a chance of interoperability. AIUI the counterargument is that since many vendors have used the scheme as an escape valve to trigger proprietary functions, making it spec req'd would disqualify too many registrations. It might be worth looking at what encourages them to use it in that way (perhaps with the help of WHATWG folks?) and see if there's a better solution.

Also, I note that there doesn't appear to be any mechanism for removing a provisional registration that's fallen into disuse; for example, several appear to reference old Internet-Drafts that have never made it to RFC. If provisional registrations can't be removed, is there any practical difference between provisional and permanent?

Cheers,

1. see e.g. <https://www.w3.org/DesignIssues/Model.html>, "The danger of too many access schemes".

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Jul 2020 17:44:08 -0700

On Fri, Jul 17, 2020 at 5:39 PM Mark Nottingham <[email-masked]> wrote:

> > And the errata was correct in its identification of the problem that
> FCFS is incompatible with having requirements that need to be checked.
> I was wondering the same thing. I know we had extensive discussions about
> that draft, and IIRC at the time several folks (including me) pointed out
> that FCFS is incompatible with the notion that new schemes should be
> rare.[1]
>
> Looking at the current registry and the large number of provisional
> registrations without a specification, I'd be sorely tempted to make it
> Specification Required, so that there's at least a chance of
> interoperability. AIUI the counterargument is that since many vendors have
> used the scheme as an escape valve to trigger proprietary functions, making
> it spec req'd would disqualify too many registrations. It might be worth
> looking at what encourages them to use it in that way (perhaps with the
> help of WHATWG folks?) and see if there's a better solution.
>
> Also, I note that there doesn't appear to be any mechanism for removing a
> provisional registration that's fallen into disuse; for example, several
> appear to reference old Internet-Drafts that have never made it to RFC. If
> provisional registrations can't be removed, is there any practical
> difference between provisional and permanent?
>

To add some color to this, there has been discussion of using this as input
to the question of whether browsers would safelist schemes for
registerProtocolHandler:

https://github.com/mozilla/standards-positions/issues/339

-Ekr

---

From: Larry Masinter <[email-masked]>
Date: Fri, 17 Jul 2020 21:27:41 -0700

Maybe it's time to rethink  the whole registry of schemes,  because this one isn't working.

If the URL spec moves https://url.spec.whatwg.org/ then the scheme registry should go with it. 
As long as IETF non-web applications can get the registrations they need.

Then Subject appeal would be THEIR headache.

Larry
--
https://LarryMasinter.net https://going-remote.info

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Jul 2020 17:23:43 +1200

On 18-Jul-20 16:27, Larry Masinter wrote:
> If the URL spec moves

Why would that happen?

   Brian

> https://url.spec.whatwg.org/ then the scheme registry should go with it.

---

From: Larry Masinter <[email-masked]>
Date: Fri, 17 Jul 2020 22:50:50 -0700

>    Brian

https://url.spec.whatwg.org/#goals 

Main goal: "Align RFC 3986 and RFC 3987 with contemporary implementations and obsolete them in the process."

I would expect   more stringent rules that would help interoperability more than "specification required"
- Must have proof-of-concept implementation, two or more browsers commit to implement
- Drop or deprecate when two or more browsers do, as is happening with "ftp:" URLs

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 18 Jul 2020 08:52:31 +0200

Huh?  URIs are not just for browsers. 

Sent from mobile, sorry for terse

> On 18. Jul 2020, at 07:51, Larry Masinter <[email-masked]> wrote:
> 
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 18 Jul 2020 14:58:46 -0400

Larry,

This may be just an expansion on Carsten's "URIs are not just
for browsers" but the two main difficulties with that scenario
are:

(i) It blows off all non-browser uses of URIs.  To draw an
example from your earlier message, while FTP may not be in
general use on the public Internet any more, especially from
browsers, it is still widely supported in text editors and for
retrieval of information from repositories [1], many of whom
have adopted or accept an FTP URI syntax. The recent discussion
of email address syntax and validity in HTML [2] (of which you
have been a part) and discrepancies between what the web allows,
IETF Standards, and plausible practices when email addresses are
used as identifiers may be another example, albeit an indirect
one.  

(ii) It might be one thing to say (referencing RFC 3986) that
there are no locator URIs other than URLs, parse the
URL-specific material out of 3986, and see if what is left in
worse publishing as a replacement.  But saying that all URIs are
URLs, URLs are being taken over by WHATWG, and 3986 should be
obsoleted (taking anything non-URL-ish that remain with it)
presumably deprecates all name-type URIs, including URNs.  My
impression is that there is a significant portion of the
Internet community, including some national governments and
repository libraries, that does not want to go there.

The document you cited [3] also reinforces my concerns about
WHATWG as a setter of standards for the Internet based on what a
small number of browsers do and as an actor in this space that
does not play well with others.  As one handy example, Section
3.2 is inconsistent with DNS specifications (RFC 1034/RFC 1035
included) that do not require that labels in FQDNs for "hosts"
conform to the preferred syntax.   It also depends on the
so-called Public Suffix List, which is known to be problematic
(as it goes on the warn... sort of) and uses a concept of
_registerable domain_ that is inconsistent with domain trees in
which the sorts of registrations they are talking about may
exist at multiple levels (see RFC 1480 for an interesting
example that, in combination with public suffix ideas, recently
bit me).   As another, Section 3.3 uses terminology and
procedures that were deprecated in 2010.  More generally, that
section is based, not on IETF Standard IDNA, but on an
interpretation/ profiling of Unicode UTS#46 that amounts to
"IDNA2003 as extended by Unicode forever; IDNA2008 never".

If one accepts the hypothesis that the Internet is evolving, or
has already evolved, to the point that the web (presumably as
defined by W3C and WHATWG) is all that counts, all non-web
applications are obsolescent and browsers are the only
applications that count, little or any of the above is actually
a problem.  For at least some of us who do not believe that,
perhaps because of advancing age and accompanying
stick-in-the-mud tendencies, it feels like a probably.

best,
   john

[1] Where the data are public and, in most cases, the fact that
one has accessed it is of even less interest, and less concern
from a privacy standpoint, than one's choice of sources for the
daily news.

[2] https://github.com/whatwg/html/issues/4562

[3] https://url.spec.whatwg.org/

--On Friday, July 17, 2020 22:50 -0700 Larry Masinter
<[email-masked]> wrote:

> Main goal: "Align RFC 3986 and RFC 3987 with contemporary
> implementations and obsolete them in the process."
> 
> I would expect   more stringent rules that would help
> interoperability more than "specification required" - Must
> have proof-of-concept implementation, two or more browsers
> commit to implement - Drop or deprecate when two or more
> browsers do, as is happening with "ftp:" URLs
> 
> --

---

From: John C Klensin <[email-masked]>
Date: Sat, 18 Jul 2020 16:22:27 -0400

--On Saturday, July 18, 2020 10:38 +1000 Mark Nottingham
<[email-masked]> wrote:

>> If "expert review" could optionally be accomplished by
>> (dis)approving a Pull Request in an IANA-maintained Git
>> repository (as was recently done for .well-known) so much the
>> better.
> 
> I was wondering the same thing. I know we had extensive
> discussions about that draft, and IIRC at the time several
> folks (including me) pointed out that FCFS is incompatible
> with the notion that new schemes should be rare.[1]
> 
> Looking at the current registry and the large number of
> provisional registrations without a specification, I'd be
> sorely tempted to make it Specification Required, so that
> there's at least a chance of interoperability. AIUI the
> counterargument is that since many vendors have used the
> scheme as an escape valve to trigger proprietary functions,
> making it spec req'd would disqualify too many registrations.
> It might be worth looking at what encourages them to use it in
> that way (perhaps with the help of WHATWG folks?) and see if
> there's a better solution.
> 
> Also, I note that there doesn't appear to be any mechanism for
> removing a provisional registration that's fallen into disuse;
> for example, several appear to reference old Internet-Drafts
> that have never made it to RFC. If provisional registrations
> can't be removed, is there any practical difference between
> provisional and permanent?

Mark,

Extrapolating from the above, it sounds like an interesting
middle ground might be to allow very lightweight provisional
registrations but start a clock on them such that, if a
specification did not appear within a set period of time, they
would be at least marked obsolete and maybe removed from the
registry (the difference being whether the name would be
considered available for reuse).  At the risk of more
complexity, perhaps that could be "mark obsolete, allow for some
appeal period that would require proof of active use and at
least a promise of documentation, then remove".   One could
further tune something like that to treat I-Ds for a while but
not very long; after that, RFC or some other stable
specification.  

That is just an idea, with lots of details absent and in need of
filling in, but I wonder if something like it would address the
issues you are raising without discarding the idea of quick
registrations to eliminate or reduce naming conflicts.

best,
    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Jul 2020 08:37:20 +1200

Also, looking at the WHATWG material and in particular its rejection
of RFC6874, they don't seem to have picked up on the underlying
problem that made that RFC necessary: the difference between (a) what
one is allowed to type into a browser and (b) what is allowed as a URI
on the wire. As the RFC says "Unfortunately, there is no formal distinction
between the syntax allowed in a browser's input dialogue box and the syntax
allowed in URIs." It's entirely possible that we got it wrong in RFC6874,
but until this formal distinction exists, the IETF standard is what it is.
WHATWG can't change it unilaterally just because it makes their code
awkward.

They could always come to the IETF and talk about it. I only discovered
yesterday that they have an opinion on RFC6874, which was published 7 years
ago. (I was aware that Mozilla rejected it 5 years ago, and that on paper
it broke CUPS, see https://tools.ietf.org/html/draft-sweet-uri-zoneid-01.)

Regards
   Brian Carpenter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 18 Jul 2020 16:44:31 -0400

Small distinction.
Anyone is free to ignore RFCs if they want to.  We have no police. 
Although we do have an understanding with W3C that we will respect each 
others work.

Having said that, WHATWG is not free to do what I understood Larry 
suggested, which is to deprecate RFCs.  They could ask the IETF to do 
so.  But they can not do so on their own.  (Presuming that by deprecate 
one means either obsolete or move to historic.)

Yours,
Joel

---

From: Larry Masinter <[email-masked]>
Date: Sat, 18 Jul 2020 13:49:40 -0700

Let me try to make my point clearer. When we started the registry of
schemes, there was an attempt to add enough extensibility by not
constraining the target syntax. In practice, the variations of rules for
file: ftp: urn: mailto: data: etc meant that the parser had to special case
all of  them.

And there isn't a greate deployment strategy for new
schemes.RegisterProtocolHandler might be OK but it is a run-time setup. To
get actual interoperability for a new scheme, you need a commitment from a
critical mass of browsers or other consumers of URLs before anyone will
deploy sending URLs around. It's a chicken-and-egg startup problem. The
caniuse approach might be helpful here.

The change from URI back to URL is a total red herring. URNs have nothing
to do with it.
It's true that most people call them URLs and not URIs and IRIs. But it
doesn't matter what you call them.

-- 
--
https://LarryMasinter.net <http://larry.masinter.net>

---

From: Larry Masinter <[email-masked]>
Date: Sat, 18 Jul 2020 16:08:54 -0700

I didn't mean to suggest that merely by publishing the URL standard that it would automatically change IETF standards. 
(But if you had to choose an implementation, one of which is compatible with the browsers, and one which is compatible with the RFCs, which would you choose?)

With URL schemes, it's hard to get any implementation of consumers of a new scheme until there are enough producers to pay attention.
But who would start producing URLs that most of the deployed consumers can't handle.
(this is true for any common protocol element)

Change "browser" to "URL interpreter" to account for the non-browser implementations.
What I am trying to propose is that new URL schemes that you want to register as "Permanent" should come with a credible deployment strategy (e.g., sufficient coverage of deployed browser/consumers).

> -----Original Message-----
> From: Joel M. Halpern <[email-masked]>
> Sent: Saturday, July 18, 2020 1:45 PM
> To: Brian E Carpenter <[email-masked]>; Larry Masinter
> <[email-masked]>
> Cc: 'IETF' <[email-masked]>
> Subject: Re: WHATWG [was: Appeal from Tim McSweeney regarding draft-
> mcsweeney-drop-scheme]
> 
> Small distinction.
> Although we do have an understanding with W3C that we will respect each others
> work.
> 
> Having said that, WHATWG is not free to do what I understood Larry suggested,
> which is to deprecate RFCs.  They could ask the IETF to do so.  But they can not do
> so on their own.  (Presuming that by deprecate one means either obsolete or
> move to historic.)
> 
> Yours,
> Joel
> 
> > on the wire. As the RFC says "Unfortunately, there is no formal
> > distinction between the syntax allowed in a browser's input dialogue
> > box and the syntax allowed in URIs." It's entirely possible that we
> > got it wrong in RFC6874, but until this formal distinction exists, the IETF standard
> is what it is.
> > They could always come to the IETF and talk about it. I only
> > discovered yesterday that they have an opinion on RFC6874, which was
> > published 7 years ago. (I was aware that Mozilla rejected it 5 years
> > ago, and that on paper it broke CUPS, see
> > https://tools.ietf.org/html/draft-sweet-uri-zoneid-01.)
> >
> > Regards
> >     Brian Carpenter
> >
> >> This may be just an expansion on Carsten's "URIs are not just for
> >> browsers" but the two main difficulties with that scenario
> >> are:
> >>
> >> (i) It blows off all non-browser uses of URIs.  To draw an example
> >> from your earlier message, while FTP may not be in general use on the
> >> public Internet any more, especially from browsers, it is still
> >> widely supported in text editors and for retrieval of information
> >> from repositories [1], many of whom have adopted or accept an FTP URI
> >> syntax. The recent discussion of email address syntax and validity in
> >> HTML [2] (of which you have been a part) and discrepancies between
> >> what the web allows, IETF Standards, and plausible practices when
> >> email addresses are used as identifiers may be another example,
> >> albeit an indirect one.
> >>
> >> (ii) It might be one thing to say (referencing RFC 3986) that there
> >> are no locator URIs other than URLs, parse the URL-specific material
> >> out of 3986, and see if what is left in worse publishing as a
> >> replacement.  But saying that all URIs are URLs, URLs are being taken
> >> over by WHATWG, and 3986 should be obsoleted (taking anything
> >> non-URL-ish that remain with it) presumably deprecates all name-type
> >> URIs, including URNs.  My impression is that there is a significant
> >> portion of the Internet community, including some national
> >> governments and repository libraries, that does not want to go there.
> >>
> >> The document you cited [3] also reinforces my concerns about WHATWG
> >> as a setter of standards for the Internet based on what a small
> >> number of browsers do and as an actor in this space that does not
> >> play well with others.  As one handy example, Section
> >> so-called Public Suffix List, which is known to be problematic (as it
> >> goes on the warn... sort of) and uses a concept of _registerable
> >> domain_ that is inconsistent with domain trees in which the sorts of
> >> registrations they are talking about may exist at multiple levels
> >> (see RFC 1480 for an interesting example that, in combination with
> >> public suffix ideas, recently
> >> If one accepts the hypothesis that the Internet is evolving, or has
> >> already evolved, to the point that the web (presumably as defined by
> >> W3C and WHATWG) is all that counts, all non-web applications are
> >> obsolescent and browsers are the only applications that count, little
> >> or any of the above is actually a problem.  For at least some of us
> >> who do not believe that, perhaps because of advancing age and
> >> accompanying stick-in-the-mud tendencies, it feels like a probably.
> >>
> >> best,
> >>     john
> >>
> >> [1] Where the data are public and, in most cases, the fact that one
> >> has accessed it is of even less interest, and less concern from a
> >> privacy standpoint, than one's choice of sources for the daily news.
> >>
> >> --On Friday, July 17, 2020 22:50 -0700 Larry Masinter <[email-masked]>
> >> wrote:
> >>
> >>>>> If the URL spec moves
> >>>>
> >>>> Why would that happen?
> >>>>
> >>>>     Brian
> >>>
> >>> interoperability more than "specification required" - Must have
> >>> proof-of-concept implementation, two or more browsers commit to
> >>> implement - Drop or deprecate when two or more browsers do, as is
> >>> happening with "ftp:" URLs
> >>>
> >>> --

---

From: Rob Sayre <[email-masked]>
Date: Sat, 18 Jul 2020 19:51:51 -0700

On Sat, Jul 18, 2020 at 4:09 PM Larry Masinter <[email-masked]> wrote:

> I didn't mean to suggest that merely by publishing the URL standard that
> it would automatically change IETF standards.
> (But if you had to choose an implementation, one of which is compatible
> with the browsers, and one which is compatible with the RFCs, which would
> you choose?)
>

I would probably use the WHATWG version where applicable, but it doesn't
cover enough to obsolete RFC 3986 and RFC 3987, in particular the appendix
on "Delimiting a URI in Context" [1].

That appendix is becoming obsolete, whether we like it or not, as users
have come to expect behavior similar to what Twitter does. See [2] for an
example of a URI delimited in an unexpected way due to a user making this
assumption.

I wrote it all down in [3]. That code also covers normalization and IDNA
outside of the grammar (mostly for length calculations). The code contains
a few Twitter-specific things (like t.co processing and some strange rules
around parentheses in a path), but it is otherwise pretty general. In
particular, it covers what they call a "URL without protocol", which I'm
sure will annoy some.

thanks,
Rob

[1] https://tools.ietf.org/html/rfc3986#appendix-C
[2] https://lists.llvm.org/pipermail/llvm-dev/2019-January/129027.html
[3]
https://github.com/sayrer/twitter-text/blob/master/parser/src/twitter_text.pest#L101

---

From: Ben Campbell <[email-masked]>
Date: Sun, 19 Jul 2020 16:46:09 -0500

Please note Ted’s document[1] currently being discussed in (and is on the IETF108 agenda for) DISPATCH. This is probably not relevant to “What to do about this appeal” discussion, but probably is relevant to the “Registration of schemes is broken” discussion. 

[1] https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/  <https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/>

Thanks,

Ben.

> On Jul 17, 2020, at 11:27 PM, Larry Masinter <[email-masked]> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2020 11:34:42 +1000

> On 19 Jul 2020, at 6:22 am, John C Klensin <[email-masked]> wrote:
> 

That's somewhat similar to the model we're using for Link Relations and Well-Known URIs (both Specification Required). For them, you can make a provisional registration if there's an I-D or similar ephemeral document, but the expert(s) are empowered to remove it if there isn't progress to a more stable reference. Registrations without _any_ document (however brief) aren't allowed.

The experts are also empowered to register (potentially as permanent) values that are found to be in widespread use, after consultation with the community.

It's early days, and we may need to add some more process when we start thinking about following through on removing registrations, but so far I like the properties it has.

Cheers,

---

From: Larry Masinter <[email-masked]>
Date: Sun, 19 Jul 2020 21:18:06 -0700

Getting some uniformity of process around web extension points would be
helpful. You've done a lot to simplify submission, why not for schemes.
I don't think it's necessary to remove old provisional schemes, but it
should be possible for someone else to claim use .

 The thing that we wanted to avoid was  scheme-squatting, and fighting over
who gets to use pizza:  or food: or amazon: 
This is a risk in RegisterProtocolHandler  That kind of judgement was part
of the reaction to the drop scheme.
Such a common word, 'drop' but he couldn't change it because he was already
using the word in dropnumber.com.

I don't know how to solve this problem; there are too many constraints. 

I blame RegisterProtocolHandler because before it was really hard to deploy
a new scheme, so it wouldn't matter who owned pizza:

---

From: Larry Masinter <[email-masked]>
Date: Sun, 19 Jul 2020 21:52:05 -0700

Given the people lining up to claim their name 
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1
is it possible to put a moratorium on provisional registrations?

> From: Larry Masinter <[email-masked]> On Behalf Of Larry Masinter
> Sent: Sunday, July 19, 2020 9:18 PM
> To: 'Mark Nottingham' <[email-masked]>; 'John C Klensin'
<[email-masked]>
> Cc: 'Carsten Bormann' <[email-masked]>; 'IETF' <[email-masked]>
> Subject: RE: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-
> scheme
> 
helpful.
> You've done a lot to simplify submission, why not for schemes.
should be
> possible for someone else to claim use .
> 
>  The thing that we wanted to avoid was  scheme-squatting, and fighting
over who
> gets to use pizza:  or food: or amazon:
of the
> reaction to the drop scheme.
> I blame RegisterProtocolHandler because before it was really hard to
deploy a
> new scheme, so it wouldn't matter who owned pizza:
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 20 Jul 2020 15:18:15 +1000

> a new scheme, so it wouldn't matter who owned pizza: 

I don't agree that registerProtocolHandler is the root cause.  That's a symptom of a deeper malaise.  I'm running Windows and poked around in my registry a little.  The number of entries under HKEY_CLASSES_ROOT that specify 'URL Protocol' are pretty shocking.  Some use the reverse domain name thing (com.microsoft.print3d:) and others are entirely unqualified (feed: and feeds: appear to route RSS to Outlook; acrobat: routes to Adobe's PDF viewer).

I can only conclude that the victim passed long before registerProtocolHandler arrived on scene.  The URL as a means of addressing programs and providing context is too useful to leave to the privileged few.

That my computer likely has a completely different set of functioning URL schemes to any other is just one of the problems that come from this.  But we should not pretend that the IETF has any amount of control over what happens.  We have some influence, but that depends on how relevant our response is.

Right now, the gap between reality and the registry is largely down to Dave Thaler registering a ton of these (including feed:, above).  Relying on Dave is not really a long-term strategy.

---

From: Larry Masinter <[email-masked]>
Date: Sun, 19 Jul 2020 23:26:08 -0700

The root cause was making it fcfs rather than Ietf consensus. RegisterProtical just makes it urgent

--
LarryMasinter.net

> On Jul 19, 2020, at 10:19 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Jul 2020 08:12:14 -0400

--On Sunday, 19 July, 2020 21:52 -0700 Larry Masinter
<[email-masked]> wrote:

> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
> #uri-schemes-1 is it possible to put a moratorium on
> provisional registrations?

Larry,

Two thoughts:

(1) This situation might be different and I don't pretend to
understand the tradeoffs that might apply, but I think that our
general experience in the past has been that, if we make
registration harder or impossible, people just squat and we end
up with name conflicts and difficulty in tracking them.

(2) I don't have time this morning to sort the list and do any
kind of statistics, but, as I scan down the list, it looks like
most of those provisional registrations come from one company
and its employees.  That is not the pattern one would expect
from a land rush on names, people trying to lock others out of
specific names, etc.   If the concern were really that there are
too many provisional registrations of names that are possibly
not being either retired or made permanent, a discussion with
Dave or Microsoft about what is going on might be more
productive, and would certainly be faster, than trying to change
registration procedures.

Looking at that list suggests that, at least for provisional
registrations, it would be really nice to have the registration
date, and any update dates, visible in the registry.  If we are
going to start making changes, I suggest that might be a good
idea for all temporary or provisional registrations, not just
for this purpose but for other registries as well.

    john

---

From: Ted Hardie <[email-masked]>
Date: Mon, 20 Jul 2020 10:12:06 -0700

A bit more context on why relying on Dave Thaler isn't the long term
strategy, below.

On Sun, Jul 19, 2020 at 10:20 PM Martin Thomson <[email-masked]> wrote:

> deploy
> I don't agree that registerProtocolHandler is the root cause.  That's a
> symptom of a deeper malaise.  I'm running Windows and poked around in my
> registry a little.  The number of entries under HKEY_CLASSES_ROOT that
> specify 'URL Protocol' are pretty shocking.  Some use the reverse domain
> name thing (com.microsoft.print3d:) and others are entirely unqualified
> (feed: and feeds: appear to route RSS to Outlook; acrobat: routes to
> Adobe's PDF viewer).
>
> I can only conclude that the victim passed long before
> registerProtocolHandler arrived on scene.  The URL as a means of addressing
> programs and providing context is too useful to leave to the privileged few.
>
> That my computer likely has a completely different set of functioning URL
> schemes to any other is just one of the problems that come from this.  But
> we should not pretend that the IETF has any amount of control over what
> happens.  We have some influence, but that depends on how relevant our
> response is.
>
> Right now, the gap between reality and the registry is largely down to
> Dave Thaler registering a ton of these (including feed:, above).  Relying
> on Dave is not really a long-term strategy.
>
>
As others have noted, there are a bunch of different things you can
optimize when running a registry.  When the scheme registry was in
operation under RFC 2717 and 2718, at least some folks were trying to use
it to minimize the total number of schemes in existence (a common question
was "Why can't you do this with HTTP?") and the gatekeeping aspect of it
meant that every registration had to satisfy a pretty skeptical audience of
its utility (see Section 2.3 of 2718).

By the time we started working on RFC 4395, it was obvious that this
gatekeeping had not really worked--people minted URI schemes readily, but
they didn't register them.  The scary potential result of that was
collision, and there was at least one such scheme (mms) that drove a lot of
the desire to shift to optimizing collision avoidance instead of scheme
minimization.  The creation of the provisional registration was an effort
to lower the bar enough that folks would register them and explain at least
what the security considerations for the scheme were.  That lowered bar was
still "Expert Review", though, and there was still an expectation that the
individual who minted the scheme was the registrant.

RFC 7595 lowered the bar even further, so that provisionals can be
registered on a first-come first-served basis, provided the template
supplied is actually complete.  Further, the template was radically
simplified so that scheme syntax, scheme semantics, encoding
considerations, interoperability considerations, and security
considerations were all removed from the template and shifted to the scheme
specifications where those are supplied.  The result is it is now possible
for a third party to register schemes that they encounter, provided they
can identify a contact and change controller; they need know nothing else.
So anyone who cares can imitate Dave's work when they encounter a scheme
that has not been registered.

That optimization, to make the registry as complete a record as possible of
schemes present in the wild could, of course change.  But it was  driven by
a real concern that unregistered schemes could collide with each other or
registered schemes.  Before adjusting the registry again, I'd like to
understand what's being optimized by the new approach and what the theory
is for meeting the original driving concern.

regards,

Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Mon, 20 Jul 2020 10:15:13 -0700

Howdy,

On Sun, Jul 19, 2020 at 2:47 PM Ben Campbell <[email-masked]> wrote:

> Please note Ted’s document[1] currently being discussed in (and is on the
> IETF108 agenda for) DISPATCH. This is probably not relevant to “What to do
> about this appeal” discussion, but probably is relevant to the
> “Registration of schemes is broken” discussion.
>
>
I don't think this is a reflection that the registration of schemes is
broken; it's a reflection that the registration of URI.arpa zone entries
is.  That requires a scheme be registered in a category that's gone, and
this short document fixes that and nothing else.

regards,

Ted

> [1]
> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/
> <https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/>
>
> Thanks,
>
> Ben.
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 21 Jul 2020 16:41:14 +1000

Hi Ted,

> On 21 Jul 2020, at 3:12 am, Ted Hardie <[email-masked]> wrote:
> 
> As others have noted, there are a bunch of different things you can optimize when running a registry.  When the scheme registry was in operation under RFC 2717 and 2718, at least some folks were trying to use it to minimize the total number of schemes in existence (a common question was "Why can't you do this with HTTP?") and the gatekeeping aspect of it meant that every registration had to satisfy a pretty skeptical audience of its utility (see Section 2.3 of 2718).  
> 
> By the time we started working on RFC 4395, it was obvious that this gatekeeping had not really worked--people minted URI schemes readily, but they didn't register them.  The scary potential result of that was collision, and there was at least one such scheme (mms) that drove a lot of the desire to shift to optimizing collision avoidance instead of scheme minimization.  The creation of the provisional registration was an effort to lower the bar enough that folks would register them and explain at least what the security considerations for the scheme were.  That lowered bar was still "Expert Review", though, and there was still an expectation that the individual who minted the scheme was the registrant.
> 
> RFC 7595 lowered the bar even further, so that provisionals can be registered on a first-come first-served basis, provided the template supplied is actually complete.  Further, the template was radically simplified so that scheme syntax, scheme semantics, encoding considerations, interoperability considerations, and security considerations were all removed from the template and shifted to the scheme specifications where those are supplied.  The result is it is now possible for a third party to register schemes that they encounter, provided they can identify a contact and change controller; they need know nothing else.  So anyone who cares can imitate Dave's work when they encounter a scheme that has not been registered.
> 
> That optimization, to make the registry as complete a record as possible of schemes present in the wild could, of course change.  But it was  driven by a real concern that unregistered schemes could collide with each other or registered schemes.  Before adjusting the registry again, I'd like to understand what's being optimized by the new approach and what the theory is for meeting the original driving concern.

That's a good summary. To me, the question is whether there are ways to avoid spurious / vanity registrations without creating unnecessary barriers to entry.

The balance we settled on in the well-known and link relation registries was to require a specification, but to allow the Expert(s) to register values that are in wide use, in consultation with the community. 

Personally I think it's working out reasonably well; it prevents registration because someone had an idea in the shower (too early), while allowing registration of something that's actually getting adoption in the wild (which is the problem that Dave was trying to solve AIUI).

Stepping back, I do think we should continue to experiment with and adjust registry policies based upon feedback from their users. Allowing a request to be made via an issue queue is showing some early promise, and I think we could expand that. Eventually, it would be good to align policies *where it's appropriate*, but I think we've got more to learn before we go there.

Cheers,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Jul 2020 23:17:42 -0400

On Tue, Jul 21, 2020 at 2:42 AM Mark Nottingham <[email-masked]> wrote:

> That's a good summary. To me, the question is whether there are ways to
> avoid spurious / vanity registrations without creating unnecessary barriers
> to entry.
>

I have railed against 'vanity crypto' in the past. And there is actually a
pretty good argument that less crypto is more. But I have since realized
even that type of gatekeeping is counterproductive.

There are some important and valid concerns, the two most important for me
being:

* Avoiding ambiguity where two communities attempt to use the same scheme.
* Avoiding namespace exhaustion.
There is also:

* Enabling interoperability.
* Ensuring availability of documentation
* Maintaining quality

Which are important to some of course. BUT is it worth our time and effort
to save people from their own folly unasked? I don't ask people to look at
my stuff because I enjoy having people jump up and down on the little
pieces. I do it because I want it to work, and to be useful. If people want
to shoot themselves in the feets, why not let them?

I come to the IETF for advice and to build a deployment coalition for my
proposals. I have never come to ask permission.

The IETF tried to establish a gatekeeper role over DNS SRV prefixes at one
point. And it collapsed because there was far more interest in gatekeeping
than allowing anyone allocations. When I attempted to register the code
points for SAML, the IETF had no process whatsoever and those attempting to
create one were still being given the run-around five years after the SAML
specs published with code points I made up.

The area where I do see a real need for process is defining schemes for
existing protocols. Lets say someone invents a pgp: scheme. I think it
would be pretty important that such a scheme get community review.

Gatekeeping can be a useful function but it can also do immense damage.
Stopping one good idea does real harm. And lets not be prejudiced about
ideas people have in the shower. I do much of my best thinking in the hot
tub.

There have always been people who think that their role in the Internet is
to identify bad ideas and stop them happening and that this is doing the
community a favor.

So while the second set of concerns are valid, I don't see the IETF
achieving anything good by attempting to enforce them, on the contrary, it
is only causing harm.

The IANA protocol directory has been open for some time. I have registered
mmm for Mathematical Mesh Services. Now, I ask you, should anyone else be
allowed to register mmm for their URI scheme? Seems like that would only
lead to confusion. And I would make the exact same argument for
.well-known.

My proposal is this:

Collapse the protocol, .well-known and uri registries into one registry of
application name labels. Registering a label in the application name labels
registry would be 'essentially' first come first served and automatically
create reservations for the .well-known and uri scheme, to be used if
required.

By 'essentially', I mean we should have guards in place to stop speculative
reservation of namespace, namejumping and the like.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jul 2020 09:29:55 +0100

> even that type of gatekeeping is counterproductive. 

Some of the COSE registries (for example, at https://www.iana.org/assignments/cose/cose.xhtml#algorithms) have a column marked “Recommended”. I find this helpful, but maybe the language is not as strong as we would like. As IETFers we assume this to mean something more than is written, and perhaps (in order to make clear what is going on) we should be explicit in changing the column heading to “Recommended by the IETF” or by saying s/No/Not recommended by the IETF/  

Doing this in other registries would allow “vanity” registrations while making it clear what the IETF’s opinion is.

Cheers,

Adrian

From: ietf <[email-masked]> On Behalf Of Phillip Hallam-Baker
Sent: 22 July 2020 04:18
To: Mark Nottingham <[email-masked]>
Cc: Ted Hardie <[email-masked]>; IETF <[email-masked]>
Subject: Re: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme

On Tue, Jul 21, 2020 at 2:42 AM Mark Nottingham <[email-masked] <mailto:[email-masked]> > wrote:

I have railed against 'vanity crypto' in the past. And there is actually a pretty good argument that less crypto is more. But I have since realized even that type of gatekeeping is counterproductive. 

There are some important and valid concerns, the two most important for me being:

There is also:

* Maintaining quality

Which are important to some of course. BUT is it worth our time and effort to save people from their own folly unasked? I don't ask people to look at my stuff because I enjoy having people jump up and down on the little pieces. I do it because I want it to work, and to be useful. If people want to shoot themselves in the feets, why not let them?

I come to the IETF for advice and to build a deployment coalition for my proposals. I have never come to ask permission.

The IETF tried to establish a gatekeeper role over DNS SRV prefixes at one point. And it collapsed because there was far more interest in gatekeeping than allowing anyone allocations. When I attempted to register the code points for SAML, the IETF had no process whatsoever and those attempting to create one were still being given the run-around five years after the SAML specs published with code points I made up.

The area where I do see a real need for process is defining schemes for existing protocols. Lets say someone invents a pgp: scheme. I think it would be pretty important that such a scheme get community review.

Gatekeeping can be a useful function but it can also do immense damage. Stopping one good idea does real harm. And lets not be prejudiced about ideas people have in the shower. I do much of my best thinking in the hot tub. 

There have always been people who think that their role in the Internet is to identify bad ideas and stop them happening and that this is doing the community a favor. 

So while the second set of concerns are valid, I don't see the IETF achieving anything good by attempting to enforce them, on the contrary, it is only causing harm.

The IANA protocol directory has been open for some time. I have registered mmm for Mathematical Mesh Services. Now, I ask you, should anyone else be allowed to register mmm for their URI scheme? Seems like that would only lead to confusion. And I would make the exact same argument for .well-known. 

My proposal is this:

Collapse the protocol, .well-known and uri registries into one registry of application name labels. Registering a label in the application name labels registry would be 'essentially' first come first served and automatically create reservations for the .well-known and uri scheme, to be used if required.

By 'essentially', I mean we should have guards in place to stop speculative reservation of namespace, namejumping and the like.

---

From: tom petch <[email-masked]>
Date: Wed, 22 Jul 2020 12:51:01 +0100

On 22/07/2020 09:29, Adrian Farrel wrote:
> Doing this in other registries would allow “vanity” registrations while making it clear what the IETF’s opinion is

Well, recommended by someone such as the WG or a designated expert or ....

Look, for example, at the TLS ciphersuite registry and it has a 
'recommended' column but you need to know that this is a designated 
expert registry and has - at most - endorsement from the WG and not from 
the IETF in the sense we usually understand it, of having been judged to 
have or have not consensus in an IETF Last Call.

Tom Petch

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Jul 2020 06:34:36 -0700

On Wed, Jul 22, 2020 at 4:51 AM tom petch <[email-masked]> wrote:

> > Some of the COSE registries (for example, at
> https://www.iana.org/assignments/cose/cose.xhtml#algorithms) have a
> column marked “Recommended”. I find this helpful, but maybe the language is
> not as strong as we would like. As IETFers we assume this to mean something
> more than is written, and perhaps (in order to make clear what is going on)
> we should be explicit in changing the column heading to “Recommended by the
> IETF” or by saying s/No/Not recommended by the IETF/
> > Doing this in other registries would allow “vanity” registrations while
> making it clear what the IETF’s opinion is
>

Not quite.

The experts are responsible for approving assignments and the bar for that
is that a specification exists. However, setting the Recommended column to
"Y" requires a standards action.

https://tools.ietf.org/rfcmarkup?doc=8447#section-5

-Ekr

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jul 2020 14:45:57 +0100

What EKR says.

And adding a sentence of clarification at the top of the registry can’t hurt.

A

From: Eric Rescorla <[email-masked]> 
Sent: 22 July 2020 14:35
To: tom petch <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; Phillip Hallam-Baker <[email-masked]>; Mark Nottingham <[email-masked]>; Ted Hardie <[email-masked]>; IETF <[email-masked]>
Subject: Re: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme

On Wed, Jul 22, 2020 at 4:51 AM tom petch <[email-masked] <mailto:[email-masked]> > wrote:

Not quite.

The experts are responsible for approving assignments and the bar for that is that a specification exists. However, setting the Recommended column to "Y" requires a standards action.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jul 2020 13:59:56 +0000

*   Some of the COSE registries (for example, at https://www.iana.org/assignments/cose/cose.xhtml#algorithms<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_cose_cose.xhtml-23algorithms&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SnuYhHSaxiICItpZITDo-cBxFkPmIiZ6cyZqSkpyPOI&s=SVfKcEej_mz9BciI3xcRJL5TVzfCl39gZOGDQJqd_Pw&e=>) have a column marked “Recommended”.

We also do this in four of the TLS registries. It is very useful.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jul 2020 14:12:39 +0000

Actually, every TLS registry that has a recommended column, has this text at the top *in the registry*

Note
    If an item is not marked as "Recommended", it does not
    necessarily mean that it is flawed; rather, it indicates that
    the item either has not been through the IETF consensus process,
    has limited applicability, or is intended only for specific use
    cases.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Jul 2020 16:54:03 +1000

Hi Phillip,

> On 22 Jul 2020, at 1:17 pm, Phillip Hallam-Baker <[email-masked]> wrote:
> 

You make many good points above, and I don't disagree with any of them.

However, I'm concerned about another phenomenon; as we lower the barrier to entry for registries (especially when we do things like GitHub management of issues lists, which is *much* friendlier than using e-mail lists for many non-IETF-encultured registrants), it becomes trivial to register a value pre-emptively, sometimes on a whim (as in, "I had this idea, let's register it."). Without pointing fingers, I have seen some evidence of this.

If doing so has no impact upon the registry then I agree that it shouldn't matter.  However, I think there is some undesirable impact, if enough of these registrations occur. 

For example, take link relations and well-known URIs (two registries where I currently serve as an Expert). Plain english terms that have applicability in the field of the registry can be consumed by such registrations, leaving us in a situation where registered values backed by a broader and larger community will be forced to use unintuitive (and sometimes longer) terms. All potential values in these registries are *not* equivalent.

Simply put, I don't think it's reasonable for someone to have an idea in the shower one morning and then register the value an hour later, *if* that value has significant potential value to the community, *and* that person isn't willing to work with others. Good names are valuable, and many people think that if they grab an intuitive name, the users will follow.

Since I don't think that the ICANN model is suitable for these registries, there are a few ways that we try to mitigate this risk (backed by the defining RFCs) while still meeting the goals you mention:

1. They are Specification Required. Writing something down requires some amount of effort, but it can be brief. Importantly, we shouldn't block registration on "correctness" or "purity" beyond applying any requirements stated for the extension point in question. Sometimes we provide advice ("have you thought about...") but in doing so, we should make it clear that addressing it isn't blocking.

2. We require the specification to be _reasonably_ stable and available. This is an evolving and still somewhat flexible criteria; because we're able to update the registry pretty easily now, the barrier is lower than that in many other registries (I understand that some require publication by an Open Standard body in most cases). We prefer that, but also accept values from commercial entities, Open Source projects, and community organisations; really any group of people who have the ability to maintain the reference. The spec doesn't have to be an I-D; it could be e.g. a page on GitHub.

3. There is language in the defining RFCs that encourages names that have a specificity corresponding to their applicability. So, if a proposed name is limited to one application or doesn't have a broad community behind it, we might steer them towards a name like 'myApp-metadata' rather than 'metadata'.

4. Registrations that aren't sourced from Standards are provisional. Provisional registrations can be made permanent if the Expert(s) find that they're in broad use, after consultation with the community.

5. Provisional registrations can be removed by the Expert(s) after consultation with the community if they're found to be in disuse. That hasn't been attempted yet, and I'd expect that if we decided to do so, there's be some discussion about how to go about it, and whether removal or just marking as 'historic' or similar was the right way to go. 

6. The Expert(s) can, after consultation, register values that are found to be in broad use. To me, this is an alternative to the model that URI schemes currently uses; rather than severely lowering the bar to enable population of the registry (mostly through one or two 'heroic' catch-up drafts, like Dave did), keep the bar at a reasonable level, but allow the Experts to catch it up when there's a value that's been obviously consumed without registration.

While not perfect, I do think that this approach has some good qualities; it's not so much "gatekeeping" as it is making the Expert(s) "custodians." Yes, they have some powers, but they're fairly limited, in the interest of balancing the different needs of the registry community.

> Gatekeeping can be a useful function but it can also do immense damage. Stopping one good idea does real harm. And lets not be prejudiced about ideas people have in the shower. I do much of my best…

I don't have a hot tub, but I agree with the general sentiment (perhaps its the inability to have electronic devices nearby).  We shouldn't stop these folks from registering, but they shouldn't be allowed to consume valuable names on a whim; if it's a good idea, a slightly longer name won't hurt it. We should also have some mechanism for cleaning up after the ones who lose interest and/or fizzle a few weeks/months later.

> So while the second set of concerns are valid, I don't see the IETF achieving anything good by attempting to enforce them, on the contrary, it is only causing harm.

I agree it's a tricky balance. I think that here -- as in many other places -- we need to write down our intent *much* more carefully, if we expect it to persist.

> By 'essentially', I mean we should have guards in place to stop speculative reservation of namespace, namejumping and the like. 

Sorry, you're losing me here. 

Cheers,

---

From: IETF Chair <[email-masked]>
Date: Tue, 28 Jul 2020 08:53:57 -0400

Hi Tim,

The IESG’s response to your appeal is available at <https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08.pdf>.

Alissa Cooper, IETF Chair
For the IESG

---

From: IETF Chair <[email-masked]>
Date: Tue, 28 Jul 2020 08:58:11 -0400

Apologies, I mis-copied the link. The correct link for the response is: https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08.pdf

Alissa

> On Jul 28, 2020, at 8:53 AM, IETF Chair <[email-masked]> wrote:
> 
> Hi Tim,
> 
> The IESG’s response to your appeal is available at <https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08.pdf <https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08..pdf>>.
>

---

From: IETF Chair <[email-masked]>
Date: Tue, 28 Jul 2020 09:12:06 -0400

Well, it seems that an extra period gets added to the URL when embedded here in email. The response is linked from https://www.ietf.org/standards/process/appeals/ (and hopefully that link will work for everyone).

Alissa

> On Jul 28, 2020, at 8:58 AM, IETF Chair <[email-masked]> wrote:
> 
> Apologies, I mis-copied the link. The correct link for the response is: https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08.pdf <https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08..pdf>
> 
> Alissa
> 
> 
>> On Jul 28, 2020, at 8:53 AM, IETF Chair <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Tim,
>> 
>> The IESG’s response to your appeal is available at <https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08.pdf <https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08...pdf>>.
>>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Jul 2020 23:24:01 +1000

That's a longstanding problem in the e-mail system; e.g., look at the CSS in the QUIC weekly github digests.

> On 28 Jul 2020, at 11:12 pm, IETF Chair <[email-masked]> wrote:
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 28 Jul 2020 12:11:25 -0400 (EDT)

I was reading through this thread over the last couple days and really didn't want to participate but after today's appeal decision I thought it would be best to fill in some of the holes for the community's benefit FWIW.  So as soon as I gather up copies of all the email correspondence I will post them here with a couple other thoughts.

On July 28, 2020 at 9:24 AM Mark Nottingham <
[email-masked]> wrote:

On 28 Jul 2020, at 11:12 pm, IETF Chair <
[email-masked]> wrote:

Well, it seems that an extra period gets added to the URL when embedded here in email. The response is linked from
https://www.ietf.org/standards/process/appeals/ (and hopefully that link will work for everyone).

Alissa

On Jul 28, 2020, at 8:58 AM, IETF Chair <
[email-masked]> wrote:

Apologies, I mis-copied the link. The correct link for the response is:
https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08.pdf

Alissa

On Jul 28, 2020, at 8:53 AM, IETF Chair <
[email-masked]> wrote:

Hi Tim,

The IESG’s response to your appeal is available at <
" rel="noopener" target="_blank" data-mce-href="https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08.pdf>">https://www6.ietf.org/iesg/appeal/response-to-mcsweeney-2020-07-08.pdf>.

For the IESG

On Jul 16, 2020, at 12:00 PM, Murray S. Kucherawy <
[email-masked]> wrote:

For the IESG

--

Mark Nottingham
https://www.mnot.net/