NAME OF TARGET IN OPERATIONS ATTRIBUTES
The initial issue was whether the printer target in the operation
attributes should always be called printer-uri or whether it should be
printer-tls-uri when TLS is being used. A similar question exists for
jobs.
For job targets, we have only defined a job-uri job attribute, even for
TLS submitted jobs. So it would seem that the job target operation
attribute should always be job-uri with no special job-tls-uri.
I decided that the printer target would always be printer-uri, rather
than printer-tls-uri for TLS requests. The code is simpler if it is
always looking for the same attribute, and I couldn't see any reason for
the redundancy. With the changes I suggest in the third section,
printer-uri becomes the only choice.
CONTAINING-PRINTER-URI
But then I realized that containing-printer-uri is defined
ambiguously. If I do Get-Job-Attributes by HTTP to a job submitted via
HTTPS, do I get back the HTTPS printer or the HTTP printer?
I am probably not using this attribute to figure out how the job was
submitted, so having it return the HTTPS printer-uri to which it was
submitted isn't useful.
Instead, I am probably requesting the containing-printer-uri so that I
can do another operation on the job's printer. Thus, I would expect the
Printer to return the HTTP printer so I can continue with the same scheme
I am using with the Get-Job-Attributes request.
A printer might second guess me and give me the printer uri that
will work best for me.
So we need some words in the model document. I address that in the
last section.
PRINTER-URI VERSUS PRINTER-TLS-URI
Finally, this leads me back to printer-uri versus printer-tls-uri.
Having both seems to lead to numerous problems.
I propose that the value printer-uri for Get-Printer-Attributes be
defined as the printer-uri to which the Get-Printer-Attributes was
targeted. So if I do Get-Printer-Attributes to "http://foo/bar",
printer-uri is "http://foo/bar", and if I do Get-Printer-Attributes to
"https://foo/bar", printer-uri is "https://foo/bar".
For the rare case, where a client wants the "other" printer name, I
suggest an attribute called "printer-alt-name", which is an alternate uri.
If I do Get-Printer-Attributes to "http://foo/bar", printer-alt-uri is
"https://foo/bar", and if I do Get-Printer-Attributes to
"https://foo/bar", printer-alt-uri is "http://foo/bar"
WHY IS THIS BETTER?
Whether a printer is configured for just HTTP, just HTTPS or both, the
value of "printer-uri", as seen by a client, will always be the printer
uri to which the client submitted the request and is probably
continuing to use. Thus, for the normal case, where the client
continually uses a single uri for a printer, where it is HTTP or HTTPS,
"printer-uri" holds the printer's name. For the abnormal case, of
shifting to a different scheme, the printer-alt-uri is available. From
a client's standpoint these are a simple rules.
With this definition of printer-uri, the hand-wavy statement in section 8
about "printer-uri" standing for "printer-uri" and "printer-tsl-uri"
goes away.
Also, with this definition of printer-uri, the operation attribute name
of "printer-uri" becomes the obvious choice, and the definition of
containing-printer-uri becomes easier.
1) The scheme of the containing-printer-uri shall be the same as
the scheme of the printer target of the request used to obtain
the attribute. This is not a useful case because the value
returned is the same as the printer target, but so is
printer-uri.
2) The scheme of the containing-printer-uri shall be the same as
the scheme of the job target of the request used to obtain the
attribute unless that scheme would not allow the client to
perform requests, such as Get-Jobs.
3) The scheme of the containing-printer-uri shall be unrelated to
the scheme of the printer to which the job was submitted except
by coincidence.