* "printer-uri": When the target is a printer and the transport is HTTP=
HTTP (for TLS), the target printer-uri defined in each operation in th=
model document SHALL be an operation attribute called "printer-uri" and=
SHALL also be specified outside of the operation layer as the request-=
the Request-Line at the HTTP level. This
Must these URIs be identical?
HTTP/1.1 clients generate an abs_path (a relativeURI) as the Request-UR=
identifies a resource on a server, but does not include scheme, host or=
Are "printer-uri", "printer-uri-supported", and "job-uri" supposed to b=
absoluteURIs or abs_paths (see
ftp://ietf.org/internet-drafts/draft-fielding-uri-syntax-02.txt for def=
? If "printer-uri-supported" is to specify host, scheme, or port, absol=
are required. If "printer-uri" or "job-uri" are absoluteURIs, then the=
request-URI and the target Operation Attribute can't be identical. Whi=
raises some questions:
- Suppose the "printer-uri" (or "job-uri") and request-URI are not iden=
Should the Printer
a) Return an error status? Warning?
b) Allow one to take precedence over the other?
- Suppose even the "abs_path" part of the URIs differs?
- Suppose they're not identical, but effectively point to the same reso=
* An empty abs_path is equivalent to an abs_path of "/".
* Characters other than those in the "reserved" and "unsafe" sets ar=
equivalent to their ""%" HEX HEX" encoding.
* As a result of an HTTP redirect?
- Suppose one copy of the URI has been supplied, but not the other. Sh=
a) Reject the request?
b) Return an error status? Warning?
c) Perform the operation?
My preferences would be:
- Make target URI Operation Attribute OPTIONAL when the transport is =
- request-URI takes precedence over target Operational Attribute when=
transport is HTTP or HTTPS.
- "printer-uri" and "job-uri" have abs_path form.
- "printer-uri-supported", "job-printer-uri", etc. have absoluteURI f=
Confused implementor in Boulder,