- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Wed, 25 Jan 2006 11:32:26 -0500
- To: Jeremy Carroll <jjc@hpl.hp.com>
- Cc: uri@w3.org
-1 >A comment on >http://tools.ietf.org/html?draft=draft-hansen-2717bis-2718bis-uri-guidelines-07.txt > >In RFC 3986 I read: > >[[ > Some schemes define additional subcomponents that consist of case- >insensitive data, giving an implicit license to normalizers to >convert this data to a common case (e.g., all lowercase). >]] >page 42, section 6.2.3 That's a stretch. There is an implicit requirement for comparators; normalization outside comparison is moot. >It is helpful if "schemes with subcomponents that consist of case- >insensitive data" in their definition documents would specify that >usually lowercase SHOULD be used. This is particularly pertinent in >applications such as XML Namespaces and Semantic Web, where >character-by-characters comparison is the norm, and unnormalized >URIs result in false negatives. These applications have made their bed with the false negatives in them. Let them sleep in it. At least for email addresses, we should not be buggering the mnemonic advantages of original case in a misguided advocacy of man-in-the-middle normalization. www.YourBusinessName.com reads right in a screen reader. www.yourbusinessname.com does not. etc. If the field is case-insensitive, the end user should bear the burden of normalization, and the data crossing the network should be inviolate. >Suggested text along the lines of >[[ >When a scheme defines subcomponents that consist of case-insensitive >data, then it SHOULD specify that implementations should accept >uppercase letters as equivalent to lowercase for the sake of >robustness but should only produce lowercase scheme names for >consistency. >]] Note the issue is not just scheme names, it is URI components per the scheme syntax. Al > > > >Jeremy
Received on Wednesday, 25 January 2006 16:32:51 UTC