Subject: [IPP] IPP Everywhere and "The Great Compromise"

From: Michael Sweet <[email-masked]>
Date: Mon, 20 Aug 2012 21:42:02 -0400

All,

We discussed the PWG Last Call comments received thus far at today's IPP WG conference call.  Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG for document formats.  After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments:

1. Discovery:

   a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)
   b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols)

2. Document Formats:

   a. Printers MUST support both JPEG and PWG Raster (no change)
   b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both)

Please comment on the proposed changes.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

---

From: "William A Wagner" <[email-masked]>
Date: Tue, 21 Aug 2012 00:16:22 -0400

I think this is a practical and reasonable compromise. From at least my
perspective, this does not put an unreasonable additional burden on printers
while  making potentially easier for clients to achieve and claim
compliance.

Bill Wagner

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
Sweet
Sent: Monday, August 20, 2012 9:42 PM
To: [email-masked]
Subject: [IPP] IPP Everywhere and "The Great Compromise"

All,

We discussed the PWG Last Call comments received thus far at today's IPP WG
conference call.  Two of the comments concerned the client requirements to
support DNS-SD for discovery and both PWG Raster and JPEG for document
formats.  After over an hour of spirited debate, the following "great
compromise" was proposed to resolve the last call comments:

1. Discovery:

   b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients
can choose amongst the two required protocols)

2. Document Formats:

   b. Clients MUST support at least one of JPEG and PWG Raster (relaxes
conformance - previously a Client had to support both)

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

---

From: Randy Turner <[email-masked]>
Date: Mon, 20 Aug 2012 21:39:10 -0700

i think I understand the compromise, although I would have worded 1b and 2b a little different

Clients MUST support either DNS-SD or WS-Discovery….

It's just a different use of a contraction

"…one of DNS-SD AND WS-Discovery"  seemed to use an AND contraction which implied both - someone might inadvertently parse this in a way we didn't expect….although I got the gist of the compromise.

R.

On Aug 20, 2012, at 9:16 PM, William A Wagner wrote:

> I think this is a practical and reasonable compromise. From at least my perspective, this does not put an unreasonable additional burden on printers while  making potentially easier for clients to achieve and claim compliance.
> Bill Wagner
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
> believed to be clean. _______________________________________________
> ipp mailing list
> [email-masked]

---

From: Daniel Dressler <[email-masked]>
Date: Mon, 20 Aug 2012 22:55:30 -0600

As a random bystander I can confirm that "one of X and Y" sounds a bit odd.
Although the context does make it clear.

How about "Clients MUST support either DNS-SD or WS-Discovery or both" to
eliminate any final confusion with English's exclusive or.

While I'm being usless let me also suggest another wording "The
intersection between the set of client's supported protocols and the set
{DNS-SD, WS-Discovery} must not be the empty set."

Daniel

2012/8/20 Randy Turner <[email-masked]>

> "…one of DNS-SD AND WS-Discovery"  seemed to use an AND contraction which
> implied both - someone might inadvertently parse this in a way we didn't
> expect….although I got the gist of the compromise.
>
> R.
>
> perspective, this does not put an unreasonable additional burden on
> printers while  making potentially easier for clients to achieve and claim
> compliance.****
> Bill Wagner****
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Michael
> Sweet
> *Sent:* Monday, August 20, 2012 9:42 PM
> *To:* [email-masked]
> *Subject:* [IPP] IPP Everywhere and "The Great Compromise"****
> ** **
> All,****
> ** **
> We discussed the PWG Last Call comments received thus far at today's IPP
> WG conference call.  Two of the comments concerned the client requirements
> to support DNS-SD for discovery and both PWG Raster and JPEG for document
> compromise" was proposed to resolve the last call comments:****
> ** **
> 1. Discovery:****
> ** **
>    a. Printers MUST support both DNS-SD and WS-Discovery (adds
> WS-Discovery)****
>    b. Clients MUST support at least one of DNS-SD and WS-Discovery
> (Clients can choose amongst the two required protocols)****
> ** **
> 2. Document Formats:****
> ** **
>    a. Printers MUST support both JPEG and PWG Raster (no change)****
> conformance - previously a Client had to support both)****
> ** **
> Please comment on the proposed changes.****
> ** **
> Michael Sweet, Senior Printing System Engineer, PWG Chair****
> ** **
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.****
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 21 Aug 2012 07:14:07 -0400

Randy and Daniel,

I agree my wording for the client requirements still needs some polish - toss it up to writing it up late at night... How about:

    Clients MUST support DNS-SD and/or WS-Discovery.

(the math geek in me likes the intersection version below... :)

Sent from my iPad

On 2012-08-21, at 12:55 AM, Daniel Dressler <[email-masked]> wrote:

> As a random bystander I can confirm that "one of X and Y" sounds a bit odd. Although the context does make it clear.
> 
> How about "Clients MUST support either DNS-SD or WS-Discovery or both" to eliminate any final confusion with English's exclusive or.
> 
> While I'm being usless let me also suggest another wording "The intersection between the set of client's supported protocols and the set {DNS-SD, WS-Discovery} must not be the empty set."
> 
> Daniel
>

