Subject: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt

From: Dave Thaler <[email-masked]>
Date: Fri, 14 Feb 2014 22:21:18 +0000

This draft replaces draft-ietf-iri-4395bis-irireg-04. Since the IRI
WG closed, we've gone back to it being an individual submission.
This version addresses some of the issues raised on -04 (see
draft-thaler-uri-scheme-reg-ps-01 and the discussion at last IETF) as
noted below. There are still a number of open issues for which, with
the permission and help of the appsawg chairs, I have filed issue
tracker tickets to track.

I have not filed tickets for things already addressed in this version.
These are enumerated below, and if there are disagreements on any
then we can file a ticket for it.

1) The IRI WG previously agreed that the fragment component is not
scheme-specific, and that the doc should be updated to clarify that
a scheme definition should only define the scheme-specific part.
This is now done at end of section 1.

2) Since the IRI WG was closed, I reverted most of the IRI-specific
changes from RFC 4395 that were in draft-ietf-iri-4395bis-irireg-04.
I left in text clarifying that a URI scheme name and an IRI scheme
name were the same and hence there aren't separate registries, since
apparently that was a common question on RFC 4395.

3) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation
at last IETF, the IRI WG previously agreed that the 4-week mailing
list review was optional for Provisional. RFC 4395 was ambiguous as
to optional vs mandatory. Updated text in section 7.2 to make it
explicit that it is only mandatory for Permanent.

4) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation
at last IETF, RFC 4395's convention for private namespaces (i.e.,
converting "." to "-" in scheme names based on a domain name)
causes conflicts. Updated example to use "." instead of "-" to
reduce collisions. And open ticket #17 covers the rest of the
conflict problem.

5) Combined the Permanent, Provisional, and Historical URI Scheme
sub-registries into one URI Scheme registry with a status column.
This is done to make it easier to prevent duplicates and see
existing conventions, as well as to support the "Pending Review"
temporary state added in draft-ietf-iri-4395bis-irireg.

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 14, 2014 12:13 PM
To: Larry Masinter; Dave Thaler; Ted Hardie; Dave Thaler; Larry Masinter; Ted Hardie; Tony Hansen; Tony Hansen
Subject: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt

A new version of I-D, draft-thaler-appsawg-uri-scheme-reg-00.txt
has been successfully submitted by Dave Thaler and posted to the IETF repository.

Name:		draft-thaler-appsawg-uri-scheme-reg
Revision:	00
Title:		Guidelines and Registration Procedures for New URI Schemes
Document date:	2014-02-14
Group:		Individual Submission
Pages:		18
URL:            http://www.ietf.org/internet-drafts/draft-thaler-appsawg-uri-scheme-reg-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thaler-appsawg-uri-scheme-reg/
Htmlized:       http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme-reg-00

Abstract:
   This document updates the guidelines and recommendations, as well as
   the IANA registration processes, for the definition of Uniform
   Resource Identifier (URI) schemes.  It obsoletes RFC 4395.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Feb 2014 17:12:21 +1100

Hi Dave,

I took a look through, and the draft looks very good; quite readable.

A few notes I scratched down as I went through, FWIW:

* Introduction - "discourage use of the same scheme name for different purposes." This is a bit ambiguous; e.g., I use http:// for the purposes of checking the weather and my bank balance, and that's OK. Suggest: "discourage handling of a scheme by in conflicting ways."

* Introduction (and throughout) - there are a number of lowercase "should" and "may"s in the document; some people might complain.

* Demonstratable... - s/demonstratable/demonstrable/

* Demonstratable - "...some parts of URI processing may be scheme-dependent." I think this needs to be stronger; at least "...are often scheme-dependent."

* CREF1 - LGTM.

* Syntactic Compatibility - "Schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." and ".." (dot-segments).  If they avoid use of "/", how do you tell what delimits dot-segments from other stuff?

* Syntactic Compatibility - "...the first part of a URI is not an artistic indicator..."  I'd drop "artistic".

* Syntactic Compatibility - "Schemes that do not contain a conformant hierarchical structure in their <scheme-specific-part> SHOULD NOT use double slashes following the <scheme:> string."  Why is this not a MUST NOT?

