Subject: Re: [IPP] PWG Call for Objections: IPP Transaction-Based Printing Extensions v1.1 (TRANS) (ends March 27, 2020)

From: "Rizzo, Christopher via ipp" <[email-masked]>
Date: Mon, 2 Mar 2020 18:49:28 +0000

I'm trying to get thru the IPP Everywhere self-cert tests and fix any issues with our software.  The device under test (DUT) fails the very first test:

B-1 IPP Browse test: Printers appear in a search for "_ipp._tcp,_print" services.

The reason the device I'm testing fails, is because our device does not include ",_print" on the "_ipp._tcp" print service type.

I do not have strong knowledge of Bonjour requirements and MDNS itself, and I cannot find unambiguous requirements that say what "_print" is for and what it means to a client.  In addition, the Bonjour Printing spec version 1.2.1 section 7.5 Advertising Services seems ambiguous, because it has an example (Apple LaserWriter) of advertising services without ",_print" in the first paragraph, and then shows "_http._tcp,_printer" service type example in last paragraph.

What specification can I refer to that explicitly explains what the purpose of ",_printer" is and why it is required?  (Actually - after writing this question and then reading RFC 6763 section 7.1 Selective Instance Enumeration - "_printer" subtype helps Safari Web Browser distinguish between a printer web page vs. a generic web server apparently, but that should only apply to the "_http" service - correct?) And on top of that, to my knowledge the ability to use Bonjour in Safari has been removed a few years back).  Where in the IPP Everywhere specification is the requirement the ",_print" be appended to printing service advertisements, and which service advertisements should it be appended to?

Also, why does the test look for ",_print" when the Bonjour 1.2.1 spec and the RFC refers to ",_printer" as a sub-type on http advertisement?

Thanks,
Chris

Christopher Rizzo
Xerox Corporation
GDG/Discovery/Advance Technology
26600 SW Parkway Ave.
Wilsonville, OR 97070-9251
Phone: (585) 314-6936
Email: [email-masked]

"The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."
-Maurice Wilkes, Memoirs of a Computer Pioneer

From: ipp <[email-masked]> on behalf of PWG Workgroup <[email-masked]>
Reply-To: Michael Sweet <[email-masked]>
Date: Thursday, February 27, 2020 at 1:52 PM
To: PWG Announcements <[email-masked]>
Cc: PWG Workgroup <[email-masked]>
Subject: [IPP] PWG Call for Objections: IPP Transaction-Based Printing Extensions v1.1 (TRANS) (ends March 27, 2020)

All,

This PWG Call for Objections starts today, February 27, 2020, and ends Friday March 27, 2020 at 10pm US Pacific time.

This is the formal announcement of the PWG Call for Objections for approval of the IPP Transaction-Based Printing Extensions v1.1 (TRANS), located at:

                https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans11-20200226.pdf

The IPP WG has completed a last call of this document.

The PWG Process/3.0 defines the PWG Call for Objections procedure.  The PWG Definition of the Standards Development Process Version 3.0 is located at:

                https://www.pwg.org/chair/membership_docs/pwg-process30.pdf

HOW TO RESPOND

ONLY if you do NOT approve of this errata update, please send an email with your specific objections and *exactly* the following subject line format:

   Subject: <Company Name> has reviewed the IPP Transaction-Based Printing Extensions v1.1 and has objections

WHERE TO SEND YOUR RESPONSE

Please do NOT simply reply to this note on the PWG-Announce list.

Please send your response to *all* of the following email addresses:

   ipp at pwg.org (IPP WG mailing list - you must be subscribed!)
   blueroofmusic at gmail.com (Ira McDonald, IPP WG Co-Chair)
   ptykodi at tykodi.com (Paul Tykodi, IPP WG Co-Chair)
   msweet at lakesiderobotics.ca (Michael Sweet, IPP WG Secretary and Document Editor)

Note: You must be subscribed to the IPP workgroup mailing list to send email to that list - otherwise your email will be silently discarded.  You can subscribe to this list at:

                https://www.pwg.org/mailman/listinfo/ipp

________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet via ipp <[email-masked]>
Date: Mon, 2 Mar 2020 14:21:23 -0500

Chris,

> On Mar 2, 2020, at 1:49 PM, Rizzo, Christopher via ipp <[email-masked]> wrote:
> 
>  

