Re: [rfc-i] Next steps for draft-kuehlewind-update-tag

[Larry Masinter <[e-mail]>]

This is a road we've been down before: 
    https://www.w3.org/2001/tag/doc/versioning-html/
https://www.w3.org/2005/05/tr-versions
https://www.w3.org/2001/tag/2011/12/evolution/Overview.html


I think one might have more luck defining relationships between Standards STD n and Versions of them, and BCPs, which contain References to RFCs ( rather than between RFCs newer to older).  While RFC NNNN doesn't change STD MMM and BCP MMM can (and should).  You could experiment with more meta-data-driven relationships.    Probably you would have to define metadata for intent to update a Standard or BCP, especially when a Standard makes use of a RFCbis.




Larry
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: rfc-interest <[e-mail]> On Behalf Of Mark
> Nottingham
> Sent: Friday, August 13, 2021 8:51 PM
> To: Brian E Carpenter <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [rfc-i] Next steps for draft-kuehlewind-update-tag
> 
> That seems reasonable, although I'd think we shouldn't modify rfc-index.xml
> itself during an experiment, since many others are likely to rely upon that
> format.
> 
> Cheers,
> 
> 
> > On 14 Aug 2021, at 1:09 pm, Brian E Carpenter
> <[e-mail]> wrote:
> >
> > On 14-Aug-21 13:17, Mark Nottingham wrote:
> >> Where does "the metadata" live?
> >
> > As far as I can tell, they live in
> > https://www.rfc-editor.org/rfc/rfc-index.xml, and its companion
> > /rfc-index.xsd, with a rendered version in /rfc-index.txt
> >
> > You will see, for example, that <see-also> is already implemented. I think it
> would be ten minutes work to add the other suggestions in draft-
> kuehlewind-update-tag to the schema.
> >
> > I do agree with Robert's argument that we need to experiment, but I
> > don't want to see debris from the experiment in published RFCs. I
> > would suggest doing an experimental enhancement of rfc-index.xml. Try it
> out first on say ten recent RFCs which contain "Updates:".
> >
> > If that seems to work we could experiment with an RFC Metadata section
> > in the final draft, to be deleted by the RFC Editor (like the
> > Implementation Status section).
> > Apart from that, the IESG has been asking for years that drafts
> > explain exactly what they update in earlier RFCs. This isn't really new at all;
> the only new bit would be to clarify whether the update is Amends, Extends
> or occasionally See Also.
> >
> >    Brian
> >
> > P.S. Question to the RFC Editor: Is there a reason that
> > https://www.rfc-editor.org/info/rfc29 does not show "See also: RFC
> > 28"? RFC 29's meta-data include <see-also>
> >   <doc-id>RFC0028</doc-id>
> > </see-also>
> >
> >
> >>
> >> If it's in the XML, it's immutable.
> >>
> >> If it's in the published text and HTML but not in the XML, that
> >> implies
> > that it's collected somewhere else, or it's truly ephemeral.
> >>
> >> Just a thought: Maybe we should consider creating an IANA RFC metadata
> registry?
> >>
> >> Cheers,
> >>
> >>
> >>> On 14 Aug 2021, at 6:58 am, Brian E Carpenter
> <[e-mail]> wrote:
> >>>
> >>> Robert, you say
> >>>
> >>>> Instead of pursuing a change to the published metadata at this
> >>>> time,
> >>>
> >>> It occurs to me that changing the *metadata* for a published RFC,
> >>> and changing it back at the end of an experiment, is not a problem.
> >>> But we can never change the text of a published RFC. It's
> >>> unfortunate that the current "Updates:" is both metadata and
> >>> immutable text. Of course, an "Update Considerations" section (and
> >>> its evil twin "Extension Considerations") would be part of the immutable
> text.
> >>>
> >>> What is wrong with a pure metadata experiment, which is reversible?
> >>> Continue to use immutable "Updates" in the text, but split it into
> >>> two in the metadata?
> >>>
> >>> Regards
> >>>  Brian Carpenter
> >>>
> >>> On 14-Aug-21 02:00, Robert Sparks wrote:
> >>>> I plan to put together a draft on this topic, but will not be able
> >>>> to
> > do
> >>>> so until a couple of weeks from now. This is one of the things I
> >>>> intended to say in that draft:
> >>>>
> >>>> Instead of pursuing a change to the published metadata at this
> >>>> time, I strongly suggest focusing the experiment on whether the
> >>>> desired improvement in clarity can be achieved with prose. For the
> >>>> first experiment, add a "Updates Consideration" near the beginning
> >>>> to any document that might have used the new tags whether it uses
> >>>> the Updates tag or not. Have the IESG ensure there is IETF
> >>>> consensus on what the prose in that section says. If it turns out
> >>>> that the text to put there becomes obvious and is easy to
> >>>> mechanically create, then we know what
> > we
> >>>> need to do with the metadata. If we continue to have long
> >>>> discussions
> >
> >>>> during evaluation about what the section should say, we know we
> >>>> need to
> >>>
> >>>> do something more than pursue this particular classification scheme.
> >>>>
> >>>> I think running that for a year and reporting on what was learned
> >>>> would
> >>>
> >>>> be a great help to this conversation.
> >>>>
> >>>> To be clear, this only addresses one part of the problem that I
> >>>> think
> >
> >>>> really underlies the discomfort you are working to relieve. If your
> >>>> initial reaction is "but nobody's going to see that section",
> >>>> you're feeling one of the other problems. Working this one out first is
> important.
> >>>>
> >>>> RjS
> >>>>
> >>>> On 8/13/21 7:03 AM, Mirja Kuehlewind wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Based on the latest discussion at the gendispatch meeting, I’m
> >>> moving this discussion back to the rfc-interest mailing list (with
> gendispatch in bbc only for this initial information).
> >>>>>
> >>>>> Also based on the discuss at the gendispatch meeting, I opened a
> couple of issues on GitHub:
> >>>>>
> >>>>> #13 Run this as an experiment or propose as BCP?
> >>>>> https://github.com/mirjak/draft-kuehlewind-update-tag/issues/13
> >>>>>
> >>>>> #14 Limit to IETF stream for now?
> >>>>> https://github.com/mirjak/draft-kuehlewind-update-tag/issues/14
> >>>>>
> >>>>> #15 Do we need "see also”?
> >>>>> https://github.com/mirjak/draft-kuehlewind-update-tag/issues/15
> >>>>>
> >>>>> #16 How many tags to use?
> >>>>> https://github.com/mirjak/draft-kuehlewind-update-tag/issues/16
> >>>>>
> >>>>> Please klick on these links to see a bit more description for each
> >>>>> issue. Feel free to comment on GitHub or here by email. If you
> >>>>> reply by email, if possible please reply separately per issue and
> >>>>> adjust the subject
> > line accordingly.
> >>>>>
> >>>>> The impression I got from the meeting, is that many/most people
> >>>>> agree that there is _a_ problem but there is a lot of different
> >>>>> views how to address it (see issue #16 above). I don’t think there
> >>>>> is one best
> > solution at this point and as such this draft is proposing one of them
> > as a way forward.
> >>>>>
> >>>>> However, given there is no clear single path forward I also got
> >>>>> the impression that people would be more happy with starting an
> >>>>> experiment rather than picking one approach and go for BCP right
> >>>>> away. How the experiment might exactly look like needs a bit more
> >>>>> work (see issue #13), however,
> >>> if people think that's the right way forward, I'm happy to work on more
> details.
> >>>>>
> >>>>> If we run this an experiment, I think it actually could be nice to
> >>>>> start it now (and potentially only for the IETF stream; see issue
> >>>>> #14) and
> > then reevaluate as soon as the new RFC editor model and another
> > discussion
> >>> venue for these kind of works is in place.
> >>>>>
> >>>>> Please let us know if you have any thoughts and provide input on
> >>>>> these
> >>> issues by email or on GitHub!
> >>>>>
> >>>>> Mirja
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> rfc-interest mailing list
> >>>>> [e-mail]
> >>>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> >>>>
> >>>> _______________________________________________
> >>>> rfc-interest mailing list
> >>>> [e-mail]
> >>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> >>>>
> >>>
> >>> _______________________________________________
> >>> rfc-interest mailing list
> >>> [e-mail]
> >>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest