Harry-
Ummm...
Subject: MOD Issue 1.10 - Case sensitiveness in URLs
>THiS IS abOUT As fAR As i WOUlD gO wiTH anY REcomMendAtiOn reGARding Ca=
> sE
> SensiTIVitY in ThE IMPleMeNtoRS GUiDe...
>> " IPP client and server implementations must be aware of the diverse
> uppercase/lowercase nature of URLs. RFC xxxx defines URL schemes and Ho=
> st names
> as case insensitive but reminds us that the rest of the URL may well
> demonstrate case sensitivity. When creating URL's, where the choice is
> completely arbitrary, it is probably best to select lower case however,=
> this
> cannot be guaranteed and implementations MUST NOT rely on any specific =
> case
> type in the URL beyond the URL scheme and host name".
>> Harry Lewis - IBM Printing Systems
> =
>>
I agree. In fact, although we've been talking about what the URI spec (RFC 2396) says and doesn't say about case sensitivity, the spec for our transport layer, HTTP/1.1, it quite clear:
> When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
 A port that is empty or not given is equivalent to the default port for that URI-reference;
 Comparisons of host names MUST be case-insensitive;
 Comparisons of scheme names MUST be case-insensitive;
 An empty abs_path is equivalent to an abs_path of “/”.
>Characters other than those in the “reserved” and “unsafe” sets (see section 3.2) are equivalent to their “"%" HEX HEX” encoding.
[Quoted from <draft-ietf-http-v11-spec-rev-05>.]
As I've opined here in the past, I think it's a mistake to put restrictions on our HTTP/1.1 transport layer that go beyond what the HTTP/1.1 specs say. Doing so effectively prevents the use of off-the-shelf transport layer components (stacks, SDKs, web servers, libraries, etc) because although you can find HTTP implementations that are guaranteed to meet the HTTP spec, you won't find many that are guaranteed to meet our subset (case-insensitive URIs, whatever).
It would be a shame to preclude the use of standard HTTP components, since it's hard to find a platform these days that DOESN'T include HTTP support. Who wants to build a parallel implementation that duplicates a subset of the functionality already built into your desktop client platform or your embedded protocol stack (and is probably not as well integrated)? Then what's the point of using HTTP as a substrate anyway?
-Carl
-----
See the original message at http://www.egroups.com/list/ipp/?start=4585
--
Free e-mail group hosting at http://www.eGroups.com/