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

From: Michael Sweet <[email-masked]>
Date: Mon, 1 Mar 2010 14:40:24 -0800

On Feb 28, 2010, at 3:57 PM, Ira McDonald wrote:
> Hi,
> 
> I've just posted an Initial working draft of IPP Everywhere Project Charter
> for review tomorrow during our IPP WG teleconference at:
> 
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100228.pdf / doc
> - with line numbers and all proposed milestone dates
> 
> The content is derived from Mike's IPP Everywhere BOF slides at our
> recent PWG face-to-face meeting on 10 February 2010.

Since we didn't get a chance to go over this in today's conference call, my comments:

1. Line 39, IPP Everywhere Profiles - I don't think we want to define multiple conformance levels; instead, we want to define a single conformance level (basically somewhere between 2.0 and 2.1 - call it 2.05 :) with the bits that are necessary to support printing from any client.

2. Lines 36 and 39 - since we are only defining a single conformance level, maybe we don't want two separate standards documents (extensions + profile) but instead a single combined document?

3. Line 45, OSS-2 - we have already identified one potential new format (raster), and we may also find that we want to define a proper subset of PDF with just the parts needed for printing, so we shouldn't rule them out as IPP Everywhere work (although it may ultimately make more sense to push that work in other forums, e.g. IETF RFCs or ISO standards)

4. Line 48, OSS-4 - if we do one spec instead of two (see #2 above), then this will need to be removed.

5. Line 58, OBJ-5 - the optimization is not just for the clients.

6. Line 59, OBJ-6 - Pete had mentioned defining a Semantic Model document that could be used as the basis of the IPP transport mapping as well as future transports; it seems backwards to define the semantic model from the transport mapping...

7. Lines 68, 69, 70 - Push back 1 quarter since this puts all of the IPP Everywhere work on top of the final IPP/2.0 and JPS2 work; better to make sure we have those right (and maybe even some good testing completed) than to have to juggle it all at once to meet the deadline.

________________________________________________________________________
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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Mon, 1 Mar 2010 18:01:55 -0500

Hi Mike,

Thanks for all these comments - I just skimmed them.

But, if we want (and we had concensus) to get the "low
hanging fruit first" in IPP Everywhere, then we certainly
want 2 or more conformance levels eventually - therefore,
we need to start that way.

And while we could roll these together, I suspect that
the correct solution to Printer MIB visibility is the original
proposal in late 1990's - to whit, a first-class Device
object - way too much different content to bury in one
IPP Job spec that's partly profiles of discovery and
document format requirements.

IPP/2.0 does NOT define any attributes or operations.

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:[email-masked]
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Sun, Feb 28, 2010 at 6:57 PM, Ira McDonald <[email-masked]> wrote:
> Cheers,
> - Ira (IPP co-editor)
> 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:[email-masked]
> winter:
>  579 Park Place  Saline, MI  48176
>  734-944-0094
> summer:
>  PO Box 221  Grand Marais, MI 49839
>  906-494-2434
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 1 Mar 2010 15:19:27 -0800

> we need to start that way.

I don't think we've been talking about multiple conformance levels, but rather regular updates (as needed) for a single conformance level that reflects the current state of the art.

> document format requirements.

A separate semantic model document could handle defining the device object, and then the IPP Everywhere spec can reference it and say "this is how we map it to IPP"...

> IPP/2.0 does NOT define any attributes or operations.

Right, but this is IPP Everywhere, not IPP/2.0.

---

From: Ira McDonald <[email-masked]>
Date: Mon, 1 Mar 2010 19:19:47 -0500

Hi Mike,

My replies inline below.

Cheers,
- Ira

> I don't think we've been talking about multiple conformance levels, but rather regular updates (as needed) for a single conformance level that reflects the current state of the art.

<ira>
My point was that, in the PWG Process (and IETF), NO new content can
EVER be added to an existing conformance profile in the same level.

If second edition of IPP Everywhere adds PDF (for example), then that
MUST be a new IPP Everywhere conformance level.

I think an "ipp-everywhere-versions-supported" Printer attribute needs
to be orthogonal to and independent of "ipp-versions-supported".
</ira>

> A separate semantic model document could handle defining the device object, and then the IPP Everywhere spec can reference it and say "this is how we map it to IPP"...

<ira>
Nope - in the PWG Semantic Model WG charter, they can ONLY
do XML mappings from other existing IETF or PWG specs that
define the objects and/or properties/attributes.

So an IPP spec is definitely required for a Device object,
unless we use opaque stuff like some kludge format for ASN.1
names in a new operation attribute for Get-Printer-Attributes
(which is yucky and likely not to be interoperable).
</ira>

> Right, but this is IPP Everywhere, not IPP/2.0.

<ira>
Nope - combining these documents won't work - there will
almost undoubtedly ultimately need to be more than one
well-focused IPP extension spec (for Job, Printer, Device,
etc. extensions) - if we roll all these together with this IPP
Everywhere profile of OTHER non-IPP protocols and PDLs,
we'll never manage to publish a PWG Candidate Standard,
IMHO.

Catchall specs have caused us trouble before (including
in the IPP WG efforts).
</ira>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 1 Mar 2010 16:47:44 -0800

> EVER be added to an existing conformance profile in the same level.

Right now I'm looking at the work in front of us, and not the work we (may) do in N years.

Put in another context, there is 10 years between IPP/1.1 and IPP/2.0.  *If* the printing landscape changes sufficiently I think we'll be looking at IPP/3.0 and not just a new IPP Everywhere "profile".

> MUST be a new IPP Everywhere conformance level.

or a new IPP conformance level.  I see no reason to keep IPP Everywhere separate from the main specs if it is successful enough to warrant a second (or third, etc.) pass.

> to be orthogonal to and independent of "ipp-versions-supported".

Testing for a particular feature using a version number is, in general, a bad idea.

> define the objects and/or properties/attributes.

Then let's change the charter.  It is not chiseled in stone, right?

Moreover, at least some of this stuff is coming from the existing Printer MIB, and so already exists to do mappings that we can then use for IPP.

> Catchall specs have caused us trouble before (including

I would suggest that IPP Everywhere is, by definition, a catch-all effort - if we only get half-assed implementations of bits and pieces then we have failed!

I'm not here to write standards for the fun of it, I want to develop something genuinely useful and hopefully ubiquitous...

---

From: Ira McDonald <[email-masked]>
Date: Mon, 1 Mar 2010 20:05:52 -0500

Hi,

So you want a single boolean attribute "ipp-everywhere-supported"?

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.

Yes - after much discussion 10 years ago, the charter of the PWG
Semantic Model WG - no definitions ever - *is* cast in stone.

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.

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.

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 imagine IPP Everywhere/1.0 is raster/graphic only and IPP Eve/2.0
adds a WYSIWYG document format or two.

We need to think about this stuff now - because the SC won't let us
just wander outside our charter - bad stuff *has* happened in the
past when we went down that route.

Cheers,
- Ira

On Mon, Mar 1, 2010 at 7:47 PM, Michael Sweet <[email-masked]> wrote:
> I don't think we've been talking about multiple conformance levels, but
> rather regular updates (as needed) for a single conformance level that
> reflects the current state of the art.
>
>
> <ira>
> Put in another context, there is 10 years between IPP/1.1 and IPP/2.0.  *If*
> the printing landscape changes sufficiently I think we'll be looking at
> IPP/3.0 and not just a new IPP Everywhere "profile".
>
> or a new IPP conformance level.  I see no reason to keep IPP Everywhere
> separate from the main specs if it is successful enough to warrant a second
> (or third, etc.) pass.
>
> A separate semantic model document could handle defining the device object,
> and then the IPP Everywhere spec can reference it and say "this is how we
> map it to IPP"...
>
>
> <ira>
> Moreover, at least some of this stuff is coming from the existing Printer
> MIB, and so already exists to do mappings that we can then use for IPP.
>
> I would suggest that IPP Everywhere is, by definition, a catch-all effort -
> if we only get half-assed implementations of bits and pieces then we have
> failed!
> I'm not here to write standards for the fun of it, I want to develop
> something genuinely useful and hopefully ubiquitous...

---

From: Michael Sweet <[email-masked]>
Date: Mon, 1 Mar 2010 20:31:15 -0800

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

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

> 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 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?

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

> format in as a REQUIRED in the first IPP Everywhere - otherwise,

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

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

---

From: Ira McDonald <[email-masked]>
Date: Tue, 2 Mar 2010 09:25:09 -0500

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.

---

From: "William Wagner" <[email-masked]>
Date: Tue, 2 Mar 2010 12:09:45 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ira
McDonald
Sent: Tuesday, March 02, 2010 9:25 AM
To: Michael Sweet; Ira McDonald
Cc: [email-masked]
Subject: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28
February 2010)

Hi Mike,

OK - I agree with you.

Cheers,
- Ira

On Mon, Mar 1, 2010 at 11:31 PM, Michael Sweet <[email-masked]> wrote:
> 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.
> 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".
> 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.
> 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?
> 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:
> 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.
> 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...)
> 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.

