Subject: Re: [IPP] IPP WG Last Call: IPP Everywhere v1.1 (Ends March 12, 2020)

From: "Rizzo, Christopher via ipp" <[email-masked]>
Date: Tue, 3 Mar 2020 01:07:17 +0000

Kennedy - My bad.  Moving this thread here.  Of course, not sure if I should start with your last note on this thread, or a new one.  Here I've started a new one from original Last Call note.

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
GDG/Discovery/Advance Technology
26600 SW Parkway Ave.
Wilsonville, OR 97070-9251
Phone: (585) 314-6936
Email: [email-masked]<mailto:[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: Michael Sweet <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 2, 2020 at 12:51 PM
To: Christopher Rizzo <[email-masked]<mailto:[email-masked]>>
Cc: PWG Workgroup <[email-masked]<mailto:[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 2:52 PM, Rizzo, Christopher <[email-masked]<mailto:[email-masked]>> wrote:

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?

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

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.

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

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: Wednesday, February 19, 2020 at 12:32 PM
To: PWG Workgroup <[email-masked]>
Subject: [IPP] IPP WG Last Call: IPP Everywhere v1.1 (Ends March 12, 2020)

All,

This message starts the IPP Workgroup Last Call of the IPP Everywhere v1.1 specification, available at:

                https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219.docx
                https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219.pdf
                https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219-rev.pdf

This last call ends on March 12, 2020 at 10pm PST.  To respond, simply "reply all" to this message.

________________________
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: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Thu, 5 Mar 2020 21:09:30 +0000

Hi Chris,

OK, moving Mike's latest comments over as well. I'll respond to that here in this thread and close the other one off.

Smith

> On Mar 2, 2020, at 6:46 PM, Michael Sweet via ipp <[email-masked]> wrote:
> 
> [Changed subject to reflect what we are talking about...]
> 
> 
>> On Mar 2, 2020, at 4:16 PM, Rizzo, Christopher <[email-masked] <mailto:[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.

The RFC 6763 section 4.1 says this:

Service Instance Name = <Instance> . <Service> . <Domain>

Later in RFC 6763 they expand Instance to be Instance Name and Service to be Service Name, which caused confusion. They really ought to have used this:

Service Instance Name = <InstanceName> . <ServiceType> . <Domain>

I suggest rephrasing it to say: "Services are identified by a service instance name consisting of an instance name, a service type name with optional subtype, 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.

I'm sorry but I really don't agree with having this new section 4.2.1. If we want to avoid future confusion between _print._sub._ipp._tcp and  _printer._tcp and _printer._sub._http._tcp, I might suggest we drop all references to the Bonjour Printing spec and focus solely on what IPP Everywhere uses for its DNS-SD advertisements. Other than the TXT portions, what are we getting by referencing Bonjour Printing at this point? Some of the normative statements above are redundant with the requirements in Bonjour Printing 1.2.1.

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

I would suggest wording it like so: "In order for a Client to discover IPP Printers that conform to this specification (and not just [STD92]), this specification defines the following DNS-SD service subtypes:"

The word "subtype" shouldn't be hyphenated.

> 
> 
> 4.2.3 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.
> 
> The domain portion of the service instance name MUST BE "local." for mDNS.
> 
> 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.".

No objections on this.

> On Mar 2, 2020, at 6:07 PM, Rizzo, Christopher via ipp <[email-masked]> wrote:
> 
> 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: [email-masked] <mailto:[email-masked]>
> 
>                 https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219.docx <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219.docx>
>                 https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219.pdf <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219.pdf>
>                 https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219-rev.pdf <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219-rev.pdf>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> 
> [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: Thu, 5 Mar 2020 16:57:58 -0500

Smith,

I generally agree with most of your comments.  See below...

> On Mar 5, 2020, at 4:09 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
>> ...

The flagship naming stuff is, unfortunately, still relevant.  So even if your printer doesn't support LPD you need to register "printername._printer._tcp.local." to deal with name collisions properly...

________________________
Michael Sweet

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 12 Mar 2020 18:39:16 -0400

Smith,

OK, I've been thinking more about this and RFC 6763 does talk about flagship naming, so perhaps the thing to do is just list _printer._tcp as one of the required service types and either drop the references to the Bonjour Printing Specification entirely (it is still referenced by RFC 6763 so implementors can get to it indirectly at least...) or make it informational and just make _printer._tcp normative (Safari doesn't even support the Bonjour menu anymore...)

How about the following?

DNS Service Discovery (DNS-SD) [RFC6763] uses service (SRV) records and traditional unicast and multicast DNS (mDNS) [RFC6762] queries. Services are identified by a service instance name consisting of an instance name, a service type or subtype name, and a domain name. Discovery of Printers involves multiple service types and subtypes as described in the following sections.

4.2.1 IPP Everywhere™ Service Sub-Types

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

4.2.2 Service (SRV) Instance Name

Printers that support DNS-SD MUST advertise the "_printer._tcp" (LPD) service over mDNS in order to conform to the Flagship Naming requirements as defined in [RFC6763]. For example, a Printer named "Example Printer" would advertise the service instance name "Example Printer._printer._tcp.local." with a port number of 0 to indicate that the LPD protocol is not actually supported.

Printers that support DNS-SD MUST also advertise the "_ipp._tcp" (generic IPP) and  "_print._sub._ipp._tcp" (IPP Everywhere™) services over mDNS. For example, a Printer named "Example Printer" would advertise 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 advertise the service instance names "Example Printer._ipps._tcp.local." and "Example Printer._print._sub._ipps._tcp.local.".

> On Mar 5, 2020, at 4:57 PM, Michael Sweet via ipp <[email-masked]> wrote:
> 
> Smith,
> 

________________________
Michael Sweet

---

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

Sorry for not replying sooner. I’m pretty sure you have made these changes in the latest draft already. Just closing the loop.

On Mar 12, 2020, at 4:39 PM, Michael Sweet <[email-masked]> wrote:

 Smith,

OK, I've been thinking more about this and RFC 6763 does talk about flagship naming, so perhaps the thing to do is just list _printer._tcp as one of the required service types and either drop the references to the Bonjour Printing Specification entirely (it is still referenced by RFC 6763 so implementors can get to it indirectly at least...) or make it informational and just make _printer._tcp normative

Either is fine with me.

(Safari doesn't even support the Bonjour menu anymore...)

(Yeah I’m still bummed out about that.)

How about the following?

  *   "_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].

That looks good!

On Mar 5, 2020, at 4:57 PM, Michael Sweet via ipp <[email-masked]<mailto:[email-masked]>> wrote:

Smith,

On Mar 5, 2020, at 4:09 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]<mailto:[email-masked]>> wrote:
...
4.2.1 History of Printer Discovery with DNS-SD

________________________
Michael Sweet

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

________________________
Michael Sweet