2.5 Case Sensitivity in URIs (issue 1.6)
IPP client and server implementations must be aware of the diverse
uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and =
Host
names as case insensitive but reminds us that the rest of the URL may =
well
demonstrate case sensitivity. When creating URL's for fields 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
fields being case-sensitive or case-insensitive in the URL beyond the =
URL
scheme and host name fields.
The reason that the IPP specification does not make any restrictions on
URIs, is so that implementations of IPP may use off-the-shelf =
components
that conform to the standards that define URIs, such as RFC 2396 and =
the
HTTP/1.1 specifications [RFC2068]. See these specifications for rules =
of
matching, comparison, and case-sensitivity.
It is also recommended that System Administrators and implementations =
avoid
creating URLs for different printers that differ only in their case. =
For
example, don't have Printer1 and printer1 as two different IPP =
Printers.=20
The HTTP/1.1 specification [RFC2068] contains more details on comparing
URLs.
>-----Original Message-----
>From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
>Sent: Tuesday, February 16, 1999 14:58
>To: kugler@us.ibm.com; ipp@pwg.org
>Subject: RE: IPP> About uri
>
>
>IPP Model and Semantics, section 4.1.5 'uri' says:
>
>The 'uri' attribute syntax is any valid Uniform Resource=20
>Identifier or URI
>[RFC2396]. Most often, URIs are simply Uniform Resource=20
>Locators or URLs.
>The maximum length of URIs used as values of IPP attributes is=20
>1023 octets.
>Although most other IPP attribute syntax types allow for only=20
>lower-cased
>values, this attribute syntax type conforms to the case-sensitive and
>case-insensitive rules specified in [RFC2396].
>
>Is that reference sufficient?
>
>
>The Implementer's Guide doesn't talk about URI comparison. =20
>Should it? =20
>
>Would it need to reference the HTTP specification as you did?
>
>Tom
>
>
>
>>-----Original Message-----
>>From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
>>Sent: Tuesday, February 16, 1999 08:11
>>To: ipp@pwg.org
>>Subject: Re: IPP> About uri
>>
>>
>>
>>
>>Yan Gao wrote:
>>Original Article: http://www.egroups.com/list/ipp/?start=3D5223
>>> Dear Sir,
>>>
>>> I did not found out in the IPP1.0 protocal whether uri should be
>>> case-sensitive or case-insensicive.
>>> Could anybody tell me please?
>>>
>>> Yan Gao
>>> gaoyan@excite.co.jp
>>>
>>
>>Part of it is case sensitive and part is case insensitive. From
>>draft-ietf-http-v11-spec-rev-06:
>>
>>3.2.3 URI Comparison
>>When comparing two URIs to decide if they match or not, a=20
>>client SHOULD use
>>a case-sensitive octet-by-octet comparison of the entire URIs,=20
>>with these
>>exceptions:
>>
>> =B7 A port that is empty or not given is equivalent to the=20
>>default port
>> for that URI-reference;
>> =B7 Comparisons of host names MUST be case-insensitive;
>> =B7 Comparisons of scheme names MUST be case-insensitive;
>> =B7 An empty abs_path is equivalent to an abs_path of =93/=94.
>>Characters other than those in the =93reserved=94 and =93unsafe=94 =
sets (see
>>section 3.2) are equivalent to their =93"%" HEX HEX=94 encoding.
>>
>>For example, the following three URIs are equivalent:
>>
>> http://abc.com:80/~smith/home.html
>> http://ABC.com/%7Esmith/home.html
>> http://ABC.com:/%7esmith/home.html
>>
>>
>>
>