IPP> printer-uri-supported question

IPP> printer-uri-supported question

IPP> printer-uri-supported question

kugler at us.ibm.com kugler at us.ibm.com
Tue Aug 10 11:31:36 EDT 1999

>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,
>would apply.

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
        that URI-reference;
     ·  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.
>fully qualified)?
>PZ> Yes.  The printer-supported-uri is transformed by well defined rules 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, 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
>                   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


More information about the Ipp mailing list