So the _print sub-type (that's what the ",_print" part selects with ippfind) is defined in the IPP Everywhere specification.  Basically almost all IPP printers that support Bonjour also advertise the _ipp._tcp service type (as defined in the Bonjour Printing Specification) but we use the _print sub-type to differentiate an IPP printer from an IPP Everywhere printer.

(AirPrint does something similar, but with the _universal sub-type...)
 
> What specification can I refer to that explicitly explains what the purpose of ",_printer" is and why it is required?  (Actually - after writing this question and then reading RFC 6763 section 7.1…

From the IPP Everywhere specification:

4.2.1 Service (SRV) Instance Name

Printers MUST NOT use a service instance name containing a unique identifier by default. A unique identifier MAY be added to the instance if there is a name collision.

Printers that support DNS-SD MUST advertise the "_ipp._tcp" (generic IPP) and "_print._sub._ipp._tcp" (IPP EverywhereTM) services over mDNS.

Printers that support DNS-SD and the "ipps" URI scheme [RFC7472] MUST advertise the "_ipps._tcp" (generic IPPS) and "_print._sub._ipps._tcp" (IPP EverywhereTM Secure) services over mDNS.

> Also, why does the test look for ",_print" when the Bonjour 1.2.1 spec and the RFC refers to ",_printer" as a sub-type on http advertisement?

The DNS-SD tests are only looking for the IPP and IPPS services, which use the "_print" sub-type.

________________________
Michael Sweet

---

From: "Rizzo, Christopher via ipp" <[email-masked]>
Date: Mon, 2 Mar 2020 19:52:12 +0000

Thanks Mike,

Yes, I noticed the IPP Everywhere requirement after sending out the note.

So why do we need to distinguish between IPP and IPP Everywhere printers?  And if this is needed, is this the primary way to distinguish between them, or are there other indications?  For example, is there an IPP Everywhere version TXT record (or should there be)?

And why use "_print" in IPP everywhere when Bonjour spec uses "_printer".  It all seems to just add confusion.  Maybe IPP Everywhere spec should include information clearing up this confusion (ie - a note that says "_print" IPP Everywhere service advertisement should not be confused with "_printer" from Bonjour spec, and that the "_print" advertisement is different (required in addition to) from the standard Bonjour advertisement to specifically differentiate an IPP Everywhere supported printer).

Apologies for my confusion, but when you have to read several specs (RFC, AirPrint, Bonjour Printing spec, IPP Everywhere) and try to coalesce all the requirements, it gets a little confusing.

Thanks,
Chris

Christopher Rizzo
Xerox Corporation

From: Michael Sweet <[email-masked]>
Date: Monday, March 2, 2020 at 11:22 AM
To: Christopher Rizzo <[email-masked]>
Cc: PWG Workgroup <[email-masked]>
Subject: Re: [IPP] PWG Call for Objections: IPP Transaction-Based Printing Extensions v1.1 (TRANS) (ends March 27, 2020)

Chris,

On Mar 2, 2020, at 1:49 PM, Rizzo, Christopher via ipp <[email-masked]<mailto:[email-masked]>> wrote:

________________________
Michael Sweet

---

From: Michael Sweet via ipp <[email-masked]>
Date: Mon, 2 Mar 2020 15:49:52 -0500

Chris,

> On Mar 2, 2020, at 2:52 PM, Rizzo, Christopher <[email-masked]> wrote:
> 
> Thanks Mike,
>  
> So why do we need to distinguish between IPP and IPP Everywhere printers?

Because IPP printers have very limited requirements WRT file format support, attribute support, and so forth.  Until AirPrint and IPP Everywhere, IPP was treated as just another protocol to send printer-specific data through, and even those printers that supported a generic PDL like PDF didn't necessarily support things like copies, media, and so forth.

> And if this is needed, is this the primary way to distinguish between them, or are there other indications?  For example, is there an IPP Everywhere version TXT record (or should there be)?

You may be able to "guess" based on the list of formats in the TXT record's "pdl" key, and once you connect to the printer you can do a Get-Printer-Attributes to confirm your guess.

But browsing for _print._sub._ipp._tcp and _print._sub._ipps._tcp services (printers) is guaranteed to work...
 
> And why use "_print" in IPP everywhere when Bonjour spec uses "_printer".

The Bonjour Printing spec was written long before IPP, IPP Everywhere, or AirPrint were ubiquitous, so the focus was on being a) discoverable and b) supportable by all network printers regardless of protocol.  LPD is the "flagship" protocol (ha!) and thus all printers have to register their service name for the "_printer._tcp" type (LPD), even if the port number is 0 (meaning "I don't really support this protocol").

