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

[Graham Klyne <[e-mail]>]

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

On 21/02/2014 03:52, Dave Thaler wrote:
> Graham Klyne writes:
>> 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.
>
> Great, thanks for the careful review.
>
>> 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.
>
> 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
>> 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 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"
>>
>> 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.)
>
> 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-*"
>
>> 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.)
>
> 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.)
>>
>> 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.)
>
> 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?
>>
>> 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."
>
> I'm dubious that this would be perceived as less of a disincentive.
>
>>
>> ...
>>
>> Section 7.1:
>>
>> [[CREF9: TODO: We don't want this.  --??]]
>>
>> 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:
>>
>> [[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.
>
> 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?
>
>>
>> ...
>>
>> 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.
>
> 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
>
>>
>> ...
>>
>> [[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
>>>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>