IETF Last Call Review of draft-ietf-sipcore-retransmission-allowed-fixes-03
review-ietf-sipcore-retransmission-allowed-fixes-03-artart-lc-duerst-2026-01-12-00

This document is almost ready. But the document raises several more general
questions that should be looked at by the IETF/IESG/...

The document collects errata for six RFCs (RFC4119, RFC5606, RFC5774, RFC6442,
RFC7378, RFC8262), and updates these RFCs. All these errata are about the
contents of a single element in XML described by XML Schema, and about examples
of that element's use: The RFCs use the values "yes" and "no", while XML Schema
only allows true, false, 1, and 0 (see
https://www.w3.org/TR/xmlschema-2/#boolean).The 'retransmission-allowed'
element,

I have not checked that the actual details (all relevant RFCs, and in these,
all relevant occurrences) are correct, sorry. I assume the two authors and
three contributors have done that with stringent diligence. Yet another check
may help.

The first general question is why there was already an Erratum in 2008
(https://www.rfc-editor.org/errata/eid1535) but five more RFCs were published
with the same errors after that. One would assume that the GEOPRIV community
would be small enough to avoid such a thing. According to the draft, things
were fixed in 8 out of 13 documents, but not in another five. Fixing might also
have been helped by a better way of integrating errata into the published RFCs.
Currently, there is https://www.rfc-editor.org/rfc/inline-errata/rfc4119.html,
but it only has second-class status.

The second general question is how to make it easier to check code examples
against syntax restrictions (e.g. schemas, programming language syntax,...),
ideally in an automated way. In XML2RFC, we have ways to label code with types.
For the full examples in the RFCs (e.g. the ones in
https://datatracker.ietf.org/doc/html/rfc4119#section-2.3), that should make
automated checks easy. But it's probably not fine-grained enough for inline
text such as "When the value of this element is 'no",...".

The third general question is how to avoid such problems in general. They seem
to be a manifestation of a general problem described in
https://tess.oconnor.cx/2023/09/polyglots-and-interoperability. In that
article, the problem is more multi-layered, but the essence here is the same:
We have a type of documents described both by XML Schema and by specific text
and examples in the RFCs. Both not making use of mechanisms such as XML Schema
and not using examples in RFCs seem bad ideas. But at least adding a checkpoint
for the authors/editors in the RFC publication process where they have to
confirm that they checked all the examples against the relevant syntax or
schema should be an improvement.

The fourth general question is whether/how much publishing this document as an
RFC will contribute to actually improving the situation. What I mean is that I
e.g. have not found any errata for RFC8262. My expectation would have been that
for all the RFCs involved, errata get submitted first, and then they get
wrapped up in a document such as this. This would give the errata additional
visibility; every little bit of additional visibility may help improve the
situation.

Specific issues:

- XML Schema Datatypes (in particular
https://www.w3.org/TR/xmlschema-2/#boolean) should by cited. Among else, this
will help people go to the source to check things.

- The title needs to be fixed. There are people who are okay with "Errata" as a
singular, but there are others who cringe at this. What is more, the title not
only uses "Errata" as a grammatical singular, it also uses it as a semantic
plural ("Errata" standing for "collection of Errata") at the same time :-(.
It's very easy to fix this: Just drop the initial "A". I also suggest adding a
"the" before 'retransmission-allowed', because "XML Element" is countable and
therefore in the singular needs an article. So the title should read
"Comprehensive Errata for the 'retransmission-allowed' XML Element".

- PIDF-LO should be expanded in the abstract and the introduction.

- The last paragraph before 1.1 starts with "Other than submitting individual
errata". I read this as "In addition to submitting individual errata". But
that's currently not the case. I suggest also submitting errata for all
affected documents, and in that case changing the text to "In addition to
submitting...". If individual errata are not submitted, I suggest changing the
text to "Rather than submitting ...".

- Same paragraph, "to further reinforce". I think "reinforce" is the wrong
word. "confirm" should do. It's very clear that it's an error once you know it;
no reinforcement needed.

- 1.2: I understand that this paragraph is necessary in theory. But I'd argue
that the actual text snippets extracted are small enough to fall under fair
use, so that this section could be dropped.

- 2.2: "\retransmission-allowed>" appears twice, but is nowhere found in RFC
5606. Probably should be "<retransmission-allowed>".

- Why do the last two replacements in section 2.2 suddenly use only very short
extracts where all the changes up to here were done on full paragraphs?

- Section 3: Why make a difference between 'true'/'false' and '0'/'1'? Because
creating implementations can also produce '0'/'1', and so accepting
implementations have to be able to interpret these values, " Implementations
SHOULD use only values 'true' and 'false'." does not increase interoperability
at all. Also, any deviation from what XML Schema says, such as this half-way
restriction of the lexical space, is a bad idea given that some implementations
may be built by using an XML Schema-derived parser.