[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
Thu Apr 29 18:25:45 UTC 2010


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




More information about the ipp mailing list