Re: Feedback on draft-gregorio-uritemplate-00

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.

Thanks! More responses inline.

> 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...

This has been a long running part of the discussion
and any ideas would be greatly appreciated. Here
is a quick synopsis of the problems:

1. What about the character encoding of non-ascii characters?
    Do we force UTF-8?

2. What about double escaping?
    Given:

       a                                 none%20of%20the%20above

   Should the substitution be:

       http://example.org/{a}
       http://example.org/none%20of%20the%20above

   or

       http://example.org/none%2520of%2520the%2520above


3. What about 'reserved' characters?
    Given:

          q                                   hullo#world

   Should the substitution be:

       http://example.org/{q}
       http://example.org/hullo#world

   or

       http://example.org/hullo%23world


> My other feedback is mainly editorial/formal...:

I will fold this feedback into what will become -01.

>
> Content:
>
> - Section 4.3: in the examples: "scheme" != "schema"

Fixed.

> Editorial:
>
> - Superfl. whitespace in "machine- readable" and "well- known"
>

Fixed.

> - Spell out "interoperability" instead of "interop"

Fixed.

>
> - Outdated references RFC2234 (-> RFC4234) and RFC2717 (-> RFC4395)

Fixed.

>
> - In first sentence of Section 4, the internal ref seems to lack a ",
> see ..."

Fixed.

> - when citing RFC3986, it would be nice when the concrete section number
> was given (several places)

I will have to go back over that in detail later.

>
> - Section 4.3: maybe make that use an xml2rfc texttable element

Ooh, toy surprise! I didn't know xml2rfc could to that. Adopted.

>
> Formal:
>
> - I think the xml2rfc docName shouldn't contain the extension "txt"

Fixed.

>
> - 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...

Fixed. (I had previously tried to drop the organization element
but found that that caused and error.)

> Best regards, Julian

   Thanks!
   -joe

-- 
Joe Gregorio        http://bitworking.org

Received on Thursday, 5 October 2006 14:52:35 UTC