Some of your discussion assumes that the use of the integer job-id
and printer-uri combination would be included in operations to the
original printer-uri.
What if we included the integer job-id as an attribute within the
operation, and after job submission and assignment, all operations
were directed at the job-URI. The server handling the job-URI would
then notice that the request is specifying an integer job-ID and
it would use that instead of the information derived from the
URI string?
Randy
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