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.