Found 2 records.

Status: Verified (1)

RFC 4660, "Functional Description of Event Notification Filtering", September 2006

Note: This RFC has been updated by RFC 6665

Errata ID: 32
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Verifier Name: Cullen Jennings
Date Verified: 2008-11-16

Section 11.1 says:

   [4]  Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
        Initiation Protocol (SIP) Event Notification Extension for
        Resource Lists", RFC 4663, September 2006.

It should say:

   [4]  Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
        Initiation Protocol (SIP) Event Notification Extension for
        Resource Lists", RFC 4662, August 2006.

Status: Held for Document Update (1)

RFC 4660, "Functional Description of Event Notification Filtering", September 2006

Note: This RFC has been updated by RFC 6665

Errata ID: 921
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Held for Document Update by: Robert Sparks

(1) [[posted separately.]]

(2)  general issue: presentation/formatting of XML text

Although it carries no functional relevance, uniform formatting
and consistent indentation of XML text significantly adds to
the readability and furthers the understanding of the structure.
Unfortunately, there are many places in the two RFCs where --
perhaps as a result of the use of various tools in the publication
process -- non-uniform and inconsistent indentation in XML text
impedes the readability of the XML schemata and the XML examples.

At a minimum, pairing opening and closing XML tags, if on different
lines, should be indented by the same amount of white space,
and XML elements on the same hierarchical level (within another
XML element) should be indented equally.

For brevity of this message, I omit detailing the numerous places
affected I have marked in my printed copies of the two RFCs.


(3)  repeated word replications and grammar  (RFC 4660)

The second paragraph of Section 3.3.1 of RFC 4660, at the bottom
of page 3, says:

   A SUBSCRIBE request destined to a list URI [4] MAY include multiple
   filters specific to individual resources.  This is achieved by
   including multiple <filter> elements with different URIs of resources
|  in each of those elements.  This resource specific resource-specific
|  filter are processed first before any list specific list-specific
|  filter, if any.  The list specific list-specific filter may or may
   not include a URI.

It should perhaps say:

   A SUBSCRIBE request destined to a list URI [4] MAY include multiple
   filters specific to individual resources.  This is achieved by
   including multiple <filter> elements with different URIs of resources
|  in each of those elements.  This resource-specific filter is
|  processed first, before any list-specific filter, if any.  The
|  list-specific filter may or may not include a URI.


(4)  distorting extra blank line   (RFC4660)

The example scenario description in Section 4.1 of RFC 4660,
on top of page 8, are made less comprehensible by the additional
blank line in between:

   List1 (list1@example.com) on RLS1 has: bob@example.com

   list2@biloxi.com

Should perhaps better say:

   List1 (list1@example.com) on RLS1 has: bob@example.com
   list2@biloxi.com

or even better:

   List1 (list1@example.com) on RLS1 has:
     bob@example.com list2@biloxi.com


(5)  inappropriate Section headlines   (RFC4660)

The ToC and the body of RFC 4660 (on page 9) contains the Section
headlines:

 5.  Server Operation

 5.1.  NOTIFY Bodies

should better say:

 5.  Notifier Operation

 5.1   SUBSCRIBE Bodies

Rationale:

Obviously, these titles are inappropriate.

a) The document deals with two kinds of 'server' roles:
     *  Resource List Server (RLS),  and
     *  SIP servers in the Notifier role
   Since Section 4 deals with RLS behaviour (and does tell so
   in its headline), and Section 5 deals with Notifier behaviour,
   the latter should tell so as well, and not pretend to be
   applicable to server operation in general.

b) NOTIFY bodies/content are dealt with in Section 5.3 ff.
   As can be seen immediately, Section 5.1 talks about
   SUBSCRIBE bodies.


(6)  typo/grammar  (RFC 4660)

Within Section 5.2.1, at the bottom of page 10, RFC 4660 says:

                                 [...].  Notifiers belonging to the
|  domain MUST apply the filter to all notifications it sends for that
   subscription, unless policy dictates otherwise.
                                                     ^^^^^^^^
It should say:

                                 [...].  Notifiers belonging to the
|  domain MUST apply the filter to all notifications they send for that
   subscription, unless policy dictates otherwise.
                                                     ^^^^^^^^^


(7)  placement of text ??   (RFC 4660)

The first paragraph of Section 5.3, on page 11,

   Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD
   retain the filter as long as the subscription persists.  The filter
   MAY be incorporated within an existing subscription (in an active
   dialog) by sending a re-SUBSCRIBE that includes the filter in the
   body.

apparently should have been moved up to the end of Section 5.2
because it is related to behaviour during
   "Notifier Processing of SUBSCRIBE Requests" == Section 5.2


(8)  improper use of articles  (RFC 4660)

There are two related issues with text in the 2nd and 3rd paragraph
of Section 5.3, on mid-page 11:

   If the response sent to the SUBSCRIBE was a "202" and the "202" was
|  chosen because the filter could not be accepted that time, the NOTIFY
   MAY be used to terminate the subscription if the filter is found
   unacceptable.

|  As described in [3], the NOTIFY message MAY contain a body that
   describes the state of the resource.  This body is in one of the
   formats listed in the Accept header field of the SUBSCRIBE, or in the
   package-specific default if the Accept header field is omitted.

The first occurrence of "the NOTIFY" is improper because this is the
first place the text talks about a NOTIFY message in this context.
The definite article should either be omitted entirely, or better
be replaced by "a NOTIFY message".
The second "the NOTIFY" is improper because it (re-)states a general
property of all NOTIFY messages, not of a specific NOTIFY message.
Therefore, the above text should say:

   If the response sent to the SUBSCRIBE was a "202" and the "202" was
|  chosen because the filter could not be accepted that time, a NOTIFY
   maeeage MAY be used to terminate the subscription if the filter is
   found unacceptable.

|  As described in [3], a NOTIFY message MAY contain a body that
   describes the state of the resource.  This body is in one of the
   formats listed in the Accept header field of the SUBSCRIBE, or in the
   package-specific default if the Accept header field is omitted.


(9)  missing articles  (RFC 4660)

Within Section 7.1.3, near the top of page 20, where RFC 4660 says:

   Notification containing both tuples is sent to the subscriber in this
   case:

it should better say:

|  A Notification containing both tuples is sent to the subscriber in
   this case:

and within Section 7.2.3, in the upper half of page 26, where the RFC
says:

   Notification to the subscriber is created, taking into account the
   <trigger> and <what> elements:

it should better say:

|  A Notification to the subscriber is created, taking into account the
   <trigger> and <what> elements:

Notes:

from pending

Report New Errata