Every RFC can have multiple editions. Every edition is immutable.
When you access an RFC you can ask for the original edition or the latest
one,
Yes,, RFCs can retain the property of being immutable, but adding another
edition isn't a mutation.
--
https://LarryMasinter.net https://interlisp.org
On Wed, Jun 18, 2025 at 1:44 PM Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> On 19-Jun-25 05:37, Donald Eastlake wrote:
> > I want to support John Klensin here. I have always thought that the
> > ~immutability~ of RFCs was one of their greatest strengths.
>
> True, but that ceased to be a simple property once we allowed multiple
> presentation formats. From then on, the property split into two:
> immutability of presentation (gone) and immutability of intent (hopefully
> still applicable). What we've been arguing about is how to precisely
> define immutability of intent.
>
> A friendly amendment to:
>
> >> "Once published, RFCs may be reissued, but only syntactic
> >> changes that do not affect the syntax for protocols
> >> themselves may be changed."
>
> is:
>
> "Once published, RFCs may be reissued, but only syntactic or
> superficial changes that do not affect the syntax for protocols
> themselves may be made."
>
> ("Superficial" is often used as a negative term but it is in fact
> exactly what I mean: changes on the visible surface.)
>
> Brian
>
> >
> > Thanks,
> > Donald
> > ===============================
> > Donald E. Eastlake 3rd +1-508-333-2270 (cell)
> > 2386 Panoramic Circle, Apopka, FL 32703 USA
> > d3e...@gmail.com
> >
> > On Wed, Jun 18, 2025 at 9:59 AM John C Klensin <john-i...@jck.com>
> wrote:
> >>
> >> Michael and Brian,
> >>
> >> I was prepared to let this drop, but parts of Michael's note
> >> reinforce my concerns, shows that we are not in agreement either.
> >> So...
> >>
> >> Responding first to Brian's suggestion, then some additional comments
> >> that I hope might be helpful in thinking about the general RFC Editor
> >> Model situation rather than necessarily belonging in any specific
> >> document (and that some may want to just skip).
> >>
> >> --On Wednesday, June 18, 2025 08:25 +1200 Brian E Carpenter
> >> <brian.e.carpen...@gmail.com> wrote:
> >>
> >>> On 18-Jun-25 08:03, Michael Richardson wrote:
> >>>>
> >>>> I share John's apprehension about the words "preserved to the
> >>>> greatest extent possible". There are certainly many failures
> >>>> possible here. I don't share John's slipery slope concern that it
> >>>> leads to "can't trust an RFC"
> >>>
> >>> Nevertheless, I think this whole discussion would go away if we
> >>> simply changed the key sentence to:
> >>>
> >>> "Once published, RFCs may be reissued, but the semantic content of
> >>> publication versions shall be preserved."
> >>
> >> I don't know if it is good enough, but one of Michael's comments
> >> points to a problem that applies even to this. "Semantic content"
> >> is, itself, normally inherently fuzzy and may require subject matter
> >> expertise to evaluate. That immediately leads, as Michael mentioned
> >> and is discussed in more detail below, to delegation of the decision
> >> about what is, or is not, semantic. On that basis, the suggestion
> >> above is far better than anything involving "greatest extent
> >> possible". But Michael's comments suggest to me that he sees a clear
> >> dichotomy between "semantic" and "syntactic". I think that, unlike
> >> "semantic", we have a fairly clear and shared understanding of
> >> "syntactic", one that is free of requirements for subject matter
> >> expertise. If there is agreement about that, then an even better
> >> sentence would be:
> >>
> >> "Once published, RFCs may be reissued, but only syntactic
> >> changes that do not affect the syntax for protocols
> >> themselves may be changed."
> >>
> >> Still not perfect, but at least avoids the subject matter expertise
> >> issues with "semantic".
> >>
> >> TL;DR note: What follows in response to the details of Michael's note
> >> is essentially an explanation of the above and some information that
> >> might be of help more generally with the RSWG/RSAB mission rather
> >> than this particular sentence. Read it or not as you have time and
> >> inclination.
> >>
> >>
> >> --On Tuesday, June 17, 2025 16:03 -0400 Michael Richardson
> >> <mcr+i...@sandelman.ca> wrote:
> >>
> >>>
> >>> I share John's apprehension about the words "preserved to the
> >>> greatest extent possible". There are certainly many failures
> >>> possible here. I don't share John's slipery slope concern that it
> >>> leads to "can't trust an RFC"
> >>>
> >>> I think that the goal here is allow for significant syntactical
> >>> updates to documents. That would include possibly recoding them.
> >>> I'm for that. (Imagine if the world suddenly decided UTF-16 was
> >>> really the right choice. Unlikely, but that's a syntactical change
> >>> with no semantic impact).
> >>
> >> Really? Depends on where the change from (presumably) UTF-8 to
> >> UTF-16 occurred. If it were a matter of re-rendering the text from
> >> of a document to UTF-16 from UTF-8, then clearly no semantic impact.
> >> However, even then, there are tools that work with UTF-8 and not with
> >> UTF-16 (e.g., things that assume that X'00' octets might be
> >> string-ending but are certainly not part of characters) and hence
> >> such a change could have significant impact on readers or systems
> >> trying to parse and/or analyze RFCs. And something that changed a
> >> specification for a protocol from "MUST use UTF-8" to "MUST use
> >> UTF-16" would certainly be a semantic change. We agree that any
> >> such change would be extremely unlikely, but your example illustrates
> >> why "greatest extent" is a problem.
> >>
> >> And I probably should have used different wording than "can't
> >> trust..." but, if the assumption that an old version and a new one
> >> are semantically identical and all we promise is "greatest extent
> >> possible", then there is a potential problem.
> >>
> >>> We can fix the "postal" situation, etc.
> >>> It's also to allow us to fix gramatical, spelling and dumb
> >>> situations where we omitted the word "not" via errata.
> >>> I think that we are generally in agreement as to goals.
> >>
> >> Sure. On the other hand, if the text said "MUST do foo" and the
> >> change is to "MUST NOT do foo", that change may be appropriate as a
> >> correction, but it _is_, without question, a semantic change and, if
> >> such a change is made, it almost certainly needs to be explained in
> >> text (e.g., "this used to say "MUST do", but was wrong because ...
> >> and has been corrected) and I'm not sure that sort of thing is what
> >> people are contemplating.
> >>
> >>> We could go on list things that violate the expectations.
> >>> For instance, a bits-on-the-wire change would not be semantic
> >>> preserving. I don't think it's a good idea.
> >>
> >> See above.
> >>
> >>> Maybe someone can come up with better text than "greatest extent
> >>> possible"
> >>
> >> That was my point; I hope Brian's suggestion meets people's needs.
> >> Or see below.
> >>
> >>> My view is that we should enable the RPC to do the right thing, and
> >>> that we should trust them to:
> >>> 1. know what is semantic and what is syntactic
> >>> 2. know when the situation is unclear to ask the stream manager
> >>> (e.g., IESG) 3. trust the IESG to figure it out, and consult the
> >>> community.
> >>
> >> In a way, my concern is about your #1: I think there are cases --
> >> possibly even some extreme ones illustrated above -- in which drawing
> >> the boundary between semantic and anything else requires substantive
> >> technical knowledge and understanding. The RPC has, to my knowledge,
> >> not claimed that type of expertise since before we invented the "RPC"
> >> terminology. That is different from trusting them to understand when
> >> they encounter a possible edge case and that they need to consult
> >> elsewhere. But then I think there needs to be a clear understanding
> >> (not necessarily with details in the text of this document) that
> >> "consult elsewhere" usually involves stream managers, not just
> >> someone's favorite expert of the day.
> >>
> >>> (Decades ago I heard about the ossification that occurs to
> >>> organizations that make more and more rules to deal with concerns
> >>> like this. They eventually can't do anything. I asked a prominent
> >>> Cdn Sociologist[%], I know about what this is called... best he
> >>> could come up with was "rule based culture", and he mentioned that
> >>> there was extensive literature on this. The origin of this problem
> >>> is lack of interpersonal trust, which fundamentally boils down to
> >>> not drinking enough beer with others. We want to be a value-based
> >>> culture, and that means establishing principles, not proceedures
> >>
> >> I am, for better or worse, fairly familiar with that literature. In
> >> the IETF, the same cultural principles are what led, years ago and
> >> due initially to Spencer Dawkins, to encouragement to "Do the Right
> >> Thing" rather than writing more rules. So, without getting into the
> >> beer-based meta-principle, yes. However, there is often another
> >> force at play than the one you describe. That is the evolution from
> >> (using IETF-like vocabulary) a consensus-based organization to one
> >> that creates more and more staff structure, staffed by people with
> >> different skill sets that are (or are supposed to be) than those of
> >> the original organization and its decision processes. When one then
> >> delegates decisions to those staff teams, either there needs to be a
> >> clear understanding of boundaries, and general trust in that
> >> understanding on both sides, or more and more rules, and rules to
> >> patch problems that develop with earlier rules, become inevitable.
> >> That leads to ossification (and worse) too, but the patterns are
> >> different.
> >>
> >> john
> >>
> >> _______________________________________________
> >> rfc-interest mailing list -- rfc-inter...@rfc-editor.org
> >> To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
> >
> > _______________________________________________
> > rfc-interest mailing list -- rfc-inter...@rfc-editor.org
> > To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
> _______________________________________________
> rfc-interest mailing list -- rfc-inter...@rfc-editor.org
> To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
>
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
