Jan wrote:
Help me, I am just not getting it:
Why do you insist on 'fixing STD 66'?
What is the reason you are not willing to reframe the problem to 'fixing how we get from the provided string -the input to the reference construction process- to a STD-66-valid result'?
To me this is really what you are aiming at and dropping the 'fix the URI spec' language would get everyone on board immediately in my perception.
I completely agree - I don't understand the insistence on "fixing" STD 66.
As a Web developer who's had to write code multiple times to handle URIs in very different contexts, I actually *like* the constraints in STD 66, there are many instances where it is simpler to assume that the error handling has been done prior and simply reject an invalid URI. By reducing the space of valid addresses around rigid rules to match more closely the set of addressable resources, it reduces my scope of work.
I understand that it isn't practical in some contexts (e.g. browsers) where it is inevitable that strings that are not considered valid URI references will crop up and it is desirable for everyone to deal with these in a consistent manner. So, I applaud Anne and Ian for wanting to standardize the error handling and tackling this problem head on.
But why not do it as a separate spec?
Increasing the space of valid addresses, when the set of addressable resources is not actually increasing only means more complex parsing rules.
I accept that it is a requirement in some contexts, but it is also completely unnecessary in others where coding against STD 66 is just fine if not more desirable.
Personally, I don't have any qualms in calling that larger set of addresses "URLs" if it is what most people use, and leave STD 66 and URIs are as they are.
Christophe-
(I've used 'address' as a short for a "string which should ultimately resolve as a valid STD 66 result")