---

From: "Petrie, Glen" <[email-masked]>
Date: Tue, 21 Aug 2012 08:13:13 -0700

Mike (all)

The change below pushes the burden to the printer (at an increased cost
to the printer) while the Client, a software entity, has less burden.
What is wrong with 

1. Discovery:

   a. Clients MUST support DNS-SD and WS-Discovery 

   b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED
to support both.

2. Document Formats:

a.       Clients MUST support both JPEG and PWG Raster 

b.      Printers MUST support either JPEG or PWG Raster and RECOMMENDED
to support both.

This change to the printer requirements could mean a faster time to
market since printers are already support one of the discoveries and
documents formats but may not support both discoveries and document
formats. 

As was discussed in the meeting, if either discovery or document format
change in the future, the backward compatibility burden would have to be
on the Client to deal with legacy printers.   There 'may' be an issue of
Client legacy but I content that is still easier to update Clients
rather than printer firmware.   In the event of a Cloud Print Service or
a Print Manager; then, I would assume the "RECOMMEDED" support of both
would be implemented.  

Glen

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Sweet
Sent: Monday, August 20, 2012 6:42 PM
To: [email-masked]
Subject: [IPP] IPP Everywhere and "The Great Compromise"

All,

We discussed the PWG Last Call comments received thus far at today's IPP
WG conference call.  Two of the comments concerned the client
requirements to support DNS-SD for discovery and both PWG Raster and
JPEG for document formats.  After over an hour of spirited debate, the
following "great compromise" was proposed to resolve the last call
comments:

1. Discovery:

WS-Discovery)

   b. Clients MUST support at least one of DNS-SD and WS-Discovery
(Clients can choose amongst the two required protocols)

2. Document Formats:

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean.

---

From: Rich Gray <[email-masked]>
Date: Tue, 21 Aug 2012 11:28:13 -0400

"Printers MUST support X or Y and SHOULD support both."

- Rich

---

From: Ira McDonald <[email-masked]>
Date: Tue, 21 Aug 2012 11:42:35 -0400

Hi Glen,

I understand why you want to lower Printer implementation burden,
but your proposal defeats the essence of the "Great Compromise",
which is focused on support of IPP Everywhere by OS vendors (to
achieve what the user thinks is "driver-less printing").

As you say, Printer firmware doesn't change often - but if it once
supports the two document formats and two discovery protocols it
will reliably interoperate w/ all IPP Everywhere Clients in the future.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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
Temporary Cabin *** 2012 only *** 906-494-2523

On Tue, Aug 21, 2012 at 11:13 AM, Petrie, Glen
<[email-masked]>wrote:

>  Mike (all)****
>
> ** **
>
> The change below pushes the burden to the printer (at an increased cost to
> the printer) while the Client, a software entity, has less burden.  What is
> wrong with ****
>
> ** **
>
> 1. Discovery:****
>
> ** **
>
>    a. Clients MUST support DNS-SD and WS-Discovery ****
>
> to support both.****
> **a.       **Clients MUST support both JPEG and PWG Raster ****
>
> **b.      **Printers MUST support either JPEG or PWG Raster and
> RECOMMENDED to support both.****
>
> ** **
>
> This change to the printer requirements could mean a faster time to market
> since printers are already support one of the discoveries and documents
> formats but may not support both discoveries and document formats. ****
>
> ** **
>
> change in the future, the backward compatibility burden would have to be on
> the Client to deal with legacy printers.   There 'may' be an issue of
> Client legacy but I content that is still easier to update Clients rather
> than printer firmware.   In the event of a Cloud Print Service or a Print
> Manager; then, I would assume the "RECOMMEDED" support of both would be
> implemented.  ****
>
> ** **
>
> Glen****
>
> ** **
>
> ** **
>  ------------------------------
>
> *Sent:* Monday, August 20, 2012 6:42 PM
>
> *To:* [email-masked]
> believed to be clean. ****
>
> --

---

From: "Paul Tykodi" <[email-masked]>
Date: Tue, 21 Aug 2012 11:48:41 -0400

Hi Glen,

Do you think accepting your proposal for the device (i.e. printer) and
making it available to both the client and the printer could work?

It means that not all IPP Everywhere conforming clients and printers would
necessarily be interoperable and it would support Justin's position that in
this specific area market need should drive the discovery and the document
formats a particular vendor found their customers reported were must haves.

Just a thought .

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked]
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of Petrie,
Glen
Sent: Tuesday, August 21, 2012 11:13 AM
To: Michael Sweet; [email-masked]
Subject: RE: [IPP] IPP Everywhere and "The Great Compromise"

Mike (all)

wrong with 

1. Discovery:

   b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED to
support both.

2. Document Formats:

b.      Printers MUST support either JPEG or PWG Raster and RECOMMENDED to
support both.

