Guidelines and Registration Procedures for URI Schemes
draft-ietf-appsawg-uri-scheme-reg-06

[Ballot comment]
I support Stephen's comments and was wondering about privacy considerations for the contact information provided as well in scheme registration requests.  Just noting the concern would be good and maybe recommending using a generic organizational contact if possible cold work if that's possible, may not always be.

[Ballot comment]

I put what I think it my most important comment first and hope
to see a response to that. (I don't think it'd be correct for
it to be a DISCUSS, but it's close.)

- 3.7, probably too late in the day to ask for it, but if
there are privacy considerations those would also be good to
note - and there will be for some of the application-specific
schemes, that e.g. have personally identifying information in
the scheme specific part. I'd suggest that renaming 3.7 to
"security and privacy considerations" would be good and saying
e.g. that where the scheme specific part is likely to be
privacy sensitive, then that ought be documented and ways of
minimising privacy-unfriendliness ought be documented.

- 3.2, all except the last para: I personally think the
SHOULDs here are bogus. Why does it matter at all, really?  In
any case, even if you maintain it matters, I'd suggest adding
a bit saying that even minor deployment is a reasonable
justification for going against the SHOULDs. If that's not
likely to garner immediate consensus, as I suspect, then I'll
not insist - we can drop the topic and leave it to folks
registering new schemes to continue to battle the URI
police:-(

- 3.2, last para: I'd suggest moving this quite reasonable
constraint away from the rest of this section.

- 3.6, 2nd para: I don't think you've quite said what you mean
here. "As restrictive as possible" could favour "all octets
are U+00A2" - that is very restrictive, but would be
problematic for many parsers I guess. (The U+00A2 value has no
specific significance.) I think what you meant to say was that
the scheme specification SHOULD be as close as possible to (or
deviate as little as possible from) what is allowed in 3986.

- 3.8: (very nitty nit:-) com.example.info isn't a good choice
as both com and info are gTLDs which may confuse some reader.
I'd suggest com.example.mything or similar.

- 3.8: I'm not sure, but are you really saying here that the
these scheme, after you take away the rightmost component,
ought be in the public suffix list? If so, that might actually
be good guidance as com.example.a.b.c.d is much more likely to
suffer bitrot over time I'd say. (Compared to com.example.abcd
I mean.)

- 7.3, 1st para: it'd have been nice if you could have avoided
IESG action being required for some details (e.g.  a change of
contact address from a@example.com to b@example.com), but I
guess that might be too tricky to get right in text, so ok.

- I agree with Ben's comment wrt loads of SHOULDs

[Ballot comment]
I am curious how the expert review required in the document interacts with bona-fide standards actions. There's already an ongoing discussion on that, and Barry has noted it in his on comments, so I will leave this as a comment. In particular I wonder if the "On receipt of a registration request" section of 7.2 should be different if the request was part of an IETF/IESG reviewed and approved action in the first place.

There are a lot of SHOULDs in this document. I wonder how an expert reviewer is supposed to interpret deviations from SHOULD level requirements. This is especially true in statements like "... SHOULD include clear security considerations or explain [why not]". The expert's life might be easier if there was some text encouraging that deviations from SHOULDs be accompanied by an explanation.

[Ballot comment]
There's ongoing discussion about the effect this has on existing registered schemes, particularly "urn:", including concern that this constrains other working groups (such as urnbis) inappropriately.  I will hold back the final approval until that's sorted out.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-uri-scheme-reg-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

We have questions about some of the IANA actions requested by this draft.

IANA understands that, upon approval of this document, there are four actions which IANA must complete.

First, in the Uniform Resource Identifier (URI) Schemes registry located at:

http://www.iana.org/assignments/uri-schemes/

the reference for the entire registry is to be changed from RFC4395 to [ RFC-to-be ].

Second, this draft updates the registration procedures for the Uniform Resource
Identifier (URI) Schemes registry to the following:

"Permanent URI Schemes": (No change)
Expert Review

"Provisional URI Schemes":
OLD:
Expert Review

NEW:
First Come First Served

"Historical URI Schemes":
Expert Review ???

Question: What is the policy to designated a schema as historical?  Expert Review?
What if someone requests to mark a FCFS Provisional schema, how should
IANA process the request?

Third, also in the Uniform Resource Identifier (URI) Schemes registry located at:

http://www.iana.org/assignments/uri-schemes/

the "Permanent URI Schemes", "Provisional URI Schemes", and "Historical URI Schemes" sub-registries into a single common registry.

Fourth, also in the Uniform Resource Identifier (URI) Schemes registry located at:

http://www.iana.org/assignments/uri-schemes/ the new, merged registry created in step three above is to have the following change: two new columns are to be added to the registry. First, an additional "Status" column containing the status (Permanent, Provisional, Historical, or Pending Review), and second an additional "Notes" column which is normally empty, but may contain notes approved by the Designated Expert.

Fifth, also in the Uniform Resource Identifier (URI) Schemes registry located at:

http://www.iana.org/assignments/uri-schemes/

in the new, merged registry created in step two above a new URI scheme is to be registered as follows:

URI Scheme: example
Template: [ as in section 8.1 of the current document ]
Description: Example
Status: permanent
Notes:
Reference: [ RFC-to-be ]

Comment/Question: As this document requests a registration in an Expert Review (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these five actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Guidelines and Registration Procedures for URI Schemes'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-03-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Alexey Melnikov.  The Responsible Area Director is Barry
Leiba.

Based on experience with registering provisional and permanent URIs, this document
updates RFC 4395 (which was itself a BCP itself). In particular rules for provisional
registrations were relaxed to make registrations easier.

2. Review and Consensus

This document was reviewed by people who had to deal with URI definitions and
registrations, including former Apps ADs and the current URI registration expert reviewer.
The document had enough reviews.


3. Intellectual Property

No IPR disclosures have been submitted and authors have indicated they are not aware
of any other IPR issues.

4. Other Points

The document is about IANA registrations. I believe it is detailed and well written.

1. Summary

The document shepherd is Alexey Melnikov.  The Responsible Area Director is Barry Leiba.

Based on experience with registering provisional and permanent URIs, this document updates RFC 4395 (which was itself a BCP itself). In particular rules for provisional registrations were relaxed to make registrations easier.

2. Review and Consensus

This document was reviewed by people who had to deal with URI definitions and registrations, including former Apps ADs and the current URI registration expert reviewer. The document had enough reviews.


3. Intellectual Property

No IPR disclosures have been submitted and authors have indicated they are not aware of
any other IPR issues.

4. Other Points

The document is about IANA registrations. I believe it is detailed and well written.