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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100301/d11b54a0/attachment-0001.html>