Subject: APPSDIR review of draft-farrell-decade-ni-07

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 05 Jun 2012 18:42:49 +0900

Hello everybody,

[For replies, please trim the cc list, thanks!]

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-farrell-decade-ni-07
Title: Naming Things with Hashes
Reviewer: Martin Dürst
Review Date: 2012-06-03, 2012 (written up 2012-06-04/05)
IETF Last Call Date: started 2012-06-04, ends 2012-07-02

Summary: This draft addresses a real generic need, but the current form 
of the draft is the result of adding more and more special cases without 
a clear overall view and a firm hand to separate the wheat from the 
chaff. This shows both in the technical issues as well as in many of the 
editorial issues below. This draft is not ready for publication without 
some serious additional work, but that work is mostly straightforward 
and should be easy to complete quickly.

Major design issue:

The draft defines two schemes, which differ only slightly, and mostly 
just gratuitously (see also editorial issues).
These are the ni: and the nih: scheme. As far as I understand, they 
differ as follows:
                                     ni:                nih:
authority:                          optional           disallowed
ascii-compatible encoding:          base64url          base16
check digit:                        disallowed         optional
query part:                         optional           disallowed
decimal presentation of algorithm:  disallowed         possible

The usability of URIs is strongly influenced by the number of different 
schemes, with the smaller a number, the better. As a somewhat made-up 
example, if the original URIs had been separated into httph: for HTML 
pages and httpi: for images, or any other arbitrary subdivision that one 
can envision, that would have hurt the growth and extensibility of the 
Web. Creating new URI schemes is occasionally necessary, and the ideas 
that lead to this draft definitely seem to warrant a new scheme (*), but 
there's no reason for two schemes.
[(*) I know people who would claim the the .well-formed http/https thing 
is completely sufficient, no new scheme needed at all.]

More specifically, if the original URIs had been separated into httpm: 
(for machines) and httph: (for humans), the Web for sure wouldn't have 
grown at the speed it did (and does) grow. In practice, there are huge 
differences in human 'speakability' for URIs (and IRIs, for that 
matter); compare e.g. http://google.com with 
http://www.google.co.jp/#sclient=psy-ab&hl=en&site=&source=hp&q=hash&oq=hash&aq=f&aqi=g4&aql=
(which I have significantly shortened to hopefully eliminate potential 
privacy issues), or compare the average mailto: URI with the average 
data: URI. However, what's important is that there never has been a 
strong dividing line between machine-only and human-only URIs or 
schemes, the division has always been very gradual. Short and mainly 
human-oriented URIs have of course been handled by machines, and on the 
other hand, very long URIs have been spoken when really necessary. 
"Speakability" has been maintained to some extent by scheme designers, 
and to some extent by "survival of the fittest" (URIs that weren't very 
speakable (or spellable/memorizable/guessable/...), and their Web sites, 
might just die out slowly).

It should also be noted that the resistance against multiple URI schemes 
may have been low because there are so many different ways to express 
hashes in the draft anyway, and one more (the nih: section is the last 
one before the examples section) didn't seem like much of a deal 
anymore. But when it comes to URIs, one less is a lot better than one more.

In the above ni:/nih: distinction, nih: seems to have been added as an 
afterthought after realizing that reading an ni: URI aloud over the 
phone may be somewhat suboptimal because there is a need for repeated 
"upper case" - "lower case" (sure very quickly shortened to "upper" - 
"lower" and then to "up" - "low" or something similar). It is not a bad 
idea to try to make sure that IETF technology, and URIs in particular, 
are accessible to people with certain kinds of dislexya. (There are 
indeed people who have tremendous difficulties with distinguishing 
upper- and lower-case letters, and this may or may not be connected with 
other aspects of dislexya.) It is however totally unclear to this 
reviewer why this has to lead to two different URI schemes with other 
gratuitous differences.

Finding a solution is rather easy (of course, other solutions may also 
be possible): Merge the schemes, so that authority, check digit, and 
query part are all optional (an authority part and/or a query part may 
very well be very useful in human communication, and a check digit won't 
hurt when transmitted electronically) and the decimal presentation of 
the algorithm is always allowed, and use base32 
(http://tools.ietf.org/html/rfc4648) as the encoding. This leads to a 
16.6% less efficient encoding of the value part of the ni: URI, but 
given that other URI-related encodings, e.g. the %-encoding resulting 
when converting an IRI to an URI, are much less efficient, and that URI 
infrastructure these days can handle URIs with more than 1000 bytes, 
this should not be a serious problem. Also, there's a separate binary 
format (section 6) that is more compact already.

(relatively) Minor technical issues:

Section 2, "When the input to the hash algorithm is a public key value": 
Is it absolutely clear that this will work for any and all public key 
values, existing and future, and not only for what's currently around? 
After all, as far as I understand, the concept of a public key is a 
fairly general one.

"Other than in the above special case where public keys are used, we do 
not specify the hash function input here.  Other specifications are 
expected to define this.": Do you really expect that to happen? Wouldn't 
it be better limit variability here as much as possible, and to use 
media types to identify different kinds of data? This would also work 
for public keys: If there's a MIME media type for a 
SubjectPublicKeyInfo, then the fact that this media type is the 
preferred way to transfer a public key becomes an application convention 
rather than a special case in the spec. If a better way (or just another 
way) to encode/transfer public keys became popular at a later date, 
there would be no need to change the spec.

Related, in Section 3:
    The "val" field MUST contain the output of base64url encoding the
    result of applying the hash function ("alg") to its defined input,
    which defaults to the object bytes that are expected to be returned
    when the URI is dereferenced.
How do I know whether the default applies or not? The URI doesn't tell 
you. Deducing from context is a bad idea.

Section 3: "Thus to ensure interoperability, implementations SHOULD NOT 
generate URIs that employ URI character escaping": This is wrong and 
needs to be fixed. Characters such as "&", "=", "#", and "%", as well as 
ASCII characters not allowed in URIs and non-ASCII characters MUST be 
%-encoded if they appear in query parameter values in URIs (or in query 
parameter tags, which is however less likely). It would be better if the 
spec here deferred to the URI spec rather than trying to come up with 
its own rules.

Section 3: "The Named Information URI adapts the URI definition from the 
URI Generic Syntax [RFC3986].": This sounds as if this were a voluntary 
decision (and the text should be changed to avoid such an impression), 
but if you don't conform to RFC 3986 syntax, you're not an URI. This is 
the first time I have seen an URI scheme definition starting explicitly 
with the top ABNF rule from RFC 3986 
(http://tools.ietf.org/html/rfc3986#appendix-A). This is completely 
unnecessary. Just make sure your production conforms to the generic URI 
syntax, and mention all the ABNF rules from RFC3986 that you use.

Also, using the "URI" production from RFC 3986, and then silently 
dropping the #fragment part, is technically wrong. Scheme definitions 
have nothing to do with the fragment (including the question of whether 
there's a fragment or not; the semantics of fragments are defined by the 
MIME media type that you get when you resolve). This may not be 
completely clear in RFC 4395, but the IRI WG is working on an update of 
RFC 4395 where this will be made clearer (see also 
http://trac.tools.ietf.org/wg/iri/trac/ticket/126; thanks for giving me 
a chance to remember that I had to create a new issue in the tracker for 
this :-).

Section 3, ABNF:
             ni-hier-part   = "//" authority path-algval
                              / path-algval
This gives you ni://example.com/sha-256;f4OxZX_x_FO5... (//authority/) 
and ni:/sha-256;f4OxZX_x_FO5... (one slash only), but the examples show 
ni:///sha-256;f4OxZX_x_FO5... (three slashes). It looks like the ABNF 
you want is:
             ni-hier-part   = "//" authority path-algval
                            / "//" path-algval
(aligning "=" and "/" helps!)
or more simply:
             ni-hier-part   = "//" [authority] path-algval
or even more simply:
             ni-hier-part   = "//" authority path-algval
because authority can be empty; let's show this:
    authority     = [ userinfo "@" ] host [ ":" port ]
If we can show that host can be empty, we're done:
    host          = IP-literal / IPv4address / reg-name
If we can show that any one of these can be empty, we're done, let's 
pick reg-name:
    reg-name      = *( unreserved / pct-encoded / sub-delims )
* means "zero or more", thus reg-name can be empty. QED.

Section 4:
    The HTTP(S) mapping MAY be used in any context where clients without
    support for ni URIs are needed without loss of interoperability or
    functionality.
What is meant by "support for ni"? There's nowhere in the spec where 
this is explained clearly. If I were a browser maker, or writing an URI 
library,..., what would I do to support the ni scheme? The only thing I 
have come up with is to covert ni to the .well-known format, then use 
HTTP(S). In that case, the above text seems wrong, as it says that 
.well-known is used when there's no support for ni, not in order to 
support ni.

Section 5: This defines an "URL segment format". It seems to be limited 
to path componest in HTTP URIs. What if I want to use this in a query 
part, or maybe even as a fragment identifier? What if I want to use this 
as a path component in an FTP URI? Or in some other schem? It would be 
better to define the alg-val (see next point) part as such (before the 
other things), with an explanation along the following lines: "This is 
defined here both for use in other sections of this document as well as 
for use in other places where it may be helpful, such as HTTP URI path 
segments,..."

Section 5 (and Section 3): "To do this one simply uses the "alg;val" 
production": There is no "alg;val" production. Please change to "To do 
this one simply uses the <alg-val> production" and fix the ABNF in 
section 3 to
             path-algval = "/" alg-val
             alg-val     = alg ";" val
It's probably even better to fold this in with the changes to 
ni-hier-part, resulting e.g. in:
             ni-hier-part   = "//" authority "/" alg-val
             alg-val     = alg ";" val

Section 9.4: Status can be 'empty' or 'deprecated'. I suggest to replace 
'empty' with something positive, such as 'valid' or 'active'. This will 
help people who go to the IANA page and start to ask "well, it doesn't 
have a status, what does that mean". Also, I strongly suggest to add an 
additional status 'reserved', and remove the current "Reserved" hash 
name string from the entries with IDs 0 and 32.

Section 9.4: "The Suite ID value 32 is reserved for compatibility with 
ORCHIDs [RFC4843].": How will compatibility be kept for future 
changes/additions in ORCHID?

Major editorial issues:

Title and abstract (and the spec itself) use the wording "Naming 
Things". While in a security context, it may be that there is an 
implicitly assumption that there are only digital things, in a wider 
context, this is of course not true. Research on the Internet of Things 
and efforts such as the Semantic Web/Linked Data try to deal with things 
in the real world. People in these areas it will be confused by title, 
abstract, and text, unless you can show (me and) them an ni: hash for a 
person, an apple, a building, or an elephant. Therefore, while it may be 
possible to keep the catchy title, the abstract has to be fixed to avoid 
such misunderstandings, e.g. by changing "to identify a thing" to "to 
identify a digital object" or some such in the abstract, and likewise in 
the main text of the spec.

"Human-speakable" (e.g. ), "human-readable" (e.g. section title of 
section 7), and "for humans" (e.g. section title of section 9.2): These 
terms are used throughout the spec, but are imprecise and confusing. 
First, there's the problem of interpreting "for humans" in the sense of 
the previous paragraph, which of course has to be fixed. But the main 
problem is that none of the "ni:" URIs are "non-human-readable" or 
"non-human-speakable". Reading them aloud is only somewhat more tedious, 
but not at all impossible. And because the value part of the nih: form 
is 50% longer, and people quickly develop conventions for shortening 
things such as "upper case" and "lower case", it's not even clear that 
reading aloud the nih: form will necessarily take that much time. 
Therefore, I strongly recommend to change all occurrences of 
"Human-speakable", "human-readable", "for humans", and the like, to the 
more precise "more easily read out aloud by humans" or something equivalent.

Abstract and further on: "specifying URI, URL": By all URx theories (see 
e.g. http://www.w3.org/TR/uri-clarification/), URLs are a subset of 
URIs, and therefore saying that the spec specifies an URI and an URL is 
somewhat confusing. I'd propose using wording along the following lines: 
"specifying an URI scheme and a way to map these URIs to http".

Section 2, "When the input to the hash algorithm is a public key value", 
and example section: It took me a while to understand that the "public 
key" stuff was not yet another way to present a hash, and also not a way 
to mix in a public key to the hash in order to obtain some specific 
security property (I wasn't able to figure out how that would work, but 
draft-hallambaker-decade-ni-params contains something similar involving 
digital signatures and a public key). The document would be much easier 
to understand if there was a section e.g. entitled "Forms of input to 
hash", with subsections e.g. "general data", "public keys", "other stuff 
(not defined in this document)". As it is written, the relevant 
paragraphs in section 2 look like an afterthought, and it's not clear to 
what.
Also, the example section should be fixed as follows: 1) say upfront 
that there will be two examples, one for a short string and another for 
a public key. 2) Make sure both examples exercise all forms (the public 
key example seems to be pretty complete, but the "Hello World!" example 
seems to be incomplete). 3) Use the same form of presentation (either a 
table in both cases or short paragaphs in both cases.
The caption on Figure 7 is also way too unspecific.

Section 9.4: "Hash Name Algorithm Registry", and later "a new registry 
for hash algorithms as used in the name formats specified here": IANA 
will be helped tremendously if your draft comes with an 
easy-to-understand and unambiguous name for the new registry. "Hash Name 
Algorithm Registry" may be okay, but is probably not specific enough. 
The circumscription at the start of the section is definitely not good 
enough because you're not registering hash algorithms, but names of hash 
algorithms and their truncations.

Minor editorial issues:

Introduction: It would be good to have a general reference to hashing 
(for security purposes) for people not utterly familiar with the subject.

Intro: After reading the whole document, the structure of the Intro 
seems to make some sense, but it didn't on first reading (where it's 
actually more important). The main problem I was able to identify was 
that after a general outlook in paragraph 1, the Intro drops into a list 
of examples without saying what they are good for. I suggest to, after 
the sentence "This document specifies standard ways to do that to aid 
interoperability.", add a sentence along the lines: "The next few 
paragraphs give usage examples for the various ways to include a hash in 
a name or identifier as they are defined later in this document.". It 
may also make sense to further streamline the following paragraphs, so 
that it is clearer which pieces of text refer each to one of the 
"standard ways".

