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

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 6 Aug 2014 19:43:46 +0000

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

[parc]
Email: [email-masked]<mailto:[email-masked]>
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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Wed, 06 Aug 2014 15:51:00 -0400

+1.

We can add it to section 7.1 (service URIs)

On Aug 6, 2014, at 3:43 PM, Zehler, Peter <[email-masked]> 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.
>  
> “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
> 
> Email: [email-masked]

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Wed, 6 Aug 2014 20:21:01 +0000

Hi Pete,

I agree with your assertion.  This is already mentioned in section 4.1.1 “Select A Printer Via Static Hostname Or Address” in IPP Implementor’s Guide v2.  But I will call it out in section 7 as well.

The “/ipp/print” resource path is also the path specified in IPP USB and in pending standards from the Wi-Fi Alliance.  If we ever do an update to IPP Everywhere we should add “/ipp/print” to that as well.

Smith

---

From: Ira McDonald <[email-masked]>
Date: Wed, 6 Aug 2014 16:27:50 -0400

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: [email-masked]
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 <[email-masked]> wrote:

> 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.
>
>
>
> “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
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 06 Aug 2014 21:29:42 -0400

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 <[email-masked]> wrote:

> for Job URI values (e.g., derived from the print queue's URI by adding exactly 
> Remembering that, when it's finally published, the "ipps:" RFC will have high