This change to the printer requirements could mean a faster time to market
since printers are already support one of the discoveries and documents
formats but may not support both discoveries and document formats. 

As was discussed in the meeting, if either discovery or document format
change in the future, the backward compatibility burden would have to be on
the Client to deal with legacy printers.   There 'may' be an issue of Client
legacy but I content that is still easier to update Clients rather than
printer firmware.   In the event of a Cloud Print Service or a Print
Manager; then, I would assume the "RECOMMEDED" support of both would be
implemented.  

Glen

  _____  

All,

1. Discovery:

2. Document Formats:

---

From: Michael Sweet <[email-masked]>
Date: Tue, 21 Aug 2012 11:51:53 -0400

Glen,

Comments inline...

On Aug 21, 2012, at 11:13 AM, "Petrie, Glen" <[email-masked]> wrote:
> Mike (all)
>  
> The change below pushes the burden to the printer (at an increased cost to the printer) while the Client, a software entity, has less burden.  What is wrong with
>  
> 1. Discovery:
>  
>    b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED to support both.

Pretty much all printers already support DNS-SD and WS-Discovery, which is why we opted to put the "burden" on the printers (since they already carry that burden).

> b.      Printers MUST support either JPEG or PWG Raster and RECOMMENDED to support both.

I personally would rather just see a single format (PWG Raster) be required since it is the only simple raster format that works for text, graphics, and photos.  However, Justin objected to PWG Raster because Microsoft currently does not support it.  Thus the "great compromise".

Many printers already support JPEG via dedicated hardware, and PWG Raster uses the same compression algorithm that is used by most vendor PDLs, so again I am not sure we are really increasing the burden for printers and the printer requirement to support both has been in the spec for over a year now...

> This change to the printer requirements could mean a faster time to market since printers are already support one of the discoveries and documents formats but may not support both discoveries and document formats.

I would argue that document formats and discovery protocols are not the hard parts - doing a GOOD implementation of IPP is much more difficult, as the interoperability reports can attest.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 23 Aug 2012 10:02:03 -0400

After letting this sink in over the past couple days, I have to pull my support for allowing a client to only support JPEG.  Aside from the quality issues, JPEG does not support multiple page content and so does not satisfy the requirements set forth in the IPP Everywhere spec and current charter.  That leaves us with:

1. Discovery:
   a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)
   b. Clients MUST support DNS-SD and/or WS-Discovery (Clients can choose amongst the two required protocols)

I humbly suggest that the <1000 lines of code (CUPS' implementation is 830 lines for both read and write) needed to generate PWG Raster is not an undue burden on clients to implement support for and conform to IPP Everywhere.

Please comment, and we will review this at the next IPP conference call on September 10th.

---

From: "Murdock, Joe" <[email-masked]>
Date: Thu, 23 Aug 2012 22:12:39 +0000

I agree with the proposed changes device supports DNS-SD and WS-Discovery and JPEG and PNG-Raster.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Thursday, August 23, 2012 7:02 AM
To: [email-masked]
Subject: Re: [IPP] IPP Everywhere and "The Great Compromise"

1. Discovery:

On Aug 20, 2012, at 9:42 PM, Michael Sweet <[email-masked]<mailto:[email-masked]>> wrote:

All,

1. Discovery:

2. Document Formats:

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
_______________________________________________
ipp mailing list
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

---

From: [email-masked]
Date: Thu, 23 Aug 2012 18:24:09 -0400

Same here - device supports DNS-SD and WS-Discovery and JPEG and 
PNG-Raster.

-Nancy
---------------------------------------------------
Nancy Chen
Principal Engineer
Solutions and Technology
Services & Solution Business - US
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: +1 (856) 222-7006

"Murdock, Joe" <[email-masked]> 
Sent by: [email-masked]
08/23/2012 06:12 PM

To
"[email-masked]" <[email-masked]>, 
cc

Subject
RE: [IPP] IPP Everywhere and "The Great Compromise"

I agree with the proposed changes device supports DNS-SD and WS-Discovery 
and JPEG and PNG-Raster.

After letting this sink in over the past couple days, I have to pull my 
support for allowing a client to only support JPEG.  Aside from the 
quality issues, JPEG does not support multiple page content and so does 
not satisfy the requirements set forth in the IPP Everywhere spec and 
current charter.  That leaves us with:

1. Discovery:
a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)
b. Clients MUST support DNS-SD and/or WS-Discovery (Clients can choose 
amongst the two required protocols)

I humbly suggest that the <1000 lines of code (CUPS' implementation is 830 
lines for both read and write) needed to generate PWG Raster is not an 
undue burden on clients to implement support for and conform to IPP 
Everywhere.

Please comment, and we will review this at the next IPP conference call on 
September 10th.

On Aug 20, 2012, at 9:42 PM, Michael Sweet <[email-masked]<
mailto:[email-masked]>> wrote:

All,

1. Discovery:

2. Document Formats: