Search RFCs

RFC Editor

Found 4 records.

Status:Verified (1)

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

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

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 conformwith 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 semanticalambiguity in the syntax described.Because I am a bloody XML and XML XPATH layman, I am not in aposition to exactly diagnose what is wrong, and to quickly proposesuitable corrections, in a way that keeps the specification asclose to XPATH as possible.I just present some of the strange outcomes of strict applicationof the RFC 4661 ABNF and a few pointers to examples in the RFCtext that do not conform with that syntax.a) ambiguous semantics / insufficient syntaxThe 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 containingmultiple terms of the form  '(elem-expr / attr-expr)'  separatedby "and" and/or "or" operators.There are no operator precedence rules specified, and there's nopossibility to insert parentheses to build sub-expressions / groupsto 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 muchsense; 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 attributetogether 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 syntaxSuccessive substitution of the ABNF productions of RFC 4661 leadsto 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 fromthe short examples at the bottom of page 11 up to many of thedetailed XML examples in both RFCs.d)  back end of examples not matching the syntaxFurther 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 presentedare expected to be crafted as intended, i.e. with valid syntax.Hence, the ABNF needs to be substantially reworked to allowproduction of these examples, and to really produce exactly whatit should.  Otherwise, implementations based on the ABNF willdrastically fail, will not conform to the intended behaviour,and will not be interoperable with implementations not basedon 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

Report New Errata