* Well-Defined - "While URIs may or may not be defined as locators in practice, a scheme definition itself MUST be clear..."  Does this really deserve to be a MUST? When advice is given about what to document elsewhere in the spec, it always seems to be a SHOULD.

* Well-Defined - "In particular, the mapping SHOULD describe the mechanisms for encoding binary or character strings within valid character sequences in a URI."  I feel like this ought to be more clearly qualified to cases where such content is valid for the application; some might read this as requiring a mapping for binary in all schemes.

* Definition of Operations - HTTP calls them "methods", and this should be noted here to avoid confusing people (we saw it recently).

* Definition of Operations - I'd like to see us encourage (but probably not require) schemes to define a *default* operation for locators; the AWWW calls this "dereferencing" <http://www.w3.org/TR/webarch/#dereference-uri> and it would be nice to align the worldviews between the W3C and IETF here. It would also be good if we encouraged such default methods to be "safe" -- that is, not having surprising or undesired side effects, from the client's standpoint.

* Scheme Name Considerations - There's a shift in use of language in this section in the two paragraphs starting with "Avoid..." -- it's direct, first-person advice, whereas the rest of the spec is more third-person.

* Scheme Name Considerations - I'm very much against "private" / organisationally scoped registrations -- is the idea that someone can then make up new URI schemes without registering them? This seems counter to the purposes of having URIs, as per the AWWW. 

* CREF2 - The HTML5 folks have spec'd (not clear if they've implemented) web+, so we should at least talk about it. To me, the problem is that if somebody comes along and does something like email+, which one wins -- i.e. do I now have to handle both email+web+http:// and web+email+http:// as equivalent? Bleurgh. 

* CREF3 - As per above, I think that allowing domain-based URI schemes is a Bad Idea. What's the use case? 

* Guidelines for Provisional URI Scheme Registration - The first paragraph indicates that provisional is for "private" schemes. I think we need to have a discussion about that in the WG (perhaps in a separate thread), because AFAICT provisional is NOT being used that way; rather, it's being used to reserve namespace for parties that can't be bothered doing full registration. That's not to say that there's something wrong with that; as the draft points out, one motivation is to make registration easier; it's just that we should be honest about why we have provisional - I'd rather not encourage private URI use at all (but keep provisional).

* Registration Procedures - I'd be much more comfortable if there were references in this section to the previous requirements; people often just skip to this section in this kind of RFC, oblivious to the carefully prepared requirements and arguments above. In an ideal world, I'd restructure the draft so that the whole thing read like a flow chart, but I'm not going to ask the WG to do that :)

* Registration Procedures - "Unless Expert Review has explicitly rejected the registration request within two weeks, IANA should automatically add the registration to the registry as 'provisional."  I'm a bit uncomfortable with this; if the Experts aren't on the ball, get sick, go on holiday, etc., we can end up with some surprising results. Can we just raise an exception to the ADs or something?

That's all I've got. Thanks again,

On 15 Feb 2014, at 9:21 am, Dave Thaler <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

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

---

From: Graham Klyne <[email-masked]>
Date: Mon, 17 Feb 2014 12:14:33 +0000

Dave,

Reviewing: http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme-reg-00

I'm responding with a perspective of being the current designated IANA reviewer. 
  Broadly, I'm supportive of the changes proposed, and in particular to lower 
the perceived barrier to provisional registration of schemes.

...

Section 3: "For IETF Standards-Track documents, Permanent registration status is 
REQUIRED."  -- I can guess at what this is trying to say, but I think it's not 
clear (and I wonder if it needs to be saif at all).

...

Section 3.3 ("well defined").  One of the first questions I ask myself when 
reviewing a URI scheme proposal is: "What kinds of thing do URIs in this scheme 
identify, or how do I find out?".  I'd like to see all scheme registrations 
providing a clear answer for this.

One of the problems I have sometimes experienced in reviewing URI scheme 
registration submissions is understanding what the corresponding scheme is 
intended to identify.  If it is a locator, then it's usually fairly clear.  But 
some schemes I've seen - particularly where used as particular identifiers 
within other protocols - have been less clear (in their original submissions). 
Recent(ish) examples that come to mind are acct:, turn: and stun: (not 
criticizing them, just trying to give examples of things that are not always 
immediately clear).