There are two instances of the term "binary presentation". Looking 
around, it seems that they are supposed to mean the same as "binary 
format". Please replace all instances of "binary presentation" with 
"binary format" to avoid misunderstandings and useless seach time.

Section 3: "A Named Information (ni) URI consists of the following 
components:": It would be good to know exactly where the list ended. One 
way to do this would be to say "consists of the following nine components".

Section 3: "Note that while the ni names with and without an authority 
differ syntactically, both names refer to the same object if the digest 
algorithm and value are the same.": What about cases with different 
authority? The text seems to apply by transitivity, but this may be easy 
to miss for an implementer. I suggest changing to: "Note that while ni 
names with and without an authority, and ni names with different 
authorities, differ syntactically, they all refer to the same object if 
the digest algorithm and value are the same.".

Section 3: "Consequently no special escaping mechanism is required for 
the query parameter portion of ni URIs.": Does this mean "no escaping 
mechanism at all"? Or "nothing besides %-encoding"? Or something else? 
Please clarify.

Figure 3: the "=" characters of the various rules should be aligned as 
much as possible to make it easier to scan the productions (see 
http://tools.ietf.org/html/rfc3986#appendix-A for an example).

Section 3:
             unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
                 ;  directly from RFC 3986, section 2.3
                 ; "authority" and "pct-encoded" are also from RFC 3986
Please don't copy productions. Please don't copy half (or one-third, 
actually) of the productions you use, and reference the rest. Please 
don't say what productions you copy from where in a comment, and even 
less in a comment for an unrelated production. Please before the ABNF, 
say which productions are used from another spec.

Section 4:
    The HTTP(S) mapping MAY be used in any context where clients without
    support for ni URIs are needed without loss of interoperability or
    functionality.
This is difficult to understand. If some new functionality is proposed, 
it's usually a client *with* the new functionality that's needed, not 
one without. Also, the "without loss of interoperability or 
functionality" is unclear: Sure if ni isn't supported, there's a loss in 
interoperability. So I suggest to rewrite this as:
    The HTTP(S) mapping MAY be used in any context where clients with
    support for ni URIs are not available.
(but see also the comment in minor technical issues)

Section 6: "binary format name": Why 'name'? Why not just "binary 
format"? The later is completely clear in the context of the document or 
together with an indication of the document; for something that can be 
used independently, even "binary format name" isn't enough.

Section 6: "suite ID": The word "suite" seems out of place here. In the 
general use of the term, it refers to "a group of things forming a unit 
or constituting a collection" (see 
http://www.merriam-webster.com/dictionary/suite). A good definition that 
works for the uses I'm familiar with in digital security would be "An 
algorithm suite is a coherent collection of cryptographic algorithms for 
performing operations such as signing, encryption, generating message 
digests, and so on." 
(http://fusesource.com/docs/framework/2.4/security/MsgProtect-SOAP-SpecifyAlgorithmSuite.html; 
disclaimer: I'm in no way a SOAP fan). The use here is not for a 
collection, but for a single truncated-length variant of a single hash 
algorithm. I seriously hope you can find a better name.

Section 6: "Note that a hash value that is truncated to 120 bits will 
result in the overall name being a 128-bit value which may be useful 
with certain use-cases.": This left me really wondering: Is there 
something magic to 128 bits in computer/internet security? What are the 
"certain use cases"? Or is this just an example to make sure the reader 
got the relationships, and it could have been as well "Note that a hash 
value that is truncated to 64 bits will result in the overall name being 
a 72-bit value which may be useful with certain use-cases." (or whatever 
other value that's registered in section 9)?

Section 7: Just for the highly unfortunate case that this doesn't 
disappear, it would be very helpful if the presentation of this section 
paralleled section 3.

Section 7: "contain the ID value as a UTF-8 encoded decimal number": I'm 
an internationalization expert with a strong affection for UTF-8, but 
even for me, this should be "contain the ID value as an ASCII encoded 
decimal number".

Section 9: The registration templates refer to sections. This is fine 
for readers of the draft, but not if the template is standalone. I 
suggest using a format such as that at 
http://tools.ietf.org/html/rfc6068#section-8.1, which in draft stage may 
look e.g. like 
http://tools.ietf.org/html/draft-duerst-eai-mailto-03#section-8.1.

Section 9.3: "Assignment of Well Known URI prefix ni" and later (and 
elsewhere in the draft) "URI suffix": Are we dealing with a prefix or a 
suffix here?

Section 9.4: "This registry has five fields, the binary suite ID,...":
Better to remove the word "binary", because the actual number is decimal.

Section 9.4: "The expert SHOULD seek IETF review before approving a 
request to mark an entry as "deprecated."  Such requests may simply take 
the form of a mail to the designated expert (an RFC is not required). 
IETF review can be achieved if the designated expert sends a mail to the 
IETF discussion list.  At least two weeks for comments MUST be allowed 
thereafter before the request is approved and actioned.": I'm at a loss 
to see why asking the IETF at large is a SHOULD, but if it's done, then 
the two weeks period is a MUST.

Section 9.4: The registry initialization in Fig. 8 refers to RFC4055 
many times. But RFC 4055 does in no way define SHA-256. It looks like 
the actual spec is http://tools.ietf.org/html/rfc4055#ref-SHA2 (National 
Institute of Standards and Technology (NIST), FIPS 180-2: Secure Hash 
Standard, 1 August 2002.) I think this should be cited, in particular 
because there is a "Specification Required" requirement, and this sure 
should mean that there is a Specification for the actual algorithm, and 
not just a specification that mentions some labels. So using RFC4055 as 
a reference could be taken as creating bad precedent.

Section 9.4: "The designated expert is responsible for ensuring that the 
document referenced for the hash algorithm is such that it would be 
acceptable were the "specification required" rule applied.": Why all 
this circumscription? Why not just say something like: "The designated 
expert is responsible for ensuring that the document referenced for the 
hash algorithm meets the "specification required" rule."

Nits:

Author's list: Last time I heard about this, there was a general limit 
of 5 authors per RFC. I'm not sure whether this still exists, and what'd 
be needed to get around it, but I just wanted to point out that this may 
be a potential problem or additional work (hoops to get through).

Intro: "Since, there is no standard" -> "Since there is no standard"

Intro: "for these various purposes" -> "for these purposes" or "for 
various purposes" (the indefinite 'various' is incompatible with the 
definite 'these').