Since _printer._tcp is the flagship protocol, the sub-type for the printer's web page is "_printer._sub._http._tcp".

> It all seems to just add confusion.  Maybe IPP Everywhere spec should include information clearing up this confusion (ie - a note that says "_print" IPP Everywhere service advertisement should not be confused with "_printer" from Bonjour spec, and that the "_print" advertisement is different (required in addition to) from the standard Bonjour advertisement to specifically differentiate an IPP Everywhere supported printer).
>  

I want to avoid making things more confusing, and also don't want to restate every requirement from the Bonjour Printing specification...

How about I add the following note at the end of section 4.2:

Note: The first version of the Bonjour Printing Specification was published by Apple shortly after the Internet Printing Protocol was published by the IETF. As the Line Printer Daemon Protocol [RFC1179] was considered the most popular network printing protocol at the time, the "_printer._tcp" DNS-SD service type (LPD) was assigned as the "flagship" protocol for DNS-SD advertisements. Similarly, the HTTP service registration for the embedded web server uses the "_printer._sub._http._tcp" service type, even for IPP Printers.

________________________
Michael Sweet

---

From: "Rizzo, Christopher via ipp" <[email-masked]>
Date: Mon, 2 Mar 2020 21:16:26 +0000

How do you feel about adding the following (first sentence) to your section 4.2 proposal?

Note: The IPP Everywhere required "_print._sub._ipp._tcp" and "_print._sub._ipps._tcp" advertisements, which are used to distinguish between legacy IPP and IPP Everywhere support, should not be confused with "_printer._tcp" and "_printer._sub._http._tcp" advertisements referenced in [BONJOUR].  The first version of the Bonjour Printing Specification was published by Apple shortly after the Internet Printing Protocol was published by the IETF. As the Line Printer Daemon Protocol [RFC1179] was considered the most popular network printing protocol at the time, the "_printer._tcp" DNS-SD service type (LPD) was assigned as the "flagship" protocol for DNS-SD advertisements. Similarly, the HTTP service registration for the embedded web server uses the "_printer._sub._http._tcp" service type, even for IPP Printers.

Thanks,
Chris

Christopher Rizzo
Xerox Corporation

Date: Monday, March 2, 2020 at 12:51 PM

Chris,

On Mar 2, 2020, at 2:52 PM, Rizzo, Christopher <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Mike,

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Tue, 3 Mar 2020 00:26:16 +0000

Hi Chris and Mike,

I think you are asking good questions, but I think this dialog actually belongs over with the last call for IPP Everywhere™ 1.1, not in the Call for Objections to IPP Transaction-Based Printing Extensions v1.1?

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Mar 2, 2020, at 2:16 PM, Rizzo, Christopher via ipp <[email-masked]> wrote:
> 

I'd rather that we keep Chris' addition and eliminate all the rest of it:

Note: The IPP Everywhere required "_print._sub._ipp._tcp" and "_print._sub._ipps._tcp" advertisements, which are used to distinguish between legacy IPP and IPP Everywhere support, should not be confused with "_printer._tcp" and "_printer._sub._http._tcp" advertisements referenced in [BONJOUR].

I'd also suggest:

1. Section 4.2.1 should be updated like so:

Printers that support DNS-SD MUST advertise the "_ipp._tcp" (generic IPP) service type and the "_print._sub._ipp._tcp" (IPP Everywhere™) service subtype over mDNS.

Printers that support DNS-SD and the "ipps" URI scheme [RFC7472] MUST advertise the "_ipps._tcp" (generic IPPS) service type and the "_print._sub._ipps._tcp" (IPP Everywhere™ Secure) service subtype over mDNS.

The domain portion of the service instance name MUST BE "local." for mDNS.

That way the reader will be clearly told that the second is a subtype of the first, which will hopefully reduce the need for a more lengthy explanation in the note. We could go so far as to reference RFC 6763 section 7.1.

