Hi Ira and Mike,
I agree 100% with waiting! Achieving full Internet Standard is a higher priority.
Smith
> On Apr 14, 2018, at 11:27 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Smith,
>> AFTER we move RFC 8010/8011 to full Internet Standard, the RFC Editor has a process
> to attach errata notes to published RFCs (which doesn't commit anyone to ever revise the
> original RFC). I suggest we defer this edit until then, OK?
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
>http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
> May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
>>> On Sat, Apr 14, 2018 at 8:36 AM, Michael Sweet <msweet at apple.com <mailto:msweet at apple.com>> wrote:
> Smith,
>> 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.
>>> > On Apr 13, 2018, at 3:31 PM, Kennedy, Smith (Wireless & Standards Architec) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
> >
> > Greetings,
> >
> > I've recently been asked by someone working on a new IPP client implementation about the meaning of RFC 8010 section 3.3 (https://tools.ietf.org/html/rfc8010#section-3.3 <https://tools.ietf.org/html/rfc8010#section-3.3>), which says:
> >
> > Table 1 maps the Model group name to value of the "begin-attribute-
> > group-tag" field:
> >
> > +----------------+--------------------------------------------------+
> > | Model Document | "begin-attribute-group-tag" field values |
> > | Group | |
> > +----------------+--------------------------------------------------+
> > | Operation | "operations-attributes-tag" |
> > | Attributes | |
> > +----------------+--------------------------------------------------+
> > | Job Template | "job-attributes-tag" |
> > | Attributes | |
> > +----------------+--------------------------------------------------+
> > | Job Object | "job-attributes-tag" |
> > | Attributes | |
> > +----------------+--------------------------------------------------+
> > | Unsupported | "unsupported-attributes-tag" |
> > | Attributes | |
> > +----------------+--------------------------------------------------+
> > |
> > Requested | (Get-Job-Attributes) "job-attributes-tag"
> > |
> > |
> > Attributes
> > | |
> > +----------------+--------------------------------------------------+
> > |
> > Requested | (Get-Printer-Attributes)"printer-attributes-tag"
> > |
> > |
> > Attributes
> > | |
> > +----------------+--------------------------------------------------+
> > | Document | in a special position at the end of the message |
> > | Content | as described in
> > Section 3.1.1
> > . |
> > +----------------+--------------------------------------------------+
> >
> > Table 1: Group Values
> >
> > For each operation request and response, the Model prescribes the
> > required and optional attribute groups, along with their order.
> > Within each attribute group, the Model prescribes the required and
> > optional attributes, along with their order.
> >
> >
> >
> > 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:
> >
> > +----------------+--------------------------------------------------+
> > |
> > Requested | "job-attributes-tag"
> > |
> > |
> > Attributes | (Get-Job-Attributes operation response) |
> > +----------------+--------------------------------------------------+
> > |
> > Requested | "printer-attributes-tag"
> > |
> > |
> > Attributes | (Get-Printer-Attributes operation response)
> > |
> > +----------------+--------------------------------------------------+
> >
> >
> > Thoughts? Maybe these kinds of editorial errata can be rolled in as part of their move to full Internet Standard?
> >
> > Smith
> >
> > /**
> > Smith Kennedy
> > Wireless & Standards Architect - IPG-PPS
> > Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
> > Chair, IEEE ISTO Printer Working Group
> > HP Inc.
> > */
> >
> >
> >
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org <mailto:ipp at pwg.org>
> > https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org <mailto:ipp at pwg.org>
>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180414/f5671ecf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180414/f5671ecf/attachment.sig>