Re: Rolled up Feedback on draft-gregorio-uritemplate-00

As discussed before, it's not possible to apply a generic rule about  
escaping to URIs and still retain the full range of possible  
characters; different components have different escaping rules.

The two ways around this discussed so far IIRC have been:
   a) allowing hints as to how to encode them (either in the variable  
input or in the spec of a particular template type)
   b) requiring processors to encode automatically using component- 
specific rules

I think either of these approaches would work.

Also, there was discussion about the range of characters allowed in  
template variable names; i.e. they should be able to be URIs.

Cheers,


On 2006/11/09, at 2:07 PM, Joe Gregorio wrote:

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


--
Mark Nottingham     http://www.mnot.net/

Received on Monday, 13 November 2006 23:16:58 UTC