>From: Zehler, Peter
>>>All,
>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
>printer-uri-supported?
>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
exceptions:
· 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:
http://abc.com:80/~smith/home.htmlhttp://ABC.com/%7Esmith/home.htmlhttp://ABC.com:/%7esmith/home.html
>>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
>printer-uri-supported?
>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
"job-uri".
>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).
>Pete
> 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
>>>
-Carl