Ira,
I disagree with your comment (a) below; I believe the PWG email lists are the correct place to have open discussions on any aspect of PWG activities. I don't believe that individuals should be told what is constructive or non-constructive comments or subject matter for emails. Some email content may be out of scope but will be addressed by the PWG members. I hope that PWG continue to be open forum for print standards.
If other members of PWG disagree with me; then, I would like to who decides what is constructive/non-constructive comments?
Glen
> -----Original Message-----
> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Ira
> McDonald
> Sent: Wednesday, April 28, 2010 1:44 PM
> To: William Wagner; Ira McDonald
> Cc: 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/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.
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.