Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-uri-scheme-reg-04.txt> (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice

From: Dave Thaler <[email-masked]>
Date: Thu, 2 Apr 2015 19:27:04 +0000

Thanks for the thorough review.  The co-authors and doc shepherd met in
Dallas and went over these.  Below is what we did in response in draft-05:

Martin J. Dürst" wrote:
> My overall impression is that the overall direction of the draft is just fine, but
> that presentation and wording are quite rough in many places and would
> tremendously benefit from more careful wording.
> 
> 
> Introduction: Overall, this felt too long, and it would benefit from better
> structuring, and/or moving some of the points out to their own
> sections/subsections. For example, adding subsection titles such as "URIs and
> IRIs" and "Generic Syntax and Scheme Specific Syntax" or some such would
> help quite a lot.

Added subsection titles.

> "  o  provide a central point of discovery for established URI scheme
>        names, and easy location of defining documents for standard
>        schemes;"
> The use of the word "standard" in "standard scheme" is unclear. This use
> doesn't appear anywhere in the document. Do you mean permanently
> registered schemes? If there's some specific point to be made, please make it
> more clearly. Otherwise, I suggest to just drop the word "standard".

Agreed, dropped the word "standard".

> "o  discourage multiple separate uses of the same scheme name;"
> I'd personally be happier if this said "strongly discourage", because I hope we
> all agree that it's really not a good idea. If the consensus is that it's obvious
> anyway that it's really not a good idea, and we don't need to be overly clear
> about that, then I'll keep quiet.

We believe it's obvious anyway from the current text.
 
> "o  encourage registration by setting a low barrier for registration."
> What about making this "encourage early registration"?

No, that would have a different meaning.  The main problem with provisional
today is lack of registration *at all*.   The goal is to lower the bar so that
we actually get more of them rather than squatting, the common case today.
 
> "A URI scheme name is the same as the corresponding IRI scheme name."
> At the minimum, I'd turn this around and say "An IRI scheme name is the
> same as the corresponding URI scheme name." But because the there isn't
> really anything like an "IRI scheme name", I'd actually prefer if this said "IRIs
> use the same scheme names as URIs." or something similar.

Done.
 
> "For example, this means that fragment identifiers (#) cannot be re-used
> outside the generic syntax restrictions."
> My 'best-guess' interpretation of this sentence is that this intended to say
> that a scheme definition cannot define fragments that contain characters (e.g.
> #) that RFC 3986 doesn't allow.

Correct.
 
> But this is bad advice, because scheme definitions cannot say anything about
> fragments at all. This isn't syntax, but semantics; the semantics of a fragment
> are defined by the media type, not the scheme. I haven't found any place
> anywhere in this doc that says this, it clearly should be added.
>
> If you want to make an example re. syntax, I'd suggest to say something like
> "For example, the query part cannot contain literal '#' characters because they
> and anything after them would be interpreted as part of the fragment and
> not the query." or some such.
> 
> Also, the "(#)" in the text is completely superfluous; the '#' itself isn't the
> fragment, and a reader should be able to correlate the word in the text and
> the same word in the ABNF.

Updated to read:
" For example, this means that fragment identifiers cannot be re-used
   outside the generic syntax restrictions, and fragment identifiers are
   not scheme-specific."

> "A scheme definition must specify the scheme name and the syntax of the
> scheme-specific part, which is clarified as follows:"
> Saying "clarified as follows" and then just giving some ABNF may be difficult
> to grok for some people. I propose to change the sentence to "A scheme
> definition must specify the scheme name and the syntax of the scheme-
> specific part, which corresponds to the 'hier-part' and the optional query in
> the above definition. This can be clarified by rewriting the definition as
> follows:"

We thought it's already obvious enough and such a change might make it
harder to read.  Since you said it "may" be difficult to grok, we didn't take this
as a must-change.
 
> 2. Terminology:
> 
>     Within this document, the key words MUST, MAY, SHOULD, REQUIRED,
>     RECOMMENDED, and so forth are used within the general meanings
>     established in [RFC2119], within the context that they are
>     requirements on future registrations.
> The double 'within' is confusing. I propose to replace "within the context that
> they are requirements on future registrations" with "as requirements on
> future registrations"

Done.
 
> 3.  Requirements for Permanent Scheme Definitions
> 
>                                                                       For
>     IETF Standards-Track documents, Permanent registration status is
>     REQUIRED.
> Please change this to: "For URI Scheme definitions in IETF Standards-Track
> documents, Permanent registration status is REQUIRED."

Done.

> 3.2. Syntactic Compatibility
> 
>                                             Care must be taken to ensure
>     that all strings matching their scheme-specific syntax will also
>     match the <absolute-URI> grammar described in [RFC3986].
> 
> Pronouns like "their" don't usually work well in standard language. I
> suggest changing "their scheme-specific syntax" to "the syntactic
> restrictions of the scheme definition" or some such.

This text is unchanged from RFC 4395.  However, we believe the RFC editor
has specific stylist preferences in this area that they often change anyway,
and so we defer to the RFC editing pass to handle during AUTH48.

>                                                     If there is a strong
>     reason for a scheme not to use the hierarchical syntax, then the new
>     scheme definition SHOULD follow the syntax of previously registered
>     schemes.
> 
> Please change "the syntax of previously registered schemes" to "the
> syntax of previously registered schemes with similar components or
> similar syntactic needs." or some such, to make it clear that it's not
> sufficient to just copy some syntax if it's totally unrelated.

Added "similar".

>     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).
> It would be good if the text gave the reasons for the SHOULD (which I
> fully agree with; maybe even a MUST).

Reworded as 
"... order to avoid unintended processing such as resolution of "." and ".." (dot-segments)."

> Please add a(n informational) reference to Gettys, J., "URI Model
> Consequences", <http://www.w3.org/DesignIssues/ModelConsequences> in
> this section. It is a great text helping designers of URI scheme syntax
> to understand the ideas regarding the different syntax components.

That reference is not positioned as a consensus statement and actually
makes weaker recommendations than in this document.   As such, we thought
it might add confusion if it were referenced.   While it may be a good reference
for some purposes, we decided that citing it was not necessary.
 
>     New schemes SHOULD clearly define the role of [RFC3986] reserved
>     characters in URIs of the scheme being defined.
> The location of [RFC3986] is a bit strange. It might work if "[RFC3986]
> reserved characters" is taken as a phrase, but it's difficult for the
> reader to see that. Also, the specific topic is discussed in Section 2.2
> of [RFC3986], so change the above to:
>     New schemes SHOULD clearly define the role of reserved characters
>     (see [RFC3986], Section 2.2) in URIs of the scheme being defined.

Done.
 
> 3.3. Well-Defined
> 
>                                                          and how legal
>     values in the base namespace, or legal protocol interactions, might
>     be represented in a valid URI.
> "might be represented" -> "are represented"

Done.

>                                     See Section 3.6 for guidelines for
>     encoding binary or character strings within valid character sequences
>     in a URI .
> "binary or character strings" -> "sequences of bytes or characters" (in
> most contexts (programming languages,...), "character string" is
> equivalent to "string", while "binary string" is undefined.)

Changed to "strings or sequences of bytes".

> Superfluous space before period.

Done.

> 
>                 If not all legal values or protocol interactions of the
>     base standard can be represented using the scheme, the definition
>     SHOULD be clear about which subset are allowed, and why.
> "Which subset are" -> "which subset is" (or "which subsets are")
> 
> 
> 3.5. Context of Use
> 
>                    Most commonly, URIs are used as references to
>     resources within directories or hypertext documents, as hyperlinks to
>     other resources.
> 
> This sentence is totally unclear. Why do directories turn up here? Is
> "resources within directories" and "other resources" parallels? Are
> "references" and "hyperlinks" intended to be parallels? Is "references
> to resources within ..." intended to mean "references to resources from
> within ..." or "references to (resources within ...)"?. Please clarify.

Agree, and RFC 4395 and the drafts that preceded it were equally unclear.
Larry (who was part of the original discussion) rewrote this now as:
"For example, URIs are commonly used within hypertext documents as
references to other resources."

> 3.6. Internationalization and Character Encoding
> 
>     When describing schemes in which (some of) the elements of the URI
>     are actually representations of human-readable text, care should be
>     taken not to introduce unnecessary variety in the ways in which
>     characters are encoded into octets and then into URI characters; see
>     [RFC3987] and Section 2.5 of [RFC3986] for guidelines.  If URIs of a
>     scheme contain any text fields, the scheme definition MUST describe
>     the ways in which characters are encoded and any compatibility issues
>     with IRIs of the scheme.
> 
> I think it would be extremely helpful to the average URI scheme
> designer/describer if this section mentioned the use of UTF-8. The
> reference to Section 2.5 of RFC 3986 is good, but the problem with that
> section is that it starts out with very general and abstract language,
> and one has to read through the whole section to find the relevant (and
> extremely clear and appropriate) advice in the last paragraph.
> 
> At a minimum, please point the reader to the last paragraph of Section
> 2.5. Much better would be to include that paragraph verbatim (and saying
> so explicitly):

Done.  Did not include the large verbatim quote but cited it explicitly.

> 
> >>>>
>     When a new URI scheme defines a component that represents textual
>     data consisting of characters from the Universal Character Set [UCS],
>     the data should first be encoded as octets according to the UTF-8
>     character encoding [STD63]; then only those octets that do not
>     correspond to characters in the unreserved set should be percent-
>     encoded.  For example, the character A would be represented as "A",
>     the character LATIN CAPITAL LETTER A WITH GRAVE would be represented
>     as "%C3%80", and the character KATAKANA LETTER A would be represented
>     as "%E3%82%A2".
> >>>>
> 
>     The scheme specification SHOULD be as restrictive as possible
>     regarding what characters are allowed in the URI, because some
>     characters can create several different security considerations (see,
>     for example [RFC4690]).
> I'm afraid that many people will read "as restrictive as possible" as
> "well, let's just do ASCII only" or some such. I believe and hope that
> this wasn't the intent, but I don't think this comes across. One kind of
> improvement would be to change "as restrictive as possible" to just
> "restrictive". Another is to change "as restrictive as possible" to "as
> restrictive as possible without excluding characters outside US-ASCII".

We (including the doc shepherd) discussed this and believe it already had
the intended meaning, especially with the paragraph that immediately
follows the quoted text (and which you quote later in this email)
and reflects WG consensus.   However, we added additional text to the
subsequent paragraph for your last point below, which we believe is s
ufficient to also clarify the intent of the text above.

> 
> "can create security considerations" sounds weird. The characters may
> create security issues or security problems or some such, which may need
> to be described in a security consideration section.

Changed "considerations" to "issues".

>     All percent-encoded variants are automatically included by definition
>     for any character given in an IRI production.  This means that if you
>     want to restrict the URI percent-encoded forms in some way, you must
>     restrict the Unicode forms that would lead to them.
> 
> I know what you want to say here (I think it's the point originally
> brought up by Björn Höhrmann in the IRI WG). But I think it's too
> restrictive and can be worded better:
> 
>     URI schemes that include textual data from Unicode have to be aware
>     that they have to define both the actual characters allowed (for
>     IRIs) and the corresponding percent-encoded forms (for URIs and
>     IRIs). This can be done in various ways, but in most cases, it is
>     advisable to define the actual characters allowed in an IRI
>     production, to allow the 'pct-encoded' definition from Section 2.1
>     of [RFC 3986] at the same places, and to add prose that limits
>     percent-escapes to those that can be created by converting valid
>     character sequences to percent-encoding via UTF-8.

Added this variation of your suggestion, after the existing text about IRIs:
   In most cases,
   it is advisable to define the actual characters allowed in an IRI
   production, to allow the 'pct-encoded' definition from Section 2.1 of
   [RFC3986] at the same places, and to add prose that limits percent-
   escapes to those that can be created by converting valid character
   sequences to percent-encoding via UTF-8.

Dave

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Apr 2015 15:57:06 -0400

--On Thursday, April 02, 2015 19:27 +0000 Dave Thaler
<[email-masked]> wrote:

>...
>> "For example, this means that fragment identifiers (#) cannot
>> be re-used outside the generic syntax restrictions."
>> My 'best-guess' interpretation of this sentence is that this
>> intended to say that a scheme definition cannot define
>> fragments that contain characters (e.g.
>> # ) that RFC 3986 doesn't allow.
> 
> Correct.

Hi.

Just because this may be an illustration of how much 3986 (with
or without this I-D) is confusing everyone, my reading of the
syntax in 3986 is that 
   somescheme://domain/foobar#sss#yyy 
is perfectly valid.  The actual fragment is "foo#yyy" and there
is no requirement that the embedded "#" be %-encoded.

So Martin's "best guess" sentence above, which you identified as
correct, actually is not.

>> But this is bad advice, because scheme definitions cannot say
>> anything about fragments at all. This isn't syntax, but
>> semantics; the semantics of a fragment are defined by the
>> media type, not the scheme. I haven't found any place
>> If you want to make an example re. syntax, I'd suggest to say
>> something like "For example, the query part cannot contain
>> literal '#' characters because they and anything after them
>> would be interpreted as part of the fragment and not the
>> query." or some such.

Now _that_ is strictly correct.  I also note the "isn't syntax,
but semantics" comment above, which is critical to the
syntax-eemantics distinction being drawn in URNBIS -- thanks
Martin.

>...

> Updated to read:
> " For example, this means that fragment identifiers cannot be
> re-used    outside the generic syntax restrictions, and
> fragment identifiers are    not scheme-specific."

This is not correct and has already triggered controversy
because, as Martin points out, the binding between "fragment"
and media type is a matter of semantics, not syntax.  Indeed,
assigning any meaning at all to the string consisting of the
characters "f", "r", "a", "g", "m", "e", "n", and "t" is about
semantics: as far as the generic syntax is concerned, that term
refers to a substring that is preceded by "#" and extends to the
end of the string in in which some characters, if they appear,
are required to be %-encoded (but "#" is not one of those
characters, nor is "?").

>...

I have discussed some issues related to other comments in this
note in other postings and won't repeat myself, but the above
seemed critical.

best,
    john

---

From: Dave Thaler <[email-masked]>
Date: Thu, 2 Apr 2015 21:30:09 +0000

And below is what we (co-authors, with input from doc shepherd) 
did in response in draft-05, regarding the last set of IETF Last Call comments:

Martin J. Dürst wrote: 
> 3.8. Scheme Name Considerations
> 
>                                        New registered schemes
>     registrations MUST follow this syntax, which only allows a limited
>     repertoire of characters (taken from US-ASCII).
> "schemes registrations" -> "scheme registrations"

Done

>     A scheme name is not a "protocol" although, like a service name as
>     defined in section 5 of [RFC6335], it often identifies a particular
>     protocol or application.
> '"protocol" although' doesn't work. I suggest to reword as:
>     A scheme name is not a "protocol". However, like a service name as
>     defined in section 5 of [RFC6335], it often identifies a particular
>     protocol or application.

Done

> I wonder whether it makes sense to say something about abbreviations, such
> as "If there is a well-known abbreviation for the protocol or service, then it's
> preferable to use it as a scheme name (e.g. http:
> rather than hypertext-transfer-protocol:)."

We believe it's already obvious from the existing text in section 3.8 that states
   Scheme names SHOULD be short, but also sufficiently descriptive and
   distinguished to avoid problems.

>     Some organizations desire their own namespace for URI scheme names
>     for private use (see Section 6).  In doing so, it is important to
>     prevent collisions, and to make it possible to identify the owner of
>     a private use scheme.  To accomplish these two goals, such
>     organizations SHOULD use a prefix based on their domain name,
>     expressed in reverse order.  For example, a URI scheme name of
>     com.example.info might be used by the organization that owns the
>     example.com domain name.  Care must be taken, however, if the
>     organization later loses the domain name embedded in their scheme
>     names, since domain name registrations are not permanent.  The URI
>     scheme name registration procedure can be used in such an event.
> The the last sentence is unclear. I suggest to rewrite the last sentence to
> something like "In order to permanently associate the private use scheme
> name with the original domain name owner, the private use scheme can be
> registered using the registration procedure in Section XYZ.".

Done.
 
> Either at the end of section 1 or in a subsection of section 3, it should be
> made *extremely* clear that scheme registrations neither can nor should
> define anything related to fragments, i.e. that fragments are mostly if not
> completely orthogonal to schemes, and their interpretation is defined by the
> MIME media type of the returned representation when dereferencing.

Done as stated in my response to your previous comments which also called this out.

> 4. Guidelines for Provisional URI Scheme Registration
> 
> There is a point about provisional registrations meeting the syntax
> restrictions for scheme names, but nothing about syntax restrictions for the
> rest of the URIs. I think it should be made very clear that while we have made
> provisional registration very easy on purpose, if a scheme doesn't meet the
> general syntax restrictions, it may not work in some or all URI software, and it
> doesn't have a chance to move to permanent registration.

My co-authors felt that the document was already clear enough about those points,
and the danger of putting in more text about provisional registration is that the
more complicated the discussion is, the more likely someone will give up and
simply squat on a scheme name rather than registering as provisional.  Hence
we want to keep the provisional discussion as simple as possible (but no simpler :)

> o  The scheme definition SHOULD include a clear Security
>     Considerations (Section 3.7)
> 
> "a clear Security Considerations" -> "a clear Security Considerations section"
> or "clear security considerations"
> Also: "(Section 3.7)" -> "(see Section 3.7)"

Done

> 5. Guidelines for Historical URI Scheme Registration
> 
>     In some circumstances, it is appropriate to note a scheme that was
>     once in use or registered but for whatever reason is no longer in
>     common use or the use is not recommended.
> Change the last bit ("or the use is not recommended") to "or is no
> longer recommended for use" to avoid a change of subject in mid-sentence.

Changed to "or whose use is not recommended" to fix grammar.

>                    Any scheme that is no longer in common use MAY be
>     designated as historical; the registration SHOULD contain some
>     indication to where the scheme was previously defined or documented.
> "indication to" -> "indication about"

Changed to "indication as to" to fix grammar

> 6. Guidelines for Private URI Scheme Use
> 
>             As such, a unique namespace (see Section 3.8) MUST be used,
>     and it is strongly encouraged to do a Provisional registration unless
>     the scheme name is constructed from a domain name.
> Please add a pointer to the example at the end of section 3.8.

Done
 
> 7. URI Scheme Registration Procedure
> 
> 7.1. General
> 
>     The IANA policy (using terms defined in [RFC5226]) for Provisional
>     registration was formerly Expert Review and is now changed to simply
>     use a First Come First Served policy.
> "is now changed" will read badly a few years down the line. Please
> reword. 

Reworded.

> Also, it may be worth pointing out that somebody who wants to
> register something as provisional still can ask for review. While there
> are people who know that they are exactly right (even if they may be
> wrong), there are also other people who might want to get a (few)
> pair(s) of eyes more on what they are doing.

Added parenthetical clause to the intro text about asking for review:
   3.  If the registration request is for a Permanent registration: registration (or,
       optionally, for any other registration if desired):

> 7.2. Registration Procedures
> 
>     Someone wishing to register a new scheme MUST:
> 
>     1.  Check the IANA URI Schemes registry to see whether there is
>         already an entry for the desired name.  If there is already an
>         entry under the name, choose a different scheme name, or update
>         the existing scheme specification.
> The last clause may be interpreted to allow hijacking. It should be made
> clear that this isn't the intent.

Deleted last clause.
 
>     2.  Prepare a scheme registration request using the template
>         specified in Section 7.4.
> In this paragraph, it should be made clear that the template should be
> complete on its own. As an example,
>     Scheme syntax:
>        See the syntax definition in section FOO.
> is bad, but
>     Scheme syntax:
>        See the syntax definition in section FOO of the BAR specification.
> may be okay, even if it reads somewhat redundantly when inside the BAR
> specification itself.

Changed as follows:
OLD: This template describes the fields that MUST be supplied in a
OLD: scheme registration request:

NEW: This template describes the fields that MUST be supplied in a
NEW: scheme registration request, suitable for adding to the registry:

See also the response to the template fields point below, which goes
together with the above change.

>         2.  Send a copy of the completed template or a pointer to the
>             containing document (with specific reference to the section
>             with the completed template) to the mailing list uri-
>             [email-masked] , requesting review.
> It should be made clear that sending a full copy of the template is
> strongly preferred, because it significantly increases the chance and
> timeliness of comments.

All the technical information needed to review is no longer in the 
template, per WG consensus.  The scheme syntax, scheme semantics,
encoding considerations, interoperability considerations, and security
considerations sections are now only in the scheme defining
document not the request/template itself.   (As a reminder, that change
was done because (a) third-party registrations don't know it and so
cannot require it, and (b) we agreed to lower the bar for provisional
so nothing is required beyond what a third-party registration would
require.   It's still allowed and encouraged in a referenced document
though, if available.)

>                                                                     For
>             example, general discussion of URI syntactical issues could
>             be discussed on [email-masked]; schemes for a network protocol
>             could be discussed on a mailing list for that protocol.
> Change "could" to "ought" or "can" (two times).

Done
 
>     4.  Submit the (possibly updated) registration template (or pointer
>         to document containing it) to IANA at [email-masked].
> It may be obvious to insiders, but worth pointing out because we want to
> reach outsiders, too: It is important to note that submission to IANA
> for registration doesn't happen automatically but has to be done by the
> registrant.

Co-authors thought it was already obvious enough in various places in the doc.

>     1.  IANA checks the submission for completeness; if sections of the
>         template are missing or any citations are not correct, IANA will
>         reject the registration request.
> Again, it may be obvious to insiders, but worth adding: This doesn't
> preclude new, fixed submissions.

Added "A registrant can resubmit a corrected request if desired."

>     3.  Otherwise, IANA enters the registration request in the IANA
>         registry, with status marked as "Pending Review" and the
>         remainder of this section applies.
> Please add a comma after "Pending Review" (end of 'with' clause).

Done
 
>     6.  In the case of a Permanent registration request, the Designated
>         Expert may:
>         *  Request additional review or discussion, as necessary.
> Again this may be obvious to insiders, but it may be worth saying that
> this should as much as possible be conducted on public mailing lists.

We felt this should be left up to the Designated Expert to do the right thing.
(I.e. no consensus to suggest more than that.)

>     Either based on an explicit request or independently initiated, the
>     Designated Expert or IESG can request the upgrade of a 'provisional'
>     registration to a 'permanent' one.
> "IESG" -> "the IESG"

Done

> It would probably be better if the paragraph starting with the above
> lines would move from the end of section 7.2 to the end of section 7.3.

Section 7.2 is about new registrations and 7.3 is about later updates to one.
So the meaning is different.

>                                             Typically this would only
>     occur if the use is considered a standard (not necessarily an IETF
>     standard).
> A standard may be used, but 'use' isn't a standard. Either say "use is
> considered to be very widespread" (I'd avoid the word "standard" in that
> sense) and remove the "IETF standard" parenthetical, or change to "if
> the scheme is defined in a standard" (in that case "IETF standard"
> should be changed to (IETF) Internet Standard).

