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
At 19:52 12/19/1997 PST, Robert Herriot wrote:
>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.
>>>>>>