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

[Stephen Farrell <[e-mail]>]

Hi Bjoern,

Thanks for the feedback!

On 06/08/2012 03:16 AM, Bjoern Hoehrmann wrote:
> Hi,
> 
>   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

> boilerplate does not belong in an Introduction section, it should be in
> a Terminology or Conformance or similarily named section.

What we have is very common in RFCs.

> 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.

Fair enough, added one to the intro.

> 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.

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
> least.

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

> 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.)

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.

> 
> 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".

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."

> 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.

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

> 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.

Ok.

> 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?

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.

> 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.

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

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

> 
> 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/`.

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.

> 
> regards,