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
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 7:47 PM, Michael Sweet <msweet at apple.com> wrote:
> On Mar 1, 2010, at 4:19 PM, Ira McDonald wrote:
>> Hi Mike,
>> My replies inline below.
>> Cheers,
> - Ira
>>> On Mon, Mar 1, 2010 at 6:19 PM, Michael Sweet <msweet at apple.com> wrote:
>> On Mar 1, 2010, at 3:01 PM, Ira McDonald wrote:
>> 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.
>> 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.
>> 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".
>> If second edition of IPP Everywhere adds PDF (for example), then that
> 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.
>> I think an "ipp-everywhere-versions-supported" Printer attribute needs
> to be orthogonal to and independent of "ipp-versions-supported".
> </ira>
>> Testing for a particular feature using a version number is, in general, a
> bad idea.
>> 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.
>> 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.
>> 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.
>> 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>
>>> IPP/2.0 does NOT define any attributes or operations.
>> 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>
>> 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...
> ________________________________________________________________________
> 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.