Subject: RFCs 4660 & 4661 - further issues and errata

From: Alfred Hönes <[email-masked]>
Date: Thu, 9 Nov 2006 18:00:56 +0100 (MEZ)

Hello,
I already have sent to you a short notice about the Reference
issue with the recently published, and closely related, RFCs
4660 and 4661 (SIP Event Notification Filtering) authored by you.

Below you'll find additional comments on issues I found in these
RFCs.  I suspect having identified a significant inconsistency,
presented as item (1) below; item (2) raises a general editorial
issue; the remaining items below are presented in RFC textual
order, ready for incorporation into an RFC Errata Note.

I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  significant issues with filter syntax  ( ABNF in RFC 4661 )

Many of the filter examples in RFC 4661 and RFC 4660 do not conform
with the ABNF presented in Section 5, on page 11, of RFC 4661.
Further, that ABNF allows unexpected, strange instantiations of
'elem-path', and there's at least one significant semantical
ambiguity in the syntax described.

Because I am a bloody XML and XML XPATH layman, I am not in a
position to exactly diagnose what is wrong, and to quickly propose
suitable corrections, in a way that keeps the specification as
close to XPATH as possible.

I just present some of the strange outcomes of strict application
of the RFC 4661 ABNF and a few pointers to examples in the RFC
text that do not conform with that syntax.

a) ambiguous semantics / insufficient syntax

The ABNF production,

   expression = "[" (elem-expr / attr-expr)
                         1*[oper (elem-expr / attr-expr)] "]"
entails

   oper = "and" / "or"

Accordingly, these rules allow to build up expressions containing
multiple terms of the form  '(elem-expr / attr-expr)'  separated
by "and" and/or "or" operators.
There are no operator precedence rules specified, and there's no
possibility to insert parentheses to build sub-expressions / groups
to enforce the desired operator precedence.
Thus, it remains unclear whether, e.g., an expression of the form,
     [ <expr1> or <expr2> and <expr3> ]
means:
     [ <expr1> or ( <expr2> and <expr3> ) ]
(corresponding to commonly used precedence rules),
or:
     [ ( <expr1> or <expr2> ) and <expr3> ]
(corresponding to simple left-to-right operator evaluation).

b)  strange productions (#1)

The ABNF production,

   elem-path = (element / "*") 1*["/" / "*" / element] ["*" / element]

together with:

   element = [ns] string
   ns = string ":"

admits 'elem-path' values of strange and unexpected forms, e.g.,

   ****
   *<ns_string1>:<elem_string1><elem_string2><ns_strind3>:<elem_string3>

without any intervening separator characters.

I am quite sure that this was not intended.

Looking at the 'elem-path' production, it can be observed:
The construction '1*[ ... ]' apparently does not make much
sense; since a group in brackets, '[ ... ]', means "optional",
this construction would be equivalent to the simpler '*( ...)'.
Perhaps, the  '1*[ ... ]' group should look similar to the
'1*( ... )'  group in
   elem-reference =  "/" 1*("/" / "/*" / ("/" element))
including the required "/" in all alternatives.
This also make the final, optional group questionable.

c)  strange productions (#2)

The ABNF productions,
   reference = elem-reference / attr-reference
   attr-reference = reference attribute
together with:
   attribute = "@" [ns] string
   ns = string ":"
admits 'reference' values with multiple attribute references like
   <elem-reference>@<ns1>:<attr1>@<attr2>@<attr3>@<ns4>:<attr4>

I am quite sure that this was not intended.

c)  front end of examples not matching the syntax

Successive substitution of the ABNF productions of RFC 4661 leads
to the following observations:

  *  each 'elem-reference' must start with a double-slash, "//" ;
  *  each 'reference' starts with an 'elem-reference',
     and hence it must start with a double-slash;
  *  each 'selection' starts with a 'reference,
     and hence it must start with a double-slash.

Many examples do not conform to this restriction, starting from
the short examples at the bottom of page 11 up to many of the
detailed XML examples in both RFCs.

d)  back end of examples not matching the syntax

Further observations from the ABNF:
  *  (un-escaped) square brackets, "[" and "]" only appear
     in the 'expression' production, forming the leading and
     the trailing character of it, respectively;
  *  each 'selection' contains at most one 'expression', and
     this 'expression' is the trailing part of the 'selection;
  *  hence, each 'selection' contains at most one matching pair
     of square brackets, and if it does, the "]" must be the
     last character of it.

There are examples given, e.g. in Section 6.1 of RFC 4661,
on top of page 13, and in Section 6.6 of RFC 4661, on page 15,
where this restriction is not adhered to!

Final conclusion:  Apparently, all (or most) examples presented
are expected to be crafted as intended, i.e. with valid syntax.
Hence, the ABNF needs to be substantially reworked to allow
production of these examples, and to really produce exactly what
it should.  Otherwise, implementations based on the ABNF will
drastically fail, will not conform to the intended behaviour,
and will not be interoperable with implementations not based
on the ABNF of RFC 4661.

(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 ([email-masked]) on RLS1 has: [email-masked]

   [email-masked]

Should perhaps better say:

   List1 ([email-masked]) on RLS1 has: [email-masked]
   [email-masked]

or even better:

   List1 ([email-masked]) on RLS1 has:
     [email-masked] [email-masked]

(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:

(10)  punctuation/quoting  (RFC 4661)

In the 1st paragraph of Section 3.6.1, on page 8, RFC 4661 says:

   The <changed> element is used to identify the XML element or
   attribute, from the package-specific XML document, whose value MUST
   change from that of the "previous XML document", in order to activate
|  the trigger and cause the content to be delivered.  Previous XML
   document" in this context refers to the raw version of the most
   recent XML document that was sent to the subscriber, before the
   filters were applied to it.  [...]
                                                      ^^
It should say:

   The <changed> element is used to identify the XML element or
   attribute, from the package-specific XML document, whose value MUST
   change from that of the "previous XML document", in order to activate
|  the trigger and cause the content to be delivered.  "Previous XML
   document" in this context refers to the raw version of the most
   recent XML document that was sent to the subscriber, before the
   filters were applied to it.  [...]

(11)  clarification needed  (RFC 4661)

The example in Section 6.5 of RFC 4661 makes us of an XML namespace
"game-ext".
I strongly suspect that this is a hypothetical namespace; at least,
it currently does not appear in the IANA XML namespace sub-registry.
If this is the case, this fact should have been communicated to the
RFC reader, e.g. by changing the text near the bottom of page 14,

   A user wants to know if a group of his friends is available for
   gaming.  He orders notifications about the current status and future
   changes of the game-specific presence information.

to say more precisely:

   A user wants to know if a group of his friends is available for
   gaming.  He orders notifications about the current status and future
|  changes of the (hypothetical) game-specific presence information.

Please comment.

Item (1) seems to be such severe that correction is needed urgently.
I do not argue whether this can be done by an RFC Errata Note, or an
immediate revision of RFC 4661 is needed.

Perhaps, the items (3)..(11) might be addressed by an Errata Note.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+