Smith,
The "job-uri" attribute is a holdover from IPP/1.0 where every IPP object would get its own URI. However, since the URI path information was never standardized (RFC 3510 only went so far as to say that "job-uri" SHOULD use "printer-uri" as a prefix, and that came out years after IPP/1.0), interoperability between Clients and Printers was a serious problem and made both implementations needlessly complicated. In contrast, the "printer-uri" + integer identifier mechanism is both trivial and cleaner to implement.
Subsequent objects (subscription, document, and now resource) have only ever used "xxx-id (integer(1:MAX))".
> On May 1, 2018, at 2:34 PM, Kennedy, Smith (Wireless & Standards Architec) <smith.kennedy at hp.com> wrote:
>> Hi there,
>> When interacting with a Job object, like for instance in a Get-Job-Attributes operation, RFC 8011 section 4.3 says:
> 4.3. Job Operations
> All Job operations are directed at Jobs. A Client MUST always supply
> some means of identifying the Job object in order to identify the
> correct target of the operation. That Job identification SHOULD be
> the combination of a Printer URI with a Job ID but MAY be the
> (single) Job URI. The IPP implementation MUST support both forms of
> identification for every Job.
> Why briefly is Printer URI + Job ID preferable to Job URI again?
>> Smith
>> /**
> Smith Kennedy
> Wireless & Standards Architect - IPG-PPS
> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
> Chair, IEEE ISTO Printer Working Group
> HP Inc.
> */
>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180501/adef8325/attachment.html>