Rolled up Feedback on draft-gregorio-uritemplate-00

I've just reviewed all the feedback on the -00 draft
and believe that there is rough agreement on the following points:

1. template variables should not span segments
2. mandate a utf-8 encoding
3. The spec is self contradictory:
   http://lists.w3.org/Archives/Public/uri/2006Oct/0011.html

So that leads to escaping the values substituted for variables.
I read over the ABNF in RFC 3986 and I think the following
algorithm will produce the 'right' results, and by 'right' I mean
the it will produce a valid URI and at the same time the results
won't be suprising:

1. Start with a 'string' for each variable value, and by 'string'
   I mean a series of unicode characters.
2. encode that string as 'utf-8'
3. %-encode each octet not in:
    "!" / "$" / "'" / "(" / ")" / "*" / "+" / "," / ";" / ALPHA /
DIGIT / "-" / "." / "_" / "~"

  [That's (unreserved/pct-encoded/sub-delims) with '&' and '=' removed.]
This will force the %encoding of "/", ":", "&", "=" and "@" among others.

So

   a = "name=fred"
   http://example.org/{a}

expands to:

   http://example.org/name%3Dfred

and

   name = joe.gregorio
   mailto:{name}@gmail.com

expands to:

   joe.gregorio@gmail.com

and

   id=this:that
   urn:{id}

expands to:

   urn:this%3Athat

Thoughts?

   Thanks,
   -joe


On 10/5/06, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> Hi Joe/Mark/Marc/David,
>
> I think this goes into the right direction. Congratulations.
>
> The main issue I see is that the spec doesn't seem to have a position on
> what to do with values that contain non-URI friendly character
> sequences. For instance, in
> <http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-00.html#rfc.section.4.2.p.2>
> you say:
>
> "If the value of a template variable would conflict with a reserved
> character's purpose as a delimiter, then the conflicting data must be
> percent-encoded before substitution."
>
> However, in
> <http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-00.html#rfc.section.4.3>
> we see:
>
> +++++++++++
> The following are examples of URI Template expansions that are not legal.
>
>      Name                                Value
>      ------------------------------------------------------------
>      a                                   fred barney
>      b                                   %
>
> The following URI Templates are expanded with the given values and do
> not produce legal URIs.
>
>      http://example.org/{a}
>      http://example.org/fred barney
>
>      http://example.org/{b}/
>      http://example.org/%/
> +++++++++++
>
> ..although I would have assumed that "http://example.org/{b}/"  should
> have been expanded to "http://example.org/%25/" according to Section 4.2...
>
>
>
> My other feedback is mainly editorial/formal...:
>
> Content:
>
> - Section 4.3: in the examples: "scheme" != "schema"
>
>
> Editorial:
>
> - Superfl. whitespace in "machine- readable" and "well- known"
>
> - Spell out "interoperability" instead of "interop"
>
> - Outdated references RFC2234 (-> RFC4234) and RFC2717 (-> RFC4395)
>
> - In first sentence of Section 4, the internal ref seems to lack a ",
> see ..."
>
> - when citing RFC3986, it would be nice when the concrete section number
> was given (several places)
>
> - Section 4.3: maybe make that use an xml2rfc texttable element
>
>
> Formal:
>
> - I think the xml2rfc docName shouldn't contain the extension "txt"
>
> - I've never seen "individual" as an org name in an IETF document;
> leaving it out instead seems to be the agreed-upon way to do it...
>
>
>
> Best regards, Julian
>
>


-- 
Joe Gregorio        http://bitworking.org

Received on Thursday, 9 November 2006 22:07:22 UTC