URI Template
RFC 6570

Note: This ballot was opened for revision 08 and is now closed.

(Wesley Eddy) Yes

Comment (2012-01-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This seems to be a very useful and well-written document.

(Pete Resnick) Yes

Comment (2012-01-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

Comment (2012-01-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please run the nit-checker over this document. It appears to have a couple of unused references.

(Stewart Bryant) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2011-12-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Stephen Farrell) No Objection

Comment (2011-12-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
- 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.

(Russ Housley) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection