Re: draft-fielding-uri-rfc2396bis-02

> Here are some comments on my first experience with rfc2396bis-02
> this morning as well as some comments on further work.
>
> 1.  abnf2re had no problems with the grammar; it took only a few
>     minutes to update my parser to work with this grammar.

Thanks for the feedback.  I checked it using the abnf parser at 
ietf.org.

> 2.  Overall, the restructuring of the grammar seems much
>     easier to follow, particularly with respect to empty
>     components.
>
> 3.  I wonder whether net_path should be named something
>     else, just so people don't get the idea that it is
>     a path for the purpose of 5.2.

I couldn't think of a better name, and at this point would prefer
to stick with the ones we have.

> 4.  I have been working on the  inverse of the algorithm
>     of section 5.2 for resolving relative references.
>     I thought an algorithm for that might appear in this draft.

As Graham described and I stated in the issues list when that was
requested by TimBL, the reason I did not put such an algorithm in
the specification is because there is no standard for what is the
"best" result of such a parser.  In many cases, a relativise
algorithm should be given a third URI -- the top "root" of the
site tree for that document -- in order to come up with the best
result.  That's because we don't want to relativise URI references
that are outside the tree, even if they are within the same server.

> I have been comparing my algorithms with the uripath.py implementation
> and do find some discrepancies.  Comments on the following examples
> would be welcome.  (Also, there was a note about two interoperable
> implementations for standardization - is what I'm doing helpful?)

Yes, but note that refTo is not following a standard.  If we were
to include that algorithm, then we would need two independent
implementations.

> c.  relative reference ?y
>
>>>> resolve_relative_URI('http://a/b/c/d;p?q', '?y')
> 'http://a/b/c/d;p?y'
>>>> compute_relative_URI('http://a/b/c/d;p?q', 'http://a/b/c/d;p?y')
> '?y'
>
> uripath.py does not seem to agree with the spec:
>
>>>> join('http://a/b/c/d;p?q', '?y')
> 'http://a/b/c/?y'

Yes, that is listed in the changes.  Folks had it correct when they
implemented RFC 1808, then it was changed for 2396, and only after
that was published did objections to the change come from the browser
developers.  So now it is back to what was specified for 1808.
This should still be okay because people don't normally include
relative references within query results.

....Roy

Received on Wednesday, 28 May 2003 20:14:21 UTC