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 <ipp at pwg.org> wrote:
>> 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.
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:
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) 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.
>> 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
>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org <mailto:ipp at pwg.org>
>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200303/1d27f391/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200303/1d27f391/attachment.sig>