[IPP] Stable draft of IPP Everywhere Project Charter (17 April2010)

[IPP] Stable draft of IPP Everywhere Project Charter (17 April2010)

William Wagner wamwagner at comcast.net
Wed Apr 28 21:37:33 UTC 2010

Hi Ira,

I am sorry that you think I was "beating up" on IPP. I have been involved
with IPP from the start (over 10 years ago), have done my part in getting it
deployed, and so have a certain affinity for it. But some observations have
been made, and they have some validity and bearing on this effort, but they
have not gotten much exposure. I do not agree that ignoring these things is
preferable and dealing with them is "not constructive".

Your idea of putting the charter up for PWG "Last Call" is good. I think the
intent was to get the sense of the membership about the approach specified
in the charter. The charter most certainly is for developing an addition to
IPP. I do not know if the membership agrees that "any new transport [other
than used by IPP] is a real-world loser" (most networked printers I know
also support WSD), but it would be to everyone's advantage to find out.

Bill Wagner

-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com] 
Sent: Wednesday, April 28, 2010 4:44 PM
To: William Wagner; Ira McDonald
Cc: Michael Sweet; ipp at pwg.org; George Liu
Subject: Re: [IPP] Stable draft of IPP Everywhere Project Charter (17

Hi Bill:

Comments on your points:

(a) I fail entirely to see the merit in beating up "IPP" on the
      IPP WG mailing list - this is not constructive.

(b) IPP, like WebDAV and a dozen other IETF application
      protocols in the last 10 years, uses HTTP over a unique
      IANA-registered IP port number (not 80).  Folks in the
      REST camp would take particular issue with "transition",
      as though SOAP was the only possible Web Services

Mike - we should abandon this PWG Formal Vote idea and
instead put this Charter up for PWG Last Call - PWG Process
doesn't allow non-editorial changes after a PWG Formal Vote.

This particular charter is *not* for Everywhere over some yet
to be determined transport.  It's for IPP Everywhere - and that's
the only reasonable binding - because existing deployed printers
already support IPP - any new transport is a real-world loser for
the near-term mobile environment.

- Ira

This particular proposal
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
mailto:blueroofmusic at gmail.com
  579 Park Place  Saline, MI  48176
  PO Box 221  Grand Marais, MI 49839

On Wed, Apr 28, 2010 at 2:47 PM, William Wagner <wamwagner at comcast.net>
> I would like to clarify that "my" suggestion that Ira cites was echoed by
> others, primarily in response to (my understanding of) Mike's indication
> that he wanted to proceed with IPP-Everywhere only if there was
> support from the industry (which is an excellent criterion). Putting it up
> for vote both acts to engage more of the membership and  "requires" that
> negative responses include an explanation of why it is rejected. There
> several generally acknowledged needs that IPP-Everywhere intends to
> but also several different ideas about how they are best addressed.
> Looking at the Mike's IPP-Everywhere Wiki page
> (http://pwg-wiki.wikispaces.com/IPP+Everywhere), the main points are a
> standard document format (or two) which should address much of the driver
> issue, and a printer discovery method. These are critical issues, and are
> also critical aspects of the Google CloudPrint initiative. But both by
> and by assumption, the solution is linked by many to IPP. And the Charter
> makes this link very specific and very tight.
> Although I think that there is little question but that IPP represents the
> refinement of printing semantics and that these semantics should be
> preserved in the next manifestation of printing interface, I do think that
> there are differing views on whether this next manifestation should be an
> add-on to IPP or a step beyond IPP. In favor of the former, the fact that
> IPP is implemented in most networked printers suggests that an
> IPP-Everywhere that is an incremental addition to IPP should be well
> accepted by the industry as "good bang for the buck". But there is another
> viewpoint that might maintain:
>    a. IPP has not been all that successful in terms of use, is not
> supported by current Windows OS's, and is regarded (or perhaps
> by some business sorts in the industry as a wasted effort. There was even
> the suggestion that there is a negative perception of IPP and that the
> term be replaced in IPP-Everywhere (although no agreement on replaced with
> what.)
>    b. IPP uses a "transition" transport of HTTP over IP, which seemed
> reasonable ten years ago, but is something of an anachronism in a world
> going with a "web services" approach. And one would expect that the
> Discovery, Eventing & Notification aspects that IPP-Everywhere needs will
> come out of the Web Services world. Perhaps, when Google indicates that
> IPP-Everywhere addresses much of what is needed in CloudPrint but has some
> serious things missing, and when they ask for a CloudPrint use case using
> IPP-Everywhere, they may be thinking of issues in this area.
> So in considering the IPP-Everywhere charter, members must consider not
> whether IPP-Everywhere is a good and needed capability, I don't think that
> there is much question about that, but whether the specific approach
> specified in the charter is the optimum way to produce the optimum
> And hopefully members will comment on this one way or the other since the
> comments and actual participation in the specification and development of
> IPP-Everywhere will be much more significant than an up or down vote.
> Bill Wagner

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

More information about the ipp mailing list