---

From: Ira McDonald <[email-masked]>
Date: Tue, 2 Mar 2010 12:55:35 -0500

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

---

From: "William Wagner" <[email-masked]>
Date: Tue, 2 Mar 2010 13:34:14 -0500

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:[email-masked]] 
Sent: Tuesday, March 02, 2010 12:56 PM
To: William Wagner; Ira McDonald
Cc: [email-masked]
Subject: Re: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28
February 2010)

Hi Bill,

Cheers,
- Ira

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 3 Mar 2010 04:45:12 -0800

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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of William Wagner
Sent: Tuesday, March 02, 2010 1:34 PM
To: 'Ira McDonald'
Cc: [email-masked]
Subject: RE: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28February 2010)

Hi Ira,

Bill Wagner

-----Original Message-----
From: Ira McDonald [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2010 12:56 PM
To: William Wagner; Ira McDonald
Cc: [email-masked]
Subject: Re: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28
February 2010)

Hi Bill,

Cheers,
- Ira

On Tue, Mar 2, 2010 at 12:09 PM, William Wagner <[email-masked]>
wrote:
> kept up with it, don't regard it highly, and want to move on.
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 3 Mar 2010 09:57:40 -0500

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

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 3 Mar 2010 07:37:19 -0800

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

-----Original Message-----
From: Ira McDonald [mailto:[email-masked]] 
Sent: Wednesday, March 03, 2010 9:58 AM
To: Zehler, Peter; Ira McDonald
Cc: William Wagner; [email-masked]
Subject: Re: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28February 2010)

Hi Pete,

Cheers,
- Ira

---

From: Ira McDonald <[email-masked]>
Date: Wed, 3 Mar 2010 11:04:01 -0500

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