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

[Graham Klyne <[e-mail]>]

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
--



On 14/02/2014 22:21, Dave Thaler wrote:
> 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: [e-mail] [mailto:[e-mail]]
> 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
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>