Re: [url] Requests for Feedback (was Feedback from TPAC)

On 06/12/2014 08:10, Julian Reschke wrote:
> On 2014-12-06 01:31, Bjoern Hoehrmann wrote:
>>    Goals
>>
>>       The URL standard takes the following approach towards making
>>       URLs fully interoperable:
>>         * Align RFC 3986 and RFC 3987 with contemporary
>>           implementations and obsolete them in the process. (E.g.
>>           spaces, other "illegal" code points, query encoding,
>>           equality, canonicalization, are all concepts not entirely
>>           shared, or defined.) URL parsing needs to become as solid
>>           as HTML parsing. [34][RFC3986] [35][RFC3987]
>
> I think obsoleting RFC 3986 is a non-goal; *until* it is demonstrated that
> there's actually a problem with that spec (at which point bug reports should be
> sent).

+1

I've been using RFC3986 in my work (as developer) for many years now, and find 
it for the most part to be clear and unambiguous for my needs.  I also liberally 
add references to RFC 3986 to my code where I feel it helps explain what I'm 
doing.  For me, there's no particular benefit in having a different spec that 
also explains how to parse a string to a URL/URI, and I don't really want to 
have to absorb and reference a different spec for describing what constitutes a 
valid URI/URL string and how to resolve a relative reference to obtain such a 
string.

(I'm OK with the idea that there is a spec for processing strings into valid 
URI/URL structures, for use by HTML parsers and other applications that require 
similar functionality.  I see that as the primary function of the new URL 
specification.)

I have a concern (but I can't tell if it's actually a problem) that 
re-addressing the notion of relative references, which the new URL spec appears 
to do, will invalidate some of the assumptions in my code that are based on RFC 
3986 (e.g. a relative reference being defined syntactically by the absence of a 
scheme, and use of the mechanism defined in RFC 3986 for resolving relative 
references to absolute.)

Finally, I think there are other reasonable ways of getting from an input string 
to a valid URI/URL.  In my current work, I'm making extensive use of CURIEs 
(http://www.w3.org/TR/curie/) in JSON, with the goal that these can be resolved 
to proper URIs according to the context in which they are used.  So I have a 
problem with there being just "one true way" of resolving an intended resource 
reference to a URI/URL.

In summary, it would, for me, be useful to keep the definition of a URI/URL 
separate from details of how to process URI/URL related artifacts.  I would see 
this as a natural division of labour between RFC3986 and the new URL specification.

#g
--

PS: on the naming thing of URI vs URL:  I have found there are places when it is 
useful to actually distinguish between URI and URL strings, even within a single 
data structure.  The difference is based on context and intended use rather than 
any intrinsic difference in the values.  Often, the URI and URL for a resource 
may be the same string, but sometimes I find a need to have different values 
(e.g. for identifier strings that I want to remain stable when a resource is 
moved to a different location).

Received on Saturday, 6 December 2014 09:08:13 UTC