I have been a proponent of a single URI for some time now.
(As many will remember...)
The anticipated problems of identifying printer objects
with multiple URIs for different capabilities (TLS or no-TLS)
will not only arise in implementation, but also in
deployment and administration (as I have said before).
So the problem is how would we deal with specifying just
one URI to identify a printer object, which in some ways
is what Bob is proposing (but not exactly).
I too would like to see us just use "printer-uri" as our
only means of identifying the printer object. Job object
URI strings take care of themselves, since they are
dynamically generated.
I think one way we can do this is through the use of
server redirection. Since dynamic creation
of job URIs eliminates the need for worrying about
job URIs, similarly we could have servers dynamically
generate TLS URIs, whether the server is requesting
TLS-access OR the client is requesting TLS-access.
With the server requesting TLS sessions, the server
can just issue a redirect to a TLS-URI when a client
attempts to access a particular object to which the
server demands TLS access. This type of arrangement
would allow the server to set access policy depending
upon the type of access the client is requesting.
Meaning that the server would allow non-TLS access
for get-attributes types of requests, but mandate
TLS access for operations which take resources (like
create-job).
For client-requested TLS sessions, the client would
just include an operation-attribute that specifies that
the client would like to use TLS, the server would then
issue a redirect to a particular URI to which TLS
access is allowed. Again, the client can elect to do
this type of access depending upon whatever type of
operation that the client wishes to be "secure".
Just my suggestion for making static URI configuration
decisions easier (for both implementers and
administrators).
Randy
> -----Original Message-----
> From: Robert.Herriot at Eng.Sun.COM [SMTP:Robert.Herriot at Eng.Sun.COM]
> Sent: Friday, December 19, 1997 7:53 PM
> To: ipp at pwg.org> Subject: IPP>MOD printer-uri/printer-tls-uri issues
>> While I was putting the finishing touches on the protocol document,
> I came across an unresolved issue which opened up a few more.
>> 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.
>>>