Your suggestion wouldn't work for the LPD-to-IPP gateway because it
assumes that the target for all operations is the Printer specified by
the LPD operation. The gateway can easily take the LPD
(printer-name,Job-Id) and produce an IPP (Printer-URI,Job-Id), but it
cannot produce an IPP Job-URI. I suspect the same problem exists for
the win32 library.
It is necessary that the Job-URI and the (Printer-URI,Job-Id) be
separate interfaces at potentially different hosts in order for this
proposal to work.
Bob Herriot
>
>
>
> Robert Herriot wrote:
> >
> > It was suggested at the last teleconference that we should have both
> > Job-URIs and Job-Ids. This email looks at the pros and cons of that
> > idea.
> >
> > I want to make it clear at the outset of this email, that I am not
> > taking
> > a position on whether we should have both. Rather I want to explore
> > what
> > the ramifications are if we have both.
> >
> > The following are what I think the characteristics of such a solution
> > are.
> >
> > If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST
> > support both; otherwise, we are in worse shape than with just one of
> > them from all servers. Client MUST be free to use whichever they want.
> >
> > For Print-Job, it doesn't matter whether a client specifies whether it
> > wants a Job-URI or Job-ID, or whether the server returns both. In
> > both
> > cases, the server has to deal with both and the client has to be aware
> > of the choice. So for this discussion, let's assume that the server
> > would return both.
> >
> > For Get-Attributes and Cancel-Job, a server must implement these
> > operations for both Job-URIs and Job-Ids. The target may be a Job-URI
> > or the target may be a Printer-URI with a Job-Id attribute.
> >
> > Both Job-URI and Job-Id attributes are mandatory. Thus a client can
> > query for either via Get-Jobs or Get-Attributes.
> >
> > The following discusses how this solution works with various gateways.
> > This solution works well in Win32 because it would use the Job-Id
> > only.
> > It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways.
> >
> > The IPP-to-LPD gateways work well because the Job-Id and Job-URL
> > are both easy to support. So, acting as an IPP server, the gateway can
> > easily support both together.
> >
> > The LPD-to-IPP gateway is easy to support with Job-Ids, so such a
> > gateway, as a client of a IPP server, would use only the Job-Id and
> > would ignore the Job-URL.
> >
> > So from a legacy point of view, the solution with both Job-URIs and
> > Job-Ids
> > is as good as the Job-Id solution only.
> >
> > But now we need to examine what this change means for server
> > implementations.
> >
> > With this change servers would have a bit more work to do because they
> > would have to offer two ways to do the same thing. Moreover, it is
> > mandatory that if they support a particular operation, they must
> > support both Job-URIs and Job-Id. That may be a burden that some
> > implementors won't like -- more code for some abstract future payback.
> >
> > I expect that for most IPP servers its Job-URIs will always consists
> > of
> > its Printer-URI and a Job-Id so the server can easily convert between
> > Job-URIs and Job-Ids with no architectural additions.
> >
> > But for servers that want the Job-URI to reference some remote host,
> > the solution is more complicated because operations, such as
> > Get-Attributes and Cancel-Job will go to the remote host when the
> > client uses the Job-URI and these same operations will go to the
> > Printer when the client uses the Printer-URI and Job-Id. Such servers
> > will have to deal with forwarding issues and the fact that a Job-URI
> > that references a remote host does not guarantee that all traffic goes
> > there because client that use the Job-Id will still come to the
> > original
> > printer.
> >
> > As I said at the beginning of this email, I take no position on this
> > proposal. Rather I offer it as the beginning of a discussion.
> >
> > I would like others to comment on whether this proposal solves the
> > problem, or adds too much complexity to servers for the payback.
> >
> > Bob Herriot
>