I think the text "Schemes that are not intended to be used as locators SHOULD 
describe how the resource identified can be determined or accessed by software 
that obtains a URI of that scheme." goes some way to this, but that was present 
in the previous draft and didn't always get noticed.  Also, there is not always 
a mechanism that is available to software (e.g. urn":).  I'm wondering if this 
can be beefed up a bit... e.g. to lead with something like:

"URI scheme specifications should be clear about the kind of resource that they 
may identify, or the means (technical or non-technical) by which URIs are 
related to the resources they identify"

My text could surely be improved.  The first part of this would apply to a 
scheme like "acct:" saying that an acct: URI identifies a user account in some 
domain or system (**); the latter would apply to locator schemes like http:, or 
identifier schemes like urn: where there is a defined administrative delegation 
structure.

<aside>
(**) for background, the acct: scheme was defined as part of the WebFinger work, 
but acct: URIs are not specifically tied to or defined by the WebFinger protocol.
</aside>

In making this comment, I also note there is some slight overlap with material 
covered in section 3.4.

...

Section 3.8:

Re:  "[[CREF2: Open Issue: Should we define a mechanism to register a scheme 
prefix ("web+", "ms-", etc.)?  --DT]]"

I think not.

I've not come across any great need for this, and I think it might even 
encourage scheme proliferation in conflict with the exhortations in section 3.1 
("In general, the use and deployment of new schemes in the Internet 
infrastructure may be costly; ...", etc.)

...

Section 4

re: [[CREF4: Open issue: previously this also RECOMMENDED following the
    same guidelines as for permanent registration.  However, this higher
    bar disincented people to register schemes at all, and hence
    interfered with the goals of the registry.  Hence tentatively
    removed, but need to confirm consensus on this.  --DT]]

I've not seen any cases where this has been a problem, but maybe that's because 
I mainly see a self-selecting population ;)  (I.e. those who have actually 
submitted a registration request.)

Some time ago, we started creating a FAQ/guidance page at IANA for a similar 
registry (message header fields), with the goal of demystifying the process and 
encouraging early registration.  Unfortunately, that effort fizzled (though I 
think an initial draft is still around on an IETF/IANA wiki page.)

Maybe this kind of approach would be an alternative?  I.e. create a FAQ, and 
direct readers to that page for provisional registration.  The FAQ-as-guidance 
can then be updated more easily than the BCP document (within its defined 
constraints).

...

Section 7.1