"2.  Hashes are what Count" -> "2.  Hashes are what Counts" (the former 
may look logically correct, but 'what' requires a singular verb form.

Section 2: "the left-most or most significant in network byte order N 
bits from the binary representation of the hash value" -> "the left-most 
(or most significant in network byte order) N bits from the binary 
representation of the hash value" or "the left-most N bits, or the N 
most significant bits in network byte order, from the binary 
representation of the hash value" (the current text is virtually 
unparsable).

Figure 1: The 0x notation is never explained. A short clause or pharse 
is all that would be needed, but it would be better if this were spelled 
out.

Section 3, Query Parameter separator: "The query parameter separator 
acts a separator between" -> "The query parameter separator acts *as* a 
separator between".

Section 3, Query Parameters: "A tag=value list of optional query 
parameters as are used with HTTP URLs" ->  "A tag=value list of optional 
query parameters as used with HTTP URLs" (or "A tag=value list of 
optional query parameters as they are used with HTTP URLs").

Section 4: "the object named by the ni URI will be available at the 
corresponding HTTP(S) URL" -> "the object named by the ni URI will be 
available via the corresponding HTTP(S) URL" (via stresses the point 
that this should be done via (sic) redirection)

Section 4: "so there may still be reasons to use" -> "so there can still 
be reasons to use" (better to use can because non-normative; the 
document otherwise does a good job on this)

Section 10: "Note that fact that" -> "Note the fact that", or much 
better: "Note that".

Regards,     Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Jun 2012 12:11:42 +0100

Hi Martin,

First, thanks for the speedy and thorough review. Some
good points made, some with which I strongly disagree,
but thrashing stuff like that out is part of the point
of the reviews.

> [For replies, please trim the cc list, thanks!]

Not sure what trimming you mean. I've reduced it
to ietf-discuss and apps-discuss and authors.

> and should be easy to complete quickly.

Wheat? Chaff? Firm hand? Hmm. Are those useful phrases here?
I disagree about 'em in any case, and you're wrong as to how
we got here and IMO quite wrong in your main technical comment.
See below for that.

> format (section 6) that is more compact already.

I strongly disagree with merging ni & nih. Though that clearly
could be done, it would be an error.

There was no such comment on the uri-review list and the designated
expert was happy. That review was IMO the time for such comments
and second-guessing the designated expert at this stage seems
contrary to the registration requirements. So process-wise I
think your main comment is late.

But in any case, I also think you're wrong technically in this
case.

nih *is* intended for a corner case, where humans need to speak these
URIs and was added as a direct result of requirements from the core
WG and not as an afterthought. ni URIs are not intended for that
and so there really are IMO different requirements, (esp. e.g.
checkdigit) that are best met with different schemes.

Merging ni/nih would also add more complexity for no benefit,
which would be a bad idea.

Your analogy about httpm/h may appear reasonable, but it is always
unreasonable to draw conclusions from analogies. It is also unwise
to reason from counterfactuals, which we'd also be doing if we
accepted your argument. So I find that speculation utterly useless
to be honest.

In this case, we are dealing with different requirements so this
should stay as-is.

Finally, we have (some, early,) running code that matches the
current draft and that ought also count for something when compared
to a change that would be a gratuitous dis-improvement based it
seems upon dubious argument that is also offered at the wrong
point in the process. (I'd say that gets over the level of my
disagreement here with a firm hand:-)

> After all, as far as I understand, the concept of a public key is a

Yes. SPKI is good for this and is what's used elsewhere, e.g. in
dane and websec. Its the right choice and will be so long as folks
still need to map public key formats to X.509 which I expect will
be the case for many years to come. (Not that we get new public
key formats very often in any case.)

> expected to define this.": Do you really expect that to happen? 

I do, yes, assuming that ni URIs get adopted. If they don't, then
its not a problem:-)

> Wouldn't
> media types to identify different kinds of data? 

To be honest, I think that's another day's work. I don't know that
there's a generic solution that'd work for enough protocols. If there
were, then that could, and I think, should, be done in another RFC.

> This would also work

See above.

> you. Deducing from context is a bad idea.

I agree that deducing the input from context alone could be
difficult, though you would know when you got the right answer.
I think the way to handle this is for other specifications that
use ni URIs to specify the inputs.

> spec here deferred to the URI spec rather than trying to come up with

Can you suggest text to include? I'm always uncertain about this
kind of thing and would be very happy to take your suggestion.

> decision (and the text should be changed to avoid such an impression),

Huh? I don't get what change you'd like.

> a chance to remember that I had to create a new issue in the tracker for

Again, I'm not clear what change is suggested.

> * means "zero or more", thus reg-name can be empty. QED.

Good catch. Will craft a fix that disallows "ni:/sha-s56;..."
and forces "ni:///sha-256;..." when the authority is empty.

> .well-known is used when there's no support for ni, not in order to

We can re-word, but personally I think its clear now. A suggestion
would be welcome.

> for use in other places where it may be helpful, such as HTTP URI path

Can do that. Good suggestion.

>             ni-hier-part   = "//" authority "/" alg-val

Ok.

> have a status, what does that mean". 

Can do.

> Also, I strongly suggest to add an

Huh? Wouldn't that confuse things more? IANA handles Reserved
values all the time.

> changes/additions in ORCHID?

Dunno actually:-) Ari might. But we can change it to just say "reserved
for compatibility with 4843"

> the main text of the spec.

First, I disagree that people will really be confused. I think this
is both a nit and a gratuitous one. However, I've no problem with
making that (tiny, inconsequential and by no means major:-) change to
the abstract.

> terms are used throughout the spec, but are imprecise and confusing.

Imprecise: sure. Confusing: really? Were you really confused?

> more precise "more easily read out aloud by humans" or something

Happy to take a look. But I suspect we'll still disagree on
whether or not there's real confusion here.

> "specifying an URI scheme and a way to map these URIs to http".

Sure. Happy to make this *minor* change:-)

> paragraphs in section 2 look like an afterthought, and it's not clear to

I really don't get what's not clear there and I suspect I don't like
the suggested re-structuring but I'll take a look. Be good if you can
make a suggestion for text to add to the current structure that would
have avoided your confusion.

> The caption on Figure 7 is also way too unspecific.

I'll take a look. I entirely disagree that these are *major*
editorial changes.

> algorithms and their truncations.

I'll take a look.

> (for security purposes) for people not utterly familiar with the subject.

Disagree. If I added that I could reasonably be asked to introduce
URIs for the security folks. Serious and pointless ratholes would ensue.

> way to do this would be to say "consists of the following nine components".

Those look reasonable. Will see if the changes work out.

> the digest algorithm and value are the same.".

Sure.

> mechanism at all"? Or "nothing besides %-encoding"? Or something else?

I wish I knew:-) What do you think is right here? (Honestly,
input on this would be appreciated.)

> http://tools.ietf.org/html/rfc3986#appendix-A for an example).

Ack.

> say which productions are used from another spec.

We got contrary advice from elsewhere (can't recall where right now;-).
I'll let Barry (as sponsoring AD) just tell us his preference and go
with that if that's ok.

>    support for ni URIs are not available.

Sure.

> used independently, even "binary format name" isn't enough.

I don't get the problem with that.

> algorithm. I seriously hope you can find a better name.

That's a don't-care for me. I think suite is fine, but could
take other terms (so long as its not "algorithm"). Suite could
be justified since we have alg+truncation here, but like I
said I'd be fine to change, if a good suggestion is made.

> other value that's registered in section 9)?

Bit of both. I believe the core WG are keen to end up with a 128 bit
binary value as their preferred option.

> disappear, it would be very helpful if the presentation of this section

Disagree. Different requirements, different URIs, different
presentation. I don't think there's a real problem here.

> even for me, this should be "contain the ID value as an ASCII encoded

Fine.

> http://tools.ietf.org/html/draft-duerst-eai-mailto-03#section-8.1.

Will take a peek. Not sure I agree. (Nor disagree:-)

> elsewhere in the draft) "URI suffix": Are we dealing with a prefix or a

Will take a peek.

> Better to remove the word "binary", because the actual number is decimal.

Ack.

> the two weeks period is a MUST.

I don't get your comment. The two weeks is a MUST already.

> a reference could be taken as creating bad precedent.

I guess so. Good catch.

> hash algorithm meets the "specification required" rule."

Honestly? I can't recall:-) Will change unless I do remember.

> Section 10: "Note that fact that" -> "Note the fact that", or much

Those look ok or are nits in any case.

Thanks again for the thorough review even though we disagree as
to the main point.

Cheers,
Stephen.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 11 Jun 2012 20:04:21 +0900

Hello Stephen,

As Barry has suggested, I'm removing [email-masked] to reduced 
cross-posting. I'm going to split my response into several installments, 
hopefully separating the less contentious issues from the more 
contentious ones, and starting with the former ones.

Also, I want to apologize for the delays here, related to "day job" duties.

> URIs for the security folks. Serious and pointless ratholes would ensue.

Okay.

> Those look reasonable. Will see if the changes work out.

The change that I have seen in your pre-draft for the above three items 
look good.

