RFC5222 defined an https based protocol. The draft adds an optional parameter and it adds a new interface. It also defines an alternative form of schema. Any implementation of RFC5222 that exists now, or built in the future would be interoperable with any other implementation of that RFC. If any implementation, old or new, is extended with the new optional parameter, it will interoperate with any other implementation.
So you don’t need to know about the new document interoperate with any other implementation, whether that implementation has the new parameter or interface.
I claim that the new document doesn’t Update 5222. But because it adds a new, optional parameter and interface, one of the chairs thinks it does. Depends on how you define “Updates”. It Extends it. It doesn’t Amend it.
Brian
Excellent. A worked
example. Can you say more about dispute and which draft is in
question?
For context, Barry's
rule as I understand it is simple: if a draft requires an
implementation to vary its behavior from a previously issued RFC
using that RFC as a base, then an Updates tag is needed, and an
explanation of why the Updates tag is there must be present in
the front matter.
Examples:
- RFC XYZ defines
flags a, b, and c in the protocol and leaves some reversed
bits for future flags. draft-jones-use-flag-c-this-way
changes the implementation behavior when flag c is seen, then draft-jones-use-flag-c-this-way
must Update RFC XYZ.
- draft-smith-flag-d
adds a new flag d. It too must Update RFC XYZ and say why it
is doing so in the front matter.
- RFC PDQ has a code
point registry. draft-levy-some-new-thing defines a code
point in that registry that requires a new exchange (think
SMTP EHLO tags). The new behavior does NOT require an Updates
header, because the code point is already a signal for new
behavior, and non-compliant implementations simply don't
invoke it.
There are some corner
cases, like when participants in an exchange are not directly
connected (think email headers, for instance), or perhaps
downstream BGP peers? Those cases require some care, regardless
of the tag.
Eliot
On 04.07.2026 11:42, Brian Rosen wrote:
We are VERY inconsistent on Updates. Some,
including me, believe Updates changes something about the
prior work. Others believe that it informs readers that there
is prior relevant work. The example is a simple extension. The
extension adds capability, does not change anything to the
updated RFC. So does the document that describes the function
extension Update or not? I have a draft that presents this
very issue. One chair believes that Updates is needed. I, and
the relevant AD do not. We should not be in this situation.
I think an Extends label is precisely what it needed, and some
label should be used in a draft that makes some actual
change. Amends works for me.
Brian
&TL;DR; the
cure will cause interoperability problems.
I appreciate
the attempt to clarify semantics, but I don't think this
document is a good starting point for the following
reasons:
- Nobody
outside our little lot is going to understand the
differences between extends and amends, so this will
just add confusion to the reader. The scariest
version of this would be use of any two or even three
of these tags.
- If they
actually understand Amends, the result will be
conformance chaos. People claim conformance to and
interoperability with, a specification (e.g., an
RFC). You cannot retroactively determine that they no
longer claim compliance with that spec through some
other spec. Either they do or they don't.
- Amends seems
to invite backward incompatibility and
interoperability failure. With so many decades of
experience, that should be done sparingly and with
great consideration. When it happens, the best
approach is create a new spec and obsolete the old
one.
- Extends
seems to attempt to obviate appropriate use of code
point registries and IANA, inviting sloppy
specifications, knowing that "we can just Extend it
later". If appropriate use of code points is used,
Extends is not needed.
I would not
deny that there are inconsistencies with Updates. Let's
just fix that. In fact, I thought Barry Leiba had
created a best practice for that by saying that when you
Update a specification you have to say how you update it
in the front matter. Are we still so inconsistent in
Updates' use?
Eliot
<OpenPGP_0x87B66B46D9D27A33.asc>
--
rswg mailing list -- [email protected]
To unsubscribe send an email to
[email protected]
<OpenPGP_0x87B66B46D9D27A33.asc> -- rswg mailing list -- [email protected]To unsubscribe send an email to [email protected]
|
