[IPP] "printer-uri" path component recommendation in the new implementers guide

[IPP] "printer-uri" path component recommendation in the new implementers guide

Michael Sweet msweet at apple.com
Thu Aug 7 01:29:42 UTC 2014


Ira,

RFC 3510 already says this in section 4.6.2:

   IPP Printers that conform to this specification SHOULD only generate
   IPP Job URLs (for example, in the "job-uri" attribute in a 'Print-
   Job' response) by appending exactly one path component to the
   corresponding IPP Printer URL (for interoperability).


Of the manufacturers that are currently represented in my home office, I see the following kinds of job URIs:

    1. ipp://host.example.com/ipp/print/job-0123 [zero-filled to 4 digits]
    2. ipp://host.example.com/ipp/print/job-123  [no zero-fill]
    3. ipp://host.example.com/ipp/print/job123   [no hyphen]
    4. ipp://host.example.com/ipp/print/123      [no "job" prefix]
    4. ipp://host.example.com/jobs/123           [different path prefix]

Only the last format is unambiguous (and is in fact the format that CUPS uses). The others *could* be used, but only if we prohibited printer-uri values of the same form, i.e., implementations would need to add a leading underscore or something to the printer URI to avoid confusion...

We could use a query string instead of a path component to make it unambiguous, e.g.:

    ipp://host.example.com/ipp/print?job-id=123

However, RFC 3510 says the following:

   Historical Note:  During the development of this document,
   consideration was given to the addition of standard IPP URL
   parameters for the client authentication and security mechanisms.
   However, based on a strong IETF IPP Working Group consensus, no
   parameters were added to the "ipp" URL scheme as originally defined
   in IPP Protocol [RFC2910] in September 2000, for reasons of backwards
   compatibility with the many currently shipping implementations of
   IPP/1.1.

I don't know whether this statement is valid these days, or what shipping implementations had problems with query strings/parameters.

Another option is to deprecate the "job-uri" attribute entirely.  I can remember being "shouted down" during the development of notifications when I asked whether we wanted a notify-subscription-uri attribute - "job-uri's are vile things and we don't want to make the same mistake twice" (or something along those lines).

Thoughts?


On Aug 6, 2014, at 4:27 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:

> Hi Pete,
> 
> +1.
> 
> I *could* add this as a SHOULD in the IETF "ipps:" URI Scheme draft
> for print services (and reference IPP FaxOut and IPP Scan for the other
> service paths?).
> 
> It can't be a MUST, because it would break deployed usage with CUPS
> of "ipps:" (since administrators won't have observed all any convention).
> 
> I would also like to add guidance (with SHOULD) in the "ipps:" URI Scheme
> for Job URI values (e.g., derived from the print queue's URI by adding exactly 
> one component which SHOULD include the integer "job-id" value as a string).
> 
> Remembering that, when it's finally published, the "ipps:" RFC will have high
> visibility for implementors.
> 
> Opinions?
> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic at gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> 
> On Wed, Aug 6, 2014 at 3:51 PM, Michael Sweet <msweet at apple.com> wrote:
> +1.
> 
> We can add it to section 7.1 (service URIs)
> 
> 
> On Aug 6, 2014, at 3:43 PM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> 
>> All,
>> 
>>  
>> 
>> Given that IPP FaxOut and IPP Scan have set requirements on the path components of the service’s URL perhaps the new implementers guide can do the same for print (e.g. “ipp/print”).  I would hope going forward any additional service mappings will have similar path component requirements.
>> 
>>  
>> 
>> The requirement in scan is
>> 
>> “Each instance of a Scan Service is identified by a URI. The path component of an IPP Scan URI MUST be “/ipp/scan” for the only (or default) instance of the service on an Imaging Device and “/ipp/scan/instance-name” for each additional, non-default instance on the Imaging Device.”
>> 
>>  
>> 
>> Peter Zehler
>> 
>> <image001.png>
>> 
>> Email: Peter.Zehler at Xerox.com
>> Office: +1 (585) 265-8755
>> 
>> Mobile: +1 (585) 329-9508
>> FAX: +1 (585) 265-7441
>> US Mail: Peter Zehler
>> PARC, A Xerox Company
>> 800 Phillips Rd.
>> M/S 128-27E
>> Webster NY, 14580-9701
>> 
>>  
>> 
>> _______________________________________________
>> ipp mailing list
>> ipp at pwg.org
>> https://www.pwg.org/mailman/listinfo/ipp
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140806/028587bb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140806/028587bb/attachment.p7s>


More information about the ipp mailing list