URI Template
draft-gregorio-uritemplate-08
Yes
(Peter Saint-Andre)
No Objection
(Dan Romascanu)
(Jari Arkko)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
Note: This ballot was opened for revision 08 and is now closed.
Pete Resnick Former IESG member
Yes
Yes
(2012-01-04)
Unknown
2.2: I'm not clear from what is said in section 3 or Appendix A what happens when an op-reserve appears in a template that is being processed where the processor doesn't recognize these operators, in particular '$', '(', and ')'. Are they all treated as error conditions? If so, where in the algorithm.
2.3: Do you really want varnames to be able to end with "." or "_" or begin with "_" or pct-encoded? If you want only internal ".", then you want:
varname = varchar *(["."] varchar)
If you only want internal "_" and pct-encoded as well, then:
varname = ALPHA / DIGIT *(["_" / "." / pct-encoded] / ALPHA / DIGIT)
I don't care, but the current construct (can't begin with ".", but otherwise anything goes) seemed like an odd choice.
2.4.1: An upper limit on max-length might be a useful addition.
3.2.1: The current text says:
...If the value
contains multibyte UTF-8, care must be taken to avoid splitting the
value in mid-character: count each Unicode codepoint as one
character.
The admonition in 1.6 seems equally useful for the values variables: Though they might exist as encoded, all contents of variables are assumed by the spec to be Unicodes, and must be appeneded by UTF-8ing them and pct-encoding as necessary. I think it's worth adding text on this.
Peter Saint-Andre Former IESG member
Yes
Yes
()
Unknown
Wesley Eddy Former IESG member
Yes
Yes
(2012-01-02)
Unknown
This seems to be a very useful and well-written document.
Adrian Farrel Former IESG member
No Objection
No Objection
(2011-12-31)
Unknown
I have no objection to the publication of this document as a Standards Track RFC. I have a few very minor comments you might look at. --- You may note that you use RFC 2119 language in Section 1.1 but do not include the explanation until Section 1.5. --- Should you provide references for WSDL, WADL, and OpenSearch in section 1.3? --- In section 1.5 there is a minor notational discrepency. You have: ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" That means that HEXDIG has a mixed mode of hex notation and quoted letters. It might have made more sense to write... HEXDIG = DIGIT / %x41-46 ; 0-F But I struggle to see this as in any way an important comment! Maybe more interesting is to check that you really intended to exclude lower case alpha from the representation of hex numbers used in pct encoding. --- While Appendix A begins with a helpful note that the body of the document is normative text, it doesn't actually comment on whether the appendix is normative or not. It would be nice to make this explicit.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(2012-01-02)
Unknown
Please run the nit-checker over this document. It appears to have a couple of unused references.
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2011-12-30)
Unknown
- End of p12 says "If a value provided by a user" which implies that
all the usual injection attacks need to be countered in at least some
deployments. Why doesn't that need to be mentioned in the security
considerations? I don't think 3986 envisages that kind of issue. (Esp.
if templates were combined with OAuth v1 or something else that
authenticates the URL after expansion, meaning that the user at the
browser could not have produced the URL herself.)
- Can expressions be nested?, e.g. "{foo{bar}baz}" 1st sentence of 3.2
implies not, but in any case it might be worth adding a sentence
saying that nesting like that is not supported.
- Expressions can be obfuscated. That could provide a new attack
vector: expression author convinces webmaster that template is safe
when its not. Not sure if that's worth a mention or not.
- Seven operators; lists of variable with optional modifiers (esp
"explode") - that all seems to me like too much to be universally
useful and safe. Just an opinion, not a discuss.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown