Hi all,
Sorry for various confusion.
Bill - I meant that criticizing IPP transport because Microsoft
doesn't make it easy (they (*do* support IPP in all Windows 7
distributions) isn't constructive. Though some printers (many
less than IPP) do support WS-Print, a PWG standard (that
also works in the Apple, Linux, UNIX, and mainframe markets)
shouldn't specify WS-Print as a required transport for IPP
Everywhere.
Future open standard Web Services printing protocols are
just that - future - not applicable to the IPP Everywhere topic.
Glen - one or a few REQUIRED PDLs have always been an IPP
Everywhere requirement, from the start.
George - adding the requirement that common PDLs be emitted
by a so-called "driverless client" (actually a client with a standard
driver that is not vendor-built) is too restrictive and could (as Paul
noted) delay the adoption of IPP Everywhere by many vendors.
In a future IPP Everywhere requirements spec, iit might be a
reasonable goal, but it does not belong in this Charter.
Cheers,
- Ira
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 Thu, Apr 29, 2010 at 10:38 AM, Petrie, Glen
<glen.petrie at eitc.epson.com> wrote:
> 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.