Hi Smith,
If I visit the RFC Index page, 8010 and 8011 show as Internet Standard.
Almost no existing RFCs have changed their own cover page to list this
(and such a listing is deprecated in IETF process docs, because the IETF
can later mark an old RFC as Historic, for example).
I'm REALLY not happy about re-issuing RFC 8010 and 8011 to change
their cover pages. They say standards-track and they are.
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/blueroofmusichttp://sites.google.com/site/highnorthinc
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 Tue, Jul 3, 2018 at 12:42 PM, Kennedy, Smith (Wireless & Standards
Architec) <smith.kennedy at hp.com> wrote:
> Hi Mike and Ira,
>> Is editorial work needed to get the RFC itself to be listed as an
> "Internet Standard" when one visits the links? I see this one doesn't list
> its Internet Standard number in the header:
>>https://tools.ietf.org/html/std90>> but this one does:
>>https://tools.ietf.org/html/std91>> Ours is here:
>>https://tools.ietf.org/html/std92>> which is a concatenation of RFC 8010 and 8011, but provides somewhat
> inadequate navigation IMHO - 8011 is concatenated after 8010. And when you
> visit the RFC pages directly for 8010 and 8011, they aren't yet labeled as
> "INTERNET STANDARD" but are still labeled as "PROPOSED STANDARD":
>>https://tools.ietf.org/html/rfc8010>https://tools.ietf.org/html/rfc8011>> RFC 3629 seems to have everything as "right" as is possible currently,
> presentation wise:
>>https://tools.ietf.org/html/std63>https://tools.ietf.org/html/rfc3629>> Not trying to spend cycles on unnecessary stuff but this kind of
> presentation thing can cause issues to the uninitiated.
>> 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.
> */
>>>> > On Jun 28, 2018, at 8:33 AM, Michael Sweet <msweet at apple.com> wrote:
> >
> > And "STD92" as the pointer:
> >
> > https://www.rfc-editor.org/info/std92> >
> >
> >> On Jun 28, 2018, at 10:22 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> This morning's RFC Index shows IPP/1.1 (RFC 8010/8011) as "Internet
> Standard"
> >>
> >> https://www.rfc-editor.org/rfc-index.html> >>
> >> 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/highnorthinc> >> 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 Tue, Jun 26, 2018 at 10:37 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> >> Hi,
> >>
> >> Normally they just assign an STD number and update std-index.txt (for
> the RFC set)
> >> and rfc-index.txt (for Internet Standard status). Only when any
> *future* update of the
> >> RFCs happens would be any cover page change.
> >>
> >> RFCs never state more than just "Standards Track" on their cover page
> and usually
> >> don't mention their own STD number (because an STD could become
> historic or
> >> deprecated via the underlying RFC status - although I think it's only
> happened once).
> >>
> >> I expect to see IPP/1.1 update in the RFC Index web page w/in a few
> weeks.
> >>
> >> 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/highnorthinc> >> 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 Tue, Jun 26, 2018 at 10:28 AM, Michael Sweet <msweet at apple.com>
> wrote:
> >> Smith,
> >>
> >> I'm not sure about the timing - a lot depends on the RFC editor's load
> and any editorial changes that we want to make. Ideally I'd like to just
> have them assign STD numbers and change the status on the cover page
> (minimal change) to speed this along... :)
> >>
> >>
> >>> On Jun 26, 2018, at 12:02 AM, Kennedy, Smith (Wireless & Standards
> Architec) <smith.kennedy at hp.com> wrote:
> >>>
> >>> Thanks for the update, Mike! Given this status change for RFC 8011
> (and corresponding change for RFC 8010), when do we expect them to complete
> the move to 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.
> >>> */
> >>>
> >>>
> >>>
> >>>> On Jun 25, 2018, at 5:23 PM, Michael Sweet <msweet at apple.com> wrote:
> >>>>
> >>>> *Internet Standard*
> >>>>
> >>>>> Begin forwarded message:
> >>>>>
> >>>>> From: The IESG <iesg-secretary at ietf.org>
> >>>>> Subject: Protocol Action: Internet Printing Protocol/1.1: Model and
> Semantics to Internet Standard
> >>>>> Date: June 25, 2018 at 5:15:02 PM EDT
> >>>>> To: IETF-Announce <ietf-announce at ietf.org>
> >>>>> Cc: The IESG <iesg at ietf.org>, Barry Leiba <barryleiba at computer.org>,
>draft-sweet-rfc2911bis at ietf.org, draft-sweet-rfc2910bis at ietf.org,
>barryleiba at computer.org, rfc-editor at rfc-editor.org> >>>>> Resent-From: alias-bounces at ietf.org> >>>>> Resent-To: msweet at apple.com, blueroofmusic at gmail.com> >>>>>
> >>>>> The IESG has approved changing the status of the following document:
> >>>>> - Internet Printing Protocol/1.1: Model and Semantics
> >>>>> (rfc8011) to Internet Standard
> >>>>>
> >>>>> This protocol action is documented at:
> >>>>> https://datatracker.ietf.org/doc/status-change-change-ipp-> to-internet-standard/
> >>>>>
> >>>>> A URL of the affected document is:
> >>>>> https://datatracker.ietf.org/doc/rfc8011/> >>>>>
> >>>>> Status Change Details:
> >>>>>
> >>>>> As specified in RFC 6410:
> >>>>>
> >>>>> (1) There are at least two independent interoperating
> implementations
> >>>>> with widespread deployment and successful operational
> experience.
> >>>>>
> >>>>> - Over 98% of all digital network printers shipped in the last
> >>>>> decade support IPP/1.1 (originally defined in RFC 2910/2911,
> >>>>> September 2000).
> >>>>>
> >>>>> (2) There are no errata against the specification that would cause a
> >>>>> new implementation to fail to interoperate with deployed ones.
> >>>>>
> >>>>> - There are currently no errata against RFC 8010/8011.
> >>>>>
> >>>>> (3) There are no unused features in the specification that greatly
> >>>>> increase implementation complexity.
> >>>>>
> >>>>> - There are no unused features in RFC 8010/8011.
> >>>>>
> >>>>> - The Purge-Jobs operation (from RFC 2911) is DEPRECATED in
> >>>>> RFC 8011 (page 73) with "SHOULD NOT support" because it
> >>>>> destroys Printer accounting implementation. This operation
> >>>>> has never been widely implemented in digital network printers.
> >>>>>
> >>>>> - The Restart-Job operation (from RFC 2911) is DEPRECATED in
> >>>>> RFC 8011 (page 89) with "SHOULD NOT support" because it
> >>>>> destroys Printer accounting implementation. This operation
> >>>>> has never been widely implemented in digital network printers.
> >>>>>
> >>>>> (4) If the technology required to implement the specification
> >>>>> requires patented or otherwise controlled technology, then the
> >>>>> set of implementations must demonstrate at least two
> independent,
> >>>>> separate and successful uses of the licensing process.
> >>>>>
> >>>>> - There is no patented or otherwise controlled technology that
> >>>>> is required to implement IPP/1.1 per RFC 8010/8011.
> >>>>>
> >>>>> Personnel
> >>>>>
> >>>>> Alexey Melnikov is the responsible Area Director.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> _________________________________________________________
> >>>> Michael Sweet, Senior Printing System Engineer
> >>>>
> >>>> _______________________________________________
> >>>> ipp mailing list
> >>>> ipp at pwg.org> >>>> https://www.pwg.org/mailman/listinfo/ipp> >>>
> >>
> >> _________________________________________________________
> >> Michael Sweet, Senior Printing System Engineer
> >>
> >>
> >> _______________________________________________
> >> ipp mailing list
> >> ipp at pwg.org> >> https://www.pwg.org/mailman/listinfo/ipp> >>
> >>
> >>
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer
> >
>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180703/7c1f4e70/attachment.html>