attachment

<div dir="ltr">---------- Forwarded message ----------<br><div class="gmail_quote">From: <b class="gmail_sendername">Alexey Melnikov</b> <span dir="ltr"><<a href="mailto:aamelnikov@fastmail.fm">aamelnikov@fastmail.fm</a>></span><br>Date: Tue, Jun 7, 2016 at 9:57 AM<br>Subject: AD review of draft-sweet-rfc2910bis-07.txt<br>To: Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>>, Michael R Sweet <<a href="mailto:msweet@apple.com">msweet@apple.com</a>><br>Cc: <a href="mailto:art-ads@ietf.org">art-ads@ietf.org</a>, Barry Leiba <<a href="mailto:barryleiba@computer.org">barryleiba@computer.org</a>><br><br><br><u></u>




<div><div><div>Hi,<br></div>
<div>Below is my AD review. Most of these are minor and I am happy to start IETF LC right away, but I need a new version to address the issues I found:<br></div>
<div> </div>
</div>
<div>A small note about referencing "Model" (rfc2911bis). This is an issue with generated HTML, but text like:<br></div>
<div> </div>
<div>   The first three fields in the above diagram contain the value of<br></div>
<div>   attributes described in Section 3.1.1 of the Model.<br></div>
<div> </div>
<div>produces a link that points to rfc2910bis and not rfc2911bis. Something like:<br></div>
<div> </div>
<div>  ... Model [rfc2911bis].<br></div>
<div> </div>
<div>would be better. This can probably be sorted out by the RFC Editor, but you might want to fix this yourself.<br></div>
<div><div> </div>
<div> </div>
<div>Issues found by ID-nits:</div>
<div> </div>
<div>  == Unused Reference: 'IANA-CON' is defined on line 1508, but no explicit<br></div>
</div>
<div>     reference was found in the text<br></div>
<div> </div>
<div> -- I suggest removing the reference.</div>
<div> </div>
<div>  ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579)<br></div>
<div> </div>
<div> -- It looks like updating to RFC 2579 is the right thing here.</div>
<div> </div>
<div>** Downref: Normative reference to an Informational RFC: RFC 2818.<br></div>
<div> </div>
<div>    -- This is Ok, already in the DownRef registry. So just ignore this.<br></div>
<div> </div>
<div>Other issues:</div>
<div> </div>
<div>In Section 3:<br></div>
<div> </div>
<div>The first reference to a charset needs a reference to RFC 2978.<br></div>
<div> </div>
<div>In 3.2:<br></div>
<div> </div>
<div>   begin-attribute-group-tag = %x00-02 / %x04-0F ; see section 3.5.1<br></div>
<div> </div>
<div>s/%04/%x04<br></div>
<div> </div>
<div>(you are missing "x", without it the ABNF is not syntactically valid).<br></div>
<div> </div>
<div>3.8.  Value Length<br></div>
<div> </div>
<div>   For any of the types represented by binary signed bytes, the sender<br></div>
<div>   MUST encode the value in exactly one octet.<br></div>
<div> </div>
<div>Can you give me an example? Are you talking about booleans or something else?<br></div>
<div> </div>
<div> </div>
<div>In 8.1.2:<br></div>
<div> </div>
<div>      IPP Clients and Printers MAY support Basic<br></div>
<div>      Authentication [RFC7617] for User Authentication if the channel is<br></div>
<div>      secure.<br></div>
<div> </div>
<div>I think you need to expand on what "secure" means here. I think you meant that TLS was successfully negotiated and the TLS server identity was verified successfully by the client.<br></div>
<div> </div>
<div>In Section 9:<br></div>
<div> </div>
<div>When you mention IPP/2.0, 2.1 or 2.2, you should have a Normative reference to relevant specs, because you use them in a SHOULD-level requirement.<br></div>
<div> </div>
<div> </div>
<div>In Appendix B:<br></div>
<div> </div>
<div>           This section is strictly informative.  The MIME media type listed in<br></div>
<div>this section should not be re-registered by IANA when this document<br></div>
<div>is published.<br></div>
<div> </div>
<div>I think this is wrong. The IANA registration template is out of date. It is missing "Change Controller", etc. See RFC 6838, section 5.6.<br></div>
<div> </div>
<div>So I think this needs to be updated and also mentioned in the IANA Considerations section.<br></div>
<div> </div>
<div><div> </div>
<div>Best Regards,</div>
</div>
<div>Alexey</div>
<div> </div>
<div>On Thu, Jun 2, 2016, at 12:17 PM, Ira McDonald wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><div>Hi Alexey,<br></div>
</div>
<div>The document names are:<br></div>
<pre><div>Internet Printing Protocol/1.1: Model and Semantics<br></div>
<div><a href="http://www.ietf.org/internet-drafts/draft-sweet-rfc2911bis-09.txt" target="_blank">http://www.ietf.org/internet-drafts/draft-sweet-rfc2911bis-09.txt</a><br></div>
</pre><pre><div>Internet Printing Protocol/1.1: Encoding and Transport<br></div>
<div><a href="http://www.ietf.org/internet-drafts/draft-sweet-rfc2910bis-07.txt" target="_blank">http://www.ietf.org/internet-drafts/draft-sweet-rfc2910bis-07.txt</a><br></div>
</pre><div>Background:  In the 1990s, there were a dozen proprietary print protocols and<br></div>
<div>several incompatible implementations of LPR.  Today, over 98% of all recent<br></div>
<div>network printers support IPP/1.1.  And new network printers will soon be PWG<br></div>
<div>logo certified for IPP Everywhere (printing via single standard OS driver, replacing<br></div>
<div>40 million Windows drivers and 28 million Apple drivers).  More than a dozen IETF<br></div>
<div>RFCs and 20 PWG standards are based on IPP/1.1.  Last year, the PWG profile<br></div>
<div><div>spec PWG 5100.12 (2.0, 2.1, 2.2 versions as supersets of 1.1) became the first full <br></div>
<div>PWG Standard.<br></div>
<div> </div>
<div><a href="http://www.pwg.org/ipp/everywhere.html" target="_blank">http://www.pwg.org/ipp/everywhere.html</a><br></div>
</div>
<div><a href="http://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf" target="_blank">http://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf</a><br></div>
<div> </div>
<div><div>Please let us know if you have questions or suggestions for IETF-based review.<br></div>
</div>
<div>Cheers,<br></div>
<div>- Ira (PWG Secretary, PWG IPP WG Co-Chair)<br></div>
<div> </div>
<div><div><div><div dir="ltr"><div> </div>
<div>Ira McDonald (Musician / Software Architect)<br></div>
<div>Co-Chair - TCG Trusted Mobility Solutions WG<br></div>
<div>Chair - Linux Foundation Open Printing WG<br></div>
<div>Secretary - IEEE-ISTO Printer Working Group<br></div>
<div>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br></div>
<div>IETF Designated Expert - IPP & Printer MIB<br></div>
<div>Blue Roof Music / High North Inc<br></div>
<div><a href="http://sites.google.com/site/blueroofmusic" style="color:rgb(51,51,255)" target="_blank">http://sites.google.com/site/blueroofmusic</a><br></div>
<div><a href="http://sites.google.com/site/highnorthinc" style="color:rgb(102,0,204)" target="_blank">http://sites.google.com/site/highnorthinc</a><br></div>
<div>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br></div>
<div>Winter  579 Park Place  Saline, MI  48176  <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br></div>
<div>Summer  PO Box 221  Grand Marais, MI 49839  <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><br></div>
<div> </div>
<div style="display:inline"> </div>
<div style="display:inline"> </div>
<div style="display:inline"> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
</div>
</div>
</div>
<div> </div>
<div><div>On Thu, Jun 2, 2016 at 5:31 AM, Alexey Melnikov <span dir="ltr"><<a href="mailto:aamelnikov@fastmail.fm" target="_blank">aamelnikov@fastmail.fm</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>Hi,<br></div>
<div> I am happy to AD-sponsor -bis documents, assuming I don't find anything<br></div>
<div> seriously objectionable in my AD review (this is not likely, but I<br></div>
<div> basically reserve the right to change my mind after seeing documents).<br></div>
<div> </div>
<div> What are the document names?<br></div>
<div> </div>
<div> Best Regards,<br></div>
<div> Alexey<br></div>
<div> </div>
<div><div><div> </div>
<div>On Tue, May 31, 2016, at 08:03 PM, Barry Leiba wrote:<br></div>
<div> > Hi, Ian, and I'm sorry I didn't answer this last week.  I'm glad to<br></div>
<div> > hear that you folks have gotten this work done and are ready to put<br></div>
<div> > out the IETF versions.  Unfortunately for my earlier offer, I'm no<br></div>
<div> > longer an Area Director (my second term ended in April), and Alexey<br></div>
<div> > Melnikov, whom I've added to this message, is the new AD responsible<br></div>
<div> > for this area of work.<br></div>
<div> ><br></div>
<div> > Alexey, the IPP stuff was done in the IETF long ago, producing RFCs<br></div>
<div> > 2910 and 2911, and some other stuff.  After the IETF working group was<br></div>
<div> > closed, 15 or so years ago, continued work on IPP went to the<br></div>
<div> > IEEE-ISTO PWG Internet Printing Protocol WG, which Ira and Michael are<br></div>
<div> > representing.  As the original documents are Standards Track, updates<br></div>
<div> > need to go through the IETF stream as Standards Track documents... but<br></div>
<div> > no one in the IETF works on this any more, and all the people who do<br></div>
<div> > are in the PWG IPP WG.<br></div>
<div> ><br></div>
<div> > So the right thing to do is to run their updates through the process<br></div>
<div> > as AD-sponsored documents that have full support from the current IPP<br></div>
<div> > practitioners.  Forming a working group would be of little point.<br></div>
<div> > This seems a bit like people coming to us and asking for a rubber<br></div>
<div> > stamp of "Standard" on their work, but it's not really the same thing<br></div>
<div> > in this case.  I recommend that you do AD-sponsor this, but, of<br></div>
<div> > course, have a look and see what you think.<br></div>
<div> ><br></div>
<div> > Barry<br></div>
<div> ><br></div>
<div> > On Wed, May 25, 2016 at 4:33 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>><br></div>
<div> > wrote:<br></div>
<div> > > Hi Barry,<br></div>
<div> > ><br></div>
<div> > > After more little nits than we could have imagined, Mike Sweet has<br></div>
<div> > > completed stable drafts of IPP/1.1 (RFC2910bis and RFC2911bis):<br></div>
<div> > ><br></div>
<div> > > <a href="http://www.ietf.org/internet-drafts/draft-sweet-rfc2910bis-07.txt" target="_blank">http://www.ietf.org/internet-drafts/draft-sweet-rfc2910bis-07.txt</a><br></div>
<div> > ><br></div>
<div> > > <a href="http://www.ietf.org/internet-drafts/draft-sweet-rfc2911bis-09.txt" target="_blank">http://www.ietf.org/internet-drafts/draft-sweet-rfc2911bis-09.txt</a><br></div>
<div> > ><br></div>
<div> > > These documents are now ready for IETF review.<br></div>
<div> > ><br></div>
<div> > > You offered last year to AD sponsor these updates and we hope that<br></div>
<div> > > you can advise us and forward these documents to the appropriate<br></div>
<div> > > IETF WGs/mailing lists for review and comments.  The Abstracts have<br></div>
<div> > > been updated and there are sections for "Changes Since RFC29xx".<br></div>
<div> > ><br></div>
<div> > > Cheers,<br></div>
<div> > > - Ira (PWG Secretary, PWG IPP WG Co-Chair)<br></div>
<div> > ><br></div>
<div> > ><br></div>
<div> > > Ira McDonald (Musician / Software Architect)<br></div>
<div> > > Co-Chair - TCG Trusted Mobility Solutions WG<br></div>
<div> > > Chair - Linux Foundation Open Printing WG<br></div>
<div> > > Secretary - IEEE-ISTO Printer Working Group<br></div>
<div> > > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br></div>
<div> > > IETF Designated Expert - IPP & Printer MIB<br></div>
<div> > > Blue Roof Music / High North Inc<br></div>
<div> > > <a href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br></div>
<div> > > <a href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br></div>
<div> > > mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br></div>
<div> > > Winter  579 Park Place  Saline, MI  48176 <a href="tel:734-944-0094" target="_blank">734-944-0094</a><br></div>
<div> > > Summer  PO Box 221  Grand Marais, MI 49839 <a href="tel:906-494-2434" target="_blank">906-494-2434</a><br></div>
<div> > ><br></div>
</div>
</div>
</blockquote></div>
</div>
</div>
</blockquote><div> </div>
</div>

</div><br></div>

Comments are owned by the poster. All other material is Copyright © 2001-2024 The Printer Working Group. All rights reserved. IPP Everywhere, the IPP Everywhere logo, and the PWG logo are trademarks of the IEEE-ISTO.
About the PWG · Privacy Policy · PWG Webmaster