Comments on draft-farrell-decade-ni-06

[Bjoern Hoehrmann <[e-mail]>]

Hi,

  In http://tools.ietf.org/html/draft-farrell-decade-ni-06 the RFC 2119
boilerplate does not belong in an Introduction section, it should be in
a Terminology or Conformance or similarily named section.

For a URI scheme specification having no example of what the syntax is
prior to section 8 (or 4 if you spot it there) is a bad idea, there
should be one much earlier so you can get an idea what this is about
without a lot of reading.

The terms CoAP and DECADE require references in section 9.x since they
are not introduced or used anywhere else, if the terms are kept. I do
not think "General applicability with initial use cases provided by CoAP
and DECADE" is a useful description for the kind of application that may
make use of this scheme, even if there were references.

The Contact field should identify a Person, there should be a name at
least.

Section 7 references a Wikipedia article by bare address. That should be
a proper reference, called [Wikipedia] for instance, or it should at
least be on an indended paragraph of its own. It's very distracting when
flowing text is mixed with formal syntax, especially when using URLs in
a URL scheme specification (the preceding address was an example, not a
link.)

In section 4,

  Note that since the .well-known name-space is not intended for
  general information retrieval, if an application de-references a
  .well-known/ni URL via HTTP(S), then it SHOULD expect to receive a
  30x HTTP re-direction response and it MUST be able to handle this.
  Put another way, a server SHOULD return a 30x response when a .well-
  known/ni URL is de-referenced.

This is a confusing use of RFC 2119 keywords ("put another way" would
generally suggest the two formulations mean the same thing, but they
do not). I would say something like "servers SHOULD and clients MUST",
which would also remove the confusing "SHOULD expect".

It's not immediately clear whether the schemes define a default value
for the authority component. Some definition using the word "default"
would help, including saying there is "no default". See RFC 3986 section
3.2.2. for why this matters.

In section 3 the "MUST" in "decoders MUST recognize" is incorrect, that
re-states RFC 3986 requirements and should not be rendered as a new con-
formance requirement. Say that "RFC 3986 requires ..." or something like
that.

I think the requirement in RFC 4395 section 2.6 applies here, there are
text fields in 'ni' and 'nih' addresses, so there needs to be some dis-
cussion about I18N and IRI issues, or a statement that there are none,
or something along those lines. What if I want a non-ASCII host name in
them, for instance?

I may have missed it, but I did not see much error handling defined, say
how you might handle `ni:///sha-256;%F6...` or perhaps more importantly
`ni:///sha-256;f4Ox%20...` given that some Base64 implementations might
simply silently strip white space characters and perhaps ignore or mis-
treat non-base64 characters. The Security Considerations should mention
such parsing issues.

It's not clear to me that it is a good idea to use `http://h-authority/`
as example. It would seem better to use, say, `http://example.org/`.

regards,
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/