IPP Mail Archive: Re: IPP> printer-uri-supported question

IPP Mail Archive: Re: IPP> printer-uri-supported question

Re: IPP> printer-uri-supported question

Tue, 10 Aug 1999 09:31:36 -0600

>From: Zehler, Peter
>A couple of questions have come up that I thought I should verify with=
>group at large.
>1) If the IPP printer has an DNS name should there be at least two val=
>for the printer-uri-supported attribute? One URL with the fully qualif=
>DNS name the other with the IP address in the URL.
>PZ> The printer may contain one or the other or both. See below.
>2) Must the operational attribute for printer-uri match one of the val=
ues in
>PZ> A forgiving printer implementation would not reject the operation.=
>printer may not be DNS capable or improperly configured. The request
>obviously reached the printer. The printer could treat the printer-ur=
i as
>the logical equivalent of a value in the printer-uri-supported. It wo=
uld be
>implementation dependent for which value, and associated security poli=
>would apply.

If you happen to be using HTTP as the IPP transfer protocol, your match=
algorithm should use the HTTP rules for comparing URIs:

3.2.3 URI Comparison
When comparing two URIs to decide if they match or not, a client SHO=
ULD use a
case-sensitive octet-by-octet comparison of the entire URIs, with th=

=B7 A port that is empty or not given is equivalent to the defaul=
t 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 ?/?.
Characters other than those in the ?reserved? and ?unsafe? sets (see=
3.2) are equivalent to their ?"%" HEX HEX? encoding.

For example, the following three URIs are equivalent:


>3) Does this above logic also apply to a job object specified with a
>printer-uri and job-id? Is it also true for a job specified with a jo=
>PZ> Yes and yes
>4) Can a restrictive implementation reject a printer or job operation =
if the
>operational attribute printer-uri is not a value of the
>PZ> Yes it could, with an error code of client-error-not-found
I noticed at Bakeoff 2 that about half the Printers ignored "printer-ur=
i"; that
is, it could contain a bogus value and the operation would still be acc=
The other Printers insisted on a correct printer-uri.

I know of at least one implementation that forms the "job-uri" in a Job=
response from the "printer-uri" passed in the request. The Printer its=
doesn't care about what's in "printer-uri" but it does echo it back in =

>5) Must the URL in the printer-uri-supported attribute be absolute(i.e=
>fully qualified)?
>PZ> Yes. The printer-supported-uri is transformed by well defined rul=
es to
>arrive at the address used in the HTTP layer.
>Any comments?

I tried to get some of these issues clarified a long, long time ago, wi=
thout a
whole lot of success (see http://www.pwg.org/hypermail/ipp/0454.html,
http://www.pwg.org/hypermail/ipp/1293.html, and
http://www.pwg.org/hypermail/ipp/0963.html for example). They can be i=
issues. I still wish we went with the proposal to remove the printer-u=
ri and
job-uri operation attriubtes (http://www.pwg.org/hypermail/ipp/0693.htm=

> Peter Zehler
> Xerox Architecture Center
> Email: peter.zehle-@usa.xerox.com
> Voice: (716) 265-8755
> FAX: (716) 265-8792
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 139-05A
> Webster NY, 14580-9701