- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 22 Oct 2012 22:35:16 +0000 (UTC)
- To: Jan Algermissen <jan.algermissen@nordsc.com>, Tim Bray <tbray@textuality.com>, Julian Reschke <julian.reschke@gmx.de>
- cc: "Roy T. Fielding" <fielding@gbiv.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Noah Mendelsohn <nrm@arcanedomain.com>, URI <uri@w3.org>, IETF Discussion <ietf@ietf.org>, mnot@mnot.net
On Tue, 23 Oct 2012, Jan Algermissen wrote: > > The point is that what you and Anne are addressing is parsing of URI > *References* not URIs. Anne's spec defines how you get from any arbitrary string (plus a base URL) to a data structure with fields like scheme, hostname, port, path, etc. The input can be absolute, completely invalid, the empty string, whatever. > This is why any references to fixing or aligning URI syntax with reality > is besides the point and not neccessary. All that you (we) deal with is > URI references and how to parse them to yield valid URIs. That's certainly part of the required work, yes. It's not all of it. On Mon, 22 Oct 2012, Tim Bray wrote: > > The notion that curl, or an HTTP cache manager, or an XML namespace > processor, is going to be routing around errors, strikes me on the face > of it as being wrong. One of the main uses I put curl to is making sure > I have the URL exactly right before I drop it into chat or whatever. $ wget 'http://example.com/a b' --2012-10-23 00:27:43-- http://example.com/a%20b # test.cgi returns a 301 with "Location: a b" $ curl -L http://damowmow.com/playground/demos/url/in-http-headers/test.cgi This file is: http://damowmow.com/playground/demos/url/in-http-headers/a%20b Software does this stuff already. We need to make sure it does it interoperably. On Tue, 23 Oct 2012, Julian Reschke wrote: > > This always was about venue, not people. If people want to "fix" or > "augment" URIs/IRIs, they should come over to the IETF. I think the person doing the work has the prerogative to do it wherever he or she wants to do it. Maybe the IETF should consider why Anne isn't doing it in the IETF. > > The specs don't define everything that implementations have to do to > > be interoperable. If the IETF doesn't think that's a problem, then > > that's fine, but then y'all shouldn't be surprised when people who > > _do_ think that's a problem try and fix it. > > Yes, please fix *that*, but *just* that without messing with the basics > without consensus/review. Consensus isn't a value I hold highly, but review of Anne's work is welcome. If the IETF community didn't want Anne to do this work, then the IETF community should have done it. Having not done it, having not even understood that the problem exists, means the IETF has lost the credibility it needs to claim that this is in the IETF's domain. You don't get to claim authority over an area while at the same time telling someone else "please fix that" for the hard work that comes with that area. The reality is, he who does the hard work, gets the authority. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 22 October 2012 22:35:39 UTC