This is just explaining what the existing DE (Graham) said would apply,
and is here just in case the DE changes at some point down the road.
This text is essentially straight from Graham and takes into account things
the DE considers a "de facto" standard.  This is not normative guidance,
it's just a "typically" informational bit.

> 7.4. URI Scheme Registration Template
>     Contact:
>       Person (including contact information) to contact for further
>       information.
> 
>     Author/Change controller:
>       Person (including contact information) authorized to change this.
> This is a problem with many other registration templates, too, which we
> should fix whenever we can: I have seen many people struggling with this
> distinction. It's rarely very useful.
> 
> What is useful in some cases is to make a distinction between the
> submitter/author and the organization in charge, but "Author/Change
> controller" mixes the two. The minimum improvement that I'd propose is
> the following:
>     Author/Contact:
>       Person (including contact information) to contact for further
>       information.
> 
>     Change controller:
>       Organization or person (including contact information) authorized
>       to change this.
> This would at least make it moderately easy for registrations from the IETF.

Removed "Author" from the label and added "(often the author)" into the
change controller text.   Unless the author is the current change controller
or the current contact, the registry doesn't need to track the author per se

>     The following fields are no longer required in a scheme registration
>     request.  The answers instead belong in the scheme specification.
> "no longer required" and "belong" conflict, in that "no longer required"
> doesn't exclude them, but "belong" does.  I'd prefer to say that if they
> are short or very important, they should be given in the template, if
> they are lengthy, they should be given separately, and if they are
> irrelevant, they can be ignored.

