attachment-0001
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 1, 2010, at 4:19 PM, Ira McDonald wrote:</div><blockquote type="cite"><div>Hi Mike,<br><br>My replies inline below.<br><br>Cheers,<br>- Ira<br><br><br>On Mon, Mar 1, 2010 at 6:19 PM, Michael Sweet <<a href="mailto:msweet@apple.com">msweet@apple.com</a>> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Mar 1, 2010, at 3:01 PM, Ira McDonald wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi Mike,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thanks for all these comments - I just skimmed them.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But, if we want (and we had concensus) to get the "low<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">hanging fruit first" in IPP Everywhere, then we certainly<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">want 2 or more conformance levels eventually - therefore,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">we need to start that way.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><br><ira><br>My point was that, in the PWG Process (and IETF), NO new content can<br>EVER be added to an existing conformance profile in the same level.<br></div></blockquote><div><br></div>Right now I'm looking at the work in front of us, and not the work we (may) do in N years.</div><div><br></div><div>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".</div><div><br><blockquote type="cite"><div>If second edition of IPP Everywhere adds PDF (for example), then that<br>MUST be a new IPP Everywhere conformance level.<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div>I think an "ipp-everywhere-versions-supported" Printer attribute needs<br>to be orthogonal to and independent of "ipp-versions-supported".<br></ira><br></div></blockquote><div><br></div><div>Testing for a particular feature using a version number is, in general, a bad idea.</div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font></blockquote><blockquote type="cite">And while we could roll these together, I suspect that<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the correct solution to Printer MIB visibility is the original<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">proposal in late 1990's - to whit, a first-class Device<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">object - way too much different content to bury in one<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">IPP Job spec that's partly profiles of discovery and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">document format requirements.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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"...<br></blockquote><blockquote type="cite"><br></blockquote><br><ira><br>Nope - in the PWG Semantic Model WG charter, they can ONLY<br>do XML mappings from other existing IETF or PWG specs that<br>define the objects and/or properties/attributes.<br></div></blockquote><div><br></div>Then let's change the charter. It is not chiseled in stone, right?</div><div><br></div><div>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.</div><div><br><blockquote type="cite"><div>So an IPP spec is definitely required for a Device object,<br>unless we use opaque stuff like some kludge format for ASN.1<br>names in a new operation attribute for Get-Printer-Attributes<br>(which is yucky and likely not to be interoperable).<br></ira><br><br><br><blockquote type="cite"><blockquote type="cite">IPP/2.0 does NOT define any attributes or operations.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Right, but this is IPP Everywhere, not IPP/2.0.<br></blockquote><br><ira><br>Nope - combining these documents won't work - there will<br>almost undoubtedly ultimately need to be more than one<br>well-focused IPP extension spec (for Job, Printer, Device,<br>etc. extensions) - if we roll all these together with this IPP<br>Everywhere profile of OTHER non-IPP protocols and PDLs,<br>we'll never manage to publish a PWG Candidate Standard,<br>IMHO.<br><br>Catchall specs have caused us trouble before (including<br>in the IPP WG efforts).<br></ira><br></div></blockquote></div><div><br></div>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!<div><br></div><div>I'm not here to write standards for the fun of it, I want to develop something genuinely useful and hopefully ubiquitous...<div><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>________________________________________________________________________</div><div>Michael Sweet, Senior Printing System Engineer, PWG Chair</div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br></div></div></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>