- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 23 Oct 2012 23:51:09 +0000 (UTC)
- To: Christophe Lauret <clauret@weborganic.com>
- cc: Jan Algermissen <jan.algermissen@nordsc.com>, Ted Hardie <ted.ietf@gmail.com>, URI <uri@w3.org>, IETF Discussion <ietf@ietf.org>
On Wed, 24 Oct 2012, Christophe Lauret wrote: > > 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. I think we can agree that the error handling should be, at the option of the software developer, either to handle the input as defined by the spec's algorithms, or to abort and not handle the input at all. > But why not do it as a separate spec? Having multiple specs means an implementor has to refer to multiple specs to implement one algorithm, which is not a way to get interoperability. Bugs creep in much faster when implementors have to switch between specs just in the implementation of one algorithm. > Increasing the space of valid addresses, when the set of addressable > resources is not actually increasing only means more complex parsing rules. I'm not saying we should increase the space of valid addresses. The de facto parsing rules are already complicated by de facto requirements for handling errors, so defining those doesn't increase complexity either (especially if such behaviour is left as optional, as discussed above.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 23 October 2012 23:51:32 UTC