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

Stephen Farrell <> Fri, 08 June 2012 13:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78CCA21F873C for <>; Fri, 8 Jun 2012 06:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ikw5mGyiHrYE for <>; Fri, 8 Jun 2012 06:35:56 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 7FB4921F873A for <>; Fri, 8 Jun 2012 06:35:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5D431714E4; Fri, 8 Jun 2012 14:35:42 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339162541; bh=1uVypHRiKNCWXp 0XUhY7+a8fVFwM2mkUy/MFWdTioXY=; b=MWnhSKFKjujT4MQL/Qvcv+O7/9X1ny X8X5iQEkVNHMqxnIOCd8DAySPhCNLD3TEsfzxmOYLVFU6ZMgBHY8YSeOoDmVIbGO 0BvlmJ+Xgh/7aPbK5j488hs/Cf9fNm+L+SGzgSZFJ2D5KmT5RrB7M2e+e0q4mip9 hWmcDIbcbRKyPephJ2bNh+GEwQiW5nGn+CPpGWHPMXkGix0r6MofQoviDGMR+JUU 09+or28yvNg9Mk8mkm9zPKJV6+Eis70nGsK10Ut+RRFCUYWfKXTaTYuCUKtQEhix ojdyewZi97Da50+uwbExdIohLCVquk6/mg1UIMCmAL73o0NZpwIjdkpg==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id ubixJu7P67GC; Fri, 8 Jun 2012 14:35:41 +0100 (IST)
Received: from [IPv6:2001:770:10:203:ccd0:6c1c:533b:ca48] (unknown [IPv6:2001:770:10:203:ccd0:6c1c:533b:ca48]) by (Postfix) with ESMTPSA id 581FD17180C; Fri, 8 Jun 2012 14:35:37 +0100 (IST)
Message-ID: <>
Date: Fri, 08 Jun 2012 14:35:33 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bjoern Hoehrmann <>
Subject: Re: Comments on draft-farrell-decade-ni-06
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jun 2012 13:35:57 -0000

Hi Bjoern,

Thanks for the feedback!

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


> 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

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


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

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,

> regards,