>> the digest algorithm and value are the same.".

Okay.

> input on this would be appreciated.)

(In your internal draft, you removed the paragraph just before this one, 
and now the "Consequently" doesn't make any sense anymore.)

One possibility here is to remove anything about encoding, and have 
people check in RFC 3986, but I guess you wanted to help the reader 
here, so I'd propose something along the following lines (replacing the 
"Consequently" paragraph, and also in some sense the paragraph before 
that you already removed):

<<<<
Escaping of characters follows the rules in RFC 3986. This means that 
%-encoding is used to distinguish between reserved and unreserved 
functions of the same character in the same URI component. As an 
example, an ampersand ('&') is used in the query part to separate 
attribute-value pairs; an ampersand in a value therefore has to be 
escaped as '%26'. Note that the set of reserved characters differs for 
each component, as an example, a slash ('/') does not have any reserved 
function in a query part and therefore does not have to be escaped. 
However, it can still appear escaped as '%2f' or '%2F', and 
implementations have to be able to understand such escaped forms.
Also note that any characters outside those allowed in the respective 
URI component have to be escaped.
<<<<

>> http://tools.ietf.org/html/rfc3986#appendix-A for an example).

Great.

> I'll let Barry (as sponsoring AD) just tell us his preference and go

If you want to do it in a different way, you should at least be 
consistent. That would mean to also copy "authority" and "pct-encoded". 
The later is easy, but the former would really be too much. That's why 
I'd kick out "unreserved", too.

>>     support for ni URIs are not available.

Great. But in your internal draft, the period at the end of the sentence 
is now missing. (unless there's a bug in the diff)

> I don't get the problem with that.

You had "binary presentation", and changed that to "binary format" as 
per my suggestion. This is a very similar suggestion to align 
terminology. In the later half of the above comment, I was just trying 
to speculate about reasons for the difference, an the only reason I came 
up with was that it would be good to have a longer term that could be 
used independently outside the document.

> said I'd be fine to change, if a good suggestion is made.

What about "Truncated Hash ID" or "Hash Truncation ID" or some such? I'm 
open to other ideas, too.

> binary value as their preferred option.

Is there a way to word this that doesn't leave the reader wondering how 
she is supposed to understand this?

> presentation. I don't think there's a real problem here.

I'll address the "Different requirement" in a separate thread. In 
general, I'd expect that if a draft defines 2 of the same thing (e.g. 
two mime types,...), that it streamlines the presentation as far as 
possible. That this hadn't been done was part of the reason for my 
impression that this draft got patched together. But I think we should 
put of streamlining, because I hope that section 7 will disappear anyway 
:-).

> Will take a peek. Not sure I agree. (Nor disagree:-)

Okay, let me know when you have made up your mind.

>> elsewhere in the draft) "URI suffix": Are we dealing with a prefix or a

For your information, the registry is just named "Well-Known URIs" 
(http://www.iana.org/assignments/well-known-uris/well-known-uris.xml). 
Other drafts 
(http://tools.ietf.org/html/draft-daboo-srv-caldav-10#section-9.1, 
http://tools.ietf.org/html/draft-daboo-srv-caldav-10#section-9.2, 
http://tools.ietf.org/html/draft-ietf-core-link-format-14#section-7.1, 
http://tools.ietf.org/html/rfc6415#section-6.1, 
http://tools.ietf.org/html/rfc6415#section-6.2) have neither "prefix" 
nor "suffix" in the section title. I suggest to follow these, it will be 
less confusing.

> I don't get your comment. The two weeks is a MUST already.

This combination of SHOULD and MUST just doesn't feel right to me. Let 
me try with a different subject area which may make it easier to get my 
point.

What would you think if a document said something: "The expert SHOULD 
donate money to the IETF. If the expert donates money, s/he MUST donate 
at least $200."

As this example hopefully shows, MUSTs conditioned by SHOULDs don't 
really make sense. Or is this really just me ?-)

And let me give another try. Let's assume the expert wants to make a 
decision after one week, but still inform the IETF discussion list. She 
can just send a mail to that list saying "This is not a formal review 
according to Section 9.4 of RFC YYYY, but I'm planning to deprecate this 
entry in a week unless I hear good reasons to do otherwise." Logically 
speaking, that would be following the RFC, and shows that the MUST 
doesn't make sense, because it can't force anything.

>> a reference could be taken as creating bad precedent.

Great.

> Honestly? I can't recall:-) Will change unless I do remember.

Okay.

>> representation of the hash value" (the current text is virtually

You seem to disagree with this, but every time I try to read the above 
sentence, I have to take two or three attempts. And given my long-time 
training in German and Japanese, I have to admit that I'm quite used to 
long and convoluted sentences :-).

> Those look ok or are nits in any case.

Other than indicated above, I'm fine with the changes for these 
issues/nits that you have made (or not made) in your internal copy.

Regards,    Martin.

(more replies tomorrow)

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Jun 2012 13:39:04 +0100

Hi Martin,

> Also, I want to apologize for the delays here, related to "day job" duties.

No probs.

> URI component have to be escaped.

That looks good to me, ta. I've put it in.

> I'd kick out "unreserved", too.

Ok, I've now done a version that tries to copy as much
as possible unmodified from 3986. Let me know if its
right this time:-)

> is now missing. (unless there's a bug in the diff)

Now full stopped:-)

> open to other ideas, too.

Well, the suite IDs don't have to related to a truncated
hash, but can also be full length. Sticking with suite ID
for now.

> she is supposed to understand this?

Tweaked. Though I still don't think its at all unclear.

> put of streamlining, because I hope that section 7 will disappear anyway

Still disagree:-)

> Okay, let me know when you have made up your mind.

Turns out I disagree.

> nor "suffix" in the section title. I suggest to follow these, it will be

Ok, I copied from the core link format.

> doesn't make sense, because it can't force anything.

I've changed the SHOULD seek IETF review to a MUST. I guess that
makes sense.

> long and convoluted sentences :-).

Tweaked.

> issues/nits that you have made (or not made) in your internal copy.

Grand. I've updated the working copy at [1] with those changes.

Thanks,
S.

[1] http://down.dsg.cs.tcd.ie/misc/draft-farrell-decade-ni.txt

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 12 Jun 2012 18:13:30 +0900

Hello Stephen,

This mail responds to your points on the main technical issue that I 
have identified.

>> [For replies, please trim the cc list, thanks!]

Done, removed [email-masked] for the moment.

> I strongly disagree with merging ni&  nih. Though that clearly

First, if IETF Last Call is too late to make serious technical comments 
on drafts, then I think we have to rename it to IETF Too-Late Call.

Second, designated experts are there to check for minimum requirements 
for a registration, and to give advice as they see fit (and have time). 
I'm myself a designated expert on "Character Sets", and I have 
definitely in the past approved, and would again in the future approve, 
registrations for stuff on which I would complain strongly if the 
question was "is this a good technical solution".

Graham Klyne, the designated expert for URI scheme registrations, has 
confirmed offline that he does not see his role as "expert reviewer" as 
judging the technical merit of a URI scheme proposal.

> But in any case, I also think you're wrong technically in this

Let's see. I hope we agree that we should come to a conclusion on this 
issue on technical merits, rather than on process details.

> checkdigit) that are best met with different schemes.

I agree that the value of a checkdigit is very limited for communication 
among machines (and for communication among humans with the help of 
machines, such as in the case of email).

On the other hand, I can't understand why (even assuming we needed a 
separate scheme) there is no authority and no query part on nih.

For the authority, I'd assume that it would be as useful when the URI is 
transmitted e.g. over the phone as when it is transmitted e.g. over email.

For the query part, there are already various ideas and proposals 
floating around, and at least some of them would be of interest for when 
the URI is transmitted e.g. over the phone. Also, even if we currently 
didn't have any actual proposals for query parameters, I think it would 
be a very bad idea to exclude them a priori for transmission e.g. over 
the phone.

> which would be a bad idea.

Can you please explain what kind of complexity would have to be added? 
In terms of specification, merging the two schemes doesn't seem to be 
difficult or complex at all. Also, in terms of implementation, the only 
additions to the ni: scheme that become necessary are the check digit 
and the expression of the "suite id" as a decimal. It's very difficult 
for me to imagine that this would add significant complexity to an 
implementation; if code for nih: exists, that can mostly just be moved over.

> accepted your argument. So I find that speculation utterly useless

It is definitely unreasonable to draw conclusions from analogies *only*. 
But if you think that the httpm/h analogy is wrong, and that ni/nih is 
different, could you please explain *what* is different?

> In this case, we are dealing with different requirements so this

If "different requirements" is your main (or only) real argument, could 
you at least explain exactly how they are different? Just that one 
requirement came from the core WG and others from other WGs or other 
parties doesn't help me to understand how the actual requirements 
differ. (Please note that even if the requirements differ, that doesn't 
mean that we need different technology to address them.)

Why do you say that ni: URIs are not intended for humans to speak? What 
am I supposed to do if I got an ni: URI in a mail message and call you 
on the phone to tell you about that? If I want to send somebody the 
information in an ni: URI by mail, should I use only the ni: version or 
only the nih: version, or both, if I can't exclude that the recipient 
may want to relay this information via voice?

> current draft and that ought also count for something

How much? The boiler plate on every ID is pretty clear that they are not 
set in stone. Also, the changes needed to merge the two schemes are not 
rocket science, quite to the contrary. (I herewith volunteer to fix the 
Ruby version, just to show)

> when compared
> to a change that would be a gratuitous dis-improvement

In what sense would merging the two schemes be a dis-improvement? Can 
you please explain?

> based it
> seems upon dubious argument

If you think that my arguments are dubious, please explain exactly why.

> that is also offered at the wrong
> point in the process.

