attachment
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Ira and Mike,<div class=""><br class=""></div><div class="">I agree 100% with waiting! Achieving full Internet Standard is a higher priority.</div><div class=""><br class=""><div class="">
Smith<br class=""><br class=""><br class="">
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Apr 14, 2018, at 11:27 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" class="">blueroofmusic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Hi Smith,<br class=""><br class=""></div>AFTER we move RFC 8010/8011 to full Internet Standard, the RFC Editor has a process<br class=""></div>to attach errata notes to published RFCs (which doesn't commit anyone to ever revise the<br class="">original RFC). I suggest we defer this edit until then, OK?<br class=""><br class=""></div><div class="">Cheers,<br class=""></div><div class="">- Ira<br class=""><br class=""></div></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class="">Ira McDonald (Musician / Software Architect)<br class="">Co-Chair - TCG Trusted Mobility Solutions WG<br class="">Chair - Linux Foundation Open Printing WG<br class="">Secretary - IEEE-ISTO Printer Working Group<br class="">Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br class="">IETF Designated Expert - IPP & Printer MIB<br class="">Blue Roof Music / High North Inc<br class=""><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank" class="">http://sites.google.com/site/blueroofmusic</a><br class=""><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank" class="">http://sites.google.com/site/highnorthinc</a><br class="">mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank" class="">blueroofmusic@gmail.com</a><br class="">Jan-April: 579 Park Place Saline, MI 48176 734-944-0094<br class="">May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434<br class=""><br class=""><div style="display:inline" class=""></div><div style="display:inline" class=""></div><div style="display:inline" class=""></div><div class=""></div><div class=""></div><div class=""></div><div class=""></div></div></div></div></div></div>
<br class=""><div class="gmail_quote">On Sat, Apr 14, 2018 at 8:36 AM, Michael Sweet <span dir="ltr" class=""><<a href="mailto:msweet@apple.com" target="_blank" class="">msweet@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Smith,<br class="">
<br class="">
I agree in principle with the editorial changes, however making that sort of change is probably beyond what current IETF process would allow for simply updating the status of those RFCs to Internet Standard, which means going through another round of updates. I'm not so keen on *that* - it took us long enough to get 2910/2911 updated, and doing an update to 8010/8011 will likely push more changes on us thanks to the work being done on updating the "HTTP-based Protocols" BCP.<br class="">
<div class=""><div class="h5"><br class="">
<br class="">
> On Apr 13, 2018, at 3:31 PM, Kennedy, Smith (Wireless & Standards Architec) <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>> wrote:<br class="">
> <br class="">
> Greetings,<br class="">
> <br class="">
> I've recently been asked by someone working on a new IPP client implementation about the meaning of RFC 8010 section 3.3 (<a href="https://tools.ietf.org/html/rfc8010#section-3.3" rel="noreferrer" target="_blank" class="">https://tools.ietf.org/html/<wbr class="">rfc8010#section-3.3</a>), which says:<br class="">
> <br class="">
> Table 1 maps the Model group name to value of the "begin-attribute-<br class="">
> group-tag" field:<br class="">
> <br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> | Model Document | "begin-attribute-group-tag" field values |<br class="">
> | Group | |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> | Operation | "operations-attributes-tag" |<br class="">
> | Attributes | |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> | Job Template | "job-attributes-tag" |<br class="">
> | Attributes | |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> | Job Object | "job-attributes-tag" |<br class="">
> | Attributes | |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> | Unsupported | "unsupported-attributes-tag" |<br class="">
> | Attributes | |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> |<br class="">
> Requested | (Get-Job-Attributes) "job-attributes-tag"<br class="">
> |<br class="">
> | <br class="">
> Attributes<br class="">
> | |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> | <br class="">
> Requested | (Get-Printer-Attributes)"<wbr class="">printer-attributes-tag"<br class="">
> |<br class="">
> | <br class="">
> Attributes<br class="">
> | |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> | Document | in a special position at the end of the message |<br class="">
> | Content | as described in <br class="">
> Section 3.1.1<br class="">
> . |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> <br class="">
> Table 1: Group Values<br class="">
> <br class="">
> For each operation request and response, the Model prescribes the<br class="">
> required and optional attribute groups, along with their order.<br class="">
> Within each attribute group, the Model prescribes the required and<br class="">
> optional attributes, along with their order.<br class="">
> <br class="">
> <br class="">
> <br class="">
> After reading RFC 8011 more closely, "Requested Attributes (Get-Job-Attributes)" seems to mean that the Get-Job-Attributes response will list the set of requested attributes in the group with the "job-attributes-tag", and "Requested Attributes (Get-Printer-Attributes)" means the Get-Printer-Attributes response will list the set of requested attributes in the group with the "printer-attributes-tag". But that required a bit of back-and-forth between 8010 and 8011. If there is a mechanism to report errata to an RFC, I'd like to request that these rows be modified to read more like so:<br class="">
> <br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> |<br class="">
> Requested | "job-attributes-tag"<br class="">
> |<br class="">
> | <br class="">
> Attributes | (Get-Job-Attributes operation response) |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> | <br class="">
> Requested | "printer-attributes-tag"<br class="">
> |<br class="">
> | <br class="">
> Attributes | (Get-Printer-Attributes operation response)<br class="">
> |<br class="">
> +----------------+------------<wbr class="">------------------------------<wbr class="">--------+<br class="">
> <br class="">
> <br class="">
> Thoughts? Maybe these kinds of editorial errata can be rolled in as part of their move to full Internet Standard?<br class="">
> <br class="">
> Smith<br class="">
> <br class="">
> /**<br class="">
> Smith Kennedy<br class="">
> Wireless & Standards Architect - IPG-PPS<br class="">
> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF<br class="">
> Chair, IEEE ISTO Printer Working Group<br class="">
> HP Inc.<br class="">
> */<br class="">
> <br class="">
> <br class="">
> <br class="">
</div></div>> ______________________________<wbr class="">_________________<br class="">
> ipp mailing list<br class="">
> <a href="mailto:ipp@pwg.org" class="">ipp@pwg.org</a><br class="">
> <a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank" class="">https://www.pwg.org/mailman/<wbr class="">listinfo/ipp</a><br class="">
<br class="">
______________________________<wbr class="">___________________________<br class="">
Michael Sweet, Senior Printing System Engineer<br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
ipp mailing list<br class="">
<a href="mailto:ipp@pwg.org" class="">ipp@pwg.org</a><br class="">
<a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank" class="">https://www.pwg.org/mailman/<wbr class="">listinfo/ipp</a><br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>