OK.
Christopher Rizzo
Xerox Corporation
GDG/Discovery/Advance Technology
26600 SW Parkway Ave.
Wilsonville, OR 97070-9251
Phone: (585) 314-6936
Email: Christopher.Rizzo at xerox.com
"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: "Kennedy, Smith (Wireless & IPP Standards)" <smith.kennedy at hp.com>
Date: Thursday, March 5, 2020 at 1:10 PM
To: Christopher Rizzo <Christopher.Rizzo at xerox.com>, Michael Sweet <msweet at msweet.org>
Cc: PWG Workgroup <ipp at pwg.org>
Subject: Re: [IPP] IPP WG Last Call: IPP Everywhere v1.1 (Ends March 12, 2020)
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 <ipp at pwg.org<mailto:ipp at pwg.org>> wrote:
[Changed subject to reflect what we are talking about...]
On Mar 2, 2020, at 4:16 PM, Rizzo, Christopher <Christopher.Rizzo at xerox.com<mailto:Christopher.Rizzo at xerox.com>> wrote:
How do you feel about adding the following (first sentence) to your section 4.2 proposal?
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.
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.
________________________
Michael Sweet
On Mar 2, 2020, at 6:07 PM, Rizzo, Christopher via ipp <ipp at pwg.org<mailto:ipp at pwg.org>> wrote:
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: Christopher.Rizzo at xerox.com<mailto:Christopher.Rizzo at xerox.com>
"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 <msweet at msweet.org<mailto:msweet at msweet.org>>
Date: Monday, March 2, 2020 at 12:51 PM
To: Christopher Rizzo <Christopher.Rizzo at xerox.com<mailto:Christopher.Rizzo at xerox.com>>
Cc: PWG Workgroup <ipp at pwg.org<mailto:ipp at pwg.org>>
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 <Christopher.Rizzo at xerox.com<mailto:Christopher.Rizzo at xerox.com>> 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: Christopher.Rizzo at xerox.com<mailto:Christopher.Rizzo at xerox.com>
"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 <ipp-bounces at pwg.org<mailto:ipp-bounces at pwg.org>> on behalf of PWG Workgroup <ipp at pwg.org<mailto:ipp at pwg.org>>
Reply-To: Michael Sweet <msweet at msweet.org<mailto:msweet at msweet.org>>
Date: Wednesday, February 19, 2020 at 12:32 PM
To: PWG Workgroup <ipp at pwg.org<mailto:ipp at pwg.org>>
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.docxhttps://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20200219.pdfhttps://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
ipp at pwg.org<mailto:ipp at pwg.org>
https://www.pwg.org/mailman/listinfo/ipp
_______________________________________________
ipp mailing list
ipp at pwg.org<mailto:ipp at pwg.org>
https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200305/1ca4bb68/attachment.html>