[[CREF8: Open Issue: Should Provisional status just use First Come
    First Serve?  Someone suggested FCFS with Expert Review afterwards,
    but the benefit and efficacy of a subsequent Expert Review seems
    dubious to me and might only serve to deter registrations in the
    first place, which is the problem we're trying to solve.  --DT]]

Given the limited nature of URI scheme name space, I think that IESG/IANA should 
always have final say about name allocation.  Given that we try to keep the bar 
low, I feel formal FCFS makes it too easy to use provisional registration as a 
land grab - writing that into the spec would make it harder for an expert 
reviewer to push for alternatives where appropriate.  (I think there is one 
occasion in the past few years where the choice of name has been cause for 
push-back, so it's not a great problem.)

As reviewer, I have tried to treat the role as providing guidance rather than as 
gatekeeper (I don't think I've ever recommended rejection of a provisional 
registration request, though I do often make comments), so I'm a little troubled 
by the perception that expert review is a deterrent.  Can we do something in the 
spec language to make this less of a concern?

E.g. "The purpose of expert review applied to provisional registration is not 
intended to impose onerous requirements on the proposals offered, but as a 
light-touch process to promote effective cooperative use of URI scheme name space."

...

Section 7.1:

[[CREF9: TODO: We don't want this.  --??]]

I'm not sure what it is you don't want.

I think it is useful that the IESG can be final arbiter, as it provides some 
room for making decisions that are not in strict accordance with the process 
requirements, without kicking the door open to making arbitrary and capricious 
decisions.  There have been a few cases (I forget details) where the specific 
drafting of the process has seemed to be at odds with a common sense "do the 
right thing" approach - having a way to accommodate these within a clearlhy 
documented framework seems useful to me.

...

Section 7.2:

[[CREF10: Open Issue: I think the last
        phrase above about RFC 3978 is problematic, as it just serves to
        discourage registration.  For example, third-party registrations
        may have no way to grant such rights or make such assertions.
        Similarly, a standard published by another SDO may have policy/
        process issues having a request treated as an IETF contribution.
        Recommend deleting this sentence.  --DT]]

I'd suggest that at least the registration template submitted to IANA be treated 
as "IETF contribution", even if the rest of the document cannot, since IANA may 
need to republish that much.  The registration template itself can be short and 
consist mainly of pointers to other documents, so I don't think that should be a 
great disincentive.

...

Section 7.2:

   [[CREF11: Open Issue: Say
    more about guidance to the Designated Expert.  Under what
    circumstance should this happen?  --DT]]

I'm not sure what guidance you have in mind here.  Generally, I'd expect 
upgrades from provisional to permanent to meet the same requirements as 
permanent registrations (with provision for IESG last-say as noted above).

That's pretty much covered in section 7.3.

...

[[CREF12: Open Issue: Some of the fields above may serve to deter
    registration.  Should some of them NOT be required for Provisional
    registrations (including third-party ones)?  For example, the
    requirement to have clear security considerations is not appropriate
    for third-party registrations.  Typically one is forced to fill in
    something like "Unknown, use with care."  These seem to me to be more
    appropriate inside the specification (if any) in the references,
    rather than being required in the request template.  Thus, as new
    specifications update the uses (e.g., allow use with another HTTP
    method), the IANA registry itself shouldn't be required to be
    updated.  --DT]]

Fair points.  Part of the problem here, I think, is that the template serves two 
purposes: (a) registering a scheme that is fully described elsewhere, in which 
case its mainly a pointer to that specification, and (b) describing a scheme in 
use that is not described in another document (which could really apply only for 
provisional or historic schemes).

I think the headings (especially security considerations) are useful as 
reminders of things to think about and maybe provide additional information.

Maybe the template could be restructured as key information (Name, status, 
context of use, contact, change controller, and references); then have 
"Additional information" with sub-headings to be filled in as required, and all 
optional for provisional registrations?

...

Thanks,

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Mon, 17 Feb 2014 12:24:42 +0000

Hi,

Broadly, I concur or do not disagree with Mark's comments.  A few additional 
thoughts interleaved.

> * Definition of Operations - I'd like to see us encourage (but probably not require) schemes to define a *default* operation for locators; the AWWW calls this "dereferencing" <http://www.w3.org/TR/…

This makes sense for many schemes, but not so much for "pure" identifier schemes 
like urn:, etc.  I argued for something like this for the acct: scheme, but in 
the end did not persuade.

> * Scheme Name Considerations - I'm very much against "private" / organisationally scoped registrations -- is the idea that someone can then make up new URI schemes without registering them? This se…

+1

(I already commented on this in another message, but I'll emphasize my 
concurrence here.)

> * CREF2 - The HTML5 folks have spec'd (not clear if they've implemented) web+, so we should at least talk about it. To me, the problem is that if somebody comes along and does something like email+…

FWIW, I'd say web+foo and email+foo are simply different schemes.  There's no 
sense in which one can "win".

> * Registration Procedures - "Unless Expert Review has explicitly rejected the registration request within two weeks, IANA should automatically add the registration to the registry as 'provisional."…

I think the idea was that a non-responsive expert would not block the process. 
In practice, to date, IANA keep prodding until they get a response (I sometimes 
benefit from a reminder, but I don't think I've every completely failed to 
respond in 2 weeks).

#g
--

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Feb 2014 11:31:26 +1100

On 17 Feb 2014, at 11:24 pm, Graham Klyne <[email-masked]> wrote:

> FWIW, I'd say web+foo and email+foo are simply different schemes.  There's no sense in which one can "win".

My concern is that if we start using structure in schemes to denote metadata (such as "this is OK to use in the Web security model" for web+), it becomes possible that a scheme will need to use more than one of these prefixes. 

E.g., let's say "web+" and "foo+" are prefixes, and the "fnord" scheme needs to use them both, for whatever it means.

That means that the registered scheme might be "web+foo+fnord". Leaving aside aesthetic issues*, there needs to be some very careful specification both here and in the scheme prefix conventions, otherwise the software looking for the "foo+" prefix isn't going to recognise the scheme. Remember, the point of a prefix is so that *generic* software can recognise something about the scheme.

See, for example, the "web+" specification, which already tries to register a prefix:
  http://www.w3.org/html/wg/drafts/html/master/iana.html#web+-scheme-prefix
  http://www.w3.org/html/wg/drafts/html/master/webappapis.html#custom-handlers

> If the registerProtocolHandler() method is invoked with a scheme that is neither a whitelisted scheme nor a scheme whose value starts with the substring "web+" and otherwise contains only lowercase ASCII letters, and whose length is at least five characters (including the "web+" prefix), the user agent must throw a SecurityError exception.

That means that foo+web+fnord won't work for the web+ use case, and if foo+ is specified in the same manner, we're SOL.

Now, we can say that there will only ever be one of these indicators at a time, but if so, that should be explicit. Personally, I don't like them anyway, so specifying them in such a restricted way may be a good outcome.

At any rate, since the W3C is still doing this, we do need to figure out if we're going to allow prefixes to be registered, and if so, under what conditions.

Cheers,

* That's not to say that aesthetics isn't worth considering. As web+ is written, it's a huge incentive to create crazy, ugly URI schemes, so they work in browsers; some might say "if they get popular, we'll just whitelist them and they can omit web+", but X- taught us otherwise...

---

From: Darrel Miller <[email-masked]>
Date: Mon, 17 Feb 2014 20:39:17 -0500

Dave,

I read through the draft and I was hoping to find wording that would
discourage the creation of URI schemes similar to those that have been
created in the Windows Phone OS.  Schemes like
"Explorer.AssocActionId.BurnSelection",
"Explorer.AssocActionId.EraseDisc", "Explorer.AssocActionId.EraseDisc"
seem to be far from ideal scheme names.  [1]

Did I skip over the guidance that would prevent schemes like these or
is the hope that by encouraging registration, this type of abomination
could be avoided?

Regards,

Darrel

[1] http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj207065(v=vs.105).aspx

---

From: Dave Thaler <[email-masked]>
Date: Tue, 18 Feb 2014 03:27:12 +0000

Darrel Miller writes:
> Did I skip over the guidance that would prevent schemes like these or is the
> hope that by encouraging registration, this type of abomination could be
> avoided?
> 
> Regards,
> 
> Darrel
> 

It's an open issue covered by CREF3 at the end of section 3.8:
> [[CREF3: Open Issue:
> Are strings that look like reversed FQDNs (other than grandfathered
> ones like "iris.beep") reserved for use as such?  Proposed answer is
> Yes, new schemes should not use a "." unless they are actually
> constructed from a domain name.  --DT]]

And tracked by ticket #17: http://trac.tools.ietf.org/wg/appsawg/trac/ticket/17

Besides the above issue, the other reasons I'm aware of that those examples
might be frowned on are already covered in section 3.8.

-Dave

---

From: Graham Klyne <[email-masked]>
Date: Tue, 18 Feb 2014 08:46:23 +0000

> My concern is that if we start using structure in schemes to denote metadata (such as "this is OK to use in the Web security model" for web+), it becomes possible that a scheme will need to use mor…

Yes, I agree.  That was the point of my comment: IMO, web+ and email+ are not 
(formally) structure, just a particular (and maybe fanciful) way of constructing 
a name.  Apologies that I wasn't clearer about that.

The problem comes, as you point out later, when other specifications try to 
exploit such fanciful name-forms in potentially inconsistent ways.

#g
--

---

From: Dave Thaler <[email-masked]>
Date: Fri, 21 Feb 2014 03:52:39 +0000

> the perceived barrier to provisional registration of schemes.

Great, thanks for the careful review.
 
> reviewing a URI scheme proposal is: "What kinds of thing do URIs in this
> scheme identify, or how do I find out?".  I'd like to see all scheme
> registrations providing a clear answer for this.

Providing a clear answer to this and other questions is an example of 
the burden that disincents people from registering.  The act of writing
responses, and ensuring that they are correct and readable (and in some
cases, approved by management or legal or whoever else) is perceived as
onerous compared to the marginal benefit the applicant gets.

> One of the problems I have sometimes experienced in reviewing URI
> scheme registration submissions is understanding what the corresponding
> scheme is intended to identify.  If it is a locator, then it's usually fairly clear.
> But some schemes I've seen - particularly where used as particular identifiers

I agree.  The larger question we should really be discussing is: why do we
need to know?    Would we rather have unregistered schemes that we don't
know the answer for, or registered schemes that we don't know the answer for.
Currently none of the 4 stated goals of the registry really require such
understanding.  An understanding of the _syntax_ is useful for another
unstated goal: improve compliance with guidelines/recommendations and
thus interop with generic URI parsers, etc.  But an understanding of 
_semantics_ doesn't seem to be required for that either.  So what goal do
you think it's accomplishing?  (Not to imply I don't think it's not valuable.)

In my opinion, we need to separate guidance to defining document writers
from guidance and requirements to the person wanting to _register_ a scheme
(keeping in mind that they could be unrelated, as in the third-party case).
The bar for the latter should be low.   Advice for the former should be liberally
given, but not interfere with keeping the bar to _register_ low.   

For example, you may recall that during the third-party registration experiment
that Alexey and I did, all the Microsoft schemes came from Alexey instead of
me, since the bar for third-party registration was lower... coming from me 
might imply I actually vouched that the information was correct, which was
too onerous to do during the experiment.
 
> I think the text "Schemes that are not intended to be used as locators
> SHOULD describe how the resource identified can be determined or
> accessed by software that obtains a URI of that scheme." goes some way to
> this, but that was present in the previous draft and didn't always get noticed.
> Also, there is not always a mechanism that is available to software (e.g.
> urn":).  I'm wondering if this can be beefed up a bit... e.g. to lead with
> something like:
> 
> "URI scheme specifications should be clear about the kind of resource that
> they may identify, or the means (technical or non-technical) by which URIs
> are related to the resources they identify"
> 
> domain or system (**); the latter would apply to locator schemes like http:,
> or identifier schemes like urn: where there is a defined administrative
> delegation structure.
> 
> <aside>
> (**) for background, the acct: scheme was defined as part of the WebFinger
> work, but acct: URIs are not specifically tied to or defined by the WebFinger
> protocol.
> </aside>
> 
> Re:  "[[CREF2: Open Issue: Should we define a mechanism to register a
> scheme prefix ("web+", "ms-", etc.)?  --DT]]"
> 
> I think not.
> 
> encourage scheme proliferation in conflict with the exhortations in section
> 3.1 ("In general, the use and deployment of new schemes in the Internet

I have certainly heard multiple requests for this because of the burden
of registering one scheme.  When someone wants a set of related ones,
and possibly the ability to add more over time, I get asked if they can just
use a common prefix.  Of course using a common prefix is good for
understanding that they're related.  But they're asking because of the
burden of registering each one.  So for example "ms-settings-*" 

> I've not seen any cases where this has been a problem, but maybe that's
> because I mainly see a self-selecting population ;)  (I.e. those who have
> actually submitted a registration request.)

Yes, that's why.  But I guess my view goes back to my point above
about guidance to doc authors vs guidance to applicants.
 
> Some time ago, we started creating a FAQ/guidance page at IANA for a
> similar registry (message header fields), with the goal of demystifying the
> process and encouraging early registration.  Unfortunately, that effort fizzled
> (though I think an initial draft is still around on an IETF/IANA wiki page.)
> 
> Given the limited nature of URI scheme name space, I think that IESG/IANA
> should always have final say about name allocation.  Given that we try to
> keep the bar low, I feel formal FCFS makes it too easy to use provisional
> registration as a land grab - writing that into the spec would make it harder
> for an expert reviewer to push for alternatives where appropriate.  (I think
> there is one occasion in the past few years where the choice of name has
> been cause for push-back, so it's not a great problem.)

The notion that the expert reviewer might push for alternatives is part of
the disincentive to register in the first place.  So I think that not having FCFS
for Provisional just results in the current mass unregistered use, which doesn't
help anyone.  It's a no-win situation :)

> As reviewer, I have tried to treat the role as providing guidance rather than
> as gatekeeper (I don't think I've ever recommended rejection of a
> provisional registration request, though I do often make comments), so I'm a
> little troubled by the perception that expert review is a deterrent.  Can we
> do something in the spec language to make this less of a concern?
> 

I'm dubious that this would be perceived as less of a disincentive.

> I'm not sure what it is you don't want.

The "--??" instead of "--DT" means it's not me.  This comment was in the
spec before I took over as primary editor.  So the other authors will
need to answer that.

> 
> I think it is useful that the IESG can be final arbiter, as it provides some room
> for making decisions that are not in strict accordance with the process
> requirements, without kicking the door open to making arbitrary and
> capricious decisions.  There have been a few cases (I forget details) where
> the specific drafting of the process has seemed to be at odds with a common
> sense "do the right thing" approach - having a way to accommodate these
> within a clearlhy documented framework seems useful to me.
> 
> ...
> 
> Section 7.2:
> 
> I'd suggest that at least the registration template submitted to IANA be
> treated as "IETF contribution", even if the rest of the document cannot, since
> IANA may need to republish that much.  The registration template itself can
> be short and consist mainly of pointers to other documents, so I don't think
> that should be a great disincentive.

Are other IANA requests, like requests for a port number, treated as
IETF contributions?  I see nothing at http://www.iana.org/form/ports-services
or RFC 6335 that would indicate so.   Why should this registry be different?

> That's pretty much covered in section 7.3.

I mean when would you actually take a Provisional application and say
"hey IANA, this should really be Permanent even though they only asked
for Provisional"?  The only case I can think of is when someone violated
the "For IETF Standards-Track documents, Permanent registration status is
REQUIRED" requirement, but should that really be the job of the IESG to
catch?  Do we really need to say anything about the expert recommending
an upgrade?

-Dave

> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >

---

From: Graham Klyne <[email-masked]>
Date: Fri, 21 Feb 2014 11:37:36 +0000

Dave,

TL;DR:  I've no objection to your points, just wanting to provide some feedback 
for the debate.

I think our (small) differences hinge on the extent to which URI space 
(including provisional schemes) should be managed as a space of identifiers vs a 
desire for complete documentation of usage.  I think that's a community 
consensus call, with reasonable views on all sides, and I'm OK with whatever 
point our community decides is most useful.  In reading your responses, I'd also 
consider dropping even the FCFS constraint on provisional registration.

I'd also be OK with dropping expert review for provisional registrations, if 
that's seen as a disincentive to registration.  I'd still keep it for permanent 
registrations, as there is an issue of possible interference between different 
parts of the standards community, and given how fundamental URIs are to the 
architecture of the World Wide Web (which I think we'd agree is a pretty 
important application).

My own concern is that some registrations look to me like protocol elements 
rather than identifiers, which don't have any need to be part of the URI space 
of *identifiers*.  If one is to go to the trouble if designing a URI scheme, it 
seems a small step to indicate what it actually identifies.  (FWIW, in reviewing 
proposals, I've questioned this aspect in provisional registration requests 
while making it clear that I'm not rejecting the proposal.)

All of which, I think, resonates with your comments about separating 
registration requirements from guidance for scheme authors.

#g
--

---

From: Dave Thaler <[email-masked]>
Date: Fri, 28 Feb 2014 00:17:33 +0000

> 4) As noted in my presentation at last IETF and 
> draft-thaler-uri-scheme-reg- ps-01, RFC 4395's convention for private 
> namespaces (converting "." to "-" in scheme names based on a domain 
> name) causes conflicts.  Updated example to use "." instead of "-"
> to reduce collisions.  And open ticket #17 covers the rest of the 
> conflict problem.

I just went through the site http://appurl.org/docs/quickstart 
which Mike Amundsen pointed to last August in
https://mailarchive.ietf.org/arch/msg/apps-discuss/SZ_s1HYoTWZTBiX0CeYOnNqMlfo

It says:
> AppURL recommends you use your website's (sub)domain as your scheme.
> For example, we picked grid6.us as the URL scheme for our Grid6 
> example app, because that's where its website lives.

So this directly conflicts with the RFC 4395 guidance to use a *reversed* 
domain name, and just reinforces that the problem is even worse than 
stated in the problem statement document.

I see Larry recommended they get their proposal reviewed by the apps area
(http://lists.w3.org/Archives/Public/www-tag/2013Aug/0026.html) but
the bad guidance on their page hasn't changed.

-Dave