The fact that you said below multiple “to me” makes it very obvious that everybody is applying their own set of rules to “updates” and the problem is these don't match. Also again, the draft doesn’t require the use of these tags, however, it requires that if you use them, they need to align with the provided definition. I guess we could also discuss this more in the draft, where it makes sense to use them, e.g. if there is a registry you might no need the tag or give more examples about other kind of known extension points. I will open an issue.
> On 7. Jul 2026, at 10:43, Eliot Lear <[email protected]> wrote: > > Hi Brian, > > On 07.07.2026 08:13, Brian Rosen wrote: >> In my draft, I added a new interface. It’s optional. It doesn’t use anything >> that was previously unused. It’s an entirely new interface that provides >> some useful information the existing interface doesn’t provide. > To me, the question boils down to whether implementation of your draft would > violate the base specification. If it does, then Updates seems appropriate > (at a bare minimum). If it doesn't, then no. If the WG can't answer that > question crisply, then the underlying protocol may indeed have some issues, > requiring an Update (or more), in order to handle its evolution; although I > take your point about the pain of Obsoletes. We're about to go through that > with TEAPv2. > > Michael's use of Amends in 9914 to me is a classic case of Updates, where a > field that was required to be set to zero is now the P flag. Updates needed > (again, at a minimum). > > As to Extends, or more precisely Extended-by, were it implemented, it could > not be in the front matter because protocols like SMTP* and TLS would become > unreadable. I'm still not clear on whether it would add more value or > confusion to the reader. > > Eliot > > * To answer Michael's question, there has only ever been a single MTI on port > 25 since RFC 1123, and that is EHLO, which is the only extension that is > mentioned in 5321bis. > > <OpenPGP_0x87B66B46D9D27A33.asc>-- > rswg mailing list -- [email protected] > To unsubscribe send an email to [email protected]
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
