[IPP] Re: Initial draft of IPP Everywhere Project Charter (28February 2010)

[IPP] Re: Initial draft of IPP Everywhere Project Charter (28February 2010)

Ira McDonald blueroofmusic at gmail.com
Wed Mar 3 16:04:01 UTC 2010


Hi Pete,

I welcome any catchy marketing names, but...

It's an IPP project - it's not about any other printing
protocol or transport protocol.

Some other mapping in the future may address a Web
Services or other binding - but that's definitely out of
scope for years to come - because no such non-IPP
protocol is *already* deployed.

It's not about enhancing CUPS - CUPS already does
most everything needed (including the IPP extension
attributes and the multiple discovery protocols) - so the
Apple, UNIX, and Linux clients and servers that all run
CUPS by default already get much of the client benefit.

This proposed project is about mobile devices being
able to use the only widespread *currently deployed*
modern printing protocol - IPP.

The press release for PrintMe in 2002 describes it as
the "first complete Internet printing" solution.  The exact
phrase "Complete Internet Printing" gets 13,600 Google
hits this morning.

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 Wed, Mar 3, 2010 at 10:37 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> Ira,
>
> It seems to me that a statement like "every conceivable "Print Xxx" phrase has already been trademarked" does not carry much weight given all the permutations that are possible and the lack of hard evidence to back it up.  I disagree that "A fuzzy non-IPP name is not appropriate at this stage" since I consider "IPP Everywhere" fuzzy and does not represent the true nature of the project.  A name that managers would understand would be helpful to gain internal support for the effort.  Many participants in the PWG are doing PWG work on their own time with little or no corporate support.  Addressing the "marketing" aspects of this project, even if it is only for participating company use, should not be dismissed because it does not fit your view of the world.  I think the goals of IPP Everywhere are valuable to the industry.  I need a better justification than enhancing CUPS as a reason to pursue this project.
>
> I don't see why a title such as
>
> "Complete Internet Printing"
>
> would be inappropriate given that the PWG discussed this some time ago (see link below), it is descriptive of the goal, and it is not trademarked (at least my trademark search showed nothing).
>
> http://www.pwg.org/archives/ipp/2000/009929.html
>
>
> Peter Zehler
>
> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com
> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>
>
> -----Original Message-----
> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
> Sent: Wednesday, March 03, 2010 9:58 AM
> To: Zehler, Peter; Ira McDonald
> Cc: William Wagner; ipp at pwg.org
> Subject: Re: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28February 2010)
>
> Hi Pete,
>
> For now, this is an IPP extension - thus an IPP title.
>
> As I mentioned to Bill, every conceivable "Print Xxx" phrase
> has already been trademarked.
>
> A fuzzy non-IPP name is not appropriate at this stage.
>
> All - please send further comments to the second draft that
> I posted yesterday:
>
>  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100302.pdf
>
> 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 Wed, Mar 3, 2010 at 7:45 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
>> Ira,
>> One thing I see common to internal management and external customers is the glaze over their eyes when IPP is discussed.  They either want new technology or do not care about the protocol or binding.  What they do care about is what value does a new feature provide.  Improving the end user experience and simplifying network printing are of interest to internal management and external customers.  The name of the effort should better reflect the value it will bring to adopters.
>> Pete
>>
>> PS the only reason there is some management interest in IPP 2.x is that 2.anything is better than 1.anything.  Improved interoperability is the vector of differentiation between 1.1 and 2.x.  I don't know what level of support that will result in for our product teams.
>>
>>
>> Peter Zehler
>>
>> Xerox Research Center Webster
>> Email: Peter.Zehler at Xerox.com
>> Voice: (585) 265-8755
>> FAX: (585) 265-7441
>> US Mail: Peter Zehler
>> Xerox Corp.
>> 800 Phillips Rd.
>> M/S 128-25E
>> Webster NY, 14580-9701
>>
>> -----Original Message-----
>> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of William Wagner
>> Sent: Tuesday, March 02, 2010 1:34 PM
>> To: 'Ira McDonald'
>> Cc: ipp at pwg.org
>> Subject: RE: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28February 2010)
>>
>> Hi Ira,
>>
>> You can certainly reject my observation, but please do not reject it for
>> something I did not write. Nowhere do I mention bindings or protocol. I
>> refer to names and perceived alignment. My contention was that presenting
>> this as an extension of IPP rather than a new capability that uses existing
>> protocols and methods does not give it the best advantage. This opinion was
>> also voiced by someone else at the meeting, although it did not make it to
>> the minutes. I did not say nor do I necessarily believe that the project
>> should not be done within the IPP WG.
>>
>> I am pleased to hear that you are getting good response to IPP/2.0. I am
>> not, aside from some (maybe unjustified) relief from some that they need not
>> do anything further.
>>
>> Bill Wagner
>>
>> -----Original Message-----
>> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
>> Sent: Tuesday, March 02, 2010 12:56 PM
>> To: William Wagner; Ira McDonald
>> Cc: ipp at pwg.org
>> Subject: Re: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28
>> February 2010)
>>
>> Hi Bill,
>>
>> The discussion during the PWG face-to-face clearly stated that
>> the protocol for the first iteration of IPP Everywhere will be IPP
>> application protocol (RFC 2911) over the HTTP/1.1 binding
>> (RFC 2910).
>>
>> Non-IPP bindings are way out of scope at present.
>>
>> IPP Everywhere leverages the considerable momentum
>> behind IPP/2.0.
>>
>> I get frequent private notes from implementors at various
>> of printer vendors working on IPP/2.0 conformance.
>>
>> I'm opposed to renaming/widening the scope of this project.
>>
>> If the PWG Steering Committee decides that this project
>> should move elsewhere from the IPP WG, then we'll have
>> to consider that in the "Elsewhere" working group.
>>
>> In my professional experience, most cellphone and PDA
>> vendors are well aware of IPP, but mostly don't even know
>> that the PWG exists.
>>
>> So I don't like choosing a fuzzy name like "Print Everywhere"
>> (already trademarked, by the way, as is almost every other
>> conceivable "Print Xxx" name).
>>
>> Cheers,
>> - Ira
>>
>> PS - The text descriptions of almost all of the properties in
>> Printer MIB v1 was cut-and-paste verbatim from the ISO
>> 10175 MS Word source and then modified - that's why
>> they're so well aligned.
>>
>> My HP WJA colleagues last year amusingly discovered
>> legacy text in the prtInputType object that says "the Input
>> Class provides..." (and wondered where "Input Class"
>> was defined - it isn't).
>>
>> 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 Tue, Mar 2, 2010 at 12:09 PM, William Wagner <wamwagner at comcast.net>
>> wrote:
>>> Quite an exchange! I admit that I rather got lost after the third volley,
>>> but I see that all is resolved, at least between Ira and Mike.
>>>
>>> But I would like to bring up an observation made at the face to face,
>> which
>>> I thought was quite valid, although it might not seem so to CUPs-oriented
>>> people. Calling this proposed capability IPP is not an advantage either to
>>> gain users or implementers. Most users don't know what IPP is, don't use
>> it
>>> and don't care. It is my impression that many printer manufacturers have
>> not
>>> kept up with it, don't regard it highly, and want to move on.
>>>
>>> This is not to say that the proposed capability should not build on IPP,
>>> just as it may reasonably utilize other existing methods of device
>> location,
>>> PDLs, etc. Using what has already been worked out is positive and makes
>>> adoption more likely. And IPP is, of course, the basis for our MFD
>> semantic
>>> model. But tying it in too closely so as to make it just another of the
>>> flock of IPP spec's may not give it the attention that it deserves.
>>>
>>> The name suggestion at the Face-to-face was (I think) Print-Everywhere
>>> (which would need a conflict check) although I think Print-Anywhere is
>> more
>>> appropriate (if already a conflict). But the exact name is of less
>>> importance than presenting this as a new capability building on existing
>>> protocols and techniques, of which IPP (or perhaps the PWG print service
>>> semantic model) is one. That is, I believe, what it really is.
>>>
>>> This capability seems like a good thing to me, but I can hear
>>> "IPP-Everywhere" falling with a dull thud on the planning room floors.
>>>
>>> Bill Wagner
>>>
>>> PS: By the way, without questioning the influence of DPA or Tom Hastings'
>>> contribution to the Printer MIB, it certainly is not my recollection that
>>> the Printer MIB was "written by... cut-and-paste from ISO DPA".
>>>
>>> -----Original Message-----
>>> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Ira
>>> McDonald
>>> Sent: Tuesday, March 02, 2010 9:25 AM
>>> To: Michael Sweet; Ira McDonald
>>> Cc: ipp at pwg.org
>>> Subject: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28
>>> February 2010)
>>>
>>> Hi Mike,
>>>
>>> OK - I agree with you.
>>>
>>> We can do a single IPP Everywhere spec.  Especially,
>>> if we keep the new attribute content minimal.
>>>
>>> The apparently odd boundaries of Semantic Model work
>>> can't really be changed now - but it's no impediment to the
>>> IPP Everywhere work.
>>>
>>> If we do wind up needing technical changes in CUPS
>>> Raster or other document format, the SC is probably
>>> going to make us charter a separate spec, but that's a
>>> future issue.
>>>
>>> So, we'll drop the JXS2 work item and just have IPP
>>> Everywhere Requirements and IPP Everywhere spec.
>>>
>>> I'll review the rest of your comments and try to put out
>>> another draft later this week.
>>>
>>> Cheers,
>>> - Ira
>>>
>>> PS - The Printer MIB was in point of fact written by
>>> Tom Hastings by cut-and-paste from ISO DPA.
>>>
>>> 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 Mon, Mar 1, 2010 at 11:31 PM, Michael Sweet <msweet at apple.com> wrote:
>>>> On Mar 1, 2010, at 5:05 PM, Ira McDonald wrote:
>>>>> Hi,
>>>>>
>>>>> So you want a single boolean attribute "ipp-everywhere-supported"?
>>>>
>>>> Since we haven't even started down the road of defining the specifics of
>>> IPP Everywhere, I can't say whether I will want it.
>>>>
>>>>> We CANNOT do IPP/2.3 and say "oh that's just IPP Everywhere which
>>>>> is really a bit more than IPP/2.0".  Both RFC 2911 and PWG Process
>>>>> don't let us play fast-and-loose with minor version numbers - they're
>>>>> additive in a strict sense.
>>>>
>>>> I don't recall saying I want to do IPP/2.3.  I *did* say that I didn't
>>> think we needed a profile for each version of IPP/2.0, IPP/2.1, and
>> IPP/2.2,
>>> but instead we'd have one profile for IPP/2.0 that would essentially
>> create
>>> an IPP/2.05 - IPP/2.0 + what is needed to support basic printing from any
>>> client.  IPP/2.1 and IPP/2.2 printers obviously could support IPP
>> Everywhere
>>> as well, but that wouldn't require new versions or "profiles".
>>>>
>>>>> Yes - after much discussion 10 years ago, the charter of the PWG
>>>>> Semantic Model WG - no definitions ever - *is* cast in stone.
>>>>
>>>> I'm not going to argue with you, Ira. But I am concerned that we will end
>>> up writing another set of specs that doesn't actually accomplish what we
>>> want.
>>>>
>>>>> The PWG Multifunction Device WG has to write a spec for every new
>>>>> attribute they add to the SM.  So does IPP WG.  That's the point of
>>>>> the rigid scope of the PWG Semantic Model WG charter.
>>>>
>>>> In software development, this would be like writing an interface
>>> definition after you spend years developing the software.  Most
>>> organizations employ some kind of design process (often in parallel with
>>> prototyping and/or coding) so that the interfaces are well-defined before
>>> the software is finished, otherwise all you get is chaos.
>>>>
>>>> So to say that we're going to define all of these attributes and
>>> operations for a specific protocol first and *then* generalize it in the
>>> semantic model seems backwards and destined for failure or at least years
>> of
>>> delay to get what we have in IPP over to Web Services and other
>> mappings...
>>>>
>>>> Consider the Printer MIB - imagine if the model was done first (or in
>>> parallel) with the MIB. What sorts of changes could you expect?  Would the
>>> resulting MIB be easier to use?  Would the mappings to other protocols be
>>> better/easier to use?
>>>>
>>>>> The mapping of Printer MIB v2 into the XML schema was done 5 years
>>>>> ago as part of WIMS/1.0 and has always been included in the PWG SM
>>>>> XML schema - it's now in System.SystemCapabilities.Subunits.
>>>>>
>>>>> But an IPP mapping (in the current binary transport encoding) needs
>>>>> a spec.
>>>>>
>>>>> To become practical, do you favor a collection attribute or other
>> lighter
>>>>> weight (than a first-class IPP Device object) mapping of Printer MIB?
>>>>> A simple flat mapping to zillions of new IPP Printer attributes is not
>>>>> likely to be well-received by the other PWG members, I think.
>>>>
>>>> I think we need to cherry pick the most useful properties.  For CUPS we
>>> found that the printer alert and marker properties are the most important
>>> additions, although I did end up consolidating the prtMarkerSupplies and
>>> prtMarkerColorant properties into the marker-* attributes since the
>> mapping
>>> from supply to colorant is unnecessarily complicated.
>>>>
>>>> We already have a spec for the alerts (PSX), and the IPP Everywhere Wiki
>>> has a page describing the marker-* attributes:
>>>>
>>>>    http://pwg-wiki.wikispaces.com/CUPS+Marker+Attributes
>>>>
>>>> That would yield at most 10 new printer description attributes between
>> the
>>> two specs and would provide all of the information needed for a client to
>>> monitor the current status of a typical printer.
>>>>
>>>> As for collections, I'm not a big fan since every spec that employs them
>>> has implemented several layers of nested collections which are less
>> compact
>>> and harder to support in software and hardware.  For example, media-col
>> has
>>> a media-size member attribute collection with two member attributes -
>>> media-x-dimension and media-y-dimension.  After implementing media-col
>>> support, I am convinced that it would have been better for us to promote
>>> media-x/y-dimension to be member attributes of media-col directly. 1setOf
>>> collections are similarly problematic due to the added overhead of the
>>> member attributes for every instance, although in some cases the overhead
>>> may be worth it.
>>>>
>>>>> And the PWG SC has not favored mixing new attributes with profiles.
>>>>> If we do that, then I *think* we'll never extend IPP Everywhere - and I
>>>>> don't think we can put PDF or any other rich WYSIWYG document
>>>>> format in as a REQUIRED in the first IPP Everywhere - otherwise,
>>>>> what's the point?
>>>>
>>>> I don't think we will be able to make a "rich" format required in this
>>> decade if we want support for low-end printers (and I know *I* do).
>>>  However, we *can* expect that typical workgroup and enterprise printers
>>> will probably support that rich format in order to get the best engine
>>> performance (many already support PDF...)
>>>>
>>>>> I imagine IPP Everywhere/1.0 is raster/graphic only and IPP Eve/2.0
>>>>> adds a WYSIWYG document format or two.
>>>>
>>>> What's wrong with having a REQUIRED raster format and additional
>>> RECOMMENDED formats (PDF, etc.)?  I just don't see the need for multiple
>> IPP
>>> Everywhere versions at this time.
>>>>
>>>> ________________________________________________________________________
>>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>>
>>>>
>>>
>>> --
>>> 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.
>>>
>>> _______________________________________________
>>> 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.
>>
>> _______________________________________________
>> 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