2. ippfind should support the "_print._sub._ipp._tcp" syntax instead of or in addition to the "_ipp._tcp,_print" syntax for specifying the subtypes (as I suggested in a separate thread reporting a Linux bug) because the former is what is actually used on the wire and is used when you are using general DNS tools like dig.

> Email: [email-masked] <mailto:[email-masked]>
> 
> From: Michael Sweet <[email-masked] <mailto:[email-masked]>>
> To: Christopher Rizzo <[email-masked] <mailto:[email-masked]>>
> Cc: PWG Workgroup <[email-masked] <mailto:[email-masked]>>
>> On Mar 2, 2020, at 2:52 PM, Rizzo, Christopher <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Thanks Mike,
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Mon, 2 Mar 2020 20:46:22 -0500

[Changed subject to reflect what we are talking about...]

> On Mar 2, 2020, at 4:16 PM, Rizzo, Christopher <[email-masked]> wrote:
> 

I *really* don't want to add this to the beginning of the section.  First, that isn't the usual format we use in PWG documents, and second we should focus on what *this* specification requires, *not* what a vendor (Apple) required in their own "standard".

Let's keep working on this:

4.2 DNS Service Discovery (DNS-SD)

DNS Service Discovery (DNS-SD) [RFC6762] uses service (SRV) records and traditional unicast and multicast DNS (mDNS) [RFC6763] queries. Services are identified by a service instance name consisting of a service name, type or sub-type, and domain name. Discovery of Printers is collectively defined in the Bonjour Printing Specification version 1.2.1 [BONJOUR] and extended in this specification.

Printers that support DNS-SD MUST support mDNS and MAY support dynamic DNS updates via Dynamic Updates in the Domain Name System (DNS UPDATE) [RFC2136] and other mechanisms.

4.2.1 History of Printer Discovery with DNS-SD

The Bonjour Printing Specification defines a discovery mechanism for three different printing protocols which are mapped to DNS-SD service types: "_ipp._tcp" for any version of IPP, "_pdl-datastream._tcp" for direct socket communications, and "_printer._tcp" for the Line Printer Daemon (LPD) [RFC1179] protocol. For historical reasons, the primary ("flagship") protocol used for DNS-SD Printer discovery is LPD regardless of whether the Printer actually supports LPD.

DNS-SD makes use of service "sub-types" to identify specific types of services, and the Bonjour Printing Specification also defines a well-known "_printer._sub._http._tcp" service sub-type for a Printer's embedded web server to differentiate a Printer web page from a regular web page.

4.2.2 IPP Everywhere™ Service Sub-Types

In order for a Client to discover IPP Printers that conform to this specification (and not just [STD92]), the following DNS-SD service sub-types are defined:

"_print._sub._ipp._tcp" for IPP Everywhere™ Printers using the "ipp" URI scheme [RFC3510]; and
"_print._sub._ipps._tcp" for IPP Everywhere™ Printers using the "ipps" URI scheme [RFC7472].

4.2.3 Service (SRV) Instance Name

Printers that support DNS-SD MUST advertise the "_ipp._tcp" (generic IPP) and  "_print._sub._ipp._tcp" (IPP Everywhere™) services over mDNS. For example, a Printer named "Example Printer" would have the service instance names "Example Printer._ipp._tcp.local." and "Example Printer._print._sub._ipp._tcp.local.".

Printers that support DNS-SD and the "ipps" URI scheme [RFC7472] MUST advertise the "_ipps._tcp" (generic IPPS) and "_print._sub._ipps._tcp" (IPP Everywhere™ Secure) services over mDNS. For example, a Printer named "Example Printer" would have the service instance names "Example Printer._ipps._tcp.local." and "Example Printer._print._sub._ipps._tcp.local.".

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Wed, 4 Mar 2020 18:19:01 +0000

Just copied this message into the "IPP WG Last Call: IPP Everywhere v1.1 (Ends March 12, 2020)" thread, and will respond there.

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Mar 2, 2020, at 6:46 PM, Michael Sweet via ipp <[email-masked]> wrote:
> 
>> On Mar 2, 2020, at 4:16 PM, Rizzo, Christopher <[email-masked] <mailto:[email-masked]>> wrote:
>>