Subject: IPP>MOD printer-uri/printer-tls-uri issues

From: [email-masked] (Robert Herriot)
Date: Fri, 19 Dec 1997 19:52:41 -0800

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.

---

From: Tom Hastings <[email-masked]>
Date: Sat, 20 Dec 1997 06:53:02 PST

I think Bob has come up with a significant problem and a good solution.

I suggest that the alternate URI attribute be printer-alt-uri, not
printer-alt-name.  And perhaps we should spell it out:
printer-alternate-uri.

It is an easy fix to the Model document, since it uses printer-uri
throughout.  Primarly the renamed section 4.2.2 printer-alternate-uri
needs updating to explain and so does containing-printer-uri, as Bob
explains.  Maybe section 8, though I moved the paragraph about the
two attributes from 8 to 4.2.2.

For the Directory schema, I guess there could be the same two attributes:
printer-uri
printer-alternative-uri

But which one would be the more secure? Do we need a convention?

Another ISSUE.  Before printer-uri and printer-tls-uri were both
MANDATORY.  Do we continue that, or does the printer-alternate-uri
become OPTIONAL, only being supported by printers that do both?

Another advantage of this change, is that the application/ipp payload
can be stored away, without having to change the attribute name of
the target printer in the application/ipp data.

My understanding is that there is no problem with issuing a new
Internet-Draft immediately after another one.

Tom