Carl has given the reason that IPP doesn't want to be any more restrictive
than HTTP/1.1 and the URI specifications: so that off-the shelf components
may be used.
Paul has suggested that two printers SHOULD not differ only in case.
Therefore, I propose the following text for the IIG to be the second half of
the resolution to Issue 1.10:
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 standard 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.
It is also recommended that 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.
Tom Hastings
(310) 333-6413