>From: Zehler, Peter
>A couple of questions have come up that I thought I should verify with the
>group at large.
>>1) If the IPP printer has an DNS name should there be at least two values
>for the printer-uri-supported attribute? One URL with the fully qualified
>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 values in
>PZ> A forgiving printer implementation would not reject the operation. The
>printer may not be DNS capable or improperly configured. The request
>obviously reached the printer. The printer could treat the printer-uri as
>the logical equivalent of a value in the printer-uri-supported. It would be
>implementation dependent for which value, and associated security policy,
If you happen to be using HTTP as the IPP transfer protocol, your matching
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 SHOULD use a
case-sensitive octet-by-octet comparison of the entire URIs, with these
· A port that is empty or not given is equivalent to the default port for
· 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.
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 job-uri?
>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-uri"; that
is, it could contain a bogus value and the operation would still be accepted.
The other Printers insisted on a correct printer-uri.
I know of at least one implementation that forms the "job-uri" in a Job creation
response from the "printer-uri" passed in the request. The Printer itself
doesn't care about what's in "printer-uri" but it does echo it back in the
>5) Must the URL in the printer-uri-supported attribute be absolute(i.e.
>PZ> Yes. The printer-supported-uri is transformed by well defined rules to
>arrive at the address used in the HTTP layer.
I tried to get some of these issues clarified a long, long time ago, without 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 interop
issues. I still wish we went with the proposal to remove the printer-uri and
job-uri operation attriubtes (http://www.pwg.org/hypermail/ipp/0693.html).
> Peter Zehler
> Xerox Architecture Center
> Email: peter.zehle- at 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