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,