RFC Errata
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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