Spotted by one of the GSoC 2018 students...
> Begin forwarded message:
>> From: RFC Errata System <rfc-editor at rfc-editor.org>
> Subject: [Technical Errata Reported] RFC3996 (5413)
> Date: June 28, 2018 at 8:55:26 AM EDT
> To: bob at herriot.com, tom.hastings at alum.mit.edu, harryl at us.ibm.com, ben at nostrum.com, aamelnikov at fastmail.fm, adam at nostrum.com, carl at manros.com> Cc: msweet at apple.com, rfc-editor at rfc-editor.org>> The following errata report has been submitted for RFC3996,
> "Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications".
>> --------------------------------------
> You may review the report below and at:
>http://www.rfc-editor.org/errata/eid5413>> --------------------------------------
> Type: Technical
> Reported by: Michael Sweet <msweet at apple.com>
>> Section: 5.2.1
>> Original Text
> -------------
> The value of this attribute MUST be at least as large as that of the
> Printer's "ippget-event-life" Printer Description attribute (see
> section 8.1). The Printer MAY return a value that is larger than
> that of the "ippget-event-life" Printer Description attribute
> provided that the Printer increases the Event Life for this
> Subscription object so that Notification Recipients taking account of
> the larger value and polling with a longer interval will not miss
> events. Note: Implementing such an algorithm requires some hidden
> attributes in the Subscription object that are IMPLEMENTATION
> DEPENDENT.
>>> Corrected Text
> --------------
> If the value of this attribute is larger than that of the
> "ippget-event-life" Printer Description attribute, the Printer MUST
> increase the Event Life for this Subscription object so that
> Notification Recipients taking account of the larger value and
> polling with a longer interval will not miss events. Note:
> Implementing such an algorithm requires some hidden state in the
> Subscription object that is IMPLEMENTATION DEPENDENT.
>>> Notes
> -----
> The range of values allowed for the "notify-get-interval" attribute (0 to 2^31-1) is different from the "ippget-event-life" attribute (15 to 2^31-1), and implementations have ignored this requirement because it makes no sense. Furthermore, the use of MAY for larger values does not clearly capture the requirement to extend event lives in order to avoid missing notifications.
>> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>> --------------------------------------
> RFC3996 (draft-ietf-ipp-notify-get-10)
> --------------------------------------
> Title : Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications
> Publication Date : March 2005
> Author(s) : R. Herriot, T. Hastings, H. Lewis
> Category : PROPOSED STANDARD
> Source : Internet Printing Protocol
> Area : Applications
> Stream : IETF
> Verifying Party : IESG
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180628/beab5aaf/attachment.html>