Re: 2396bis

I interpret this as a proposal to remove test case

   http://www.w3.org/2000/10/rdf-tests/rdfcore/xmlbase/test012

which I suggest we discuss at today's telecon.

A possible response to the commentor might be:

[[
Thank you for pointing out this proposed change to RFC 2396 which we had 
been unaware of.

RDFCore have resolved to remove this test case.

RDFCore would advise implementors that consume RDF that the RDFCore 
specs are based on RFC 2396, a strict interpretation of which states 
that URI's with too many ".."'s in their path are an error, though many 
URI implementations correct that error and RFC 2396bis proposes to 
require that correction.  Implementors are free to choose whether to 
strictly comply with RFC 2396 or be more liberal.

RDFCore advises implementors and content creators that produce RDF that 
creating URI's with too many ".."'s in their path is inadvisable and may 
lead to interoperability problems.
]]

Brian

Jeremy Carroll wrote:
> 
> I've looked through 2396bis
> 
> http://gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html
> 
> It seems to be as the commentator said - there is a change and .. are 
> systematically eliminate during URI resolution.
> 
> In the change log:
> 
> [[
> Separated the path merge routine into two routines: merge, for describing 
> combination of the base URI path with a relative-path reference, and 
> remove_dot_segments, for describing how to remove the special "." and ".." 
> segments from a composed path. The remove_dot_segments algorithm is now 
> applied to all URI reference paths in order to match common implementations 
> and improve the normalization of URIs in practice. This change only impacts 
> the parsing of abnormal references and same-scheme references wherein the 
> base URI has a non-hierarchical path. 
> ]]
> 
> 
> The most relevant bit of the text is:
> [[
> 5.2  Obtaining the Referenced URI 
> ...
> 
> 6. All prefixes of "<segment>/../" in the buffer, where ".." and <segment> are 
> complete path segments, are iteratively replaced with "/" in order from left 
> to right until no matching pattern remains. If the buffer ends with 
> "<segment>/..", that is also replaced with "/". Note that <segment> may be 
> empty.
> ]] 
> particularly the last sentence.
> 
> 
> I would be happy with any of the possible solutions here:
> 
> A) remove the test and make no comment on this
> B) support the test as in my msg, modifying the comment
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Oct/0171.html
> C) change the test to an illegal test case, justified on quote from RFC 2396
> [[
> If the resulting buffer string still begins with one or more
>          complete path segments of "..", then the reference is
>          considered to be in error.
> ]]
> D) change the test to the 2396bis pattern, justifying it with the following 
> text from 2396
> [[
> some implementations strip leading relative symbolic
>    elements (".", "..") after applying a relative URI calculation, based
>    on the theory that compensating for obvious author errors is better
>    than allowing the request to fail.
> ]]
> 
> I suspect (A) is the right course - if anyone uses this they don't get 
> interoperability - their problem.
> 
> Jeremy
> 
> 
> 
> 
> 
>

Received on Friday, 31 October 2003 04:21:14 UTC