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
April2010)
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/blueroofmusichttp://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.