- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Fri, 01 Apr 2011 14:38:58 +0900
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- CC: "public-iri@w3.org" <public-iri@w3.org>
Hello Noah, Allowing URIs/IRIs to be of 'abritrary' length (as we currently do) doesn't mean that all implementations have to handle URIs/IRIs of arbitrary length. Last time I heard about this issue (which I have to admit was a while ago), various browsers had various (rather high, like 4096 or so) limits. Longer ones should just be handled 'gracefully', i.e. result in "not resolvable" rather than "application blows up". Implementations have to do that anyway, because a limit in the spec isn't a guarantee to not find longer ones in the wild. Regards, Martin. On 2011/04/01 0:13, Noah Mendelsohn wrote: > On 3/31/2011 4:49 AM, "Martin J. Dürst" wrote: >> As an example, it would be total nonsense to define something like the >> http: scheme to have a maximum length of 512 (or any other number you >> prefer). > > I think that's just a bit too strong. I do agree that, on balance, we > should at least strongly discourage, or perhaps prohibit outright, the > imposition of limits that don't map directly to constraints in the > underlying protocols. > > That said, I don't think the arguments to the contrary are "total > nonsense". Handling strings of arbitrary length can, in certain > computing environments, lead to significant increases in complexity > and/or increased performance overhead. In a virtual memory environment, > things can get easier, but in something like an embedded system, having > to architect for arbitrarily long strings when in practice you're > unlikely to see any has real costs in design time, complexity, etc. I > still think, on balance, that baking such restrictions into scheme > definitions will rarely if ever be the right thing to do, but to imply > that doing so would be "total nonsense" seems way too strong. > > Noah > >
Received on Friday, 1 April 2011 05:39:41 UTC