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

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

Ira McDonald blueroofmusic at gmail.com
Tue Mar 2 00:19:47 UTC 2010


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.

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>


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

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>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the ipp mailing list