See above. If there's something wrong with IETF Last Call, or with the 
fact that the Apps Area Directorate does reviews (which I don't think), 
then that should be addressed separately. For this discussion, I hope we 
can concentrate on technical issues.

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Jun 2012 10:59:04 +0100

Hi Martin,

>>> decimal presentation of algorithm:  disallowed         possible

I'll note in passing that the two schemes differ in all those
respects. You may disagree with our design, but basically you're
showing that the two differ in pretty much all possible ways
other than that both include a hash value.

> judging the technical merit of a URI scheme proposal.

While that's fair enough. Its also fair to note that there was
discussion of the this document on the uri-review list but this
aspect was not raised at all. That list is called "uri-review"
and from its archives it does seem to frequently do more than
just check the paperwork (including quite a few mails from you:-).

>> But in any case, I also think you're wrong technically in this>> case.
> 

Sure.

>> nih *is* intended for a corner case, 

Let me emphasise the above. nih is not intended to be used
broadly, nor often. If you want a hash-based URI scheme for
users to speak that is for broad frequent use then I think
you are free to try design one. But nih is not that and is
not intended to be that. (And I'm not sure such a beast
could really be done well.)

>> where humans need to speak these

s/very limited/useless/

> separate scheme) there is no authority and no query part on nih.

The main intent of nih is to allow entry of something that
confirms something else (e.g. a public key) that is already
present. There is no need for an authority for that, for
the use-cases we have. We could speculate about other potential
use-cases but we'd rather not speculate like that when there's
no need to.

> transmitted e.g. over the phone as when it is transmitted e.g. over email.

We don't have a use for that that I know about. I agree
it could be done, but then I think it'd also impact on
usability, which will be pretty crap no matter what's
done. But making usability worse also seems wrong. Not
having an authority also seems to work fine for PGP keys
and the lack of an authority does get rid of some threats,
if the nih URI is used for something security-sensitive.

> floating around, 

Where? If you mean draft-hallambaker-decade-params then
we (the authors of that) don't think those are useful for
nih names.

> and at least some of them would be of interest for when

I disagree that there is any "very bad idea" here.

> Can you please explain what kind of complexity would have to be added?

I think its obvious actually. In your table above you highlighted
5 ways in which ni and nih differ. Merging all those yields loads
of combinations, which makes for complexity.

> implementation; if code for nih: exists, that can mostly just be moved

Feel free to look at our code. (With the caveat that I'm a crap
programmer so close your eyes a bit when you look at the 'C' code:-)

> It is definitely unreasonable to draw conclusions from analogies *only*.

I only saw the analogy. What in your httpm/h argument is not
couterfactual analogy?

> different, could you please explain *what* is different?

We have real use cases for ni and nih and we think they differ.
I'd be repeating myself to say why again.

> If "different requirements" is your main (or only) real argument, 

That would be a valid argument.

> could
> you at least explain exactly how they are different? 

I did that above. Asking for an "exact" explanation seems
like asking the same thing again.

> Just that one

Perhaps not. But that was the design choice we made and its
a valid one.

> Why do you say that ni: URIs are not intended for humans to speak? 

So phone me up and say this:

  ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q

> What
> on the phone to tell you about that? 

Not my problem actually, but I guess most people might
say "remember that mail you sent me with all that gobbledygook
nonsense - what the hell was that about?" :-)

>  If I want to send somebody the

You can try either and let me know what works. This seems like
a very artificial use-case for ni.

> How much? 

Feel free to go look and see. [1] I've not counted lines of
code, but we have c, python, ruby and clojure library
implementations and some apps and other bits and pieces.

   [1] http://sourceforge.net/projects/netinf/

> The boiler plate on every ID is pretty clear that they are not

I didn't say our code is set in stone. I said that running code
counts.

I didn't say a merge would require rocket science. I said it'd be
a bad idea and would produce a worse result.

> In what sense would merging the two schemes be a dis-improvement? Can

I believe I did that above.

> If you think that my arguments are dubious, please explain exactly why.

I believe I did that above. (To be clear: not all your argument is
dubious but the httph/m part is IMO.)

> can concentrate on technical issues.

Right. But let's not ignore the fact that the uri-review
list had sight of this at the end of April.

Bottom line - we have use-cases and a valid design and running
code that as far as we know works and I see no reason to make
the change you'd like, which would make thing worse IMO.

Cheers,
S.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 12 Jun 2012 22:04:54 +0900

Hello Stephen,

> just check the paperwork (including quite a few mails from you:-).

Oh well. I'm not sure how familiar you are with the IETF :-), but it's 
basically all a volunteer organization. So even more than in an 
organization where people are getting paid, some things happen to get a 
lot of attention and other things happen to get less attention than 
maybe they would deserve. And most people have their day jobs, and 
occasionally miss a mail or two, or even a few more. And many people are 
on many lists and just skim them until something catches their eye, and 
ignore many threads. If you don't do anything like this and survive, I'd 
like to know how :-).

So the uri-review list, like any other IETF (or other) list, can get 
excited about stuff, sometimes for good reasons, or can just ignore some 
aspects of some proposal. It's unfortunate, but it's something we have 
to live with. You can't ask everybody on that list to take the same 
amount of time to look at all the proposals that e.g. a Security 
Directorate or Apps Area Directorate reviewer is using.

>> issue on technical merits, rather than on process details.

Good.

> not intended to be that.

Then, at the barest minimum, don't sell it as that. The only thing the 
draft essentially says is "use this if you want to read/speak it". Now 
you are saying "don't use that for users to speak, unless in specific 
corner cases", but you still haven't told me or the readers of the draft 
what these corner cases are, and why the SHOULD/MUST not use it 
otherwise even if they might think it makes sense.

