IPP Mail Archive: Re: IPP> IIG - Issue 1.10 - URI Case - Proposed text for IPP

Re: IPP> IIG - Issue 1.10 - URI Case - Proposed text for IPP

Harry Lewis (harryl@us.ibm.com)
Mon, 12 Oct 1998 12:39:47 -0400

Fine with me.

Harry Lewis - IBM Printing Systems

owner-ipp@pwg.org on 10/11/98 10:10:03 PM
Please respond to owner-ipp@pwg.org
To: ipp@pwg.org
cc: masinter@parc.xerox.com
Subject: IPP> IIG - Issue 1.10 - URI Case - Proposed text for IPP Imp

Harry has proposed some text for the IPP Implementor's Guide (IIG) whic=
h is
non-standards track companiion document to the MOD and PRO documents.

Carl has given the reason that IPP doesn't want to be any more restrict=
ive
than HTTP/1.1 and the URI specifications: so that off-the shelf compone=
nts
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 ha=
lf 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 Ho=
st
names as case insensitive but reminds us that the rest of the URL may w=
ell
demonstrate case sensitivity. When creating URL's for fields where the
choice is completely arbitrary, it is probably best to select lower cas=
e.
However, this cannot be guaranteed and implementations MUST NOT rely on=
any
fields being case-sensitive or case-insensitive in the URL beyond the U=
RL
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 co=
nform
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 implementati=
ons
avoid creating URLs for different printers that differ only in their ca=
se.
For example, don't have Printer1 and printer1 as two different IPP Prin=
ters.

Tom Hastings
(310) 333-6413

=