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

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

Ira McDonald blueroofmusic at gmail.com
Wed Apr 28 20:43:45 UTC 2010


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

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.

Cheers,
- 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
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Wed, Apr 28, 2010 at 2:47 PM, William Wagner <wamwagner at comcast.net> wrote:
> 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 significant
> 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 address,
> 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 name
> 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 disregarded)
> 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 "IPP"
> 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 just
> 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 product.
> 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