The second, more general advice is of course to not design URIs for 
corner cases, because URIs work best if they are used widely. (There may 
be a very tiny chance that your case is different, but even after 
reading all your mail, I haven't understood that.)

> (And I'm not sure such a beast

Speaking 256 or so bits of random data aloud is in no way going to be 
terribly easy :-).

> present.

At least a little bit of information about the "use case", but this just 
leads to more questions:

Do you need an URI for that? (Isn't that what people are supposed to do 
with fingerprints these days?)

How/where would a user input that URI e.g. in a browser?

Would copy/paste from an email or a Web page be fine?

Would entry be needed, or could it just be checked? (I understand that 
forcing a user to enter the data is way safer than believing her that a 
check was made, but then it's also way more tedious, and many users will 
just switch to different software.)

Can ni: URIs also be used for the same purpose? If not, why not (they 
essentially contain the same information)?

What about other URIs, starting e.g. with http:?

I won't claim that this list of questions is exhaustive, but I hope it's 
a good start.

> There is no need for an authority for that, for

There was a lot of stuff that we take for granted today that Tim 
Berners-Lee didn't speculate when he designed the first URI schemes. But 
if he had designed these schemes with only corner cases in mind, he 
wouldn't have invented the Web :-). (sorry about an analogy again)

> We don't have a use for that that I know about.

Do you mean the "over the phone" part or the authority part? (assuming 
the later below)

> I agree
> done.

Reading "example.com" or some equivalent domain name in addition to a 
long hex string shouldn't really make matters much worse.

> But making usability worse also seems wrong.

My understanding is that there are some cases where things will be found 
with authority, but not without. If that's right, then I'm sure users 
will prefer to find what they are looking for, after aurally 
transmitting 256 or thereabout bits, even at the cost of an additional 
domain name (and a few slashes), which are the easiest parts to get 
across the line quickly and correctly.

> Not

That the lack of authority works in some cases is perfectly okay. But 
it's not an argument for not allowing authority for cases (even those 
that maybe you're not seeing yet) where it is or will be useful.

> if the nih URI is used for something security-sensitive.

Which would mean that ni: has these threats, yes? Where are they 
described? I don't remember seeing them in the security section.

> Where? If you mean draft-hallambaker-decade-params

Correct.

> then

Why not? And what if others think they would be useful?

> of combinations, which makes for complexity.

Well, if your implementation is a big switch with 32 cases, one for each 
combination, with no code sharing, then indeed you get complexity. But I 
hope we agree that that's very bad design, and totally unnecessary. It's 
very straightforward to go through the components one-by-one and deal 
with them (hint: I'd start with the check digit).

On the other hand, the complexity you get from query parameters is 
potentially huge, because, contrary to the basic syntax, we don't know 
for sure what combinations of parameters people will dream up, and how 
these will interact.

> I only saw the analogy. What in your httpm/h argument is not

Do you claim that it's not true that URIs are often transferred 
electronically, often transferred on paper, and often spoken, and that 
these sets for which these activities happen overlap? If you think that 
has to be different for ni:/nih:, you have to convince me, not the other 
way round.

> I'd be repeating myself to say why again.

You're still very vague on these "real use cases". Confirmation of PGP 
keys by speaking the URI aloud seems to be your main/only use case for 
nih:. But I'm only guessing, because you haven't really explained this yet.

> That would be a valid argument.

It would only be a valid argument if these are requirements that can't 
be consolidated.

> like asking the same thing again.

Here are the pieces of text from above that I can at least in some way 
link to actual requirements:
"nih is not intended to be used broadly, nor often."
"The main intent of nih is to allow entry of something that
confirms something else (e.g. a public key) that is already
present."

Is that all there is? Or did I miss something? Maybe it would help this 
discussion if you wrote a few paragraphs of free-standing text 
explaining the use cases (and restrictions, and reasons for these) for 
both schemes. It may turn out to be a valid addition to the document at 
the very minimum. (I'm not asking for an independent "use cases and 
requirements" draft :-)

> Perhaps not. But that was the design choice we made and its

Given the more than 20 years of experience we have of how URIs are 
handled on the Web and around it, I have very good reasons to strongly 
doubt that this is a good design choice.

>    ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q

So apart from the upper/lower problem, would the equivalent nih: URI be 
any better?

> nonsense - what the hell was that about?" :-)

I think "tell you about it" should have been "speak it out to you".

> a very artificial use-case for ni.

Why artificial? Long URIs get spoken over the phone once in a while. And 
I really don't understand why this is "very artificial" for ni:, but 
"indispensable" for nih:.

> I didn't say a merge would require rocket science.

It somehow sounded like this.

> I said it'd be

Can you substantiate that? The discussion on use cases is still open, 
and the argument with all the 32 combinations also didn't fly.

> I believe I did that above.

Very marginally, perhaps. More information would definitely help.

> dubious

Thanks for some encouragement :-).

> but the httph/m part is IMO.)

I'm sorry that I started out with that analogy, but I thought it would 
be easy to understand. You seem to be caught in the specific use/corner 
cases, but I'm trying to look at the long term big picture.

> list had sight of this at the end of April.

[If you keep insisting, why don't you check your MUA and look at all the 
messages I sent on the draft. You may be surprised, but I seriously hope 
you will stop bringing up "uri-review" again.]

> the change you'd like, which would make thing worse IMO.

It may look like some more work in the short time, but it will make 
things more general and create more potential for the future.

Regards,    Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Jun 2012 15:09:24 +0100

Martin,

I honestly don't think this exchange is going
anywhere new so I've not provided blow-by-blow
answers below.

We (the authors) think ni and nih are better
kept separate because the use-cases and
requirements differ. And that's what the
limited amount of running code does.

I think I've explained that, and I have no
intention whatsoever of getting into the "write
up the use-cases and requirements" game that
too-often happens in the IETF when its neither
needed nor productive. (Regardless of whether
the game is played with I-Ds or email.)
Sometimes that is useful, but not here IMO.

You disagree, which is fine. You think ni and nih
should be merged because they don't differ
sufficiently, (I think), and (I guess) because
you think that new URI schemes are more expensive
than what you see as the differences between
these two proposed schemes warrant.

I suggest we see if anyone else chimes in on
this aspect (so far nobody has, despite a quite
active IETF LC:-) and if not leave it to the
sponsoring AD to figure out what, if anything,
needs doing at the end of IETF LC.

Cheers,
S.

PS: Many thanks for all the other good comments,
though we disagree on this one, you've helped
make the draft better for sure.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Jun 2012 08:19:40 -0600

[change of subject]

> On 2012/06/05 20:11, Stephen Farrell wrote:

<snip/>

> judging the technical merit of a URI scheme proposal.

By my reading, the "happiana" discussions [1] over the 12+ months have
led most participants to the conclusion that registration does not imply
standardization, and that it's not the role of the designated expert to
act as a gatekeeper with respect to the technical merits of the
technologies that trigger registration requests. It might be good to
have a wider discussion about the purpose of registries and the role of
designated experts, but IMHO it's not correct to conclude that a
technology is acceptable just because the designated expert didn't
object to the registrations related to that technology.

Peter

[1] https://www.ietf.org/mailman/listinfo/happiana

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jun 2012 07:56:01 -0700

On 6/12/2012 7:19 AM, Peter Saint-Andre wrote:
> it's not the role of the designated expert to

It's almost inevitable that many designated experts will, in fact, act 
as gatekeepers.  For example the distinction between "won't do damage" 
vs. "looks like excellent engineering" is more subtle in practice than 
one might think.  Especially absent very precise specification of review 
criteria and absent actual training of the reviewers.

While, yes, protocol specs that define the registry and review of its 
entries are supposed to provide the necessary details that do the 
distinction, I believe such texts do not get deep review for 
interpretive robustness.  That is, I doubt they are bullet-proofed 
against the vagaries of differerent readers who might be doing the 
reviews or writing text for them.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Jun 2012 17:07:54 +0200

> question was "is this a good technical solution".

There's no one correct statement about what designated experts do, or are
supposed to do.  Some specs that create designated experts give more or
fewer instructions to the expert than others do.  Some give none at all.
 The desognated expert should be doing what the specification that defined
the registry said the expert should do, to the best of the expert's
interpretation.  That might involve more gatekeeping in some cases, and
less in others, and there's always an appeal path available.

It's my opinion that more specifications that create Expert Review or
Specification Required registries should be specifying what they expect
from the designated experts.

Barry

---

From: SM <[email-masked]>
Date: Tue, 12 Jun 2012 09:31:16 -0700

Hi Peter,
>object to the registrations related to that technology.

I'll +1 the above.

In a recent review the path followed by the draft is Standards Action 
whereas the assignment policy is Expert Review.  Explaining to the 
authors that they should not use the assigned value isn't a 
worthwhile effort given that they have already been through the gate 
to get the value.  The Designated Expert did his job; that is to see 
that the requirements were met instead of acting as gatekeeper.  If 
you reject assignment requests people will find it simpler not to 
register the values.  If you accept the request people might consider 
that the specification is fine.

The reasons provided for managing a namespace are:

   - prevent the hoarding of or unnecessary wasting of values

   - provide a sanity check that the request actually makes sense

   - interoperability issues

The above is at odds with standardization.  The last reason does not 
apply for Expert review.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2012 19:13:48 +0100

On 2012-06-12 17:31, SM wrote:
> authors that they should not use the assigned value isn't a worthwhile
> effort given that they have already been through the gate to get the
> value.  The Designated Expert did his job; that is to see that the
> requirements were met instead of acting as gatekeeper.  If you reject
> assignment requests people will find it simpler not to register the
> values.  If you accept the request people might consider that the
> specification is fine.
> 

I don't understand that statement. RFC 5226 says, in Section 2 about
"Why Management of a Namespace May Be Necessary":

"  A third, and perhaps most important, consideration concerns potential
   impact on the interoperability of unreviewed extensions."

One of the specific considerations for designated experts in section 3.3
is

"      - the extension would cause problems with existing deployed
        systems."

It seems clear that interoperability is a primary concern for any
expert review.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Jun 2012 14:38:32 -0400

--On Tuesday, June 12, 2012 19:13 +0100 Brian E Carpenter
<[email-masked]> wrote:

>> The above is at odds with standardization.  The last reason
>> does not apply for Expert review.
> 
> I don't understand that statement. RFC 5226 says, in Section 2
> about "Why Management of a Namespace May Be Necessary":
> 
> "  A third, and perhaps most important, consideration concerns
> potential    impact on the interoperability of unreviewed
> extensions."
> 
> One of the specific considerations for designated experts in
> section 3.3 is
> 
> "      - the extension would cause problems with existing
> deployed         systems."
> 
> It seems clear that interoperability is a primary concern for
> any expert review.

Brian, Subramanian,

I've with Barry on this.  The details of the expectations of an
expert reviewer, including the thresholds for approval, should
be specified in whatever document sets up the particular
registry.  One size does not fit all; "Expert Review" is a
designation of a mechanism and not a set of criteria.

We should, IMO, do two things in this area:

(1) When a document specifies "Expert Review" for a registry, it
should be required to spell out the criteria the Expert is
supposed to use, at least to the degree that isn't obvious.  If
it doesn't, that should be grounds for "DISCUSS until fixed".

(2) If it turns out that an Expert for a particular registry is
not behaving as people expect, part of the process for getting
that fixed (or even complaining about it), should be to see if
the registry-creating documents are clear about procedures and
criteria.  If they are not, an effort to update those criteria
would be a useful way to discuss the issues and not the
individual expert.   Of course, Experts who knowingly violate
clear criteria should be summarily fired -- but I think we can
trust that to the IESG and note that it has almost never been
necessary.

     john

---

From: SM <[email-masked]>
Date: Tue, 12 Jun 2012 12:48:48 -0700

>It seems clear that interoperability is a primary concern for any

This gets you into the level of review (see Barry's comment).

The easiest policy is FSFC.  The next step is Expert Review which is 
supposed to have clear guidelines.  If you want interoperability, 
there's Specification Required.  It seems from the above that the 
argument is about avoiding problems with deployed systems.

>designation of a mechanism and not a set of criteria.

Agreed.

>it doesn't, that should be grounds for "DISCUSS until fixed".

I like the idea of spelling up the criteria.

>trust that to the IESG and note that it has almost never been

The people who come to the registry may not know much about the 
process.  I wonder if they are aware that there is a path to complain 
if there are not satisfied.  Even then, they may find it easier to 
walk away.  I don't think that the individual expert is the 
issue.  The better path is to have clear documentation (what you 
mentioned above) about the criteria so that the registrant can tell 
what the expectations are.  I'll add publication of the median time 
to process a request as information for the registrant.

Regards,
-sm

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Jun 2012 09:29:11 +0900

> should be required to spell out the criteria the Expert is supposed to
> use, at least to the degree that isn't obvious.  If it doesn't, that
> should be grounds for "DISCUSS until fixed".

given our reknown abilities to predict and understand the future, this
is going to work out really well. </dripping sarcasm>

of course, any known non-obvious gotchas are worth passing along.  but
if they are non-obvious to the expert, then i suspect they will also
have been non-obvious to the doc author(s).

there may be a reason we have not automated this.

randy

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Jun 2012 20:43:11 -0400

--On Wednesday, June 13, 2012 09:29 +0900 Randy Bush
<[email-masked]> wrote:

>> (1) When a document specifies "Expert Review" for a registry,
>> it should be required to spell out the criteria the Expert is
>> supposed to use, at least to the degree that isn't obvious.
>> If it doesn't, that should be grounds for "DISCUSS until
>> fixed".
> 
> given our reknown abilities to predict and understand the
> future, this is going to work out really well. </dripping
> sarcasm>
> 
> of course, any known non-obvious gotchas are worth passing
> along.  but if they are non-obvious to the expert, then i
> suspect they will also have been non-obvious to the doc
> author(s).
> 

I agree with your basic point, but I wasn't suggesting
automation nor predicting the future.  I was suggesting that
giving the expert some guidance about what she is supposed to
look for (if that isn't obvious) and, e.g., whether the default
action on a marginal application is to accept or deny would be
of some help, at least to the expert's sanity.

Taking that comment as an example, I am _not_ suggesting that we
try to define the boundaries of "marginal application".  I also
trust the IESG to make reasonable appointments in at least the
vast majority of cases and assume that these will continue to be
"Expert Reviewers" rather than, e.g., "Robot Reviewers" or
"Moron Reviewers".

Contrary to some other comments, it is not at all clear to me
that having clear guidance will be of a lot of help to
applicants in predicting outcomes.  It would be nice if it
happened, but my main aspiration would be to reduce confusion on
the part of the expert about the expectations of the community.

Put differently, I don't much like oral traditions, especially
secret ones, in bodies like the IETF.  But I'm also in favor of
good sense as a primary guideline here.

    john

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 13 Jun 2012 03:01:42 +0200

* Peter Saint-Andre wrote:
>technologies that trigger registration requests.

My impression is the same (though I do not agree with "led").

>It might be good to have a wider discussion about the purpose of
>registries and the role of designated experts, but IMHO it's not correct
>to conclude that a technology is acceptable just because the designated
>expert didn't object to the registrations related to that technology.

I would say that decisions by designated experts have no implications
outside the confines of their role and their discretion. We could give
experts the power to decide over "is acceptable", but when we do not,
then they do not have that power, and nobody should argue otherwise.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 13 Jun 2012 03:15:54 +0200

>criteria and absent actual training of the reviewers.

It seems to me that if an expert reviewer thinks that something will do
notable harm, they should decline to make a decision and defer it to the
IETF at large; and any registration procedure that does not allow that
is broken. (Similarily, let's assume that something will do harm, but an
expert reviewer fails to see it, but others do: they should have the a-
bility to appeal expert reviewer decisions, so the matter can be brought
to the attention of more and possibly better qualified people; if that
is not an option, the process is broken; if, on the other hand, nobody
cares to use available procedures, including making a big fuss over it
in the regular press, or whatever, then it probably was not important e-
nough.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Jun 2012 14:53:07 +0900

> IETF at large

so they are not an expert, they are a rubber stamp?  bs.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jun 2012 09:04:57 +0100

John,

> designation of a mechanism and not a set of criteria.

I completely agree. My point was only that the baseline set by
RFC 5226 is clear that interoperability is a criterion. The
details vary case by case and should be written down.

I also agree with what I think Randy meant - the designated
expert shouldn't be afraid to say no (or yes) in dubious
cases; that's why we designate an expert...

    Brian
> .

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 13 Jun 2012 11:08:41 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Wednesday, June 13, 2012 11:05 AM
> To: John C Klensin
> Cc: SM; [email-masked]
> Subject: Re: registries and designated experts
> 
> John,
> 

[[DR]] +1. 

I think that it's a good thing to provide guidelines in the RFCs for Expert Reviews criteria, it's better than oral tradition, they set and document the expectations at the time the document is approved. However guidelines are just guidelines, otherwise the process could have been completely automated, and the expert is the one called to make the firm yes/no recommendation to IANA. If at some point in time the guidelines are in conflict with the reality, the RFC should be updated, sometimes the policy changed.

Maybe an IESG statement on this respect can help here. 

Dan

---

From: Thomas Narten <[email-masked]>
Date: Wed, 13 Jun 2012 08:48:28 -0400

> Maybe an IESG statement on this respect can help here.

Is the existing text in RFC 5226 not sufficient? It contains extensive
text about the purpose and role of designated experts, and was revised
substantially the last time around to try and find a good middle
ground between being overly prescriptive and giving experts a "blank
check" to do what they want.

Nothing in the discussion I've seen so far in this thread seems at
odds with or beyond what is already in RFC 5226 (but I may be biased).

Thomas

---

From: [email-masked]
Date: Wed, 13 Jun 2012 07:49:29 -0700 (PDT)

> so they are not an expert, they are a rubber stamp?  bs.

+1

More generally, the notion of appealing to the "IETF at large", whatever that
is supposed to consist of, isn't part of the written policy of any registry I'm
aware of. There's supposed to be an appeals process (usually to the IESG), and
that's the obvious process to invoke should an issue come up that a reviewer
feels uncomfortable resolving directly.

Additionally, given the widespread use of IANA registries by people and
organizations not connected to the IETF in any way - and this usage is
something we want to encourage - appealing registrations to the IETF at large
is a really bad idea.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 13 Jun 2012 17:50:30 -0400

--On Wednesday, June 13, 2012 08:48 -0400 Thomas Narten
<[email-masked]> wrote:

> Is the existing text in RFC 5226 not sufficient? It contains
> extensive text about the purpose and role of designated
> experts, and was revised substantially the last time around to
> try and find a good middle ground between being overly
> prescriptive and giving experts a "blank check" to do what
> they want.
> 
> Nothing in the discussion I've seen so far in this thread
> seems at odds with or beyond what is already in RFC 5226 (but
> I may be biased).

Thomas,

FWIW, I think 5226 is ok, but that the community, especially the
community who write "Designated Experts" need to pay a little
more attention to a few phrases there than has sometimes been
the case.  For example, 5226 says:

	"Ideally, the designated expert follows specific review
	criteria as documented with the protocol that creates or
	uses the namespace."

and 

	"Experts are expected to apply applicable documented
	review or vetting procedures, or in the absence of
	documented criteria, follow generally accepted norms,
	e.g., those in Section 3.3."

My impression is that people have perhaps too often skipped
specifying specific guidelines or criteria in their definitions,
leaving the experts to fall back on good sense and the last half
of Section 3.3.  That isn't necessarily bad but can easily lead
to misunderstandings if there is actually controversy about a
proposed registration.  So I'd recommend that  the community pay
a bit more attention during Last Call to whether enough (or too
much) guidance is specified than has often been the case in the
past where we argue protocol details and do a lot of nit-picking
but mostly ignore IANA Considerations sections.

That doesn't require changes to 5226.  But, if 5226 is every
revised, it might be well to check to see if the emphasis in
what it says about this issue is in line with what we want.

    john

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 14 Jun 2012 04:12:32 +0200

>so they are not an expert, they are a rubber stamp?  bs.

Expert reviewers should use their judgement, but that includes whether
their judgement is the right way to resolve some controversy or doubt.

I was thinking the above more in terms of something about an application
that had not been considered or forseen when the registry was created,
in which case an expert reviewer might want to say they think making
a decision is outside the confines of their role and expectations and
assumptions that have been made when the registry was set up and they
were appointed as reviewer, and reviewers should be expected to do that
as appropriate, in principle.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Jun 2012 10:47:45 -0700

oh boy...

On 6/15/2012 3:57 AM, Graham Klyne wrote:
> On 12/06/2012 15:56, Dave Crocker wrote:
>> It's almost inevitable that many designated experts will, in fact,
>> act as gatekeepers.
...
> The effect may sometimes be similar to being a gatekeeper but,
> speaking for myself, that's not how I see my role.

Herein lies the core problem with these types of discussions:  Most 
participants use themselves as the metric.

Designing human processes requires consideration of other folk, not 
ourselves.  Other folk display widely varying behaviors.  They have less 
information and education on the topic than current participants.  They 
have moods.  They have distractions. They have biases.

In other words, real-world, human processes are "noisier" than we tend 
to design for.

When looking for factors to consider, a posting with "here's how I 
behave" can be extremely helpful.  When looking for what can go wrong, 
it actually tends to undermine the exercise, IMO.

Note that this is not about diligence.  It is about typical human vagaries.

> My experience is that no amount of review completely bullet-proofs a
>  spec against misinterpretation. So we do the best we can.

The second sentence is such a natural choice, given the first.  What it 
misses is that "the best" often means excessive hassle.  That is, very 
poor cost/benefit tradeoff analysis.

Quality control processes can and do help.  Carried to excess, they make 
the activity more effort than it is worth.

In the face of being unable to ensure perfect bullet-proofing, we often 
think that we need to put in more effort.  In fact what is often 
appropriate is /less/ formal bullet-proofing and trusting market forces 
to do the rest, since they will anyhow.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Jun 2012 20:18:11 +0100

Hi Graham,

On 06/15/2012 11:48 AM, Graham Klyne wrote:
> Stephen,
> 
> (Personal hat on)
> 
> I've followed elements of this exchange.  I must confess that when I
> read through the draft previously, I didn't really pay attention to the
> nih: parts.

I guess part of my reaction to Martin's comments was based on
an assumption that such a comment (make your two registrations
into one) was something one could expect to have gotten from
the uri-review list. But anyway...

> I can see that there are distinct use-cases here, and I think you have
> reasonable grounds for not wanting to combine them.

Right.

> What I can't see is why the speakable form (nih:) needs to be a URI
> scheme - what are the envisaged contexts of use where the information
> provided by an nih: URI actually needs to be a URI, as opposed to just,
> say, a simple string?
> 
> In all the uses I can think of for ni:, I don't see a corresponding use
> for a speakable form.  

I agree that there's little overlap for sure.

> I think you said somewhere in this exchange, nih:
> is intended to be used to confirm some information that you already
> have.  As such, I'm not seeing how it can be said to identify a resource.

I'm checking with others since I'm not entirely familiar with
all that they want from nih, (so you might be right, or maybe
not;-)

As far as I do know now, the idea is that nih could be useful
when values are to be read over the phone. I agree the listener
wouldn't need the scheme, but I think the argument is that it'd
help the speaker (or speaker's UA) to highlight the right thing.
I'd agree if you argued that that's not the most compelling
reason, but maybe there's more.

In terms of identifying a resource, I don't get the
comment, since the information is similar to that in an ni,
so it does identify whatever it is matches that hash.

Cheers,
S.

> 
> #g
> -- 
> 
> On 12/06/2012 15:09, Stephen Farrell wrote:
>>
>> Martin,
>>
>>>>>>> anymore. But when it comes to URIs, one less is a lot better than
>>>>>>> one
>>>>>>> more.
>>>>>>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 17 Jun 2012 21:55:19 +0900

Hello Thomas, others,

> odds with or beyond what is already in RFC 5226 (but I may be biased).

I have quickly looked through RFC 5226, and found Section 5.3
(http://tools.ietf.org/html/rfc5226#section-5.3) which answers in part 
the specific issue that this thread started with, but not in the 
direction that we would need this time.

What that section says is that if the IETF/IESG thinks they need to 
register something in a registry, but the procedures for that registry 
are written too restrictive, then the procedures can be bypassed (but 
they should be fixed as soon as possible).

This time, the situation was somewhat reversed: The expert approved the 
registration, and this fact was then used as a claim that IETF Last Call 
comments on the item registered were no longer appropriate.

I'm with Ned in that I don't think that IETF consensus should be 
involved in any but the most important registrations and most blatant 
registration mistakes, because there are many registrations that don't 
need standardization.

But I really hope that we all agree that registrations can't preempt 
IETF Last Call comments or consensus. I didn't find anything about this 
aspect of registrations and expert reviews in RFC 5226, but maybe I 
didn't look hard enough?

Regards,    Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Jun 2012 14:33:02 +0100

Martin,

> comments on the item registered were no longer appropriate.

I'm sorry, but that's just not accurate. The specific comment (of
yours) was to the effect that two registrations should become
one. I believe its fair to say that that is something one
could have expected to be raised on the uri-review list, given
the comments typically sent to that list, and the comments we
got there on our I-D, and so I brought that up when you (who
often comment on that list), only raised this during IETF LC.

At no point did I claim that IETF LC comments were no longer
appropriate, and indeed I've been responding al all IETF LC
comments on their merits, including this one of yours. But,
yes, I do think that your specific issue (essentially, not doing
one of the registrations) would have been better raised
earlier on uri-review, and as the one asking for the registrations
it does feel like having to jump through the same bureaucratic
hoops a second time.

However, perhaps there is a generic issue in that its not clear
whether one is doing paperwork or getting substantive technical
review when one requests a registration, at least to the
uri-review list. I'm not sure how many other *-review lists
might have the same situation.

That could be clarified I guess. If that list is just to check
the paperwork, then I'd guess that pretty much all technical
comment ought be re-directed elsewhere. If that list is for
substantive technical review, then seeing frequent contributors
to that list first bringing up issues at IETF LC would seem
noteworthy. (I'm not saying such issues ought be ignored, but
they maybe ought be treated as we would the case of a WG
participant making comments on a topic only after WGLC.)

S

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 18 Jun 2012 20:43:30 +0900

Hello Stephen,

On 2012/06/17 22:33, Stephen Farrell wrote:
> one.

[Minor detail: It was about merging two schemes. Merging the 
registrations is a consequence of merging the schemes, but not the core 
issue.]

> I believe its fair to say that that is something one
> got there on our I-D,

I agree that, as you say below, it would have been better if the issue 
had been raised earlier. But that's the same all over the place; it 
would often have been better if an issue got raised earlier during WG 
discussion rather than later, during WG discussion rather than in WGLC, 
during WGLC rather than in IETF LC, during IETF LC rather than in IESG 
review, and so on. I also agree that nobody would have been surprised if 
such an issue had been brought up on the uri-review list.

But that's different from expecting a specific issue to be brought up in 
a specific place, and only there.

> and so I brought that up when you (who

[Minor detail: I don't consider myself a "frequent" contributor to that 
list. But of course frequency is relative.]

First: I mentioned the issue that having two different encodings (base64 
and base16) of the same data was a non-starter *way* earlier. If you 
didn't read that, or don't remember that anymore, it's not my fault.

Second: As explained earlier, my comments were part of an Apps 
Directorate review. When I'm doing an Apps Directorate review, I'm 
setting away time for that explicitly, and try to do a really thorough 
job, with a wide perspective. I can do that because I'm only doing one 
of these every few months. This is quite different from a registration 
mailing list where I'm not the Designated Expert, and can't devote that 
much time to each and every registration that comes by.

The Apps Directorate review is also intended to help the Apps ADs. I'd 
expect that they want to know everything that a reviewer thinks is 
relevant, rather than the reviewer suppressing stuff because he happens 
to be on a registration mailing list on that specific topic and didn't 
have time to look at the draft when it was passing by on that list.

> comments on their merits, including this one of yours.

You didn't explicitly claim that IETF LC comments were no longer 
appropriate. And you were indeed quite responsive to many of the issues 
brought up, including many other issues that one could reasonably expect 
to be brought up on the [email-masked] mailing list (scheme syntax 
issues, escaping/encoding issues,...), and where you didn't say that 
these should have been brought up earlier.

But for that one specific issue, you kept telling me things like 
"second-guessing the designated expert at this stage seems contrary to 
the registration requirements", "process-wise ... your main comment is 
late", "let's not ignore the fact that the uri-review list had sight of 
this at the end of April", and so on.

On my side, this definitely felt very much like "your comment is 
inappropriate at this time" rather than just "would have been great if 
we got this earlier".

> But,

There are a lot of hoops at the IETF. WG discussion, WG LC, registration 
reviews where applicable, IETF LC, IESG review,.... It would be good if 
we could do with less, but I guess they are all there for a reason.

> might have the same situation.

Quite a few, I guess. I see three main reasons for this:

1) The description of what the Designated Expert should check and what 
not is not clear enough. [For URI/IRI schemes, the IRI WG is working on 
an update to RFC 4395, and yours as well as everybody else's comments 
are highly appreciated.]

2) Many registries have been criticized for being too strict, leading to 
situations where labels are being used without being registered. As a 
result of that, the review has shifted from "is this really absolutely 
needed" in the direction of "make sure this isn't explicitly harmful". 
[This is in particular the case for quite a few registries in the Apps 
Area; it may be quite different in the Security Area, in particular for 
things such as cryptographic algorithms.]

3) The Designated Expert, and even more the other people on these 
mailing lists, are all volunteers, and most have a day job.

While 1) and 2) may eventually be addressed by updating the registry 
guidelines, 3) is difficult to fix.

> That could be clarified I guess.

As said above, the IRI WG is working on an update of RFC 4395, and 
everybody's comments, including yours, are highly appreciated

> If that list is just to check
> comment ought be re-directed elsewhere.

I'd describe the purpose of the list more as "make sure the basic 
paperwork is okay, make sure this is not overly harmful, and provide a 
place for technical input". There are many people on that list that can 
give technical advice, and quite a bit of it is usually appreciated, so 
I don't see why we should exclude it.

> If that list is for

I strongly disagree here. The purpose of registration is not the same as 
the purpose of IETF standardization. There are many registries that 
contain stuff that "just happened" outside the IETF and would never have 
a chance in the IETF, but nevertheless a label is in use and it is 
better to get it registered than to deny registration. This may be (just 
guessing) different for security stuff such as cryptographic algorithms. 
But it definitely applies to many Apps Area related registries (MIME 
media types, charsets, URI/IRI schemes, and so on).

Also, a mailing list associated with a registry is not the same as a WG 
mailing list. A WG is chartered with creating something new. The main 
motivation for WG participants is to shape that "something new", and 
most aspects of a proposal will be discussed explicitly on the WG list. 
Lurking or occasional participation should indeed not be specially rewarded.

On the other hand, registration mailing lists are essentially "pro bono" 
efforts, both for the Designated Expert(s) as well as for every other 
participant. It would be highly inappropriate to disadvantage these 
volunteer participants in the same way as WG lurkers.

Regards,    Martin.

---

From: Graham Klyne <[email-masked]>
Date: Fri, 15 Jun 2012 11:48:57 +0100

Stephen,

(Personal hat on)

I've followed elements of this exchange.  I must confess that when I read 
through the draft previously, I didn't really pay attention to the nih: parts.

What I can't see is why the speakable form (nih:) needs to be a URI scheme - 
what are the envisaged contexts of use where the information provided by an nih: 
URI actually needs to be a URI, as opposed to just, say, a simple string?

In all the uses I can think of for ni:, I don't see a corresponding use for a 
speakable form.  I think you said somewhere in this exchange, nih: is intended 
to be used to confirm some information that you already have.  As such, I'm not 
seeing how it can be said to identify a resource.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Fri, 15 Jun 2012 11:57:20 +0100

On 12/06/2012 15:56, Dave Crocker wrote:
> It's almost inevitable that many designated experts will, in fact, act as
> gatekeepers. For example the distinction between "won't do damage" vs. "looks
> like excellent engineering" is more subtle in practice than one might think.
> Especially absent very precise specification of review criteria and absent
> actual training of the reviewers.

The effect may sometimes be similar to being a gatekeeper but, speaking for 
myself, that's not how I see my role.  When responding to IANA review requests, 
I may often have and express technical opinions about a proposal, but I try to 
be clear that these are separate from my view of whether or not the registry 
requirements are satisfied.  And where I feel that registration requirements are 
not satisfied, I try to provide indicators as to what the submitter might do to 
create satisfaction.  So it doesn't *feel* like being a gatekeeper.

> While, yes, protocol specs that define the registry and review of its entries
> are supposed to provide the necessary details that do the distinction, I believe
> such texts do not get deep review for interpretive robustness. That is, I doubt
> they are bullet-proofed against the vagaries of differerent readers who might be
> doing the reviews or writing text for them.

My experience is that no amount of review completely bullet-proofs a spec 
against misinterpretation.  So we do the best we can.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Sat, 16 Jun 2012 01:07:08 +0100

> so it does identify whatever it is matches that hash.

I meant to say that I don't see how it is being *used* to identify a resource - 
as you point out, it clearly *can* so identify, as much as ni: can.

What I'm trying to get to is why one might need a URI, rather than just a 
string, in situations where nih: might be used.  One of the useful features of 
URIs is that they provide a uniform way of referencing things that may be 
accessed or "baptized" by a variety of different mechanisms or structures, 
decoupling the identification mechanism from the details of what is done with 
the thing identified.  The particular use of confirming information one already 
has doesn't seem to fit this model of separating use of some value from the form 
of identification and/or access mechanism.

#g
--