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,