RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (1)

RFC 4661, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", September 2006

Source of RFC: simple (rai)

Errata ID: 918

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-09

Section 3.6.1 says:

   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:

   "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.

Notes:

missing quotation marks

from pending

Status: Held for Document Update (3)

RFC 4661, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", September 2006

Source of RFC: simple (rai)

Errata ID: 925

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Robert Sparks

 

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.

Notes:

from pending

Errata ID: 31

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Held for Document Update by: Robert Sparks

Section 11.2 says:

   [17]  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:

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

Errata ID: 923

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Robert Sparks

Section 6.5 says:

   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.

It should say:

   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.

Notes:

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 above.

from pending

Report New Errata