Subject: Comments on draft-farrell-decade-ni-06

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 08 Jun 2012 04:16:35 +0200

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:[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: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jun 2012 14:35:33 +0100

Hi Bjoern,

Thanks for the feedback!

>   In http://tools.ietf.org/html/draft-farrell-decade-ni-06 the RFC 2119

Just to note that -07 is the version for IETF LC. But your
comments apply as well to that, so that's fine.

If its useful, I've a working copy of this at [1] that has
the changes below as well as a bunch based on other
comments received so far.

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

> a Terminology or Conformance or similarily named section.

What we have is very common in RFCs.

> without a lot of reading.

Fair enough, added one to the intro.

> make use of this scheme, even if there were references.

Suggestions for text that'd work welcome. I agree that the CoAP and
DECADE mentions should probably go, so for now it just says "General
Applicability."

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

Sure. That'd be me I guess:-)

> a URL scheme specification (the preceding address was an example, not a

I've no idea what change to section 7 you mean. I'd welcome a better
reference for magnet if someone can offer one but we looked and didn't
find one.

> which would also remove the confusing "SHOULD expect".

While I think its ok, I guess "SHOULD expect" is a bit dodgy, so
I've tweaked it to say:

  "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 will often receive a 30x
   HTTP re-direction response.  A server responding to a request for
   a .well-known/ni URL SHOULD therefore return a 30x response and
   a client sending such a request MUST be able to handle that."

> 3.2.2. for why this matters.

Good catch. I've added a statement that there is no default.

> formance requirement. Say that "RFC 3986 requires ..." or something like

Ok.

> or something along those lines. What if I want a non-ASCII host name in

Hmm. So what are the reasonable options for that? I guess I'd prefer
to just copy from (or reference) something else that's deployed
and works, and not invent anything here.

I've put in a placeholder in my working copy.

> treat non-base64 characters. The Security Considerations should mention

Good point. I'd welcome suggestions for what to say there.

I've put in a placeholder in my working copy.

> as example. It would seem better to use, say, `http://example.org/`.

Not sure how to use that there, since h-authority isn't an example
authority but really a placeholder. I've left this as-is for now.

Thanks again for the good comments,
Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Jun 2012 14:24:47 +0100

Hi Björn,

> or something along those lines. What if I want a non-ASCII host name in

So what's reasonable here?

We're inheriting some definitions (authority, unreserved &
pct-encoded) from 3986 and I'd not like to break that, nor
would I like something that doesn't work with most libraries.

Any suggestions?

Thanks,
S.

---

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

Hello Stephen,

On 2012/06/09 22:24, Stephen Farrell wrote:
> We're inheriting some definitions (authority, unreserved&

I shouldn't have missed I18N and IRI issues in my apps review.

For IDNs in the authority part, you are essentially safe because RFC 
3986 says exactly how to handle this (%-encoding based on UTF-8; 
alternatively punycode (A-Labels), for which library suppor may be 
better than for the former). You don't have to say anything about this, 
but you can say something if you think it's useful for implementers and 
if it's limited to a non-normative pointer (to the last paragraph of 
http://tools.ietf.org/html/rfc3986#section-3.2.2).

For the query part, you should put in the following text (or an equivalent):

For compatibility with IRIs, non-ASCII characters in the query part MUST 
be encoded as UTF-8, and the resulting octets MUST be %-encoded (see 
http://tools.ietf.org/html/rfc3986#section-2.1).

My understanding is that there's no danger for getting non-ASCII 
characters in the path part, and that fragments are separate anyway.

Regards,   Martin.

---

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

> http://tools.ietf.org/html/rfc3986#section-3.2.2).

I'll leave it out unless a bunch of folks thing it better in.

> http://tools.ietf.org/html/rfc3986#section-2.1).

Added that,
Thanks,
S