Again per WG consensus they are removed from the template.

Draft -05 updates the text marginally as follows:

   The previous version of this specification required the following
   additional fields in a scheme registration request.  These fields are
   no longer part of the template.  The answers instead belong in the
   scheme specification.

The co-authors and doc shepherd together felt that any more than that
would probably not be in line with declared WG consensus.

>     Interoperability considerations:
>                inability to support multibyte character sets;
> The modern Internet, in particular in URIs and IRIs, does have
> absolutely no need to support multibyte character sets, and even less of
> a need to use such a term (see
> http://www.w3.org/MarkUp/html-spec/charset-harmful.html). Please change
> this to something like
> "inability to support non-ASCII characters".

Removed phrase, since it was just one of three examples, and there's already
other text in the doc about internationalization.

>     Scheme syntax:  The entire range of allowable syntax specified in
>       [RFC3986] is allowed for "example" URIs.
> Please add: The entire range of allowable syntax specified in [RFC3987]
> is allowed for "example" IRIs.

Done

> 8.1. "Example" Scheme Registration Request
> Please change this title to "Example" Scheme Registration Template.

Not done since the meaning is different (see earlier definition of "template").

> 10. Security Considerations
>     All registered values are expected to contain accurate security
>     consideration sections; 'permanent' registered scheme names are
>     expected to contain complete definitions.
> Words such as "accurate" and "complete" are wishful thinking. When it
> comes to security, there is always the chance of a discovery of new
> security issues. This section should make it clear that best effort is
> expected of the registrants, and that third parties may request the
> addition of new issues, but that the security information in a scheme
> registration should never be seen as complete and final.

Replaced with a reference to section 3.7 which already contained better text.

Dave

---

From: Graham Klyne <[email-masked]>
Date: Sat, 04 Apr 2015 17:20:05 +0100

> is no requirement that the embedded "#" be %-encoded.

Exerpted from http://tools.ietf.org/html/rfc3986#appendix-A:

   fragment      = *( pchar / "/" / "?" )

   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

   pct-encoded   = "%" HEXDIG HEXDIG

   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                    / "*" / "+" / "," / ";" / "="

I think it's clear: there's no way an unencoded '#' can appear in a fragment.

#g
--

---

From: t.petch <[email-masked]>
Date: Thu, 9 Apr 2015 12:25:30 +0100

One thought has been bugging me on this on which I have belatedly done
my homework.

How do IRTF documents fit into this?

Over the past few years, the processes for the publication of RFC have
been revised and the procedures for IRTF (and IAB and Individual
Submission) documents have been formalised.

Thus RFC5226 or draft-leiba-cotton sort of imply that they are for IETF
stream documents only whereas IRTF RFC can and do have IANA
Considerations. Both leiba-cotton and this I-D make reference to the
IESG as the place to go for resolution of uncertainties yet the IESG has
no such role for IRTF RFC apart from establishing that there is no
conflict with the work of the IETF - it is nowadays up to the IRSG to
resolve any issues.

And all the talk about Designated Experts and Expert Review refers to
the role of the IESG as being in charge, no mention of the IRSG.

So if an IRTF I-D asks for permanent registration, the IESG sees no
conflict with the work of the IETF but the Designated Expert is unhappy,
where does this go next?  IESG? IRSG? IAB?

Tom Petch

---

From: t.petch <[email-masked]>
Date: Thu, 9 Apr 2015 17:35:06 +0100

Dave

Looking at the IANA Considerations of -06, I would suggest specifying a
name for the new, combined registry.

With the terminology of -leiba-cotton-, 'Uniform Resource Identifier
Schemes' would be a grouping with the new registry one of the registries
under it.  The obvious name for the new registry would be, well 'Uniform
Resource Identifier Schemes ' but that is taken and I struggle to think
of an epithet which would cover both registered and yet to be
registered, historic and not historic, permanent and not permanent URI
scemes; but IANA are going to need one.

And the 'Note' under the grouping will need updating as well.
e.g.
OLD
[RFC4395] defines an IANA-maintained registry of URI Schemes.
These registries include the Permanent and Provisional URI Schemes.

NEW
[RFC4395] defined an IANA-maintained registry of URI Schemes.  [RFC2B]
updates the procedure for registering schemes.  There is now a single
combined registry of Permanent, Provisional, Historic and Pending Review
URI Schemes.

And the Registration Procedure changes as well to a mix of FCFS and
Expert Review but I am not sure how to word that.

Tom Petch

---

From: Graham Klyne <[email-masked]>
Date: Fri, 10 Apr 2015 08:45:34 +0100

My interpretation is: IESG.  The document indicates that IESG is the final arbiter.

#g
--

On 09/04/2015 12:25, t.petch wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Apr 2015 11:01:00 +0100

> My interpretation is: IESG.  The document indicates that IESG is the

Yep, I think that's the case too.

There are some IRTF RFCs that created registries with DEs, for
example [1,2]. So far nobody's asked for a registration and no
experts have been assigned;-) I'm not sure if any other IRTF
RGs have created IANA registries.

When a request does arrive, I'd expect IANA to ask the IESG
as usual. But since there's now an IETF WG on DTN, that isn't
a deal for [1,2].

If a DE was needed for a registry created by an RG and there's
no obvious IETF "home" for that work, I'd not be at all surprised
if the IESG asked the IRTF chair for advice.

S.

[1]
https://www.iana.org/assignments/bundle/bundle.xhtml#block-processing-control
[2]
https://www.iana.org/assignments/ltp-parameters/ltp-parameters.xhtml#cancel-segment-reason-codes