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/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 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.orghttps://www.pwg.org/mailman/listinfo/ipp
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.