And I think we can accomplish this with the addition
of a single operation attribute on all requests.
Randy
> -----Original Message-----
> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com]
> Sent: Saturday, December 20, 1997 6:53 AM
> To: Robert.Herriot@Eng.Sun.COM; ipp@pwg.org
> Subject: Re: IPP>MOD printer-uri/printer-tls-uri issues
>
> 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.
> >
> >
> >
> >
> >
> >